## 3 Preliminaries
### Security Requirements for Bio-2 FA-IoD  
The proposed Bio-2 FA-IoD protocol is designed to meet the following critical security and functional requirements essential for a robust IoD authentication system. These requirements are drawn from a consensus in the existing IoD security literature [1; 2; 3; 4; 5; 6; 7; 11]:  
* **Mutual authentication**: All communicating IoD entities (e.g., operator via OD, and GCS) must verify each other's identity before any sensitive payload exchanges or command execution can occur. This is a fundamental requirement to prevent unauthorized access and ensure that all parties are legitimate. * **Keylogging and shoulder-surfing resistance**: The protocol should protect operator credentials (like passwords or PINs, if used as a secondary factor to biometrics) from being captured by keyloggers on potentially compromised GCS terminals or observed by nearby attackers during input on the operator's device (OD) [8]. * **Replay attack resistance**: Old authentication messages intercepted by an adversary must not be successfully replayed to gain unauthorized access or disrupt operations. This is often achieved using fresh nonces or timestamps [1]. * **Impersonation attack resistance**: An adversary should not be able to successfully impersonate a legitimate operator, OD, drone, or GCS. This includes user impersonation, drone impersonation, and GSS/server impersonation [2]. * **Drone capture resilience**: Given that drones may be deployed in unattended or hostile locations, they are susceptible to physical capture. The compromise of a single drone (and any secrets stored on it) should not compromise the operator's long-term credentials, the security of other drones, or past/future session keys for other entities. Protocols should be designed to minimize sensitive data stored on the drone or ensure such data is heavily protected [5; 6]. * **Session key agreement and security**: Upon successful mutual authentication, the communicating parties (OD and GCS) should agree upon a secure session key (\(KS\) in our context, primarily used for OTAC) to encrypt critical parts of their authentication exchange. This key must be protected from disclosure and should be unique to each session. * **Confidentiality**: Sensitive data exchanged during the authentication process (e.g., \(PIN\), \(RP_{ID_{O}}\)) and subsequent communications (if applicable) must be kept confidential from eavesdroppers. * **Integrity**: The protocol must provide means to ensure that messages exchanged between entities are not tampered with or altered by an adversary during transit. * **Anonymity and untraceability**: Ideally, the real identities and locations of IoD entities (especially users and drones) should remain unknown to adversaries even if they can eavesdrop on exchanged messages. Attackers should not be able to trace or link communication sessions to specific users or drones over time [2; 6]. * **Forward and backward secrecy**:
* forward secrecy (PFS): Compromise of long-term secret keys (e.g., \(P_{ID_{O}}\) or \(K_{\beta O}\)) should not compromise the confidentiality of past session keys (\(KS\)). * backward secrecy (PBS): Compromise of long-term secret keys should not compromise the confidentiality of future session keys derived after the compromise. The LAPEC protocol [22], for example, specifically aims for backward secrecy. * **Resistance** to specific IoD attacks: The protocol should withstand attacks common to wireless and drone environments, such as man-in-the-middle (MitM) attacks, denial of service (DoS) attacks at the protocol level, privileged insider attacks [1; 8], stolen verifier attacks [19], ephemeral secret leakage (ESL) attacks, and physical/side-channel attacks. * **Efficiency** (lightweight design): Given the resource constraints (CPU, memory, battery) of drones and potentially ODs, the authentication protocol must be lightweight. This implies minimizing complex cryptographic operations and reducing communication overhead [1; 11; 22].