# SENTINEL: A Secure and Efficient Authentication Framework for Unmanned Aerial Vehicles
## 5 Security Protocols in SENTINEL
### Drone Authentication Protocol  
To be authenticated from a ground station \(gs\), the drone \(d\) just uses the flight session key \(k_{d}\) that is already registered to the flight information database that can be accessed by all ground stations. This scheme can be effective in reducing the communication overhead rather than using a certificate-based authentication scheme. In this authentication procedure, we consider two authentication scenarios: (1) the authentication procedure between a drone and a ground station, and (2) the authentication procedure between a drone and another drone. To authenticate the drone \(d\), a ground station \(gs\) retrieves the registered flight session key \(k_{d}\) from the flight information database and then uses \(k_{d}\) to check the validity of authenticated code values computed by the drone \(d\) with the same key \(k_{d}\). Figure 4 shows the first authentication procedure between \(d\) and \(gs\). Figure 3: Mutual authentication and key agreement protocol. 1. The drone \(d\) creates a message \(msg_{d}\) that contains the information about the drone \(d\)'s (GPS) location and timestamp. The message also contains the drone \(d\)'s identifier \(id_{d}\) as the message sender's identifier ('Source ID') and the ground station's identifier as the message recipient's identifier ('Destination ID') in order to prevent replay attacks and man-in-the-middle attacks. Then, \(d\) computes the authentication code \(H_{d}\) using a HMAC (hash-based message authentication code function) with \(k_{d}\) and \(msg_{d}\) and sends \(H_{d}\) with the original message \(msg_{d}\) to a ground station \(gs\). 2. On receiving the message from the drone \(d\), the ground station \(gs\) fetches the drone \(d\)'s record with \(id_{d}\) from the flight information database and extracts the flight session key \(k_{d}\) from the record. For verifying the validity of the received \(H_{d}\), \(gs\) computes \(H_{d}^{\prime}=HMAC(k_{d},msg_{d})\) using received message \(msg_{d}\) and the retrieved flight session key \(k_{d}\). After computing \(H_{d}^{\prime}\), \(gs\) compares \(H_{d}^{\prime}\) with the received authentication code \(H_{d}\). If \(H_{d}^{\prime}=H_{d}\), \(gs\) believes that \(msg_{d}\) is not compromised and the drone \(d\) holds the flight session key \(k_{d}\). After verifying the authentication code, \(gs\) makes a decision on whether or not to allow the drone \(d\)'s flight entering its fly zone by checking whether this fly zone is contained in \(d\)'s flight plan. The message structure for the authentication is visually represented in Figure 5.  
We summarize the description of each field in the message as follows. * **Source ID. ** This field represents the message sender's identity (i.e., the drone \(d\)'s identity). The sender's identity can be used with the recipient's identifier to prevent man-in-the-middle attacks. In our prototype implementation, the size of this field is 4 bytes. * **Destination ID. ** This field represents the message recipient's identity. In the proposed protocol, the message recipient can be either a ground station or another drone. In our prototype implementation, the size of this field is 4 bytes. * **Timestamp. ** This field represents the time when the message was created. The timestamp can be used to ensure the freshness of messages. In our prototype implementation, the size of this field is 8 bytes. Figure 4: Authentication procedure between drone and ground station. Figure 5: Message structure for authentication. * **GPS information. ** This field represents the drone's current location information based on the GPS signal. This information can be used to trace the drone's location. In our prototype implementation, the size of this field is 24 bytes. * **Authentication code. ** This field represents the authentication code computed as \(H_{d}=HMAC(k_{d},msg_{d})\). The authentication code is used to ensure message authenticity and integrity. The proposed protocol can be extended to deal with the drone-to-drone authentication protocol.