An Eﬃcient and Provably Secure Certiﬁcateless Blind Signature Scheme for Flying Ad-Hoc Network Based on Multi-Access Edge Computing

: Unmanned aerial vehicles (UAVs), when interconnected in a multi-hop ad-hoc fashion, or as a ﬂying ad-hoc network (FANET), can eﬃciently accomplish mission-critical tasks. However, UAVs usually suﬀer from the issues of shorter lifespan and limited computational resources. Therefore, the existing security approaches, being fragile, are not capable of countering the a(cid:308)acks, whether known or unknown. Such a security lapse can result in a debilitated FANET system. In order to cope up with such a(cid:308)acks, various eﬃcient signature schemes have been proposed. Unfortunately, none of the solutions work eﬀectively because of incurred computational and communication costs. We aimed to resolve such issues by proposing a blind signature scheme in a certiﬁcateless se(cid:308)ing. The scheme does not require public-key certiﬁcates, nor does it suﬀer from the key escrow problem. Moreover, the data that are aggregated from the platform that monitors the UAVs might be too huge to be processed by the same UAVs engaged in the monitoring task. Due to being latency-sensitive, it demands high computational capability. Luckily, the envisioned ﬁfth generation (5G) mobile communication introduces multi-access edge computing (MEC) in its architecture. MEC, when incorporated in a UAV environment, in our proposed model, divides the workload between UAVs and the on-board microcomputer. Thus, our proposed model extends FANET to the 5G mobile network and enables a secure communication between UAVs and the base station (BS).

(1) A command center initiates command and computes the corresponding digital signature.
(2) The corresponding command and signature are then forwarded to the UAV by the command center. (3) The UAV, upon receiving the command and signature, a empts to verify the signature.

•
If the signature is valid, the UAV deems it to be issued by the command center and proceeds with executing the command. • Otherwise, the command is considered counterfeit and, thus, the UAV does not execute it.
However, due to its intrinsic complexities and security requirements, the mutual digital signature scheme is not appropriate for an UAV-based network. Additionally, the average speed of a typical UAV can lie in the range of 30-460 km/h in a three-dimensional (3D) se ing [5]. Moreover, the topology of the particular network varies rapidly, which necessitates the need of ascertaining the validity of a command in the shortest time. Therefore, it is essential for the UAV to validate the signature in a timely manner, especially for location-based services. For example, the user or ground station (GS) pledges a command and the corresponding signature to the UAV; however, the concerned UAV can only verify the signature. Even in the worst case, if an intruder eavesdropped on the command and corresponding signature, they cannot authenticate the signature and authorize the task to be accomplished next. In addition, frequent changes in topology also increase the latency and communication cost. In order to accommodate the key escrow problem, a certificateless signature scheme is required. In a certificateless cryptosystem, a participant private key is composed of two parts: the partial private key and a secret value. The trusted third-party key generation center (KGC) generates the partial private key, whereas the secret value is affirmed by the participant. Similarly, a participant's public key also consists of two parts, these being the participant's identity information and the public key conforming to the secret value. Therefore, the cost of public key management is significantly reduced due to the fact that the public key does not require any certificate. Furthermore, it does not suffer from the key escrow problem because the KGC has no information about the participant secret value.
Typically, small UAVs have ba eries that last for merely 20 to 30 min [6]. Therefore, it is of utmost importance to manage the ba ery resources efficiently. This prolongs the network lifetime especially for large-scale deployments of UAVs. Thus, it is harder for the UAVs to complete these resource-hungry applications in a timely fashion. Furthermore, FANET can be deployed in remote • We introduce a novel architecture for flying ad-hoc network (FANET) constituted by UAVs with a multi-access edge computing (MEC) facility that leverages the 5G wireless technology.

•
We propose an efficient and provably secure certificateless signature (CL-BS) scheme for the same architecture using the concept of hyperelliptic curve for operating in resource-constrained environments.

•
The proposed scheme is shown to be resistant against various a acks through formal as well as informal security analysis using the widely-accepted automated validation for internet security validation and application (AVISPA) tool.

•
The proposed scheme is also compared with existing counterparts and it is shown that our approach provides be er efficiency in terms of computational and communication costs.

Structure of the Paper
The remainder of the paper is structured as follows: Section 2 contains a brief about the related work; Section 3 presents the foundational concepts; Section 4 presents the proposed architecture and construction of proposed scheme (i.e., CL-BS); Section 5 holds implementation of the proposed scheme in FANET; Section 6 outlines the AVISPA tool component of our proposed scheme for formal security verification as well as informal security analysis; Section 7 compares the proposed scheme with the existing schemes; and in the end, Section 8 succinctly culminates the manuscript by concluding the work.

Flying Ad-Hoc Network
In flying ad-hoc network, the security and privacy are important because UAVs are always una ended. The primary security mechanisms for FANET emphasize authenticity, confidentiality and integrity of data via cryptography. A well-designed data protection mechanism can significantly reduce the probability of the data becoming compromised, irrespective of the malicious technique involved. There are a few studies dedicated to investigating the data protection issues for UAV networks. Won et al. [16], proposed a suite of cryptographic protocols for drones and smart objects. The protocols deal with three communication scenarios: one to-one, one-to-many, and many-to-one. In the first scenario, that is, one-to-one, the efficient encapsulation mechanism, a certificateless signcryption tag key, backs the authenticated key agreement in addition to offering non-repudiation and user revocation. The one-to-many scenario involves a certificateless multi-recipient encryption scheme, which allows a UAV to transmit privacy-intensive data to multiple smart objects. Lastly, UAVs are able to collect data from multiple smart objects in the "many-to-one" communication scenario. The protocol, however, finds it difficult to transmit a multitude of encrypted messages and at the same time assure privacy of the end devices. Such novel cryptographic mechanisms are efficient and secure. However, they are supposed to be used in group communication where nodes are of equal computational capability. A novel approach to mitigate the broadcast storm problem during the interest's dissemination is proposed by Barka et al. [17]. The approach is based on a trust-aware monitoring communication architecture for flying named data networking. It makes use of the inter-UAV communication for checking the data authenticity on a particular UAV without disturbing the desired level of security. However, data privacy and caching policies are not taken into consideration in the proposed scheme.
In order to resist the physical capturing of drones with minimum exposure of confidential data, Bae et al. [18] proposed a saveless-based key management and delegation system for a multi-drone environment. Nevertheless, the proposed scheme is not compatible with devices such as UAVs equipped with limited on-board energy that hinder the potency of finding a proper key renewal period with low computation cost and more security guarantee. Seo et al. [19] proposed a pairing-free approach for drone-based surveillance applications. However, this approach faces the user revocation problem in the case of a physical a ack. In such a case, the intruders can access not only current but future information of the drones. In order to cater the forward secrecy problem in drones, Liu et al. [20] proposed two construction schemes that achieve be er performance in terms of the computational cost required by the recipient. However, the approach uses the elliptic curves and, thus, it suffers from high computational cost. Moreover, the proposed scheme is not validated through Electronics 2020, 9, 30 5 of 22 formal security analysis. In 2018, Reddy et al. [21] presented a pairing-free key insulated signature scheme in the identity-based se ing for improving the computational and communication efficiency. Later, in 2019, Xiong et al. [22] also proposed a pairing-free and provably secure certificateless parallel key-insulated signature (CL-PKIS) scheme in order to secure the communication in the IIoT se ing. However, because the scheme involves the concept of elliptic curve, it is not free from the issue of high computational cost. Moreover, the proposed schemes are not validated through formal security analysis.

