# SENTINEL: A Secure and Efficient Authentication Framework for Unmanned Aerial Vehicles
## 8 Security Analysis
### Informal Security Analysis  
We also provide a security analysis for SENTINEL against various security attacks. Here we briefly summarize the security properties that are provided by SENTINEL compared with existing authentication protocols for IoT or drones based on the threat model (see Section 3.2). Table 5 summarizes the results, demonstrating that SENTINEL provides all the key features for the IoD environment.  
In the following, we clarify how SENTINEL provides each of the security features mentioned in Table 5.  
* **Mutual authentication.** Both the drone and the ground station have certificates issued by CA. During the key agreement process, both entities exchange their certificates and check the validity of the certificates. Consequently, the drone and the ground station authenticate each other if their certificates are valid.
* **Pseudonymity.** During the authentication process, the drone sends a message that contains its identity in SENTINEL. For preserving the privacy of the drone, a pseudonym can be used instead of the real identity of the drone. In this way, the ground station can still check if the drone has been authorized for its flight without exposing the drone's real identity.
* **Revocability.** As mentioned in Section 5, both the drone and the ground station can check whether the opposing party's certificate is revoked using a certificate validation service such as an online certificate status protocol (OCSP).
* **Session key agreement.** The drone and the ground station perform the key agreement process to make a flight session key (see Figure 3).  
\begin{table}
\begin{tabular}{l c c c c c c c} \hline \hline
**Security Features** & **[PERSON]** & **[PERSON]** & **[PERSON]** & **[PERSON]** & **[PERSON] et al.** & **[PERSON]** & **SENTINEL** \\  & **et al.**[5] & **et al.**[6] & **et al.**[4] & **et al.**[23] & **[19] & et al.**[24] & **SENTINEL** \\ \hline Mutual authentication & ✓ & ✓ & ✓ & ✓ & ✗ & ✓ & ✓ \\ Pseudonymity/Anonymity & ✓ & ✓ & ✓ & ✗ & ✗ & ✓ & ✓ \\ Revocability & ✓ & ✓ & ✓ & ✗ & ✗ & ✗ & ✓ \\ Session key agreement & ✓ & ✓ & ✓ & ✓ & ✗ & ✓ & ✓ \\ Man-in-the middle attack & ✓ & ✓ & ✓ & ✓ & - & ✓ & ✓ \\ Replay attack & ✓ & ✓ & ✓ & - & ✓ & ✓ & ✓ \\ Impersonation attack & ✓ & ✓ & ✓ & - & - & ✓ & ✓ \\ Known session key attack & - & ✓ & - & - & N/A & - & ✓ \\ \hline \hline \end{tabular}
\end{table}
Table 5: Summary and comparison of existing authentication protocols for IoD and our solution (‘-’ indicates that the paper did not mentioned them and ‘N/A’ indicates that the attack cannot be performed because there is no session key).  
* **Man-in-the middle attack.** Under the mutual authentication, SENTINEL guarantees to resist against man-in-the-middle attacks. Both the drone and ground station validate each other using the certificate.
* **Replay attack.** The timestamp is contained in the message for authentication that represents the time to create the message. With the timestamp, the message cannot be reused because the ground station can check the freshness of the message.
* **Impersonation attack.** A malicious drone can try to impersonate a legitimate drone \(d\) using \(id_{d}\) and \(cert_{d}\). Although the malicious drone uses \(id_{d}\) and \(cert_{d}\), it is not possible to obtain the pre-master-secret key without the drone \(d\)'s private key.
* **Known session key attack.** Flight session keys are always newly created with random parameters such as \(n_{d}\), \(n_{s}\), and \(pms\). Therefore, it is not possible to succeed with a known session key attack.