## 3 Preliminaries
### Threat Model  
We adopt a comprehensive adversary model based on the Dolev-Yao (DY) model [26], extended with considerations relevant to the IoD and biometric systems, similar to threat models discussed in [2; 5; 24; 27]. The adversary (\(\mathcal{A}\)) is assumed to have the following capabilities:  
* **Full control over public communication channels**: \(\mathcal{A}\) can eavesdrop on, intercept, delete, modify, inject, and replay any messages transmitted over insecure wireless links (e.g., \(D_{i}\)-GCS, and potentially OD-\(D_{i}\) if the local link is not perfectly secured).
* **Impersonation attempts**: \(\mathcal{A}\) can try to impersonate any legitimate entity (\(U_{O}\), OD, \(D_{i}\), GCS) by replaying old messages or attempting to construct valid-looking new messages using any information gathered.
* **Malicious node participation**: \(\mathcal{A}\) can be a registered but compromised entity (e.g., a captured drone whose limited credentials might be extracted, or a compromised OD). The TA is assumed to be incorruptible.
* **Drone capture and physical attacks**: Drones are vulnerable to physical capture, especially if operating in unattended or hostile environments. Upon capture, \(\mathcal{A}\) may perform physical attacks, side-channel attacks, or power analysis to extract any sensitive data stored on the drone's hardware [5; 6; 7]. The protocol design aims to minimize the impact of such a compromise by limiting the sensitive data stored directly on the drone for operator authentication.
* **Operator device attacks**: While the OD is trusted by the operator, it can be subject to attacks if it relies on traditional password/PIN entry as a fallback or secondary factor (e.g., keylogging, shoulder surfing) [8]. The use of biometrics as the primary factor mitigates this, and mechanisms like [PERSON]'s SVOSK [8] can further protect any manual input on the OD. Stolen ODs are a threat if biometric authentication can be bypassed or stored encrypted secrets are weak.
* **Server-side database attacks (GCS/TA verification data)**: \(\mathcal{A}\) might attempt to compromise the GCS or TA databases to obtain stored verification data (e.g., \(RPMD_{IDO}\), \(Salt_{1}\), \(LLT_{O}\)). The protocol should ensure that such a breach does not directly reveal primary secrets like \(P_{ID_{O}}\) or the operator's biometric template [19].  
Figure 1: Bio-2 FA-IoD—new process framework diagram: System and network model. This figure illustrates the key entities: operator (\(U_{O}\)), operator’s device (OD), drone (\(D_{i}\)), ground control station (GCS), and trusted authority (TA). It depicts the primary communication links and overall process flow, serving as an initial roadmap for the protocol’s architecture and inter-entity relationships.  
* **Biometric system attacks**: \(\mathcal{A}\) may attempt to spoof the biometric sensor on the OD with a fake biometric sample (presentation attack) or attack the fuzzy extractor mechanism (e.g., by analyzing helper data \(HD_{O}\)). The inherent security of the biometric sensor (e.g., liveness detection) and the properties of the fuzzy extractor are critical assumptions.  
The TA is assumed secure. The GCS, while a critical component, is designed such that a compromise of its stored verification data does not lead to an immediate compromise of the operator's primary secrets (\(P_{ID_{O}}\), \(K_{\hat{g}O}\)). The cryptographic primitives (hash functions, symmetric encryption) are assumed to be computationally secure, meaning an adversary cannot break their fundamental security properties (e.g., find hash collisions, decrypt ciphertexts without the key) within a polynomial time frame.