Multi-Access Edge Computing
It is mandatory for a FANET system to diminish latency to the maximum possible extent. MEC can solve the problem of latency resulting from long communication distance. So far, studies have been conducted to examine the usage of edge computing for UAVs [23][24][25]. However, the studies do not discuss the topic of communication link quality. ETSI proposed a reference architecture of MEC [26]. Primarily, the MEC reference architecture is composed of user equipment, mobile edge applications, and networks. The network is classified into either of the following three levels: system level, host level, and network level. The reference points and functional elements of the reference architecture are depicted by the reference architecture. Garg et al. aimed to answer the surveillance-related concerns by proposing a data-driven transportation optimization model [27]. The model comprises UAV, dispatcher, aggregator, and edge devices. Each of the constituents undertake the designated tasks as follows: the UAV captures and validates the date; the dispatcher, in addition to validating the tasks, schedules the processing tasks in the edge computing devices; the aggregator assures a secure transmission of data; and the edge devices analyze the data. A hierarchical MEC architecture has been proposed by Lee et al. [28]. It involves utilizing the resources of the MEC server for providing services customized on the basis of content type and the computing demand. After exploring the major causes of communication and computational latencies, Intharawijitr et al. proposed a mathematical model. The model is used to estimate the computing latency in an edge node selected on the basis of either of the three policies [29]. A game theoretic model is proposed by Messous et al. in which the UAVs, as game players, strategize to achieve the optimal tradeoff between energy overhead and the execution delay. As a result, the UAVs do not stay overburdened anymore [30]. Ansari et al. addressed the issue of end-to-end delay between the proxy virtual machine and the device. They claim to resolve the problem by suggesting two dynamic proxy virtual machine migration methods, which is corroborated by simulation results [31]. Zhang et al. a empted to resolve the issue of increased energy consumption and longer execution time by proposing a mobility-aware hierarchical MEC framework [32]. The proposed solution involves the MEC servers and, for sharing the computing tasks, a backup computing server. An incentive-based optimal computational offloading scheme was developed. The objective of quick-response and energy conservation was achieved to a significant extent.
The methodology proposed by Christian et al. [33] increases the system reliability and reduces the end-to-end source-actuator latency. Their work intends to broaden the 5G network edge by making the FANET UAVs fly close to the monitoring layer. The UAVs are accoutered with MEC facilities while carrying out the processing tasks and they follow a policy for mutual help for improved performance. However, the work fails to address the issue of limited ba ery duration of MEC UAVs.

Hyperelliptic Curve Cryptosystems (HECC)
Hyperelliptic curves can be viewed as generalizations of ECC (elliptic curve cryptosystems), introduced by Kobli [50]. A hyperelliptic curve [51] is denoted over curves, whose genus is greater than 1, as shown in Figure 1. Similarly, the curves with genus 1 are generally known as elliptic curves. The group order of the field F q for genus 1, 160 bit long operands are required, that is, we need at least g.log 2 (q) ≈ 2 160 , where g is the genus of curve over F q that is a set of finite fields of order q. Likewise, for curves with genus 2, 80 bit long operands, and, for curves with genus 3, 54 bit long operands are needed [52].
A hyper elliptic curve C of genus greater than 1 over F is a set of solutions (x, y) ∈ F × F to the following equation: A divisor D is a finite formal sum of points on hyper elliptic curve and represented as The two divisors can be added as follows: Each element of the Jacobian can be represented in the semi-reduced divisor form [53]: If the divisor is subjected to the additional constraint, that is, r ≤ g, such a divisor is defined as a reduced divisor. Additionally, in [50], the author shows that the divisors of the Jacobian can be denoted as a pair of polynomials a(x) and b(x) with following degrees: ( ) ≤ deg ( ) ≤ , where the coefficients of a(x) and b(x) are elements of F and a(x) divided by 2 + ℎ( ) − ( ).
Electronics 2020, 9, x FOR PEER REVIEW 7 of 22 Each element of the Jacobian can be represented in the semi-reduced divisor form [53]: If the divisor is subjected to the additional constraint, that is, r ≤ g, such a divisor is defined as a reduced divisor. Additionally, in [50], the author shows that the divisors of the Jacobian can be denoted as a pair of polynomials a(x) and b(x) with following degrees: deg , where the coefficients of a(x) and b(x) are elements of F and a(x) divided by + ℎ .

Threat Model
The widely used Dolev-Yao (DY) threat model [54] is used in the proposed scheme. According to the DY model, an insecure public channel (open channel) is used for communication between any two parties and the end-point entities have an untrustworthy nature. Therefore, the system is prone to eavesdropping of exchanged messages and deletion/modification attempts by the attacker. Moreover, as the UAVs may roam around in unattended hostile areas, there exists the probability of them getting physically captured. This may lead to leakage of precious data from a UAV's memory. The KGC, on the other hand, is a fully trusted entity.

