## 3 Preliminaries
### System and Network Model for IoD  
The Internet of Drones (IoD) paradigm typically involves a network of unmanned aerial vehicles (UAVs) interacting with various ground entities to perform tasks such as surveillance, data collection, and delivery [3; 6; 7; 24]. The specific architecture for our Bio-2 FA-IoD protocol includes the following key entities (visualized in Figure 1):  
* **Operator** (\(U_{O}\)): The legitimate human user who initiates control commands or data requests for a drone. The operator's identity is primarily verified through biometric means.
* **Operator's device (OD)**: A trusted personal device (e.g., smartphone, dedicated handheld controller, tablet) belonging to the operator. It is equipped with, or can interface with, a biometric sensor. The OD is responsible for capturing biometric data, performing initial processing (e.g., feature extraction, fuzzy key generation), securely storing operator-specific credentials derived during registration, and executing the client-side authentication logic. This device is analogous to the smartphone in Khedr's visual authentication protocol [8].
* **Drone** (\(D_{i}\)): The unmanned aerial vehicle. In the context of operator authentication to the GCS, the drone (\(D_{i}\)) primarily functions as a mobile platform that facilitates communication between the OD and the GCS. While drones possess their own identities and security mechanisms for flight control and drone-to-drone communication (which are outside the scope of this specific operator authentication protocol), their role here is to securely forward authentication messages between the OD and the GCS. Drones typically operate within specific flight zones and are managed by a GCS [2]. Drone technology integrates various components like communication modules (e.g., for FANETs [1; 25]), sensors, and actuators, making them versatile but also complex systems to secure.
* **Ground control station (GCS)**: A server entity, often part of a larger ground infrastructure or cloud backend. The GCS is responsible for receiving authentication requests from operators (via OD/drone), verifying operator credentials, managing drone operations, and logging relevant activities. It is analogous to the \"Server\" in [PERSON]'s protocol [8] and the \"Control Server (CS)\" or \"Ground Station Server (GSS)\" in other IoD studies [2; 7; 13]. The GCS is assumed to have significantly more computational and storage resources than drones or ODs. It often connects to a data processing center.
* **Trusted authority (TA)**: A fully trusted, offline or highly secured entity responsible for the initial system setup and registration of all legitimate participants: operators (and their biometric data), ODs (by issuing initial secrets during operator registration), and GCSs. The TA manages master keys, identities, and ensures the integrity of the registration process [2; 24]. It does not participate in every authentication session but establishes the root of trust.  
Communication pathways are as follows: The \(U_{O}\) interacts directly with the OD for biometric input. The OD communicates with the \(D_{i}\), typically over a short-range wireless link (e.g., Bluetooth Low Energy, local Wi-Fi). This link must be secured, or its exposure minimized, as it is a crucial step in relaying authentication data. The \(D_{i}\) then communicates with the GCS over potentially long-range and insecure public wireless channels (e.g., cellular networks like 5G [7], dedicated IoD frequencies). The TA interacts with entities primarily during the offline registration phase through secure channels. Figure 1 provides a visual representation of these entities and their interactions, serving as an initial roadmap for the protocol's architecture and inter-entity relationships.