Security Functionality Sample Clauses

Security Functionality. Table III shows the security capabilities of the proposed protocol as compared to the protocols presented in [15], [16], and [17]. As discussed in Section II, the protocol presented in [16] is vulnerable to forgery attacks, and hence it cannot ensure mutual authentication. In general, to keep the latency low and ensure seamless services, the MEC operator supports the UAVs by using computational infrastructure positioned close to the needs to use the PUF response Rx and the random number wireless infrastructure. However, in the protocol presented in i ⊕ || Ns , i.e., LAIu = EL h(Rx Ns ) and after decoding LAIu from EL, the USP checks this LAIu with the location of the MEC operator IDMEC . In this way, the USP can keep track of the current location of the UAV and address any disputes [15], if a MEC node sends false signals (e.g., in terms of its location) to an UAV, there is no way to detect that. In contrast, the proposed protocol can easily detect such attempts by using the parameter LAIu . Next, in the protocols proposed in [15], [16], and [17], the UAV needs to store all the secret information (e.g., keys) in its memory. Thus, if an adversary obtains physical access to the drone, it can obtain the secret key from the memory of the UAV or change the settings of the UAV. Then, if the adversary uses this compromised UAV to send false information or manipulated information to the USP, the USP will not be able detect such attacks. Therefore, the protocols presented in [15], [16], and [17], cannot ensure security against physical attacks. Finally, unlike [15], [16], and [17], the proposed scheme does not use any timestamps to ensure security against replay attacks.