Proposed Architecture
The proposed architecture of flying ad-hoc network based on multi-access edge computing is illustrated in Figure 2. The application scenario considered is the surveillance of a specific area, which may collect data, that is, video streaming and images. We consider two representative classes of UAVs: monitoring UAV (M-UAV) and raspberry pi-based multi-access edge computing UAV (RMEC-UAV). M-UAV perform data acquisition and monitoring only from the assigned zone. In our proposed architecture, the set of M-UAVs are assigned to one RMEC-UAV that is used to reduce the power consumption while executing the security mechanism (i.e., sign, verify). The set of M-UAVs allocated to RMEC-UAV is essentially subjected to the load produced by M-UAV. RMEC-UAV collects data from M-UAVs and forwards this to the base station. RMEC-UAV can also connect with the IoT devices and collect data from them. Prior to transmitting, the RMEC-UAV validates the authenticity of the M-UAVs. Upon successful validation, the RMEC-UAV forwards the data to the

Threat Model
The widely used Dolev-Yao (DY) threat model [54] is used in the proposed scheme. According to the DY model, an insecure public channel (open channel) is used for communication between any two parties and the end-point entities have an untrustworthy nature. Therefore, the system is prone to eavesdropping of exchanged messages and deletion/modification a empts by the a acker. Moreover, as the UAVs may roam around in una ended hostile areas, there exists the probability of them ge ing physically captured. This may lead to leakage of precious data from a UAV's memory. The KGC, on the other hand, is a fully trusted entity.

Proposed Architecture
The proposed architecture of flying ad-hoc network based on multi-access edge computing is illustrated in Figure 2. The application scenario considered is the surveillance of a specific area, which may collect data, that is, video streaming and images. We consider two representative classes of UAVs: monitoring UAV (M-UAV) and raspberry pi-based multi-access edge computing UAV (RMEC-UAV). M-UAV perform data acquisition and monitoring only from the assigned zone. In our proposed architecture, the set of M-UAVs are assigned to one RMEC-UAV that is used to reduce the Electronics 2020, 9, 30 8 of 22 power consumption while executing the security mechanism (i.e., sign, verify). The set of M-UAVs allocated to RMEC-UAV is essentially subjected to the load produced by M-UAV. RMEC-UAV collects data from M-UAVs and forwards this to the base station. RMEC-UAV can also connect with the IoT devices and collect data from them. Prior to transmi ing, the RMEC-UAV validates the authenticity of the M-UAVs. Upon successful validation, the RMEC-UAV forwards the data to the BS. The RMEC-UAV transmits not only the IoT data but also the flight information and the information about the role of each M-UAV.
being equipped with the essential gadgets, these being cameras, IMU, sensors, and a GPS unit, among others, can be accustomed to different application scenarios.
The proposed architecture can be divided into the following three main layers: • Layer 1 consists of the ground-level IoT devices that are devoted to different tasks as per application scenario. The ground-level IoT devices are connected with the RMEC-UAV and BS via URLLC, a 5G wireless link. Furthermore, the macro base station (MBS) are typically linked with the core network via wires that have huge bandwidth. • Layer 2 comprises a team of M-UAVs equipped with the essential gadgets, these being cameras, IMU, sensors, and a GPS unit, among others, for monitoring the assigned zone. Moreover, M-UAVs are connected with each other using Bluetooth 5 (2.4 GHz) link and with the RMEC-UAV with 802.11 ac (5 GHz) Wi-Fi link. • Layer 3 is composed of RMEC-UAV that is used to collect data from M-UAVs and forwards it to the base station. RMEC-UAV can also connect with the ground-level IoT devices and collect data from them.  Raspberry PI (RPI) board was considered for RMEC-UAV. Even though there are other substitutions for RPI, with sophisticated hardware configurations, such as La ePanda 4G/64 GB, Qualcomm Dragon board, ODROID-XU4, and ASUS Tinker Board, among others, RPI is nonetheless considered to be the most cost-effective and energy-efficient option. Other alluring features of RPI 4 that further defend its selection are the built-in wireless networking support, that is, Wi-Fi (dual-band 802.11 b/g/n/ac) and Bluetooth 5.0 BLE. RPI 4 is equipped with a 1.5 GHz 64-bit quad core ARM Cortex-A72 processor. The 5G and 802.11 ac wireless modules are enabled on RMEC-UAV in order to link it with the BS/IoT devices and hence provide a hotspot service over the M-UAVs. Fifth generation (5G) is further classified into enhanced mobile broadband (eMBB), massive machine-type communications (mMTC), and ultra-reliable low latency communications (URLLC) by the International Telecommunication Union (ITU) in order to fulfill the requirements of diverse industrial and market demands. However, we have considered URLLC in the proposed architecture, as of it offers very high mobility, which further defends its selection for UAV-based operations [55].
The images transmi ed by the monitoring UAVs, ground cameras, and the sensors, among other sources, are all received by the RMEC-UAV on-board microcontroller. The microcontroller, then, generates the tasks that will be processed by the local microcomputer, or the decision support engine (DSE). The human operator receives a decreased share of the data flow so as to decide quickly. In case the human decisions are not timely, the predictive and interpolative/extrapolative modules mounted on the RMEC-UAV DSE step in. The probability of response-delays resulting from the queues of to-be-processed jobs can never be ignored. To compensate for such time lapse and to enhance reliability, the RMEC-UAVs synergize with each other. Further, each of the M-UAVs, after being equipped with the essential gadgets, these being cameras, IMU, sensors, and a GPS unit, among others, can be accustomed to different application scenarios.
The proposed architecture can be divided into the following three main layers: • Layer 1 consists of the ground-level IoT devices that are devoted to different tasks as per application scenario. The ground-level IoT devices are connected with the RMEC-UAV and BS via URLLC, a 5G wireless link. Furthermore, the macro base station (MBS) are typically linked with the core network via wires that have huge bandwidth. • Layer 2 comprises a team of M-UAVs equipped with the essential gadgets, these being cameras, IMU, sensors, and a GPS unit, among others, for monitoring the assigned zone. Moreover, M-UAVs are connected with each other using Bluetooth 5 (2.4 GHz) link and with the RMEC-UAV with 802.11 ac (5 GHz) Wi-Fi link. • Layer 3 is composed of RMEC-UAV that is used to collect data from M-UAVs and forwards it to the base station. RMEC-UAV can also connect with the ground-level IoT devices and collect data from them.

