## 3 Preliminaries
### Assumptions of the Protocol  
The security and correct functioning of the Bio-2 FA-IoD protocol depend on the following underlying assumptions:  
1. **Secure** TA: The trusted authority (TA) is honest, secure, and will not be compromised [8]. It correctly executes its role during the registration phase, and its long-term secrets remains confidential. 2. **Secure** initial provisioning of OD: The transfer of initial secrets (\(RP_{ID_{O}}\), \(HD_{O}\)) from the TA to the operator's device (OD) during registration is conducted over a secure channel or within a physically secure environment. 3. **Operator's** device (OD) trustworthiness and security: The OD is considered a trusted computing base for the operator. It is assumed to securely store its provisioned secrets (\(C_{RP}\), \(HD_{O}\), \(Salt_{2}\)) and protect them from malware or unauthorized local access, potentially using hardware-backed security features (e.g., secure element, TEE). The operator's local password/PIN \(P_{ID_{O}}\) (if used) is entered onto the OD through a secure interface (e.g., SVOSK-like [8]). While this assumes a high level of device integrity, practical deployments can further reinforce OD security by integrating layered defense mechanisms such as trusted execution environments (TEEs) or secure boot validation to mitigate risks from sophisticated malware or side-channel attacks. 4. **Biometric** system reliability and security: * The biometric sensor on the OD is assumed to be resistant to common spoofing attacks (e.g., presentation attacks with fake biometric samples). * The fuzzy extractor (_Gen_, _Rec_ algorithms) is assumed to be correctly implemented and secure; it reliably reproduces \(K_{\beta O}\) from a legitimate (though possibly noisy) sample \(\beta^{\prime}_{O}\) using \(HD_{O}\), and the helper data \(HD_{O}\) does not leak computationally \begin{table}
\begin{tabular}{l l} \hline \hline
**Symbol** & **Meaning** \\ \hline \(U_{O}\) & Drone operator \\ OD & Operator’s device \\ \(D_{i}\) & \(i\)-th drone \\ GCS & Ground control station \\ TA & Trusted authority \\ \(ID_{X}\) & Identity of entity X \\ \(\beta_{O}\) & Operator’s biometric data (enrollment) \\ \(\beta^{\prime}_{O}\) & Operator’s fresh biometric data (verification) \\ \(K_{\beta O}\) & Biometric key derived from \(\beta_{O}\) \\ \(HD_{O}\) & Helper data for biometric key reconstruction \\ \(P_{ID_{O}}\) & Operator’s password/PIN (local to OD) \\ \(K_{O}\) & Symmetric key derived from \(P_{ID_{O}}\) and \(Salt_{2}\) on OD \\ \(RP_{ID_{O}}\) & Random password for the operator, generated by TA \\ \(C_{RP}\) & \(RP_{ID_{O}}\) encrypted with \(K_{O}\) on OD \\ \(RPMD_{ID_{O}}\) & Hash digest of \(RP_{ID_{O}}\) and \(Salt_{1}\), stored at TA/GCS \\ \(Salt_{1},Salt_{2}\) & Random salt values \\ \(H(\cdot)\) & Secure one-way hash function (e.g., SHA-256) \\ \(KDF(\cdot,\cdot)\) & Key derivation function (e.g., PBKDF2) \\ \(E_{K}(\cdot)\) & Symmetric encryption with key K (e.g., AES-128 in CBC mode) \\ \(D_{K}(\cdot)\) & Symmetric decryption with key K (e.g., AES-128 in CBC mode) \\ \(T_{ID}\) & Timestamp generated by OD \\ \(KS\) & Ephemeral session key for OTAC (\(KDF(P_{ID_{O}},T_{ID})\)) \\ \(KS_{GCS}\) & GCS’s version of \(KS\) \\ OTAC & One-time authentication code \\ PIN & Random number generated by OD, part of OTAC \\ \(LLT_{O}\) & Operator’s last login time, stored at TA/GCS \\ \(\Delta_{t}\) & Maximum allowable time difference for freshness \\ \(\parallel\) & Concatenation operation \\ \(\oplus\) & Bitwise XOR operation \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Notation used in Bio-2 FA-IoD protocol. useful information about \(\beta_{O}\) or \(K_{\beta O}\) beyond what is inherently necessary to correct minor variations in \(\beta^{\prime}\)[5,12]. * The operator's biometric trait \(\beta_{O}\) possesses sufficient entropy for \(K_{\beta O}\) to be a strong cryptographic key.