## 1 Introduction  
During the last couple of years, the exponential advancement in the manufacturing of small unmanned aerial vehicles (UAVs) has led to a new clan of networks, referred to as flying ad-hoc network (FANET). The prominent features of agility, low-cost, and easy deployment, among others, are paving ways for FANET to offer successful solutions for diverse military and civilian application. In case of a disastrous situation, FANET can offer a cost-effective solution for real-time data communication as compared to its predecessors, these being, mobile ad-hoc networks (MANETs) and vehicular ad-hoc networks (VANETs) [1]. Not only does FANET have the capability of collecting and sharing the aggregated data amongst the UAVs, it can also send it to the base station (BS). Additionally,if some of the UAVs are detached during the mission, irrespective of any reason, they still have the facility to remain associated to the network with the support of other UAVs due to an ad-hoc network between the UAVs. Furthermore, the inherent multi-hop networking schema counters the obstacles of short-range communication and limited guidance that normally arise in a stand-alone UAV system [2]. Nevertheless, such exclusive attributes make FANET a suitable solution for various applications. The small UAVs have restricted capabilities in terms of power, sensing, communication, and computation. This renders the small UAVs as luring targets to different kinds of known and unknown cyber-attacks. Generally, in a FANET environment, multiple UAVs are integrated into a team that cooperates with each other to accomplish critical tasks [3]. Hence, when a self-governing UAV desires to perform a certain task, it receives the command containing relevant task-specific information such as time, target location, and actions, among others. Then, it either flies autonomously to the target position in the assigned time, or it may cruise in the air while waiting for commands, thus reducing the response time and accomplishing the results proficiently. The ground station interconnects with UAVs over an unauthenticated and unencrypted channel. Therefore, anyone with a suitable transmitter can link with the UAV and insert commands into an ongoing session, and thus can easily interpret any UAV. Thus, it is important for a UAV to ascertain the origination of a command. Normally, digital signatures are used to ascertain the source of command. [PERSON] et al. [4] described the overall process as follows:  
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, attempts 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) setting [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.