Construction of the Proposed Scheme
The proposed scheme includes the following four entities: KGC, blind signer, requester, and verifier. Further, it involves the following six sub-algorithms for producing the certificateless blind signature: setup, partial private key se ing (PPKS), secret value se ing (SVS), private key se ing (PKS), public key se ing (PBKS), blind signature, and verification.In Table 1, we provide an explanation about the notations used in the proposed algorithm. Therefore, for representing the whole process of certificateless blind signature, we aimed to provide the simplest explanation by using the following steps:
After the above process, the KGC determines the master public key using

Construction of the Proposed Scheme
The proposed scheme includes the following four en verifier. Further, it involves the following six sub-algorithm signature: setup, partial private key setting (PPKS), secret (PKS), public key setting (PBKS), blind signature, and explanation about the notations used in the proposed alg whole process of certificateless blind signature, we aimed using the following steps:  Identities for sender and receiver 12 Plain-text (message)

Construction of the Proposed Scheme
The proposed scheme includes the following four entities: KGC, blind signer, requester verifier. Further, it involves the following six sub-algorithms for producing the certificateless signature: setup, partial private key setting (PPKS), secret value setting (SVS), private key s (PKS), public key setting (PBKS), blind signature, and verification. In Table 1, we provid explanation about the notations used in the proposed algorithm. Therefore, for representin whole process of certificateless blind signature, we aimed to provide the simplest explanati using the following steps: 1. Setup: In this sub-algorithm, the KGC selects the following parameters: , n = 2 80 }.

2.
Partial private key se ing (PPKS): In order to set the partial private key for the participating users (verifier and signer) with identity , the KGC performs the following sub-steps: • It selects u from {1, 2, ..., n − 1}; • It computes u = u . and u = u + . u ; • It computes u = u . ; • It sends ( u , u ) to the users (verifier and signer) with identity .
The users can verify the pair ( u , u ) such as: u . = u + u .  Private key of signer 10 Ns A fresh nonce that is used for anti-r 11 Identities for sender and rec 12 Plain-text (message)

Construction of the Proposed Scheme
The proposed scheme includes the following four entities: KGC, blind verifier. Further, it involves the following six sub-algorithms for producing th signature: setup, partial private key setting (PPKS), secret value setting (SVS (PKS), public key setting (PBKS), blind signature, and verification. In Tab  Identities for sen 12 Plain-text

Construction of the Proposed Scheme
The proposed scheme includes the following four entities: K verifier. Further, it involves the following six sub-algorithms for p signature: setup, partial private key setting (PPKS), secret value s (PKS), public key setting (PBKS), blind signature, and verifica = . + u ( . ) = ( + u . ) = ( u ) = u . .

4.
Private key se ing (PKS): The user (verifier and signer) set the private key as u = < u , u >.
The user sets his/her public key as ℬ u = < , u >.
• Blind signature: In this part, the blind signer first selects from {1, 2, … , n − 1}, computes Δ 1 = / s , Δ 2 = s / , and then sends it (Δ 1 , Δ 2 ) to the requester. Further, the requester proceeds as follows: • It selects ( , ) from {1, 2, … , n − 1}; • It computes ℰ = 1 C generalized form elliptic curve requiring 80 bit key 3 A divisor, which is a finite formal sum of points on hyperelliptic curve 4 ∂ Master secret key which is generated by KGC for producing partial private key 5 The master public key of KGC 6 N Randomly generated number and the size of N as n = 2 80 7 One-way hash function, which means that it has the property of irreversibility Private key of requester Private key of signer 10 Ns A fresh nonce that is used for anti-replay attack 11 Identities for sender and receiver 12 Plain-text (message)

Construction of the Proposed Scheme
The proposed scheme includes the following four entities: KGC, blind signer, requester, and verifier. Further, it involves the following six sub-algorithms for producing the certificateless blind signature: setup, partial private key setting (PPKS), secret value setting (SVS), private key setting (PKS), public key setting (PBKS), blind signature, and verification. In Table 1, we provide an explanation about the notations used in the proposed algorithm. Therefore, for representing the whole process of certificateless blind signature, we aimed to provide the simplest explanation by using the following steps: 1. Setup: In this sub-algorithm, the KGC selects the following parameters: The hash function (h); • Select ∂ from {1, 2, …, n − 1} and the size of n = 2 80 .
After the above process, the KGC determines the master public key using = ∂. . Then, it publishes the set of selected parameters, {C, , , n = 2 80 }.
2. Partial private key setting (PPKS): In order to set the partial private key for the participating users (verifier and signer) with identity , the KGC performs the following sub-steps: • It selects u from {1, 2, ..., n − 1}; • It computes u = u. and u = u + ∂. u; • It computes u = u. ; • It sends ( u, u) to the users (verifier and signer) with identity .

Secret value setting (SVS):
The user (verifier and signer) with identity selects u from {1, 2, ..., n − 1} and keeps it as his secret value.

6.
Verification: The verifier can verify the blind signature if either of the following equalities are satisfied: * = ( , Ns) = = ( , Ns) or * = . The master public key of KGC 6 N Randomly generated number and the size of N as n = 2 80 7 One-way hash function, which means that it has the property of irreversibility Private key of requester Private key of signer 10 Ns A fresh nonce that is used for anti-replay attack 11 Identities for sender and receiver 12 Plain-text (message)

Construction of the Proposed Scheme
The proposed scheme includes the following four entities: KGC, blind signer, requester, and verifier. Further, it involves the following six sub-algorithms for producing the certificateless blind signature: setup, partial private key setting (PPKS), secret value setting (SVS), private key setting (PKS), public key setting (PBKS), blind signature, and verification. In Table 1, we provide an explanation about the notations used in the proposed algorithm. Therefore, for representing the whole process of certificateless blind signature, we aimed to provide the simplest explanation by using the following steps: 1. Setup: In this sub-algorithm, the KGC selects the following parameters: The hash function (h); • Select ∂ from {1, 2, …, n − 1} and the size of n = 2 80 .
After the above process, the KGC determines the master public key using = ∂. . Then, it publishes the set of selected parameters, {C, , , n = 2 80 }.
2. Partial private key setting (PPKS): In order to set the partial private key for the participating users (verifier and signer) with identity , the KGC performs the following sub-steps:  Plain-text (message)

Construction of the Proposed Scheme
The proposed scheme includes the following four entities: KGC, blind signer, requester, and verifier. Further, it involves the following six sub-algorithms for producing the certificateless blind signature: setup, partial private key setting (PPKS), secret value setting (SVS), private key setting (PKS), public key setting (PBKS), blind signature, and verification. In Table 1, we provide an explanation about the notations used in the proposed algorithm. Therefore, for representing the whole process of certificateless blind signature, we aimed to provide the simplest explanation by using the following steps: 1. Setup: In this sub-algorithm, the KGC selects the following parameters:

Implementation of Proposed Scheme in FANET
We divided this process in two sub-phases that are (1) initialization and registration, and (2) signing and verifying Phase, which are illustrated in Figures 3 and 4, respectively.

Initialization and Registration
In this sub algorithm, the KGC selects a hyper elliptic curve (C), a divisor ( ), the hash function (   Plain-text (message) tion of the Proposed Scheme proposed scheme includes the following four entities: KGC, blind signer, requester, and Further, it involves the following six sub-algorithms for producing the certificateless blind e: setup, partial private key setting (PPKS), secret value setting (SVS), private key setting ublic key setting (PBKS), blind signature, and verification. In Table 1, we provide an tion about the notations used in the proposed algorithm. Therefore, for representing the rocess of certificateless blind signature, we aimed to provide the simplest explanation by e following steps: up: In this sub-algorithm, the KGC selects the following parameters: ), and then computes from {1, 2, … , n − 1} and the size of n = 2 80 .
After the above process, the KGC determines the master public key using

Construction of the Proposed Scheme
The proposed scheme includes the following four en verifier. Further, it involves the following six sub-algorithm signature: setup, partial private key setting (PPKS), secret (PKS), public key setting (PBKS), blind signature, and explanation about the notations used in the proposed alg whole process of certificateless blind signature, we aimed using the following steps:  Identities for sender and receiver 12 Plain-text (message)

Construction of the Proposed Scheme
The proposed scheme includes the following four entities: KGC, blind signer, requester verifier. Further, it involves the following six sub-algorithms for producing the certificateless signature: setup, partial private key setting (PPKS), secret value setting (SVS), private key s (PKS), public key setting (PBKS), blind signature, and verification. In Table 1, we provid explanation about the notations used in the proposed algorithm. Therefore, for representin whole process of certificateless blind signature, we aimed to provide the simplest explanati using the following steps: , n = 2 80 }.

Partial Private Key Generation for RMEC-UAV:
In order to set the partial private key for RMEC-UAV with identity rv , the KGC performs the following sub steps: i. It selects rv from {1, 2, … , n − 1}; ii.
The RMEC-UAV can verify the pair ( rv , rv ), such as rv . = rv + rv .  Identities for sen 12 Plain-text

Construction of the Proposed Scheme
The proposed scheme includes the following four entities: K verifier. Further, it involves the following six sub-algorithms for p signature: setup, partial private key setting (PPKS), secret value s (PKS), public key setting (PBKS), blind signature, and verificat explanation about the notations used in the proposed algorithm whole process of certificateless blind signature, we aimed to prov using the following steps: 1. Setup: In this sub-algorithm, the KGC selects the following pa

Construction of the Proposed Scheme
The proposed scheme includes the following fo verifier. Further, it involves the following six sub-alg signature: setup, partial private key setting (PPKS), (PKS), public key setting (PBKS), blind signature, explanation about the notations used in the propos whole process of certificateless blind signature, we a using the following steps: • It computes u = u. and u = u + ∂. u; • It computes u = u. ; • It sends ( u, u) to the users (verifier and sign The users can verify the pair ( u, u) such as: u. u. ∂) = ( u) = u. .

Construction of the Proposed Scheme
The proposed scheme includes the following four entities: KGC, blind signer, requester, and verifier. Further, it involves the following six sub-algorithms for producing the certificateless blind . rv and sends it to the M-UAV; • The M-UAV, then, generates the hash value as = ( , Ns) and full blind signature, using ** = * − , and transfers it ( ** , ) to the BS/IoT.

Security Analysis
This section aims to justify the effectiveness of the proposed scheme in resisting well-known a acks. function. Thus, keeping in view the aforesaid discussion, our scheme is far more secure against breaking the integrity of plain text.

Theorem 1←Unlinkability
A certificateless blind signature is presumed to offer security from the linkability attack if the blind signer has no access to the plain text.
Proof. In our designed scheme, first of all, the requester selects two blind factors ( , ), then performs calculations to find out the value of hash, using = 1( , Δ1, Δ2, r), and , using = + . Further, the requester sends to the blind signer. In case the signer wants to see the plain text, it is mandatory for him/her to recover from , where = 1( , Δ1, Δ2, r). This, however, is not feasible because of the one-way nature of the hash function. After this, the signer also needs the blind factor , which is only known to the requester. Thus, the aforementioned discussion clearly justifies that the scheme, decently, fulfills the security property of unlinkability.

Theorem 1←Replay Attack
In the proposed scheme, the adversary may not give responses to old messages.
Proof. The scheme is resilient against replay attack by offering renewal of nonce Ns. In case an attacker intrudes the message of one session, he/she may not intrude the messages of other sessions with the same Ns because the Ns is renewed at every instance. The receiver is required to perform an up-to-date check with every message and, in the case of an outdatedness being detected in the message, that particular message is trashed into the black box.

Formal Security Analysis using Analysis
In this subsection, results produced from the simulation work using AVISPA tool are presented [56]. This is done, primarily, to ascertain the potency of the proposed scheme against replay and manin-the-middle attacks. AVISPA is a push-button tool for providing an expressive and modular formal language to simulate protocols and their security properties. SPAN (specific protocol animator for AVISPA) [57], the protocol of security animator for AVISPA, is designed to assist protocol developers write high level protocol specification language (HLPSL) specifications [58]. The HLPSL specifications are interpreted into an intermediate format (IF) by the HLPSLIF translator. Then, it is transformed to the output format (OF) with either on-the-fly model-checker (OFMC) [59], CL-based Unforgeability A certificateless blind signature is obviously assumed to provide security from a forgeability a ack if there is no malicious a acker, ℳ , which produces the forge blind signature.
Proof. In our case, if an ℳ desires the generation of the forge blind signature, then he/she must compute Equation (5). Here, it is the need of *, and can be calculated from Equation (6); however, processing this equation, is the need for the calculation of s from Equation (7) is further needed, which is equal to the processing of the hyper elliptic curve discrete logarithm problem. Also, it is a need for s from Equation (8), which further requires an equivalent process for the hyper elliptic curve discrete logarithm problem. Thus, the aforementioned assumption proves that an ℳ cannot generate the forge blind signature. ** = * − , function. Thus, keeping in view the aforesaid discussion, our scheme is far more secure against breaking the integrity of plain text.

Theorem 1←Unlinkability
A certificateless blind signature is presumed to offer security from the linkability attack if the blind signer has no access to the plain text.
Proof. In our designed scheme, first of all, the requester selects two blind factors ( , ), then performs calculations to find out the value of hash, using = 1( , Δ1, Δ2, r), and , using = + . Further, the requester sends to the blind signer. In case the signer wants to see the plain text, it is mandatory for him/her to recover from , where = 1( , Δ1, Δ2, r). This, however, is not feasible because of the one-way nature of the hash function. After this, the signer also needs the blind factor , which is only known to the requester. Thus, the aforementioned discussion clearly justifies that the scheme, decently, fulfills the security property of unlinkability.

Integrity
A certificateless blind signature is supposed to secure from integrity a ack if there is no malicious a acker, ℳ , which becomes modified in the plain text.
Proof. In our proposed work, the requester produces the hash value of a plain text as =  Private key of sig 10 Ns A fresh nonce that is used for a 11 Identities for sender and 12 Plain-text (messa

Construction of the Proposed Scheme
The proposed scheme includes the following four entities: KGC, bl verifier. Further, it involves the following six sub-algorithms for produci signature: setup, partial private key setting (PPKS), secret value setting (PKS), public key setting (PBKS), blind signature, and verification. In explanation about the notations used in the proposed algorithm. There whole process of certificateless blind signature, we aimed to provide th using the following steps: 1. Setup: In this sub-algorithm, the KGC selects the following paramete

Construction of the Proposed Scheme
The proposed scheme includes the following fo verifier. Further, it involves the following six sub-alg signature: setup, partial private key setting (PPKS), s (PKS), public key setting (PBKS), blind signature, explanation about the notations used in the propose whole process of certificateless blind signature, we a using the following steps:

(
→ , Ns). Therefore, the ℳ cannot perform this process because of the one-way nature of the hash function. Thus, keeping in view the aforesaid discussion, our scheme is far more secure against breaking the integrity of plain text. □

Theorem 1
Electronics 2020, 9, x FOR PEER REVIEW 13 of 23 function. Thus, keeping in view the aforesaid discussion, our scheme is far more secure against breaking the integrity of plain text.

Theorem 1←Unlinkability
A certificateless blind signature is presumed to offer security from the linkability attack if the blind signer has no access to the plain text.
Proof. In our designed scheme, first of all, the requester selects two blind factors ( , ), then performs calculations to find out the value of hash, using = 1( , Δ1, Δ2, r), and , using = + . Further, the requester sends to the blind signer. In case the signer wants to see the plain text, it is mandatory for him/her to recover from , where = 1( , Δ1, Δ2, r). This, however, is not feasible because of the one-way nature of the hash function. After this, the signer also needs the blind factor , which is only known to the requester. Thus, the aforementioned discussion clearly justifies that the scheme, decently, fulfills the security property of unlinkability.

Theorem 1←Replay Attack
In the proposed scheme, the adversary may not give responses to old messages.
Proof. The scheme is resilient against replay attack by offering renewal of nonce Ns. In case an attacker intrudes the message of one session, he/she may not intrude the messages of other sessions with the same Ns because the Ns is renewed at every instance. The receiver is required to perform an up-to-date check with every message and, in the case of an outdatedness being detected in the message, that particular message is trashed into the black box.

Formal Security Analysis using Analysis
In this subsection, results produced from the simulation work using AVISPA tool are presented [56]. This is done, primarily, to ascertain the potency of the proposed scheme against replay and manin-the-middle attacks. AVISPA is a push-button tool for providing an expressive and modular formal language to simulate protocols and their security properties. SPAN (specific protocol animator for AVISPA) [57], the protocol of security animator for AVISPA, is designed to assist protocol developers write high level protocol specification language (HLPSL) specifications [58]. The HLPSL specifications are interpreted into an intermediate format (IF) by the HLPSLIF translator. Then, it is transformed to the output format (OF) with either on-the-fly model-checker (OFMC) [59], CL-based attack searcher (AtSe) [60], SAT-based model-checker (SATMC), or tree automata-based protocol analyzer (TA4SP). These embedded tools examine the security claims of the aforementioned IF code of an algorithm for two types of attack-replay and man-in-the-middle attacks. The IF code works under two validation states: SAFE, if the cryptographic scheme can safeguard the man-in-the-middle attack, and UNSAFE, in cases where the IF code does not provide protection against man-in-themiddle attack. Formal security verification using the AVISPA tool can be found in several studies to determine the security of many authentication protocols against replay along with man-in-themiddle attacks [61][62][63][64][65][66]. The basic structure of the AVISPA tool is revealed in Figure 5.

Unlinkability
A certificateless blind signature is presumed to offer security from the linkability a ack if the blind signer has no access to the plain text.
Proof. In our designed scheme, first of all, the requester selects two blind factors ( , ), then performs calculations to find out the value of hash, using = Electronics 2020, 9, x FOR PEER REVIEW vehicle, M-UAV: monitoring UAV, IoT: Internet of Things, URLLC: ultra-reliable low laten communications, KGC: key generation center. Identities for sender and receiver 12 Plain-text (message)

Construction of the Proposed Scheme
The proposed scheme includes the following four entities: KGC, blind signer, request verifier. Further, it involves the following six sub-algorithms for producing the certificateles signature: setup, partial private key setting (PPKS), secret value setting (SVS), private key (PKS), public key setting (PBKS), blind signature, and verification. In Table 1, we prov explanation about the notations used in the proposed algorithm. Therefore, for represent whole process of certificateless blind signature, we aimed to provide the simplest explana using the following steps: • It computes u = u. and u = u + ∂. u; • It computes u = u. ; • It sends ( u, u) to the users (verifier and signer) with identity .

Secret value setting (SVS):
The user (verifier and signer) with identity selects u fro ..., n − 1} and keeps it as his secret value. 1 ( , Δ 1, Δ 2 , r ), and , using = + . Further, the requester sends to the blind signer. In case the signer wants to see the plain text, it is mandatory for him/her to recover from , where = Electronics 2020, 9, x FOR PEER REVIEW 9 of 23 vehicle, M-UAV: monitoring UAV, IoT: Internet of Things, URLLC: ultra-reliable low latency communications, KGC: key generation center. Table 1. Notations used in proposed algorithm.

C
Means hyperelliptic curve with genus 2, which is the generalized form elliptic curve requiring 80 bit key 3 A divisor, which is a finite formal sum of points on hyperelliptic curve 4 ∂ Master secret key which is generated by KGC for producing partial private key 5 The master public key of KGC 6 N Randomly generated number and the size of N as One-way hash function, which means that it has the property of irreversibility Private key of requester 9 s = < s, s> Private key of signer 10 Ns A fresh nonce that is used for anti-replay attack 11 Identities for sender and receiver 12 Plain-text (message)

Construction of the Proposed Scheme
The proposed scheme includes the following four entities: KGC, blind signer, requester, and verifier. Further, it involves the following six sub-algorithms for producing the certificateless blind signature: setup, partial private key setting (PPKS), secret value setting (SVS), private key setting (PKS), public key setting (PBKS), blind signature, and verification. In Table 1, we provide an explanation about the notations used in the proposed algorithm. Therefore, for representing the whole process of certificateless blind signature, we aimed to provide the simplest explanation by using the following steps: 1. Setup: In this sub-algorithm, the KGC selects the following parameters: • It computes u = u. and u = u + ∂. u; • It computes u = u. ; • It sends ( u, u) to the users (verifier and signer) with identity .

Secret value setting (SVS):
The user (verifier and signer) with identity selects u from {1, 2, ..., n − 1} and keeps it as his secret value. 1 ( , Δ 1, Δ 2 , r ). This, however, is not feasible because of the one-way nature of the hash function. After this, the signer also needs the blind factor , which is only known to the requester. Thus, the aforementioned discussion clearly justifies that the scheme, decently, fulfills the security property of unlinkability. □

Theorem 1
Electronics 2020, 9, x FOR PEER REVIEW 13 of 23 function. Thus, keeping in view the aforesaid discussion, our scheme is far more secure against breaking the integrity of plain text.

Theorem 1←Unlinkability
A certificateless blind signature is presumed to offer security from the linkability attack if the blind signer has no access to the plain text.
Proof. In our designed scheme, first of all, the requester selects two blind factors ( , ), then performs calculations to find out the value of hash, using = 1( , Δ1, Δ2, r), and , using = + . Further, the requester sends to the blind signer. In case the signer wants to see the plain text, it is mandatory for him/her to recover from , where = 1( , Δ1, Δ2, r). This, however, is not feasible because of the one-way nature of the hash function. After this, the signer also needs the blind factor , which is only known to the requester. Thus, the aforementioned discussion clearly justifies that the scheme, decently, fulfills the security property of unlinkability.

Theorem 1←Replay Attack
In the proposed scheme, the adversary may not give responses to old messages.
Proof. The scheme is resilient against replay attack by offering renewal of nonce Ns. In case an attacker intrudes the message of one session, he/she may not intrude the messages of other sessions with the same Ns because the Ns is renewed at every instance. The receiver is required to perform an up-to-date check with every message and, in the case of an outdatedness being detected in the message, that particular message is trashed into the black box.

Formal Security Analysis using Analysis
In this subsection, results produced from the simulation work using AVISPA tool are presented [56]. This is done, primarily, to ascertain the potency of the proposed scheme against replay and manin-the-middle attacks. AVISPA is a push-button tool for providing an expressive and modular formal language to simulate protocols and their security properties. SPAN (specific protocol animator for AVISPA) [57], the protocol of security animator for AVISPA, is designed to assist protocol developers write high level protocol specification language (HLPSL) specifications [58]. The HLPSL specifications are interpreted into an intermediate format (IF) by the HLPSLIF translator. Then, it is transformed to the output format (OF) with either on-the-fly model-checker (OFMC) [59], CL-based attack searcher (AtSe) [60], SAT-based model-checker (SATMC), or tree automata-based protocol analyzer (TA4SP). These embedded tools examine the security claims of the aforementioned IF code of an algorithm for two types of attack-replay and man-in-the-middle attacks. The IF code works under two validation states: SAFE, if the cryptographic scheme can safeguard the man-in-the-middle attack, and UNSAFE, in cases where the IF code does not provide protection against man-in-themiddle attack. Formal security verification using the AVISPA tool can be found in several studies to determine the security of many authentication protocols against replay along with man-in-the-

Replay A ack
In the proposed scheme, the adversary may not give responses to old messages.
Proof. The scheme is resilient against replay a ack by offering renewal of nonce Ns. In case an a acker intrudes the message of one session, he/she may not intrude the messages of other sessions with the same Ns because the Ns is renewed at every instance. The receiver is required to perform an up-to-date check with every message and, in the case of an outdatedness being detected in the message, that particular message is trashed into the black box. □

Formal Security Analysis Using Analysis
In this subsection, results produced from the simulation work using AVISPA tool are presented [56]. This is done, primarily, to ascertain the potency of the proposed scheme against replay and man-in-the-middle a acks. AVISPA is a push-bu on tool for providing an expressive and modular formal language to simulate protocols and their security properties. SPAN (specific protocol animator for AVISPA) [57], the protocol of security animator for AVISPA, is designed to assist protocol developers write high level protocol specification language (HLPSL) specifications [58]. The HLPSL specifications are interpreted into an intermediate format (IF) by the HLPSLIF translator. Then, it is transformed to the output format (OF) with either on-the-fly model-checker (OFMC) [59], CL-based a ack searcher (AtSe) [60], SAT-based model-checker (SATMC), or tree automata-based protocol analyzer (TA4SP). These embedded tools examine the security claims of the aforementioned IF code of an algorithm for two types of a ack-replay and man-in-the-middle a acks. The IF code works under two validation states: SAFE, if the cryptographic scheme can safeguard the man-in-the-middle a ack, and UNSAFE, in cases where the IF code does not provide protection against man-in-the-middle a ack. Formal security verification using the AVISPA tool can be found in several studies to determine the security of many authentication protocols against replay along with man-in-the-middle a acks [61][62][63][64][65][66]. The basic structure of the AVISPA tool is revealed in Figure 5.
of an algorithm for two types of attack-replay and man-in-the-middle attacks. The IF code works under two validation states: SAFE, if the cryptographic scheme can safeguard the man-in-the-middle attack, and UNSAFE, in cases where the IF code does not provide protection against man-in-themiddle attack. Formal security verification using the AVISPA tool can be found in several studies to determine the security of many authentication protocols against replay along with man-in-themiddle attacks [61][62][63][64][65][66]. The basic structure of the AVISPA tool is revealed in Figure 5.

Performance Comparison
This section compares the performance of the proposed scheme with the existing counterparts suggested by Lei et al. [4], Islam et al. [47], Nayak et al. [48], and Chen et al. [49].

Computational Cost
In Table 2, the proposed scheme is compared, in terms of computational cost, with the existing ones, that is, Lei et al.'s scheme [4], Islam et al.'s scheme [47], Nayak et al.'s scheme [48], and Chen et al.'s scheme [49], hereinafter also referred to as the "four chosen schemes", on the basis of major operations. We considered hyperelliptic divisor multiplication as elliptic curve scalar multiplication,

Performance Comparison
This section compares the performance of the proposed scheme with the existing counterparts suggested by Lei et al. [4], Islam et al. [47], Nayak et al. [48], and Chen et al. [49].

Computational Cost
In Table 2, the proposed scheme is compared, in terms of computational cost, with the existing ones, that is, Lei et al.'s scheme [4], Islam et al.'s scheme [47], Nayak et al.'s scheme [48], and Chen et al.'s scheme [49], hereinafter also referred to as the "four chosen schemes", on the basis of major operations. We considered hyperelliptic divisor multiplication as elliptic curve scalar multiplication, and bilinear pairings are the most expensive operations used in the relevant existing schemes. The variables  Identities for sender and receiver 12 Plain-text (message)

Construction of the Proposed Scheme
The proposed scheme includes the following four entities: KGC, blind signer, requester, and verifier. Further, it involves the following six sub-algorithms for producing the certificateless blind signature: setup, partial private key setting (PPKS), secret value setting (SVS), private key setting (PKS), public key setting (PBKS), blind signature, and verification. In Table 1, we provide an explanation about the notations used in the proposed algorithm. Therefore, for representing the whole process of certificateless blind signature, we aimed to provide the simplest explanation by using the following steps: 1. Setup: In this sub-algorithm, the KGC selects the following parameters: • A hyper elliptic curve (C); The hash function (h); • Select ∂ from {1, 2, …, n − 1} and the size of n = 2 80 .
After the above process, the KGC determines the master public key using = ∂. . Then, it publishes the set of selected parameters, {C, , , n = 2 80 }.
, e , , and denote the hyperelliptic curve divisor multiplication, elliptic curve scalar multiplication, bilinear pairing, and modular exponential, respectively. It has been observed that a single scalar multiplication takes 0.97 ms for elliptic curve point multiplication (ECPM), 14.90 ms for bilinear pairing, and 1.25 ms for modular exponential [15]. The Multi-Precision Integer and Rational Arithmetic C Library (MIRACL) [68] was used to test the runtime of the basic cryptographic operations up to 1000 times to measure the performance of the proposed approach. The phenomenon was observed on a workstation having following specifications: Intel Core i7-4510U CPU @ 2.0 GHz, 8 GB RAM and Windows 7 Home Basic 64-bit Operating System [19]. Similarly, the hyperelliptic curve divisor multiplication (HCDM) was assumed to be 0.48 ms due to the smaller key size-80 bit key size [69]. Identities for sender and receiver 12 Plain-text (message)  Identities for 12

Construction of the Proposed Scheme
Plain-t

Construction of the Proposed Scheme
The computational costs provided in Table 3 and illustrated in Figure 6 clearly show that our proposed scheme, when compared with the "four chosen schemes" outperforms in terms of computational cost. The presented scheme is quicker than the existing ones by the following degrees: Lei et al. [4]
The reduction in communication cost of our proposed CL-BS scheme compared with the existing ones as provided in

Communication Cost
In this subsection, the proposed scheme is compared, in terms of communication cost, with the existing ones, these being Lei et al.'s scheme [4]

Communication Cost
In this subsection, the proposed scheme is compared, in terms of communication  [49] is | | + |H| + | |, and for our proposed scheme is | n| + |H| + | |.
The reduction in communication cost of our proposed CL-BS scheme compared with the existing ones as provided in
The reduction in communication cost of our proposed CL-BS scheme compared with the existing ones as provided in   [48], et al.'s scheme [49]. For the comparison, we supposed that, | | = 1024 bits, | | = 160 bits, its, |H| = 512 bits, | | = 1024 bits, and | | = 1024 bits [72]. According to our suppositions, nication cost for Lei et al.'s scheme [4] is 4| | + 2| | + |H| + | |, for Islam et al.'s ] is 2| | + | |, for Nayak et al.'s scheme [48] is 2| | + | |, for Chen et al.'s scheme + |H| + | |, and for our proposed scheme is | n| + |H| + | |. duction in communication cost of our proposed CL-BS scheme compared with the existing ovided in  Table 4 presents a brief comparison between the proposed scheme and relevant existing schemes in terms of security functionality. It is worth noting, from Table 4, that the related schemes are not validated through formal security validation tools, such as AVISPA, and none of them guarantee replay attack (RA) and integrity (I). Our proposed scheme is shown to be resistant against various attacks through formal analysis using the widely-accepted automated validation for internet security validation and application (AVISPA) tool as shown in Appendix A.

Conclusions
In this article, we proposed an efficient and provably secure certificateless signature scheme, CL-BS, based on multi-access edge computing (MEC) for a FANET environment using the concept of hyperelliptic curve. The proposed scheme was shown to be resistant against various attacks through informal security analysis, as well as through the formal security verification using the widelyaccepted AVISPA tool. The scheme was also efficient in terms of computational and communication costs. On doing a comparative analysis with existing counterparts, it was noticed that the proposed scheme was characterized by least computational and communication costs, these being 0.48 ms and 1616 bits, respectively, which authenticates the superiority of our scheme.  Table 4 presents a brief comparison between the proposed scheme and relevant existing schemes in terms of security functionality. It is worth noting, from Table 4, that the related schemes are not validated through formal security validation tools, such as AVISPA, and none of them guarantee replay a ack (RA) and integrity (I). Our proposed scheme is shown to be resistant against various a acks through formal analysis using the widely-accepted automated validation for internet security validation and application (AVISPA) tool as shown in Appendix A.