TY - JOUR
AU1 - Algarni, Ali Delham
AU2 - Innab, Nisreen
AU3 - Algarni, Fahad
AB - Introduction The drone, an impressive technological innovation, operates without a human on board and can be controlled remotely through flying ad hoc networks (FANET), unmanned aerial vehicular networks (UAVN), etc. It is also compatible with GPS (Global Positioning System), 5G (Fifth Generation), and other wireless networking. Drones have many application areas, including traffic monitoring, search/rescue operations, pipeline inspection, illegal trawling, wildlife surveillance, drug trafficking, smuggling, immigration, etc., which significantly enhance conventional surveillance methods into an intelligent way for information fusion and complex tactical task completion. However, the communication environment for drones, including with the ground control station (GCS), is hostile, with adversaries posing a threat and using it for malicious purposes [1]. Ensuring secure transmission between the drones and the GCS is a significant challenge, and many attempts have been made to protect the sensitive information exchanged in the IoD environment. The urgency and importance of security issues are yet to be solved, as without a robust security mechanism, the drone communication path remains vulnerable to strong adversaries, potentially leading to serious security breaches [2]. It is crucial to be aware of these risks and to work towards mitigating them. Owing to limited computing and storage resources, a single drone cannot efficiently perform a complex tactical task; however, working in the cluster is qualified for complex operations subject to collaboration and coordination (synergy) as it is a crucial characteristic of the clustering drones when deployed for an intelligent information fusion. Due to this characteristic, the drones working in clusters can transmit information in a controlled manner to each other and send intelligent commands to the ground control station (GCS) for prompt decisions. The GCS plays a crucial and irreplaceable role in this process, as it is the central hub for receiving and processing data from the drones [3]. These synergistic characteristics require a flawless authentication mechanism to be installed in all drones working in clusters to make all the associated participants authenticated securely with each other and with the ground control station, detect suspicious drones in the sky, collect rich, real-time intelligence information related to the task for which the drones have been assigned, and periodically deliver these data to the GCS for information fusion. The potential risks of not having secure authentication are significant, as any dubious information from any drone may mislead the GCS to make a wrong decision. This underscores the need for immediate action to implement secure and robust authentication. There are two types of authentication: messaging and identification. The first is challenging, whereas the second is beyond the scope of this work because information authentication can ensure integrity, availability, confidentiality, nonrepudiation, etc. [4]. Numerous researchers have presented information authentications from time to time. For example, researchers [5] proposed an ECC-based lightweight authentication protocol for drone deployment in smart city surveillance. This protocol is significant as it utilizes discrete logarithmic problems (DLP) [6] for secure key generation, a crucial aspect in securing information communication in IoD technology. Another ECC-based authentication protocol for space information networks was presented by [7], who claimed that their protocol is secure and efficiently offers services between satellite and ground stations. They [7] analyzed the security of their framework through a well-known random oracle model (ROM), a theoretical model used in the analysis of cryptographic algorithms and protocols [8]. They [7] simulated it via the automated validation of the Internet Security Protocols and Applications (AVISPA) software toolkit [9]. A simple hash cryptographic-based lightweight and robust authentication scheme for the IoD environment was presented by [10], who scrutinized security via the Turing machine, lemmas, theorems, and informal discussion [11]. However, their [10] proposal lacks a password update facility and a drone revocation/reregistration/reissue phase. A service and temporal credential-based protocol for IoD deployment drones working in clusters was presented by [12], who claimed that their scheme is the first protocol to provide security for drone-collected data and is resistant to information leakage vulnerability. They used another well-known real-or-random (ROR) model [13], a model used to analyze the security of cryptographic protocols for security analysis, and the AVISPA tool for simulation [9]. They [12] claimed that their scenario is 20% smaller in computation than its competitors, indicating potential efficiency gains. The three-factor key agreement protocol based on Boyko-Peinado-Venkatesan (BPV) was designed by [14], who claimed that the FourQ curve [15] is five times faster, lighter, and more robust in terms of security than other ECC conventional cryptographic primitives are. However, these schemes either have design flaws or fail to provide security features such as authentication, confidentiality, and privacy. Additionally, these schemes are not secure against session key disclosure attacks, spoofing, man in the middle, denial of service, etc., attacks. Similarly, the researchers in [16] demonstrated their dedication to the field by arguing that desynchronization, MITM, replay, tracing, and side-channel attacks must be addressed efficiently in IoD environments. They [16] proposed a physical unclonable function (PUF)-based [17] authentication protocol to mitigate these drawbacks. Their [16] commitment to finding solutions was evident in their claim that the security analysis of their strategy was not just comprehensive but flawless and that their simulation results were more substantial than those in other studies. They [16] also used a hybrid cryptosystem to mitigate critical vulnerabilities, a solution they claimed was more effective than existing schemes but with a more complex practical implementation. A blockchain-based security scheme was introduced in [18], and they claimed that their scheme provides secure data transmission in a 5G-enabled IoD system, with advantages over existing schemes. Their [18] blockchain-oriented data-delivery collection security authenticated all the participants of IoD and resisted numerous threats, whereas a buffer pseudonym and public key infrastructure (PKI)-based authentication scheme for an edge-assisted IoD system was designed in [19]; however, their computational costs are too high compared with those of existing schemes. The researchers in [20] also introduced a communication-aware drone delivery problem (C-DDP) for IoD to ensure efficient last-mile delivery operations. Their [20] work enhances the trade-off among the drones working in the clusters and minimizes unintentional interference in shared spectrum scenarios. Their [20] study highlighted the impact of UAV interference on ground users, emphasizing the urgency and significance of their proposed solutions. Another study [21] stressed the importance of optimizing communication strategies, with a particular focus on factors such as the signal-to-noise ratio, outage duration thresholds, and interference tolerance levels, while [22] added a layer of complexity and depth to the flying zone by enhancing drone-to-drone communication reliability and efficiency. The complexity of the flying zone necessitates advanced communication strategies. Achieving such reliable communications in UAV networks is challenging because of the open networking path and the requirement of flawless and robust authentication, which is often missing and, in turn, can cause unintentional interference to the ground control station (GCS) [23]. However, these methods [23–25], have some drawbacks because when drones are flying, they can affect people’s privacy and create a power optimization issue due to the shared spectrum, and communication links usually fail in the route traffic as drones fly at high speed. Therefore, these issues can be solved only by designing a synergistically-assisted protocol with efficient information fusion in the IoD environment. The proposed solutions are of utmost importance and urgent in the complex and dynamic environment of drone technology. Objectives This research work aim to ensure secure communication between two drones in the IoD environment, in this regard, the objectives of this research work includes: Drones often communicate with other drones, GCSs, or other devices through wireless networks. Secure communication is crucial to prevent unauthorized access or tampering. A protocol can be designed to compute a shared session key among drones, ensuring that keys are securely exchanged and authenticated. The proposed protocol is actually an implicit key authentication method in which the drone technology should be offered a strong layer of security by ensuring that the exchange of secrets among drones are authenticated without additional steps, thereby preventing unauthorized drones from spoofing or hijacking the communication channel. The proposed protocol is designed with a strong focus on resistance to attacks. It must have the ability to provide security properties that ensure resistance against various attacks, such as eavesdropping, message tampering, and impersonation. The proposed authentication protocol is specifically designed to ensure that the session keys used for communication among drones remain secret. This is not just a security measure but a guarantee that data interception and manipulation are prevented, thereby ensuring the integrity and confidentiality of the communication process. The proposed authentication protocol must have a formal framework for analyzing the security of communication protocols. A thorough analysis, which involves applying BAN logic, a formal method for analyzing the security of cryptographic protocols, is crucial in identifying and addressing vulnerabilities before deployment when dealing with drone communication protocols. Motivation and contributions Many vulnerabilities, issues, challenges, and limitations have been noted in existing authentication methods, as discussed in detail in the above protocols. To address these issues, an innovative approach, such as using random numbers, identities, and secret keys, enhances and mitigates the identified security lapses, flaws, and security issues. Additionally, by leveraging the unique characteristics of drones, such as their mobility, agility, and ability to operate in remote areas and mitigate known vulnerabilities, issues, and challenges, authentication presents a promising solution that is resilient to attacks and robust under diverse conditions. The robustness of such a solution provides reassurance about the security of the IoD environment. By incorporating these advancements, the development of an effective authentication protocol can significantly increase the overall security and reliability of the IoD environment because drones transmit information via an open channel that is vulnerable to various attacks, such as impersonation, password guessing, insider attacks, denial of service, and replay attacks. Rigorously, the authentication of drones working in clusters is crucial to prevent critical security breaches and build trust in the system. Authentication also measures challenges like key secrecy, heavyweight computations, high communication costs, and dependence on random numbers, so the major contributions of this research work are as follows: To present a protocol that provides mutual authentication and efficient services in an IoD environment, a secure session key should be established among the drones working in the cluster for secure communication without interacting with the ground control station. To utilize the elliptic curve cryptography (ECC), a one-way hash function, and XOR operations for the design of the proposed protocol in which the GCS securely stores shared credentials in the memory of each drone at the time of registration. Once deployed for tactical tasks, the drones exchange these credentials, enabling secure authentication and start communication in a collaborative and coordinated manner. To formally analyze the proposed verifiably secure and robust authentication protocol through BAN logic, a widely accepted method for evaluating cryptographic protocols, and ProVerif simulation, a tool for verifying the security properties of cryptographic protocols. To conduct a comparative analysis of the proposed synergistically-assisted IoD deployment drone protocol regarding performance metrics and security functionalities. This analysis confirms that the protocol is lightweight, robust, and synergistically assisted for the IoD environments, highlighting its practical application. Paper layout The remainder of the paper is organized as follows: In the preliminaries and backgrounds section of the article, we have presented the groundwork pertaining to conducting this research work. In the literature review section, we have presented the related work comprehensively, including methodologies and pros and cons of their work, and analyzed the baseline scheme for vulnerabilities like key disclosure, forward secrecy and stolen-verifier attacks. In the proposed protocol section, we have presented a practical and efficient protocol for an IoD environment where two drones can successfully share secrets and communicate securely. Afterwards, we analyzed the proposed protocol, formally using BAN logic and ProVerif validation and informally through pragmatic discussion. Then, we measured the performance metrics by considering communication, computational, and storage costs. This analysis shows that the proposed protocol is superior to all, and the work concludes with the optimistic note that the proposed protocol is ready for practical implementation in the IoD environment, offering hope for the future of secure drone communication. Objectives This research work aim to ensure secure communication between two drones in the IoD environment, in this regard, the objectives of this research work includes: Drones often communicate with other drones, GCSs, or other devices through wireless networks. Secure communication is crucial to prevent unauthorized access or tampering. A protocol can be designed to compute a shared session key among drones, ensuring that keys are securely exchanged and authenticated. The proposed protocol is actually an implicit key authentication method in which the drone technology should be offered a strong layer of security by ensuring that the exchange of secrets among drones are authenticated without additional steps, thereby preventing unauthorized drones from spoofing or hijacking the communication channel. The proposed protocol is designed with a strong focus on resistance to attacks. It must have the ability to provide security properties that ensure resistance against various attacks, such as eavesdropping, message tampering, and impersonation. The proposed authentication protocol is specifically designed to ensure that the session keys used for communication among drones remain secret. This is not just a security measure but a guarantee that data interception and manipulation are prevented, thereby ensuring the integrity and confidentiality of the communication process. The proposed authentication protocol must have a formal framework for analyzing the security of communication protocols. A thorough analysis, which involves applying BAN logic, a formal method for analyzing the security of cryptographic protocols, is crucial in identifying and addressing vulnerabilities before deployment when dealing with drone communication protocols. Motivation and contributions Many vulnerabilities, issues, challenges, and limitations have been noted in existing authentication methods, as discussed in detail in the above protocols. To address these issues, an innovative approach, such as using random numbers, identities, and secret keys, enhances and mitigates the identified security lapses, flaws, and security issues. Additionally, by leveraging the unique characteristics of drones, such as their mobility, agility, and ability to operate in remote areas and mitigate known vulnerabilities, issues, and challenges, authentication presents a promising solution that is resilient to attacks and robust under diverse conditions. The robustness of such a solution provides reassurance about the security of the IoD environment. By incorporating these advancements, the development of an effective authentication protocol can significantly increase the overall security and reliability of the IoD environment because drones transmit information via an open channel that is vulnerable to various attacks, such as impersonation, password guessing, insider attacks, denial of service, and replay attacks. Rigorously, the authentication of drones working in clusters is crucial to prevent critical security breaches and build trust in the system. Authentication also measures challenges like key secrecy, heavyweight computations, high communication costs, and dependence on random numbers, so the major contributions of this research work are as follows: To present a protocol that provides mutual authentication and efficient services in an IoD environment, a secure session key should be established among the drones working in the cluster for secure communication without interacting with the ground control station. To utilize the elliptic curve cryptography (ECC), a one-way hash function, and XOR operations for the design of the proposed protocol in which the GCS securely stores shared credentials in the memory of each drone at the time of registration. Once deployed for tactical tasks, the drones exchange these credentials, enabling secure authentication and start communication in a collaborative and coordinated manner. To formally analyze the proposed verifiably secure and robust authentication protocol through BAN logic, a widely accepted method for evaluating cryptographic protocols, and ProVerif simulation, a tool for verifying the security properties of cryptographic protocols. To conduct a comparative analysis of the proposed synergistically-assisted IoD deployment drone protocol regarding performance metrics and security functionalities. This analysis confirms that the protocol is lightweight, robust, and synergistically assisted for the IoD environments, highlighting its practical application. Paper layout The remainder of the paper is organized as follows: In the preliminaries and backgrounds section of the article, we have presented the groundwork pertaining to conducting this research work. In the literature review section, we have presented the related work comprehensively, including methodologies and pros and cons of their work, and analyzed the baseline scheme for vulnerabilities like key disclosure, forward secrecy and stolen-verifier attacks. In the proposed protocol section, we have presented a practical and efficient protocol for an IoD environment where two drones can successfully share secrets and communicate securely. Afterwards, we analyzed the proposed protocol, formally using BAN logic and ProVerif validation and informally through pragmatic discussion. Then, we measured the performance metrics by considering communication, computational, and storage costs. This analysis shows that the proposed protocol is superior to all, and the work concludes with the optimistic note that the proposed protocol is ready for practical implementation in the IoD environment, offering hope for the future of secure drone communication. Preliminaries and background This section provides the essential context, foundational information, and relevant background knowledge necessary for understanding the research’s main content. It serves to orient the reader, provides the essential context, and sets the stage for the article’s main content. Elliptic Curve Cryptography (ECC) ECC, a methodology introduced by in 1985 [26], is elegantly defined through the simple equation y2 = x3+ax+b. The private key in ECC is an integer; when multiplied with any fixed point of the curve, we obtain another key P called a public key. This process, along with the security features of ECC, ensures that any two points on the curve, P(x1, y1) and Q(x2, y2), if they intersect, generate a third point R(x3, y3) on the curve, which should be equivalent to the addition of P and Q. Therefore, we use this technique for designing the proposed protocol to exchange data from one drone to another securely, providing reassurance about the safety of the process. Hash function The National Security Agency (NSA) devised the Secure Hash Algorithm (SHA), a versatile tool in the field of cryptography. This algorithm, which was later released in 1993 by the esteemed National Institute of Standards and Technology (NIST), can handle input data of any size and generate a 160-bit (20-byte) hash value known as a message digest, usually shown as a hexadecimal number [27]. XOR operations In cryptography, the bitwise XOR (exclusive OR) is frequently utilized in security applications for several functions, such as data integrity checking, checksum computation, and encryption, also called a "One-Time Pad." XOR operations’ straightforwardness, effectiveness, and bitwise ciphering nature make it a key component in various security-related applications. However, it is important to remember that they are not used as stand-alone security measures but rather as components of more complex cryptographic algorithms [28]. Security requirements To ensure secure communication between two drones in the IoD environment, the following security requirements are implemented: 1-Key Exchange Protocol: Drones often communicate with other drones, GCSs, or other devices through wireless networks. Secure communication is crucial to prevent unauthorized access or tampering. The proposed authentication protocol can be used to compute a shared session key among drones, ensuring that keys are securely exchanged and authenticated. 2-Implicit Key Authentication is a key feature in drone technology that provides a strong layer of security. It ensures that the keys exchanged between the first and second drones are authenticated without additional steps, thereby preventing unauthorized drones from spoofing or hijacking the communication channel. This measure provides a sense of reassurance about the security of the communication channel. 3-The proposed protocol is designed with a strong focus on resistance to attacks. It must have the ability to provide security properties that ensure resistance against various attacks, such as eavesdropping, message tampering, and impersonation. By designing drone communication protocols based on the CK model [30], a widely accepted model for cryptographic key exchange, vulnerabilities to these attacks can be effectively mitigated. This emphasis on security measures instills confidence in the audience. 4-Session Key Secrecy: The proposed authentication protocol is specifically designed to ensure that the session keys used for communication among drones remain secret. This is not just a security measure but a guarantee that data interception and manipulation are prevented, thereby ensuring the integrity and confidentiality of the communication process. 5-Formal Analysis: The proposed authentication protocol must have a formal framework for analyzing the security of communication protocols. A thorough analysis, which involves applying BAN logic, a formal method for analyzing the security of cryptographic protocols, is crucial in identifying and addressing vulnerabilities before deployment when dealing with drone communication protocols. Threat model The Dolev-Yao [29] and Canetti-Krawczyk [30] models, which were the first to present the possible threats to the system, are known for their thoroughness in the field of cyber security. These models, widely used for protocol analysis and detection of system vulnerabilities, are the foundation of this research work. Their comprehensive nature in identifying threats and understanding potential weaknesses or loopholes provides a robust framework for our research. According to these models, the system faces several threats, some of these threats includes the following: False Data Injection Threat: The adversary’s ability to influence the information gathered by the drones, including state variables, coordinates, and preferences, falsifies valuable credentials and poses a significant risk to the system’s integrity and operation. Privacy Threat: The adversary might access the open network channel, installing aircrack-ng [31] to crack the Wi-Fi password, airodump-ng [31] to capture data packets, and airplay-ng [31] to disconnect devices from the network, thereby compromising the privacy of a legitimate drone. Traffic Analysis Threat: The packets transmitted among two drones can be captured by an adversary, analyzed, and later used for malicious acts. The drones are equipped with sensors/cameras for data collection and exchange with the GCS alongside another drone. The transmission is performed via wireless media and is vulnerable to the adversary. If the security mechanism is weak, the adversary can easily extract the internal secret credentials from the exchanged packets. Access Control Threat: The adversary’s ability to identify and exploit the different policies, rules, and design principles about a protocol’s design can lead to a loss of authenticity, unauthorized privilege changes, and significant system damage. This underscores the urgent need for robust access control measures. Identity Spoofing Threat: The adversary’s ability to masquerade as someone else to gain unauthorized access to sensitive information, commit fraud, or carry out other illicit activities highlights the need for vigilance and proactive measures to prevent such threats. Reply Attack: An attacker captures data from the open channel, eavesdrops, and later uses it for a potential replay attack to gain access to the system illegally. Desynchronization Threat: A desynchronization threat occurs when a system administrator updates a legitimate drone’s identity and other credentials; however, the drone does not know about these changes. Conversely, an adversary can access the GCS and disturb the synchrony of the shared memory for deployed drones. Man-in-the-middle (MITM) attack: The adversary places itself between two communicating parties and relays messages for them instead of transmitting them to a legitimate drone or GCS. The attacker can then divert and modify the messages’ contents and impersonate the whole system. Stolen-Verifier Attack: The attacker’s ability to steal a drone, extract its internal secret credentials, and launch various attacks on the system, including replay, masquerade, and denial-of-service (DoS) attacks, can severely damage the system’s security and functionality. This underscores the need for comprehensive security measures. Similarly, the Canetti and Krawczyk [30] model provides a reliable framework for analyzing the security of cryptographic protocols. It defines a security notion called "implicit key authentication," which captures the requirement that the shared secret key should be authenticated implicitly during the key exchange process. In this process, two parties agree on a shared secret key without additional authentication steps. This model is useful for setting rules for a cryptographic protocol and is considered to be secure if it satisfies specific security properties defined by [30], such as key secrecy, key authentication, forward, backward, and session key confidentiality. These properties ensure that the protocol resists various attacks, such as impersonation attacks, false data injection attacks, privacy issues, traffic analysis attacks, access control threats, identity spoofing vulnerabilities, reply attacks, desynchronization issues, man-in-the-middle (MITM) attacks, stolen-verifier attacks, and key compromise attacks. System model The proposed system or network model, a crucial advancement in drone technology [32] and telecommunications [33], consists of two main entities, a drone and a GCS, diagrammatically represented in Fig 1. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 1. Proposed system model. https://doi.org/10.1371/journal.pone.0314475.g001 The entities showing in Fig 1 are drone and ground control station (GCS); these are define one by one as under: Drone (D): The operator’s remote supervision of drones is a necessary aspect of this system, but it’s not just a one-way process. Even if there are no onboard operators to respond to emergencies, overseeing tasks such as farming, wildlife, surveillance, and labor monitoring for work output in a big building requires continuous investigation. These drones are not autonomous entities but rather tools that require human collaboration to improve mission efficacy while minimizing costs. This article proposes mutual authentication to establish secure communication between two drones in the airspace, emphasizing the collaborative nature of the system. The two drones can incorporate global positioning system (GPS) signals alongside additional wireless communication layouts to communicate with the flying ad hoc network (FANET) or unmanned aerial vehicular network (UAVN) or use 5G/6G. Ground Control Station (GCS): The GCS, a pivotal component in the system, is a specialist service offering connections, assistance with data analysis, and real-time capabilities for handling problems. It plays a key role in managing, overseeing, and regulating drones to provide navigational services. Every drone must have the GCS installed and be linked with other network services, such as 5G/6G, GPS, UAVN/FANET, and wireless communication gateway. Installing drones inside a designated flying zone and establishing them together in pre-established flight zones is mandatory. The GCS controls the drone’s flight and verifies its identity within the zone. The GCS also makes it simple to identify illegitimate drones in the flying area or verify the legitimacy of a valid drone. Elliptic Curve Cryptography (ECC) ECC, a methodology introduced by in 1985 [26], is elegantly defined through the simple equation y2 = x3+ax+b. The private key in ECC is an integer; when multiplied with any fixed point of the curve, we obtain another key P called a public key. This process, along with the security features of ECC, ensures that any two points on the curve, P(x1, y1) and Q(x2, y2), if they intersect, generate a third point R(x3, y3) on the curve, which should be equivalent to the addition of P and Q. Therefore, we use this technique for designing the proposed protocol to exchange data from one drone to another securely, providing reassurance about the safety of the process. Hash function The National Security Agency (NSA) devised the Secure Hash Algorithm (SHA), a versatile tool in the field of cryptography. This algorithm, which was later released in 1993 by the esteemed National Institute of Standards and Technology (NIST), can handle input data of any size and generate a 160-bit (20-byte) hash value known as a message digest, usually shown as a hexadecimal number [27]. XOR operations In cryptography, the bitwise XOR (exclusive OR) is frequently utilized in security applications for several functions, such as data integrity checking, checksum computation, and encryption, also called a "One-Time Pad." XOR operations’ straightforwardness, effectiveness, and bitwise ciphering nature make it a key component in various security-related applications. However, it is important to remember that they are not used as stand-alone security measures but rather as components of more complex cryptographic algorithms [28]. Security requirements To ensure secure communication between two drones in the IoD environment, the following security requirements are implemented: 1-Key Exchange Protocol: Drones often communicate with other drones, GCSs, or other devices through wireless networks. Secure communication is crucial to prevent unauthorized access or tampering. The proposed authentication protocol can be used to compute a shared session key among drones, ensuring that keys are securely exchanged and authenticated. 2-Implicit Key Authentication is a key feature in drone technology that provides a strong layer of security. It ensures that the keys exchanged between the first and second drones are authenticated without additional steps, thereby preventing unauthorized drones from spoofing or hijacking the communication channel. This measure provides a sense of reassurance about the security of the communication channel. 3-The proposed protocol is designed with a strong focus on resistance to attacks. It must have the ability to provide security properties that ensure resistance against various attacks, such as eavesdropping, message tampering, and impersonation. By designing drone communication protocols based on the CK model [30], a widely accepted model for cryptographic key exchange, vulnerabilities to these attacks can be effectively mitigated. This emphasis on security measures instills confidence in the audience. 4-Session Key Secrecy: The proposed authentication protocol is specifically designed to ensure that the session keys used for communication among drones remain secret. This is not just a security measure but a guarantee that data interception and manipulation are prevented, thereby ensuring the integrity and confidentiality of the communication process. 5-Formal Analysis: The proposed authentication protocol must have a formal framework for analyzing the security of communication protocols. A thorough analysis, which involves applying BAN logic, a formal method for analyzing the security of cryptographic protocols, is crucial in identifying and addressing vulnerabilities before deployment when dealing with drone communication protocols. Threat model The Dolev-Yao [29] and Canetti-Krawczyk [30] models, which were the first to present the possible threats to the system, are known for their thoroughness in the field of cyber security. These models, widely used for protocol analysis and detection of system vulnerabilities, are the foundation of this research work. Their comprehensive nature in identifying threats and understanding potential weaknesses or loopholes provides a robust framework for our research. According to these models, the system faces several threats, some of these threats includes the following: False Data Injection Threat: The adversary’s ability to influence the information gathered by the drones, including state variables, coordinates, and preferences, falsifies valuable credentials and poses a significant risk to the system’s integrity and operation. Privacy Threat: The adversary might access the open network channel, installing aircrack-ng [31] to crack the Wi-Fi password, airodump-ng [31] to capture data packets, and airplay-ng [31] to disconnect devices from the network, thereby compromising the privacy of a legitimate drone. Traffic Analysis Threat: The packets transmitted among two drones can be captured by an adversary, analyzed, and later used for malicious acts. The drones are equipped with sensors/cameras for data collection and exchange with the GCS alongside another drone. The transmission is performed via wireless media and is vulnerable to the adversary. If the security mechanism is weak, the adversary can easily extract the internal secret credentials from the exchanged packets. Access Control Threat: The adversary’s ability to identify and exploit the different policies, rules, and design principles about a protocol’s design can lead to a loss of authenticity, unauthorized privilege changes, and significant system damage. This underscores the urgent need for robust access control measures. Identity Spoofing Threat: The adversary’s ability to masquerade as someone else to gain unauthorized access to sensitive information, commit fraud, or carry out other illicit activities highlights the need for vigilance and proactive measures to prevent such threats. Reply Attack: An attacker captures data from the open channel, eavesdrops, and later uses it for a potential replay attack to gain access to the system illegally. Desynchronization Threat: A desynchronization threat occurs when a system administrator updates a legitimate drone’s identity and other credentials; however, the drone does not know about these changes. Conversely, an adversary can access the GCS and disturb the synchrony of the shared memory for deployed drones. Man-in-the-middle (MITM) attack: The adversary places itself between two communicating parties and relays messages for them instead of transmitting them to a legitimate drone or GCS. The attacker can then divert and modify the messages’ contents and impersonate the whole system. Stolen-Verifier Attack: The attacker’s ability to steal a drone, extract its internal secret credentials, and launch various attacks on the system, including replay, masquerade, and denial-of-service (DoS) attacks, can severely damage the system’s security and functionality. This underscores the need for comprehensive security measures. Similarly, the Canetti and Krawczyk [30] model provides a reliable framework for analyzing the security of cryptographic protocols. It defines a security notion called "implicit key authentication," which captures the requirement that the shared secret key should be authenticated implicitly during the key exchange process. In this process, two parties agree on a shared secret key without additional authentication steps. This model is useful for setting rules for a cryptographic protocol and is considered to be secure if it satisfies specific security properties defined by [30], such as key secrecy, key authentication, forward, backward, and session key confidentiality. These properties ensure that the protocol resists various attacks, such as impersonation attacks, false data injection attacks, privacy issues, traffic analysis attacks, access control threats, identity spoofing vulnerabilities, reply attacks, desynchronization issues, man-in-the-middle (MITM) attacks, stolen-verifier attacks, and key compromise attacks. System model The proposed system or network model, a crucial advancement in drone technology [32] and telecommunications [33], consists of two main entities, a drone and a GCS, diagrammatically represented in Fig 1. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 1. Proposed system model. https://doi.org/10.1371/journal.pone.0314475.g001 The entities showing in Fig 1 are drone and ground control station (GCS); these are define one by one as under: Drone (D): The operator’s remote supervision of drones is a necessary aspect of this system, but it’s not just a one-way process. Even if there are no onboard operators to respond to emergencies, overseeing tasks such as farming, wildlife, surveillance, and labor monitoring for work output in a big building requires continuous investigation. These drones are not autonomous entities but rather tools that require human collaboration to improve mission efficacy while minimizing costs. This article proposes mutual authentication to establish secure communication between two drones in the airspace, emphasizing the collaborative nature of the system. The two drones can incorporate global positioning system (GPS) signals alongside additional wireless communication layouts to communicate with the flying ad hoc network (FANET) or unmanned aerial vehicular network (UAVN) or use 5G/6G. Ground Control Station (GCS): The GCS, a pivotal component in the system, is a specialist service offering connections, assistance with data analysis, and real-time capabilities for handling problems. It plays a key role in managing, overseeing, and regulating drones to provide navigational services. Every drone must have the GCS installed and be linked with other network services, such as 5G/6G, GPS, UAVN/FANET, and wireless communication gateway. Installing drones inside a designated flying zone and establishing them together in pre-established flight zones is mandatory. The GCS controls the drone’s flight and verifies its identity within the zone. The GCS also makes it simple to identify illegitimate drones in the flying area or verify the legitimacy of a valid drone. Related works This section offers a brief overview and evaluation of the previous state-of-the-art works. It assesses the advantages, disadvantages, and overall contributions of different schemes presented by other researchers in the area in the form of a table. It also offers a thorough and critical summary of the existing body of research, highlighting the urgency of identifying gaps, contradictions, and areas needing further investigation. The summary of the related works is shown in Table 1, underscoring the need for future research to address these gaps. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 1. Critical literature review summary. https://doi.org/10.1371/journal.pone.0314475.t001 In summary, research on drone authentication techniques is highly important. It discusses the use of three-factor user authentication and elliptic curve cryptography (ECC), SHA, and XOR operations to enhance resource-efficient security for IoDs. However, these techniques are not without vulnerabilities, such as susceptibility to impersonation, replay, denial of service (DoS), parallel session, and secret credential leakage attacks. This underscores the need for robust security measures in drone technology. Review analysis of the baseline scheme Jan et al. [33] proposed a biometric fuzzy extractor-based scheme for the cross-verification of users and drones in the IoD environment. Their scheme has two main phases, registration and verification, which are explained in the following subsection. The notations used for the design of their scheme are shown in Table 2. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 2. Notations and their meaning. https://doi.org/10.1371/journal.pone.0314475.t002 Registration phase. The registration phase in [33] is completed in the following steps: This phase is completed by first registering a user with the GCS and then a drone. The identity and password are sent to the GCS through a secure channel for user registration. When receiving the registration message from a user, the GCS calculates PIDi = h(IDi||s), Ai = h(IDi||l), where l is a large secret number and s is the public key. The GCS injects {PIDi, Ai, IDi} in its memory and replays {PIDi, Ai} to the user. The user then receives the response message from the GCS and is asked to enter their biometrics BIOi, calculate Gen(BIOi) = (σi, τi), Ai = h(IDi||PWi)⊕Ai, and PIDi = h(IDi||PWi)⊕PIDi and inject {Ai, PIDi, Gen(.), Rep(.)} in their mobile device memory. The drone is also registered with the GCS through a secure channel and sends its identity to the GCS. The GCS calculates PIDj = h(IDj||s) and Aj = h(IDj||l), injects {IDj, PIDj, Aj} and replays {PIDj, Aj} back to the drone. The drone also injects {PIDj, Aj} into the device memory. Verification phase. As detailed in [33], this phase is accomplished in the following steps: The user provides their identity, password, and biometrics. The device with the user calculates σi* = Rep(BIOi, τi), PIDi = PIDi⊕h(IDi||PWi), Ai = Ai*⊕h(IDi||PWi), selects R1, ST1 and calculates M1 = h(PIDj||ST1)⊕PIDi, M2 = h(PIDi||PIDj||Ai)⊕R1, M3 = h(PIDi||PIDj||Ai||R1)⊕IDi, M4 = h(PIDi||PIDj||PIDk||Ai||R1) and sends Mesg1 = {M1, M2, M3, M4, ST1} to the GCS. The GCS confirms the time validity, calculates PIDi* = M1⊕h(PIDk||ST1), extracts Ai* and computes R1* = M2⊕h(PIDi*||PIDk||Ai*), PIDj* = M3⊕h(PIDi*||PIDk||Ai*||R1*) and M4* = h(PIDi*||PIDj*||PIDk||Ai*||R1*), validates M4*? = M4, selects ST2, calculates M5 = h(PIDj*||Aj*||ST2)⊕R1*, M6 = h(PIDj*||PIDk||Aj*||R1*)⊕PIDi*, M7 = h(PIDi*||PIDj*||PIDk||Aj*||R1*) and sends Mesg2 = {M5, M6, M7, ST2} to the drone. The drone first confirms the timestamp and calculates R1** = M5⊕h(PIDj||Aj), PIDi** = M6⊕h (PIDj||PIDk||Aj||R1**) and M7* = h(PIDi**||PIDj||PIDk||Aj||R1**), validate M7*? = M7, selects R2, ST3 calculates M8 = h(PIDj||PIDi**||ST3)⊕R2, M9 = h(R1**||R2), SKij = h(PIDi**||PIDj||PIDk||M9), M10 = h (PIDi**||PIDj||PIDk||R1**||R2||M9), replays Mesg3 = {M8, M9, M10, ST3} back to the GCS. The GCS confirms the timestamp, calculates R2* = M8⊕h(PIDj||PIDi||R1), M9* = h(R1||R2*), and M10 = h(PIDi||PIDj||PIDk||R1||R2*), validates M10*? = M10, calculates SKij = h(PIDi||PIDj||PIDk||M9*), and replays Mesg4 = {M8, M9, M10, ST4} to the user. The user confirms the timestamp, calculates R2* = M8⊕h(PIDj||PIDi||R1), M9* = h(R1||R2*), M10 = h(PIDi||PIDj||PIDk||R1||R2*), verifies M10*? = M10, calculates SKij = h(PIDi||PIDj||PIDk||M9*) and keeps it as a shared session key. Cryptanalysis of the baseline scheme After investigating the scheme presented by [33], the following loopholes/vulnerabilities/weaknesses are noted. Key disclosure attack. The adversary becomes successful if they can obtain PIDi, PIDj, and PIDk. To do so, they first have to select two random numbers RA1 and RA2, pass through a hash function to obtain M9 = h(RA1||RA2) and compute M5⊕h(PIDj||Aj), M5 = h(PIDi||Aj) and PIDi = M5⊕ h(IDj||l) to obtain PIDi. For PIDj, the adversary computes M8⊕h(PIDj||PIDi||R1), M8 = h(PIDj||PIDi||R1), and PIDj = M8⊕h(PIDi||R1). Now, to obtain PIDk, the adversary computes M2⊕h(PIDi||PIDk||Ai), M2 = h(PIDi||PIDk||Ai), and PIDk = M2⊕h(PIDi||Ai). By obtaining PIDi, PIDj and PIDk, the adversary can easily compute the session secret key SKij = h(PIDi||PIDj||PIDk||M9) in an easy manner. Therefore, the method protocol in [33] is vulnerable to session key disclosure attacks. Perfect forward security issue. The adversary compromises all the previously transmitted messages Mesg1, Mesg2, Mesg3, and Mesg4 and reaches the secret keys s and l. For example, a legitimate user enters their identity password, imprints biometrics and computes σi* = Rep(BIOi, τi), PIDi = PIDia⊕h(IDi||PWi), Ai = Aiaa⊕h(IDi||PWi), selects R1, ST1 and calculates M1 = h(PIDj||ST1)⊕PIDi, M2 = h(PIDi||PIDj||Ai)⊕R1, M3 = h(PIDi||PIDj||Ai||R1)⊕IDi, M4 = h(PIDi||PIDj||PIDk||Ai||R1) to construct Mesg1 = {M1, M2, M3, M4, ST1}. The adversary obtains Mesg1, selects their own timestamp TA, verifies TA-TS1≤ΔT and easily computes M3 = h(PIDi||PIDj||Ai||R1)⊕IDi and ID1 = M3⊕ h(PIDi||PIDj||Ai||R1). Then, the adversary takes two random numbers RA1 and RA2 and computes M9 = h(RA1||RA2) and can easily compute SKij = h(PIDi**||PIDj||PIDk||M9). Thus, the secrecy of the method in [33] is compromised, and it cannot deliver reliable services to the IoD environment. Stolen-verifier attack. Suppose that someone has stolen a mobile device from a user and wants to extract the user’s sensitive internal credentials. In this case, they can easily obtain this information because it is available in {Aia, PIDiaa, Gen(.), Rep(.)} by passing Gen(BIOi) = (σi, τi), Aia = h(IDi||PWi)⊕Ai, and PIDia = h(IDi||PWi)⊕PIDa steps through the reverse engineering technique. Similarly, the drone memory has {IDj, PIDj, Aj} by computing PIDj = h(IDj||s) and Aj = h(IDj||l). Therefore, the method in [33] is not resistant to stolen-verifier attacks. Review analysis of the baseline scheme Jan et al. [33] proposed a biometric fuzzy extractor-based scheme for the cross-verification of users and drones in the IoD environment. Their scheme has two main phases, registration and verification, which are explained in the following subsection. The notations used for the design of their scheme are shown in Table 2. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 2. Notations and their meaning. https://doi.org/10.1371/journal.pone.0314475.t002 Registration phase. The registration phase in [33] is completed in the following steps: This phase is completed by first registering a user with the GCS and then a drone. The identity and password are sent to the GCS through a secure channel for user registration. When receiving the registration message from a user, the GCS calculates PIDi = h(IDi||s), Ai = h(IDi||l), where l is a large secret number and s is the public key. The GCS injects {PIDi, Ai, IDi} in its memory and replays {PIDi, Ai} to the user. The user then receives the response message from the GCS and is asked to enter their biometrics BIOi, calculate Gen(BIOi) = (σi, τi), Ai = h(IDi||PWi)⊕Ai, and PIDi = h(IDi||PWi)⊕PIDi and inject {Ai, PIDi, Gen(.), Rep(.)} in their mobile device memory. The drone is also registered with the GCS through a secure channel and sends its identity to the GCS. The GCS calculates PIDj = h(IDj||s) and Aj = h(IDj||l), injects {IDj, PIDj, Aj} and replays {PIDj, Aj} back to the drone. The drone also injects {PIDj, Aj} into the device memory. Verification phase. As detailed in [33], this phase is accomplished in the following steps: The user provides their identity, password, and biometrics. The device with the user calculates σi* = Rep(BIOi, τi), PIDi = PIDi⊕h(IDi||PWi), Ai = Ai*⊕h(IDi||PWi), selects R1, ST1 and calculates M1 = h(PIDj||ST1)⊕PIDi, M2 = h(PIDi||PIDj||Ai)⊕R1, M3 = h(PIDi||PIDj||Ai||R1)⊕IDi, M4 = h(PIDi||PIDj||PIDk||Ai||R1) and sends Mesg1 = {M1, M2, M3, M4, ST1} to the GCS. The GCS confirms the time validity, calculates PIDi* = M1⊕h(PIDk||ST1), extracts Ai* and computes R1* = M2⊕h(PIDi*||PIDk||Ai*), PIDj* = M3⊕h(PIDi*||PIDk||Ai*||R1*) and M4* = h(PIDi*||PIDj*||PIDk||Ai*||R1*), validates M4*? = M4, selects ST2, calculates M5 = h(PIDj*||Aj*||ST2)⊕R1*, M6 = h(PIDj*||PIDk||Aj*||R1*)⊕PIDi*, M7 = h(PIDi*||PIDj*||PIDk||Aj*||R1*) and sends Mesg2 = {M5, M6, M7, ST2} to the drone. The drone first confirms the timestamp and calculates R1** = M5⊕h(PIDj||Aj), PIDi** = M6⊕h (PIDj||PIDk||Aj||R1**) and M7* = h(PIDi**||PIDj||PIDk||Aj||R1**), validate M7*? = M7, selects R2, ST3 calculates M8 = h(PIDj||PIDi**||ST3)⊕R2, M9 = h(R1**||R2), SKij = h(PIDi**||PIDj||PIDk||M9), M10 = h (PIDi**||PIDj||PIDk||R1**||R2||M9), replays Mesg3 = {M8, M9, M10, ST3} back to the GCS. The GCS confirms the timestamp, calculates R2* = M8⊕h(PIDj||PIDi||R1), M9* = h(R1||R2*), and M10 = h(PIDi||PIDj||PIDk||R1||R2*), validates M10*? = M10, calculates SKij = h(PIDi||PIDj||PIDk||M9*), and replays Mesg4 = {M8, M9, M10, ST4} to the user. The user confirms the timestamp, calculates R2* = M8⊕h(PIDj||PIDi||R1), M9* = h(R1||R2*), M10 = h(PIDi||PIDj||PIDk||R1||R2*), verifies M10*? = M10, calculates SKij = h(PIDi||PIDj||PIDk||M9*) and keeps it as a shared session key. Registration phase. The registration phase in [33] is completed in the following steps: This phase is completed by first registering a user with the GCS and then a drone. The identity and password are sent to the GCS through a secure channel for user registration. When receiving the registration message from a user, the GCS calculates PIDi = h(IDi||s), Ai = h(IDi||l), where l is a large secret number and s is the public key. The GCS injects {PIDi, Ai, IDi} in its memory and replays {PIDi, Ai} to the user. The user then receives the response message from the GCS and is asked to enter their biometrics BIOi, calculate Gen(BIOi) = (σi, τi), Ai = h(IDi||PWi)⊕Ai, and PIDi = h(IDi||PWi)⊕PIDi and inject {Ai, PIDi, Gen(.), Rep(.)} in their mobile device memory. The drone is also registered with the GCS through a secure channel and sends its identity to the GCS. The GCS calculates PIDj = h(IDj||s) and Aj = h(IDj||l), injects {IDj, PIDj, Aj} and replays {PIDj, Aj} back to the drone. The drone also injects {PIDj, Aj} into the device memory. Verification phase. As detailed in [33], this phase is accomplished in the following steps: The user provides their identity, password, and biometrics. The device with the user calculates σi* = Rep(BIOi, τi), PIDi = PIDi⊕h(IDi||PWi), Ai = Ai*⊕h(IDi||PWi), selects R1, ST1 and calculates M1 = h(PIDj||ST1)⊕PIDi, M2 = h(PIDi||PIDj||Ai)⊕R1, M3 = h(PIDi||PIDj||Ai||R1)⊕IDi, M4 = h(PIDi||PIDj||PIDk||Ai||R1) and sends Mesg1 = {M1, M2, M3, M4, ST1} to the GCS. The GCS confirms the time validity, calculates PIDi* = M1⊕h(PIDk||ST1), extracts Ai* and computes R1* = M2⊕h(PIDi*||PIDk||Ai*), PIDj* = M3⊕h(PIDi*||PIDk||Ai*||R1*) and M4* = h(PIDi*||PIDj*||PIDk||Ai*||R1*), validates M4*? = M4, selects ST2, calculates M5 = h(PIDj*||Aj*||ST2)⊕R1*, M6 = h(PIDj*||PIDk||Aj*||R1*)⊕PIDi*, M7 = h(PIDi*||PIDj*||PIDk||Aj*||R1*) and sends Mesg2 = {M5, M6, M7, ST2} to the drone. The drone first confirms the timestamp and calculates R1** = M5⊕h(PIDj||Aj), PIDi** = M6⊕h (PIDj||PIDk||Aj||R1**) and M7* = h(PIDi**||PIDj||PIDk||Aj||R1**), validate M7*? = M7, selects R2, ST3 calculates M8 = h(PIDj||PIDi**||ST3)⊕R2, M9 = h(R1**||R2), SKij = h(PIDi**||PIDj||PIDk||M9), M10 = h (PIDi**||PIDj||PIDk||R1**||R2||M9), replays Mesg3 = {M8, M9, M10, ST3} back to the GCS. The GCS confirms the timestamp, calculates R2* = M8⊕h(PIDj||PIDi||R1), M9* = h(R1||R2*), and M10 = h(PIDi||PIDj||PIDk||R1||R2*), validates M10*? = M10, calculates SKij = h(PIDi||PIDj||PIDk||M9*), and replays Mesg4 = {M8, M9, M10, ST4} to the user. The user confirms the timestamp, calculates R2* = M8⊕h(PIDj||PIDi||R1), M9* = h(R1||R2*), M10 = h(PIDi||PIDj||PIDk||R1||R2*), verifies M10*? = M10, calculates SKij = h(PIDi||PIDj||PIDk||M9*) and keeps it as a shared session key. Cryptanalysis of the baseline scheme After investigating the scheme presented by [33], the following loopholes/vulnerabilities/weaknesses are noted. Key disclosure attack. The adversary becomes successful if they can obtain PIDi, PIDj, and PIDk. To do so, they first have to select two random numbers RA1 and RA2, pass through a hash function to obtain M9 = h(RA1||RA2) and compute M5⊕h(PIDj||Aj), M5 = h(PIDi||Aj) and PIDi = M5⊕ h(IDj||l) to obtain PIDi. For PIDj, the adversary computes M8⊕h(PIDj||PIDi||R1), M8 = h(PIDj||PIDi||R1), and PIDj = M8⊕h(PIDi||R1). Now, to obtain PIDk, the adversary computes M2⊕h(PIDi||PIDk||Ai), M2 = h(PIDi||PIDk||Ai), and PIDk = M2⊕h(PIDi||Ai). By obtaining PIDi, PIDj and PIDk, the adversary can easily compute the session secret key SKij = h(PIDi||PIDj||PIDk||M9) in an easy manner. Therefore, the method protocol in [33] is vulnerable to session key disclosure attacks. Perfect forward security issue. The adversary compromises all the previously transmitted messages Mesg1, Mesg2, Mesg3, and Mesg4 and reaches the secret keys s and l. For example, a legitimate user enters their identity password, imprints biometrics and computes σi* = Rep(BIOi, τi), PIDi = PIDia⊕h(IDi||PWi), Ai = Aiaa⊕h(IDi||PWi), selects R1, ST1 and calculates M1 = h(PIDj||ST1)⊕PIDi, M2 = h(PIDi||PIDj||Ai)⊕R1, M3 = h(PIDi||PIDj||Ai||R1)⊕IDi, M4 = h(PIDi||PIDj||PIDk||Ai||R1) to construct Mesg1 = {M1, M2, M3, M4, ST1}. The adversary obtains Mesg1, selects their own timestamp TA, verifies TA-TS1≤ΔT and easily computes M3 = h(PIDi||PIDj||Ai||R1)⊕IDi and ID1 = M3⊕ h(PIDi||PIDj||Ai||R1). Then, the adversary takes two random numbers RA1 and RA2 and computes M9 = h(RA1||RA2) and can easily compute SKij = h(PIDi**||PIDj||PIDk||M9). Thus, the secrecy of the method in [33] is compromised, and it cannot deliver reliable services to the IoD environment. Stolen-verifier attack. Suppose that someone has stolen a mobile device from a user and wants to extract the user’s sensitive internal credentials. In this case, they can easily obtain this information because it is available in {Aia, PIDiaa, Gen(.), Rep(.)} by passing Gen(BIOi) = (σi, τi), Aia = h(IDi||PWi)⊕Ai, and PIDia = h(IDi||PWi)⊕PIDa steps through the reverse engineering technique. Similarly, the drone memory has {IDj, PIDj, Aj} by computing PIDj = h(IDj||s) and Aj = h(IDj||l). Therefore, the method in [33] is not resistant to stolen-verifier attacks. Key disclosure attack. The adversary becomes successful if they can obtain PIDi, PIDj, and PIDk. To do so, they first have to select two random numbers RA1 and RA2, pass through a hash function to obtain M9 = h(RA1||RA2) and compute M5⊕h(PIDj||Aj), M5 = h(PIDi||Aj) and PIDi = M5⊕ h(IDj||l) to obtain PIDi. For PIDj, the adversary computes M8⊕h(PIDj||PIDi||R1), M8 = h(PIDj||PIDi||R1), and PIDj = M8⊕h(PIDi||R1). Now, to obtain PIDk, the adversary computes M2⊕h(PIDi||PIDk||Ai), M2 = h(PIDi||PIDk||Ai), and PIDk = M2⊕h(PIDi||Ai). By obtaining PIDi, PIDj and PIDk, the adversary can easily compute the session secret key SKij = h(PIDi||PIDj||PIDk||M9) in an easy manner. Therefore, the method protocol in [33] is vulnerable to session key disclosure attacks. Perfect forward security issue. The adversary compromises all the previously transmitted messages Mesg1, Mesg2, Mesg3, and Mesg4 and reaches the secret keys s and l. For example, a legitimate user enters their identity password, imprints biometrics and computes σi* = Rep(BIOi, τi), PIDi = PIDia⊕h(IDi||PWi), Ai = Aiaa⊕h(IDi||PWi), selects R1, ST1 and calculates M1 = h(PIDj||ST1)⊕PIDi, M2 = h(PIDi||PIDj||Ai)⊕R1, M3 = h(PIDi||PIDj||Ai||R1)⊕IDi, M4 = h(PIDi||PIDj||PIDk||Ai||R1) to construct Mesg1 = {M1, M2, M3, M4, ST1}. The adversary obtains Mesg1, selects their own timestamp TA, verifies TA-TS1≤ΔT and easily computes M3 = h(PIDi||PIDj||Ai||R1)⊕IDi and ID1 = M3⊕ h(PIDi||PIDj||Ai||R1). Then, the adversary takes two random numbers RA1 and RA2 and computes M9 = h(RA1||RA2) and can easily compute SKij = h(PIDi**||PIDj||PIDk||M9). Thus, the secrecy of the method in [33] is compromised, and it cannot deliver reliable services to the IoD environment. Stolen-verifier attack. Suppose that someone has stolen a mobile device from a user and wants to extract the user’s sensitive internal credentials. In this case, they can easily obtain this information because it is available in {Aia, PIDiaa, Gen(.), Rep(.)} by passing Gen(BIOi) = (σi, τi), Aia = h(IDi||PWi)⊕Ai, and PIDia = h(IDi||PWi)⊕PIDa steps through the reverse engineering technique. Similarly, the drone memory has {IDj, PIDj, Aj} by computing PIDj = h(IDj||s) and Aj = h(IDj||l). Therefore, the method in [33] is not resistant to stolen-verifier attacks. Proposed protocol The drone-to-drone communication security framework has three main phases: setup, registration, and mutual authentication, as described in the following subsection. The symbols used for designing the scheme are shown in Table 3. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 3. Symbols and their meanings. https://doi.org/10.1371/journal.pone.0314475.t003 Setup phase The GCS selects a point P from the elliptic curve E(FP) over EP(x, y), chooses a secret key s, and calculates the ECC-based public key PGCS = s. P, selects h(.) and publishes public parameters {E(x, y), P, PGCS, h(.)} and secret key s. Registration phase Every drone first registers with the GCS and then is deployed for tasks in the IoD environment. The registration is performed once in offline mode, and the real identity of each drone is communicated over a secure channel. The process of registration is undertaken in the following steps: Drone1 registration. This phase of the protocol is accomplished in takes the following steps of computations: Step 1: The first drone selects an identity IDD1 and random number LD1, calculates RD1 = h(IDD1||LD1) and sends {IDD1, RD1} to the GCS. Step 2: The GCS, after receiving the {IDD1, RD1} message, checks the identity of the drone in the record; if it is found, the GCS sends a message to the drone to select a unique identity; if not found, the GCS invokes its public key PGCS and computes YD1 = PGCS⊕h(IDD1||LD1||s). Step 3: The GCS now calculates the pseudo-identity for the first drone, where SIDD1 = h(YD1. T||IDD1) and pseudo-identity for the second drone, SIDD2 = h(YD2. T||IDD2) and builds a long-term shared key KSDD = h(PGCS||IDD1||IDD2||YD1||YD2) and sends {YD1, SIDD1, SIDD2, KSDD} to the first drone and second drone. Now, the memory of both the first and second drones contains {YD1, SIDD1, SIDD2, KSDD} parameters, as shown in Fig 2. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 2. Registration of the first drone (D1) with the GCS. https://doi.org/10.1371/journal.pone.0314475.g002 Drone2 registration. This phase takes the following steps: Step 1: The second drone selects an identity IDD2 and random number LD2, calculates RD2 = h(IDD2||LD2) and sends {IDD2, RD2} to the GCS. Step 2: The GCS, after receiving the {IDD2, RD2} message, checks the identity of the drone in the record; if it is found, the GCS sends a message to the drone to select a unique identity; if not found, the GCS invokes its public key PGCS and computes YD2 = PGCS⊕h(IDD2||LD2||s). Step 3: The GCS now calculates the pseudo-identity for the first drone, where SIDD1 = h(YD1. T||IDD1), and the pseudo-identity for the second drone is SIDD2 = h(YD2. T||IDD2) and builds a long-term shared key KSDD = h(PGCS||IDD1||IDD2||YD1||YD2) and sends {YD1, SIDD1, SIDD2, KSDD} to the first drone and second drone. Now, the memory of both the first and second drones contains {YD1, SIDD1, SIDD2, KSDD} parameters, as shown in Fig 3. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 3. Registration of the second drone (D2) with the GCS. https://doi.org/10.1371/journal.pone.0314475.g003 Mutual authentication The mutual authentication is undertaken in two round trips or three computation steps, explained as follows: Step 1: The first drone selects timestamp T, computes Z1 = h(KSDD⊕PD1), recovers SIDD1 from storage, generates a nonce Nd1 and computes Z2 = Nd1. P, Z3 = Nd1. PD2, Z4 = SIDD1||Z1||T) ⊕(Z3||KSDD) and replays {Z3, Z4} to the second drone over an insecure channel. Step 2: After receiving the {Z3, Z4, T} message, the second drone validates the time stamp Tc-T≤ΔT, selects time T and nonce Nd2, and computes ECC-key PD2 = Nd2. P, Z3* = Nd2. PD1, confirms Z3*? = Z3, if validated, computes (Z3*||KSDD), revokes SIDD2, computes Z1* = h(KSDD⊕PD2), Z4* = (SIDD2||Z1*||T) ⊕(Z3*||SKDD), verifies Z4*? = Z4, if matched, computes the shared session key SKd2 = h(KSDD||Z3||Z3*||T) and sends {Z3*, Z4*} back to the first drone. Step 3: The first drone, after receiving the {Z1*, Z4*, T} message, validates the time stamp Tc-T≤ΔT, selects time and nonce Nd1 and again calculates the ECC key Z3** = Nd1. PD1 where PD1 = Nd1. P, confirms Z3**? = Z3* if validated, builds (Z3*||KSDD), computes Z1** = h(KSDD⊕PD1), Z4** = (SIDD2||Z1**||T), verifies Z4**? = Z4*, and if matched, computes the session key SKd1 = h(KSDD||Z3||Z3*||T). Now, both drones have mutually authenticated each other with the permission of the GCS, as shown in Fig 4. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 4. Drone-to-drone mutual authentication. https://doi.org/10.1371/journal.pone.0314475.g004 Setup phase The GCS selects a point P from the elliptic curve E(FP) over EP(x, y), chooses a secret key s, and calculates the ECC-based public key PGCS = s. P, selects h(.) and publishes public parameters {E(x, y), P, PGCS, h(.)} and secret key s. Registration phase Every drone first registers with the GCS and then is deployed for tasks in the IoD environment. The registration is performed once in offline mode, and the real identity of each drone is communicated over a secure channel. The process of registration is undertaken in the following steps: Drone1 registration. This phase of the protocol is accomplished in takes the following steps of computations: Step 1: The first drone selects an identity IDD1 and random number LD1, calculates RD1 = h(IDD1||LD1) and sends {IDD1, RD1} to the GCS. Step 2: The GCS, after receiving the {IDD1, RD1} message, checks the identity of the drone in the record; if it is found, the GCS sends a message to the drone to select a unique identity; if not found, the GCS invokes its public key PGCS and computes YD1 = PGCS⊕h(IDD1||LD1||s). Step 3: The GCS now calculates the pseudo-identity for the first drone, where SIDD1 = h(YD1. T||IDD1) and pseudo-identity for the second drone, SIDD2 = h(YD2. T||IDD2) and builds a long-term shared key KSDD = h(PGCS||IDD1||IDD2||YD1||YD2) and sends {YD1, SIDD1, SIDD2, KSDD} to the first drone and second drone. Now, the memory of both the first and second drones contains {YD1, SIDD1, SIDD2, KSDD} parameters, as shown in Fig 2. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 2. Registration of the first drone (D1) with the GCS. https://doi.org/10.1371/journal.pone.0314475.g002 Drone2 registration. This phase takes the following steps: Step 1: The second drone selects an identity IDD2 and random number LD2, calculates RD2 = h(IDD2||LD2) and sends {IDD2, RD2} to the GCS. Step 2: The GCS, after receiving the {IDD2, RD2} message, checks the identity of the drone in the record; if it is found, the GCS sends a message to the drone to select a unique identity; if not found, the GCS invokes its public key PGCS and computes YD2 = PGCS⊕h(IDD2||LD2||s). Step 3: The GCS now calculates the pseudo-identity for the first drone, where SIDD1 = h(YD1. T||IDD1), and the pseudo-identity for the second drone is SIDD2 = h(YD2. T||IDD2) and builds a long-term shared key KSDD = h(PGCS||IDD1||IDD2||YD1||YD2) and sends {YD1, SIDD1, SIDD2, KSDD} to the first drone and second drone. Now, the memory of both the first and second drones contains {YD1, SIDD1, SIDD2, KSDD} parameters, as shown in Fig 3. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 3. Registration of the second drone (D2) with the GCS. https://doi.org/10.1371/journal.pone.0314475.g003 Drone1 registration. This phase of the protocol is accomplished in takes the following steps of computations: Step 1: The first drone selects an identity IDD1 and random number LD1, calculates RD1 = h(IDD1||LD1) and sends {IDD1, RD1} to the GCS. Step 2: The GCS, after receiving the {IDD1, RD1} message, checks the identity of the drone in the record; if it is found, the GCS sends a message to the drone to select a unique identity; if not found, the GCS invokes its public key PGCS and computes YD1 = PGCS⊕h(IDD1||LD1||s). Step 3: The GCS now calculates the pseudo-identity for the first drone, where SIDD1 = h(YD1. T||IDD1) and pseudo-identity for the second drone, SIDD2 = h(YD2. T||IDD2) and builds a long-term shared key KSDD = h(PGCS||IDD1||IDD2||YD1||YD2) and sends {YD1, SIDD1, SIDD2, KSDD} to the first drone and second drone. Now, the memory of both the first and second drones contains {YD1, SIDD1, SIDD2, KSDD} parameters, as shown in Fig 2. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 2. Registration of the first drone (D1) with the GCS. https://doi.org/10.1371/journal.pone.0314475.g002 Drone2 registration. This phase takes the following steps: Step 1: The second drone selects an identity IDD2 and random number LD2, calculates RD2 = h(IDD2||LD2) and sends {IDD2, RD2} to the GCS. Step 2: The GCS, after receiving the {IDD2, RD2} message, checks the identity of the drone in the record; if it is found, the GCS sends a message to the drone to select a unique identity; if not found, the GCS invokes its public key PGCS and computes YD2 = PGCS⊕h(IDD2||LD2||s). Step 3: The GCS now calculates the pseudo-identity for the first drone, where SIDD1 = h(YD1. T||IDD1), and the pseudo-identity for the second drone is SIDD2 = h(YD2. T||IDD2) and builds a long-term shared key KSDD = h(PGCS||IDD1||IDD2||YD1||YD2) and sends {YD1, SIDD1, SIDD2, KSDD} to the first drone and second drone. Now, the memory of both the first and second drones contains {YD1, SIDD1, SIDD2, KSDD} parameters, as shown in Fig 3. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 3. Registration of the second drone (D2) with the GCS. https://doi.org/10.1371/journal.pone.0314475.g003 Mutual authentication The mutual authentication is undertaken in two round trips or three computation steps, explained as follows: Step 1: The first drone selects timestamp T, computes Z1 = h(KSDD⊕PD1), recovers SIDD1 from storage, generates a nonce Nd1 and computes Z2 = Nd1. P, Z3 = Nd1. PD2, Z4 = SIDD1||Z1||T) ⊕(Z3||KSDD) and replays {Z3, Z4} to the second drone over an insecure channel. Step 2: After receiving the {Z3, Z4, T} message, the second drone validates the time stamp Tc-T≤ΔT, selects time T and nonce Nd2, and computes ECC-key PD2 = Nd2. P, Z3* = Nd2. PD1, confirms Z3*? = Z3, if validated, computes (Z3*||KSDD), revokes SIDD2, computes Z1* = h(KSDD⊕PD2), Z4* = (SIDD2||Z1*||T) ⊕(Z3*||SKDD), verifies Z4*? = Z4, if matched, computes the shared session key SKd2 = h(KSDD||Z3||Z3*||T) and sends {Z3*, Z4*} back to the first drone. Step 3: The first drone, after receiving the {Z1*, Z4*, T} message, validates the time stamp Tc-T≤ΔT, selects time and nonce Nd1 and again calculates the ECC key Z3** = Nd1. PD1 where PD1 = Nd1. P, confirms Z3**? = Z3* if validated, builds (Z3*||KSDD), computes Z1** = h(KSDD⊕PD1), Z4** = (SIDD2||Z1**||T), verifies Z4**? = Z4*, and if matched, computes the session key SKd1 = h(KSDD||Z3||Z3*||T). Now, both drones have mutually authenticated each other with the permission of the GCS, as shown in Fig 4. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 4. Drone-to-drone mutual authentication. https://doi.org/10.1371/journal.pone.0314475.g004 Analysis and discussions This section provides an analysis and discussion of the proposed drone-to-drone authentication protocol, which can be performed via worldwide techniques. These are explained as follows: Security analysis through BAN logic The security analysis of the proposed scheme can be conducted via the well-known and widely used authentication logic called BAN [43]. The statements are shown in Table 4. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 4. Statements and their pronunciations. https://doi.org/10.1371/journal.pone.0314475.t004 Message Meaning Rule: This means that if D1 believes the shared secret among D1 and D2 through key Z3 and sees the encryption of Message M via key K, then D1 believes D2 once Said Message M. (R1) Verification rule: This means that if D1 believes the shared secret among D1 and D2 through key Z3 and sees the encryption of M via key K, then D1 believes D2 and has complete jurisdiction over Message M. (R2) Freshness rule: If party D1 believes the freshness of Message M, then D2 also believes the freshness of M (R3) Jurisdiction rule: If D1 believes the freshness of M and D1 believes D2 has jurisdiction over M, then D1 believes D2 believes the full jurisdiction over Message M. (R4) Message contents. Drone 1 believes the transmission of message {Z3, Z4} between drone 1 and drone 2 (MC1) Drone 2 believes the transmission of message {Z3, Z4} between drone 1 and drone 2 (MC2) Drone 2 believes the transmission of message {Z3*, Z4*} between drone 2 and drone 1 (MC4) Drone 1 believes the transmission of message {Z3*, Z4*} between drone 2 and drone 1 (MC5) Idealization. Drone 1 believes drone 2 believes the nonce they have generated (I1) Drone 1 believes drone 2 believes the ECC point they have chosen from the curve (I2) Drone 1 believes drone 2 believes the hash code and public key constituted (I3) Drone 2 believes drone 1 believes the nonce they have generated (I4) Drone 2 believes drone 1 believes the hash codes and ECC key (I5) Drone 2 believes drone 1 the nonce generated (I6) Drone 2 believes drone 1 the ECC point chosen (I7) Drone 2 believes drone 1 the message and all its credentials (I8) Drone 1 believes drone 2 believes the nonce of drone 2 (I9) Drone 1 believes drone 2 the message and all its credentials (I10) Goals. (G1)(G2)(G3)(G4)(G5)(G6) 1. Assumptions. (A1)(A2)(A3)(A4)(A5)(A6)(A7)(A8)(A9)(A10)(A11)(A12)(A13)(A14)(A15)(A16)(A17)(A18)(A19)(A20)(A21)(A22) Proof. The message contents, idealizations and assumptions are used to prove the goals. Taking MC1, I1, and A1, we obtain (1) Eqs (1), (I7) and (A7) yield (2) Eqs (2), (I9), (I10) and (A15) yield (3) Eqs (3), (MC2) and (A17) (4) Eq (4) can be written as (5) Eqs (5), (I2), (I3) and (A12) (6) and (7) Eqs (6) and (7) can be expressed as (G1—Achieved) (G2—Achieved) According to G1, G2, and Eq (5), the result obtained as follows: (G3—Achieved) Taking MC2, I4, and A3, we obtain (8) Eqs (8), (I5) and (A8) yield (9) Eqs (9), (I6), (I7) and (A16) yield (10) Eqs (10), (MC4) and (A18) (11) Eq (11) can be written as (12) Eqs (12), (I8), (I9) and (A12) (13) and (14) and (15) Eqs (13), (14) and (15) can be expressed as (G4—Achieved) (G5—Achieved) According to G4, G5, and Eq (12), the result obtained as follows: (G6—Achieved) Security analysis through ProVerif ProVerif [44], a worldwide verification software toolkit, verifies the session key’s secrecy, confidentiality, authorization, and reachability. In this context, we first define two channels, i.e., private and public, and then define all the variables, constraints, constants, equations, and queries. We then code each computation step and run the code to check for weak points as presented in separate file. If none are found, we obtain the verification summary result, which shows that the attacker cannot crack the session key at any stage and that the MITM attack is not possible on the proposed scheme. ------------------------------------------------- Verification summary: The query, not attacker(skd1[]), is true. The query, not attacker(skd2[]), is true. The query inj-event(DroneEnd(id)) ==> inj-event(DroneStart(id)) is true. ------------------------------------------------- Informal analysis This section presents an analysis of the proposed D2D mutual authentication protocol through a pragmatic discussion of different attacks. Anonymity. The message transmitted from D1 to D2 is {Z3, Z4, T}, which includes Z3 = Nd1. Z2 whereas Z2 = Nd1. P and Z4 = (SIDD1||Z1||T) ⊕(Z3||KSDD), and the message from D2 to D1 is {Z3*, Z4*, T}, which includes Z3* = Nd2. PD1 and Z4* = (SIDD2||Z1*||T) ⊕(Z3*||SKDD). All the messages are concealed from an attacker so that the location of a drone cannot be identified. If an attacker receives a message from the public channel, they do not succeed in obtaining any credentials, and a legitimate drone maintains its anonymity. Replay attack. The first drone selects a timestamp and nonce Nd1 and computes Z1 = h(KSDD⊕PD1), Z2 = Nd1. P, Z3 = Nd1. Z2 retrieves SIDD1 and computes Z4 = (SIDD1||Z1||T) ⊕(Z3||KSDD), builds {Z3, Z4, T} and sends it to D2. If an attacker obtains {Z3, Z4, T} from the open network channel, they have to pass from Tc-T≤ΔT and through many other checks, such as Z3*? = Z3 and Z4*? = Z4, which is impossible. Similarly, the second drone selects the timestamp T and nonce Nd2 and computes PD2 = Nd2. P, Z3* = Nd2. PD1, Z1* = h(KSDD⊕PD2), Z4* = (SIDD2||Z1*||T) ⊕(Z3*||SKDD), SKd2 = h(KSDD||Z3||Z3*||T) builds {Z3*, Z4*, T} and sends it to the first drone. Suppose that an attacker obtains the {Z3*, Z4*, T} message from the wireless communication channel and tries to inflict a replay attack. In this case, the attacker must validate Tc-T≤ΔT and perform many other random checks, such as Z3**? = Z3* and Z4**? = Z4*, which is impossible. Therefore, the proposed protocol is resistant to replay attacks. Insider attack. The credentials in the memory of the GCS include {YD1, SIDD1, SIDD2, KSDD} credentials consisting of YD1 = PGCS⊕h(IDD1||LD1||s), SIDD1 = h(YD1||T||IDD1), and KSDD = h(PGCS||IDD1||IDD2||YD1||YD2). Furthermore, {YD2, SIDD1, SIDD2, KSDD} credentials consist of YD2 = PGCS⊕h(IDD2||LD2||s), SIDD2 = h(YD2||T||IDD2), and KSDD = h(PGCS||IDD1||IDD2||YD1||YD2). The GCS also stores {E(x, y), P, PGCS, h(.)} and secret keys, which are 160- and 64-bit keys, respectively. Suppose that an attacker enters the GCS and acts as an insider attacker, as the GCS does not have a database table. In this case, the attacker will not be able to find anything, so their attempt will fail due to the availability of useful information in encrypted form. Therefore, the proposed D2D mutual authentication scheme is resistant to insider attacks. Key disclosure attack. The memory of the second drone consists of a shared secret key KSDD of the GCS. It selects the timestamp T and nonce Nd2 and computes PD2 = Nd2. P, Z3* = Nd2. PD1, confirms Z3*? = Z3 and computes (Z3*||KSDD) and revokes the pseudo identity SIDD2 and computes Z1* = h(KSDD⊕PD2), Z4* = (SIDD2||Z1*||T) ⊕(Z3*||SKDD), verifies Z4*? = Z4 and computes the session secret key SKd2 = h(KSDD||Z3||Z3*||T). Similarly, the first drone selects Nd1 and computes PD1 = Nd1. P, Z3** = Nd1. PD1 confirms Z3**? = Z3* and computes (Z3*||KSDD), Z1** = h(KSDD⊕PD1), Z4** = (SIDD2||Z1*||T)⊕(Z3*||KSDD), verifies Z4**? = Z4* and computes the session secret key SKd1 = h(KSDD||Z3||Z3*||T), which the attacker cannot disclose because it consists of a complex set of calculations. Stolen-verifier attack. If an attacker manages to take down or capture a drone and tries to access its internal credentials, they will be unable to do so because they are in encrypted form. The first drone selects an identity IDD1 and random number LD1, calculates RD1 = h(IDD1||LD1) and sends {IDD1, RD1} to GCS, where it invokes its public key PGCS, computes YD1 = PGCS⊕h(IDD1||LD1||s) and calculates the pseudoidentity for the first drone, SIDD1 = h(YD1. T||IDD1) and pseudoidentity for the second drone, SIDD2 = h(YD2. T||IDD2) and builds a long-term shared secret key KSDD = h(PGCS||YDD1||IDD2||YD1||YD2) and sends {YD1, SIDD1, SIDD2, KSDD} to the first drone and second drone, which they store in their memory {YD1, SIDD1, SIDD2, KSDD}. Hence, these stored credentials are secure, and an attacker will be unable to learn anything. Therefore, the proposed D2D mutual authentication protocol is resistant to stolen-verifier attacks. Forward secrecy. If any change is made to the parameters, it securely changes all the corresponding parameters because they are cross-connected. The proposed D2D mutual authentication protocol, which incorporates forward secrecy, ensures that attackers cannot compromise sensitive information. Performance analysis When measured in terms of communication and computation costs, the proposed protocol’s performance metrics yield significant results. In [44–47], the memory space occupied by the ECC key, nonce, timestamp, identity, and SHA-1 is 160 bits, 60 bits, 32 bits, 64 bits, and 256 bits, respectively. According to [44, 47], the execution time for the one-way hash (Thash) cryptographic function is 0.0046 ms, the ECC point multiplication (TMul) is 2.226 ms, the ECC point addition (TAdd) is 0.0288 ms, and the XOR and concatenation functions are zero, which should be avoided. This caution about using certain functions is important for the audience to note. Based on these results, the communication costs are the publicly exchanged messages between D1 and D2, i.e., {Z3, Z4} and {Z3*, Z4*}, resulting in a communication cost of 1344 bits. Similarly, the computational cost of the proposed protocol is 5Thash+6TMul+3TAdd, resulting in a cost of 13.5 ms. We are now comparing the proposed protocol with Jan et al. [31], Amin et al. [38], Alzahrani [41], Jan et al. [42], Algarni et al. [33], Irshad et al. [48], and Tanveer et al. [49] and underscoring the significant superiority of the proposed protocol. It not only has lower communication costs than all of the mentioned schemes but also surpasses all the mentioned schemes in terms of efficiency. The computational costs of [33, 41] may be slightly lower than those of the proposed protocol, but their communication costs are unacceptably high, as shown in Table 5 and plotted in Figs 5 and 6. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 5. Comparison of the communication cost with state-of-the-art schemes. https://doi.org/10.1371/journal.pone.0314475.g005 Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 6. Comparison of the computation cost with state-of-the-art schemes. https://doi.org/10.1371/journal.pone.0314475.g006 Download: PPT PowerPoint slide PNG larger image TIFF original image Table 5. Comparative analysis in terms of performance metrics. https://doi.org/10.1371/journal.pone.0314475.t005 It is important to note that the computational costs of the proposed protocol, while higher, are within acceptable limits, ensuring the feasibility of the protocol. This assurance of practicality is crucial for the reader. For example, Jan et al. [31]’s method for securing the IoD environment has communication costs of 3720 bits and computational costs of 17.79 milliseconds. In contrast, their work in [42] has communication costs of 2728 bits and computational costs of 31.158 milliseconds. Similarly, the authentication scheme presented by Amin et al. [38] has a communication cost of 4320 bits and a computational cost of 14.08 milliseconds, and the method proposed by Alzahrani [41] has a communication cost of 3232 bits and a computational cost of 12.447 milliseconds. Even compared with the communication costs of Algarni et al. [33], Irshad et al. [48], and Tanveer et al. [44], which are 3264-bit, 1664-bit, 3040-bit, and 4432-bit are higher than the proposed protocol, the efficiency of the proposed protocol remains unmatched. In conclusion, the D2D mutual authentication protocol’s significant superiority over its competitors is undeniable. The proposed protocol significantly outperforms existing ones in terms of performance, with impressive improvement percentages. It surpasses [31] by 63.87% in communication costs and 24.41% in computational costs. Compared to [42], the proposed scheme is 50.73% faster and 56.84% more efficient. In the case of [38], the proposed protocol is 48.88% better in communication costs and 4.49% in computation costs. It also outshines [41] by 58.41% in communication costs. While the computational costs of [41] are slightly lower than those of the proposed protocol, the overall superiority of the proposed protocol is evident. The communication cost presented by Tanveer et al. [49] is 4432 bit, which is also higher than the proposed scheme, making the proposed scheme 69.67% better than the Tanveer et al. [49] scheme in terms of communication costs as shown in Table 6 and plotted in Fig 7. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 7. Improvement in communication cost for the proposed scheme with state of the art protocols. https://doi.org/10.1371/journal.pone.0314475.g007 Download: PPT PowerPoint slide PNG larger image TIFF original image Table 6. Percentage improvement of the proposed scheme over state-of-the-art schemes. https://doi.org/10.1371/journal.pone.0314475.t006 Similarly, the communication and computation costs of the method proposed in [43] are 3264 bits and 40.211 milliseconds, respectively. In contrast, the proposed protocol offers reduced costs of 1344 bits, a significant 58.82% less than that of [41], and 13.5 milliseconds, which is a substantial 66.42% better than that of [41]. While the computational cost of [42] is marginally better than that of the proposed protocol, its communication cost is higher, and our scheme is 16.23% better. A comparison of the proposed protocol with [33] demonstrated its superiority in communication and computation costs, with percentages of improvement of 55.78% and 10.83%, respectively. Additionally, the computation cost of Tanveer et al. [49] is 36.171 ms, and the proposed scheme is 62.67% better in computation cost than [49]. Most importantly, the proposed protocol effectively balances security with performance, a crucial aspect often missing in prior works, thereby instilling confidence in its effectiveness and providing a sense of reassurance, as shown in Table 6 and plotted in Fig 8. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 8. Improvement in communication cost for the proposed scheme with state of the art protocols. https://doi.org/10.1371/journal.pone.0314475.g008 In this paragraph, we present a comprehensive comparison with prior works regarding the security characteristics, functionalities, and features of the proposed D2D mutual authentication protocol. The proposed D-to-D protocol provides more robust security than the four current techniques, specifically Jan et al. [31], Amin et al. [38], Alzahrani [41], Jan et al. [42], Algarni et al. [33], Irshad et al. [48], and Tanveer et al. [49], as demonstrated in Table 7. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 7. Comparative analysis in terms of security functionalities. https://doi.org/10.1371/journal.pone.0314475.t007 One problem with the work proposed in [31] is that a privileged insider attacker can create session keys with every other drone if they can access the identities of every registered drone. A problem with the work proposed in [42] is that the attacker can independently compute the session key if they register with the GCS for a previous session, which means there will be no security for the next session. However, the involvement of the GCS is no longer required in our scenario, highlighting the efficiency of our proposed D2D protocol and offering a promising solution. The inability to obtain session key agreement is an issue that arises in the work proposed in [38]. Furthermore, crucial data, such as long-term secret keys for the subsequent session, are kept in the drone’s memory in work proposed by Jan et al. [31, 37], Amin et al. [38], and Alzahrani [41], making the protocols susceptible to physical threats. When the proposed method is compared with the methods in [48, 49], the results show that the proposed D2D protocol has higher security requirements than the previous protocols do. Additionally, [49] is weak against insider attacks while safe against all attacks, and all the features are shown in Table 7; overall, our scheme is superior to its competitors. Security analysis through BAN logic The security analysis of the proposed scheme can be conducted via the well-known and widely used authentication logic called BAN [43]. The statements are shown in Table 4. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 4. Statements and their pronunciations. https://doi.org/10.1371/journal.pone.0314475.t004 Message Meaning Rule: This means that if D1 believes the shared secret among D1 and D2 through key Z3 and sees the encryption of Message M via key K, then D1 believes D2 once Said Message M. (R1) Verification rule: This means that if D1 believes the shared secret among D1 and D2 through key Z3 and sees the encryption of M via key K, then D1 believes D2 and has complete jurisdiction over Message M. (R2) Freshness rule: If party D1 believes the freshness of Message M, then D2 also believes the freshness of M (R3) Jurisdiction rule: If D1 believes the freshness of M and D1 believes D2 has jurisdiction over M, then D1 believes D2 believes the full jurisdiction over Message M. (R4) Message contents. Drone 1 believes the transmission of message {Z3, Z4} between drone 1 and drone 2 (MC1) Drone 2 believes the transmission of message {Z3, Z4} between drone 1 and drone 2 (MC2) Drone 2 believes the transmission of message {Z3*, Z4*} between drone 2 and drone 1 (MC4) Drone 1 believes the transmission of message {Z3*, Z4*} between drone 2 and drone 1 (MC5) Idealization. Drone 1 believes drone 2 believes the nonce they have generated (I1) Drone 1 believes drone 2 believes the ECC point they have chosen from the curve (I2) Drone 1 believes drone 2 believes the hash code and public key constituted (I3) Drone 2 believes drone 1 believes the nonce they have generated (I4) Drone 2 believes drone 1 believes the hash codes and ECC key (I5) Drone 2 believes drone 1 the nonce generated (I6) Drone 2 believes drone 1 the ECC point chosen (I7) Drone 2 believes drone 1 the message and all its credentials (I8) Drone 1 believes drone 2 believes the nonce of drone 2 (I9) Drone 1 believes drone 2 the message and all its credentials (I10) Goals. (G1)(G2)(G3)(G4)(G5)(G6) 1. Assumptions. (A1)(A2)(A3)(A4)(A5)(A6)(A7)(A8)(A9)(A10)(A11)(A12)(A13)(A14)(A15)(A16)(A17)(A18)(A19)(A20)(A21)(A22) Proof. The message contents, idealizations and assumptions are used to prove the goals. Taking MC1, I1, and A1, we obtain (1) Eqs (1), (I7) and (A7) yield (2) Eqs (2), (I9), (I10) and (A15) yield (3) Eqs (3), (MC2) and (A17) (4) Eq (4) can be written as (5) Eqs (5), (I2), (I3) and (A12) (6) and (7) Eqs (6) and (7) can be expressed as (G1—Achieved) (G2—Achieved) According to G1, G2, and Eq (5), the result obtained as follows: (G3—Achieved) Taking MC2, I4, and A3, we obtain (8) Eqs (8), (I5) and (A8) yield (9) Eqs (9), (I6), (I7) and (A16) yield (10) Eqs (10), (MC4) and (A18) (11) Eq (11) can be written as (12) Eqs (12), (I8), (I9) and (A12) (13) and (14) and (15) Eqs (13), (14) and (15) can be expressed as (G4—Achieved) (G5—Achieved) According to G4, G5, and Eq (12), the result obtained as follows: (G6—Achieved) Message contents. Drone 1 believes the transmission of message {Z3, Z4} between drone 1 and drone 2 (MC1) Drone 2 believes the transmission of message {Z3, Z4} between drone 1 and drone 2 (MC2) Drone 2 believes the transmission of message {Z3*, Z4*} between drone 2 and drone 1 (MC4) Drone 1 believes the transmission of message {Z3*, Z4*} between drone 2 and drone 1 (MC5) Idealization. Drone 1 believes drone 2 believes the nonce they have generated (I1) Drone 1 believes drone 2 believes the ECC point they have chosen from the curve (I2) Drone 1 believes drone 2 believes the hash code and public key constituted (I3) Drone 2 believes drone 1 believes the nonce they have generated (I4) Drone 2 believes drone 1 believes the hash codes and ECC key (I5) Drone 2 believes drone 1 the nonce generated (I6) Drone 2 believes drone 1 the ECC point chosen (I7) Drone 2 believes drone 1 the message and all its credentials (I8) Drone 1 believes drone 2 believes the nonce of drone 2 (I9) Drone 1 believes drone 2 the message and all its credentials (I10) Goals. (G1)(G2)(G3)(G4)(G5)(G6) 1. Assumptions. (A1)(A2)(A3)(A4)(A5)(A6)(A7)(A8)(A9)(A10)(A11)(A12)(A13)(A14)(A15)(A16)(A17)(A18)(A19)(A20)(A21)(A22) Proof. The message contents, idealizations and assumptions are used to prove the goals. Taking MC1, I1, and A1, we obtain (1) Eqs (1), (I7) and (A7) yield (2) Eqs (2), (I9), (I10) and (A15) yield (3) Eqs (3), (MC2) and (A17) (4) Eq (4) can be written as (5) Eqs (5), (I2), (I3) and (A12) (6) and (7) Eqs (6) and (7) can be expressed as (G1—Achieved) (G2—Achieved) According to G1, G2, and Eq (5), the result obtained as follows: (G3—Achieved) Taking MC2, I4, and A3, we obtain (8) Eqs (8), (I5) and (A8) yield (9) Eqs (9), (I6), (I7) and (A16) yield (10) Eqs (10), (MC4) and (A18) (11) Eq (11) can be written as (12) Eqs (12), (I8), (I9) and (A12) (13) and (14) and (15) Eqs (13), (14) and (15) can be expressed as (G4—Achieved) (G5—Achieved) According to G4, G5, and Eq (12), the result obtained as follows: (G6—Achieved) Security analysis through ProVerif ProVerif [44], a worldwide verification software toolkit, verifies the session key’s secrecy, confidentiality, authorization, and reachability. In this context, we first define two channels, i.e., private and public, and then define all the variables, constraints, constants, equations, and queries. We then code each computation step and run the code to check for weak points as presented in separate file. If none are found, we obtain the verification summary result, which shows that the attacker cannot crack the session key at any stage and that the MITM attack is not possible on the proposed scheme. ------------------------------------------------- Verification summary: The query, not attacker(skd1[]), is true. The query, not attacker(skd2[]), is true. The query inj-event(DroneEnd(id)) ==> inj-event(DroneStart(id)) is true. ------------------------------------------------- Informal analysis This section presents an analysis of the proposed D2D mutual authentication protocol through a pragmatic discussion of different attacks. Anonymity. The message transmitted from D1 to D2 is {Z3, Z4, T}, which includes Z3 = Nd1. Z2 whereas Z2 = Nd1. P and Z4 = (SIDD1||Z1||T) ⊕(Z3||KSDD), and the message from D2 to D1 is {Z3*, Z4*, T}, which includes Z3* = Nd2. PD1 and Z4* = (SIDD2||Z1*||T) ⊕(Z3*||SKDD). All the messages are concealed from an attacker so that the location of a drone cannot be identified. If an attacker receives a message from the public channel, they do not succeed in obtaining any credentials, and a legitimate drone maintains its anonymity. Replay attack. The first drone selects a timestamp and nonce Nd1 and computes Z1 = h(KSDD⊕PD1), Z2 = Nd1. P, Z3 = Nd1. Z2 retrieves SIDD1 and computes Z4 = (SIDD1||Z1||T) ⊕(Z3||KSDD), builds {Z3, Z4, T} and sends it to D2. If an attacker obtains {Z3, Z4, T} from the open network channel, they have to pass from Tc-T≤ΔT and through many other checks, such as Z3*? = Z3 and Z4*? = Z4, which is impossible. Similarly, the second drone selects the timestamp T and nonce Nd2 and computes PD2 = Nd2. P, Z3* = Nd2. PD1, Z1* = h(KSDD⊕PD2), Z4* = (SIDD2||Z1*||T) ⊕(Z3*||SKDD), SKd2 = h(KSDD||Z3||Z3*||T) builds {Z3*, Z4*, T} and sends it to the first drone. Suppose that an attacker obtains the {Z3*, Z4*, T} message from the wireless communication channel and tries to inflict a replay attack. In this case, the attacker must validate Tc-T≤ΔT and perform many other random checks, such as Z3**? = Z3* and Z4**? = Z4*, which is impossible. Therefore, the proposed protocol is resistant to replay attacks. Insider attack. The credentials in the memory of the GCS include {YD1, SIDD1, SIDD2, KSDD} credentials consisting of YD1 = PGCS⊕h(IDD1||LD1||s), SIDD1 = h(YD1||T||IDD1), and KSDD = h(PGCS||IDD1||IDD2||YD1||YD2). Furthermore, {YD2, SIDD1, SIDD2, KSDD} credentials consist of YD2 = PGCS⊕h(IDD2||LD2||s), SIDD2 = h(YD2||T||IDD2), and KSDD = h(PGCS||IDD1||IDD2||YD1||YD2). The GCS also stores {E(x, y), P, PGCS, h(.)} and secret keys, which are 160- and 64-bit keys, respectively. Suppose that an attacker enters the GCS and acts as an insider attacker, as the GCS does not have a database table. In this case, the attacker will not be able to find anything, so their attempt will fail due to the availability of useful information in encrypted form. Therefore, the proposed D2D mutual authentication scheme is resistant to insider attacks. Key disclosure attack. The memory of the second drone consists of a shared secret key KSDD of the GCS. It selects the timestamp T and nonce Nd2 and computes PD2 = Nd2. P, Z3* = Nd2. PD1, confirms Z3*? = Z3 and computes (Z3*||KSDD) and revokes the pseudo identity SIDD2 and computes Z1* = h(KSDD⊕PD2), Z4* = (SIDD2||Z1*||T) ⊕(Z3*||SKDD), verifies Z4*? = Z4 and computes the session secret key SKd2 = h(KSDD||Z3||Z3*||T). Similarly, the first drone selects Nd1 and computes PD1 = Nd1. P, Z3** = Nd1. PD1 confirms Z3**? = Z3* and computes (Z3*||KSDD), Z1** = h(KSDD⊕PD1), Z4** = (SIDD2||Z1*||T)⊕(Z3*||KSDD), verifies Z4**? = Z4* and computes the session secret key SKd1 = h(KSDD||Z3||Z3*||T), which the attacker cannot disclose because it consists of a complex set of calculations. Stolen-verifier attack. If an attacker manages to take down or capture a drone and tries to access its internal credentials, they will be unable to do so because they are in encrypted form. The first drone selects an identity IDD1 and random number LD1, calculates RD1 = h(IDD1||LD1) and sends {IDD1, RD1} to GCS, where it invokes its public key PGCS, computes YD1 = PGCS⊕h(IDD1||LD1||s) and calculates the pseudoidentity for the first drone, SIDD1 = h(YD1. T||IDD1) and pseudoidentity for the second drone, SIDD2 = h(YD2. T||IDD2) and builds a long-term shared secret key KSDD = h(PGCS||YDD1||IDD2||YD1||YD2) and sends {YD1, SIDD1, SIDD2, KSDD} to the first drone and second drone, which they store in their memory {YD1, SIDD1, SIDD2, KSDD}. Hence, these stored credentials are secure, and an attacker will be unable to learn anything. Therefore, the proposed D2D mutual authentication protocol is resistant to stolen-verifier attacks. Forward secrecy. If any change is made to the parameters, it securely changes all the corresponding parameters because they are cross-connected. The proposed D2D mutual authentication protocol, which incorporates forward secrecy, ensures that attackers cannot compromise sensitive information. Anonymity. The message transmitted from D1 to D2 is {Z3, Z4, T}, which includes Z3 = Nd1. Z2 whereas Z2 = Nd1. P and Z4 = (SIDD1||Z1||T) ⊕(Z3||KSDD), and the message from D2 to D1 is {Z3*, Z4*, T}, which includes Z3* = Nd2. PD1 and Z4* = (SIDD2||Z1*||T) ⊕(Z3*||SKDD). All the messages are concealed from an attacker so that the location of a drone cannot be identified. If an attacker receives a message from the public channel, they do not succeed in obtaining any credentials, and a legitimate drone maintains its anonymity. Replay attack. The first drone selects a timestamp and nonce Nd1 and computes Z1 = h(KSDD⊕PD1), Z2 = Nd1. P, Z3 = Nd1. Z2 retrieves SIDD1 and computes Z4 = (SIDD1||Z1||T) ⊕(Z3||KSDD), builds {Z3, Z4, T} and sends it to D2. If an attacker obtains {Z3, Z4, T} from the open network channel, they have to pass from Tc-T≤ΔT and through many other checks, such as Z3*? = Z3 and Z4*? = Z4, which is impossible. Similarly, the second drone selects the timestamp T and nonce Nd2 and computes PD2 = Nd2. P, Z3* = Nd2. PD1, Z1* = h(KSDD⊕PD2), Z4* = (SIDD2||Z1*||T) ⊕(Z3*||SKDD), SKd2 = h(KSDD||Z3||Z3*||T) builds {Z3*, Z4*, T} and sends it to the first drone. Suppose that an attacker obtains the {Z3*, Z4*, T} message from the wireless communication channel and tries to inflict a replay attack. In this case, the attacker must validate Tc-T≤ΔT and perform many other random checks, such as Z3**? = Z3* and Z4**? = Z4*, which is impossible. Therefore, the proposed protocol is resistant to replay attacks. Insider attack. The credentials in the memory of the GCS include {YD1, SIDD1, SIDD2, KSDD} credentials consisting of YD1 = PGCS⊕h(IDD1||LD1||s), SIDD1 = h(YD1||T||IDD1), and KSDD = h(PGCS||IDD1||IDD2||YD1||YD2). Furthermore, {YD2, SIDD1, SIDD2, KSDD} credentials consist of YD2 = PGCS⊕h(IDD2||LD2||s), SIDD2 = h(YD2||T||IDD2), and KSDD = h(PGCS||IDD1||IDD2||YD1||YD2). The GCS also stores {E(x, y), P, PGCS, h(.)} and secret keys, which are 160- and 64-bit keys, respectively. Suppose that an attacker enters the GCS and acts as an insider attacker, as the GCS does not have a database table. In this case, the attacker will not be able to find anything, so their attempt will fail due to the availability of useful information in encrypted form. Therefore, the proposed D2D mutual authentication scheme is resistant to insider attacks. Key disclosure attack. The memory of the second drone consists of a shared secret key KSDD of the GCS. It selects the timestamp T and nonce Nd2 and computes PD2 = Nd2. P, Z3* = Nd2. PD1, confirms Z3*? = Z3 and computes (Z3*||KSDD) and revokes the pseudo identity SIDD2 and computes Z1* = h(KSDD⊕PD2), Z4* = (SIDD2||Z1*||T) ⊕(Z3*||SKDD), verifies Z4*? = Z4 and computes the session secret key SKd2 = h(KSDD||Z3||Z3*||T). Similarly, the first drone selects Nd1 and computes PD1 = Nd1. P, Z3** = Nd1. PD1 confirms Z3**? = Z3* and computes (Z3*||KSDD), Z1** = h(KSDD⊕PD1), Z4** = (SIDD2||Z1*||T)⊕(Z3*||KSDD), verifies Z4**? = Z4* and computes the session secret key SKd1 = h(KSDD||Z3||Z3*||T), which the attacker cannot disclose because it consists of a complex set of calculations. Stolen-verifier attack. If an attacker manages to take down or capture a drone and tries to access its internal credentials, they will be unable to do so because they are in encrypted form. The first drone selects an identity IDD1 and random number LD1, calculates RD1 = h(IDD1||LD1) and sends {IDD1, RD1} to GCS, where it invokes its public key PGCS, computes YD1 = PGCS⊕h(IDD1||LD1||s) and calculates the pseudoidentity for the first drone, SIDD1 = h(YD1. T||IDD1) and pseudoidentity for the second drone, SIDD2 = h(YD2. T||IDD2) and builds a long-term shared secret key KSDD = h(PGCS||YDD1||IDD2||YD1||YD2) and sends {YD1, SIDD1, SIDD2, KSDD} to the first drone and second drone, which they store in their memory {YD1, SIDD1, SIDD2, KSDD}. Hence, these stored credentials are secure, and an attacker will be unable to learn anything. Therefore, the proposed D2D mutual authentication protocol is resistant to stolen-verifier attacks. Forward secrecy. If any change is made to the parameters, it securely changes all the corresponding parameters because they are cross-connected. The proposed D2D mutual authentication protocol, which incorporates forward secrecy, ensures that attackers cannot compromise sensitive information. Performance analysis When measured in terms of communication and computation costs, the proposed protocol’s performance metrics yield significant results. In [44–47], the memory space occupied by the ECC key, nonce, timestamp, identity, and SHA-1 is 160 bits, 60 bits, 32 bits, 64 bits, and 256 bits, respectively. According to [44, 47], the execution time for the one-way hash (Thash) cryptographic function is 0.0046 ms, the ECC point multiplication (TMul) is 2.226 ms, the ECC point addition (TAdd) is 0.0288 ms, and the XOR and concatenation functions are zero, which should be avoided. This caution about using certain functions is important for the audience to note. Based on these results, the communication costs are the publicly exchanged messages between D1 and D2, i.e., {Z3, Z4} and {Z3*, Z4*}, resulting in a communication cost of 1344 bits. Similarly, the computational cost of the proposed protocol is 5Thash+6TMul+3TAdd, resulting in a cost of 13.5 ms. We are now comparing the proposed protocol with Jan et al. [31], Amin et al. [38], Alzahrani [41], Jan et al. [42], Algarni et al. [33], Irshad et al. [48], and Tanveer et al. [49] and underscoring the significant superiority of the proposed protocol. It not only has lower communication costs than all of the mentioned schemes but also surpasses all the mentioned schemes in terms of efficiency. The computational costs of [33, 41] may be slightly lower than those of the proposed protocol, but their communication costs are unacceptably high, as shown in Table 5 and plotted in Figs 5 and 6. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 5. Comparison of the communication cost with state-of-the-art schemes. https://doi.org/10.1371/journal.pone.0314475.g005 Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 6. Comparison of the computation cost with state-of-the-art schemes. https://doi.org/10.1371/journal.pone.0314475.g006 Download: PPT PowerPoint slide PNG larger image TIFF original image Table 5. Comparative analysis in terms of performance metrics. https://doi.org/10.1371/journal.pone.0314475.t005 It is important to note that the computational costs of the proposed protocol, while higher, are within acceptable limits, ensuring the feasibility of the protocol. This assurance of practicality is crucial for the reader. For example, Jan et al. [31]’s method for securing the IoD environment has communication costs of 3720 bits and computational costs of 17.79 milliseconds. In contrast, their work in [42] has communication costs of 2728 bits and computational costs of 31.158 milliseconds. Similarly, the authentication scheme presented by Amin et al. [38] has a communication cost of 4320 bits and a computational cost of 14.08 milliseconds, and the method proposed by Alzahrani [41] has a communication cost of 3232 bits and a computational cost of 12.447 milliseconds. Even compared with the communication costs of Algarni et al. [33], Irshad et al. [48], and Tanveer et al. [44], which are 3264-bit, 1664-bit, 3040-bit, and 4432-bit are higher than the proposed protocol, the efficiency of the proposed protocol remains unmatched. In conclusion, the D2D mutual authentication protocol’s significant superiority over its competitors is undeniable. The proposed protocol significantly outperforms existing ones in terms of performance, with impressive improvement percentages. It surpasses [31] by 63.87% in communication costs and 24.41% in computational costs. Compared to [42], the proposed scheme is 50.73% faster and 56.84% more efficient. In the case of [38], the proposed protocol is 48.88% better in communication costs and 4.49% in computation costs. It also outshines [41] by 58.41% in communication costs. While the computational costs of [41] are slightly lower than those of the proposed protocol, the overall superiority of the proposed protocol is evident. The communication cost presented by Tanveer et al. [49] is 4432 bit, which is also higher than the proposed scheme, making the proposed scheme 69.67% better than the Tanveer et al. [49] scheme in terms of communication costs as shown in Table 6 and plotted in Fig 7. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 7. Improvement in communication cost for the proposed scheme with state of the art protocols. https://doi.org/10.1371/journal.pone.0314475.g007 Download: PPT PowerPoint slide PNG larger image TIFF original image Table 6. Percentage improvement of the proposed scheme over state-of-the-art schemes. https://doi.org/10.1371/journal.pone.0314475.t006 Similarly, the communication and computation costs of the method proposed in [43] are 3264 bits and 40.211 milliseconds, respectively. In contrast, the proposed protocol offers reduced costs of 1344 bits, a significant 58.82% less than that of [41], and 13.5 milliseconds, which is a substantial 66.42% better than that of [41]. While the computational cost of [42] is marginally better than that of the proposed protocol, its communication cost is higher, and our scheme is 16.23% better. A comparison of the proposed protocol with [33] demonstrated its superiority in communication and computation costs, with percentages of improvement of 55.78% and 10.83%, respectively. Additionally, the computation cost of Tanveer et al. [49] is 36.171 ms, and the proposed scheme is 62.67% better in computation cost than [49]. Most importantly, the proposed protocol effectively balances security with performance, a crucial aspect often missing in prior works, thereby instilling confidence in its effectiveness and providing a sense of reassurance, as shown in Table 6 and plotted in Fig 8. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 8. Improvement in communication cost for the proposed scheme with state of the art protocols. https://doi.org/10.1371/journal.pone.0314475.g008 In this paragraph, we present a comprehensive comparison with prior works regarding the security characteristics, functionalities, and features of the proposed D2D mutual authentication protocol. The proposed D-to-D protocol provides more robust security than the four current techniques, specifically Jan et al. [31], Amin et al. [38], Alzahrani [41], Jan et al. [42], Algarni et al. [33], Irshad et al. [48], and Tanveer et al. [49], as demonstrated in Table 7. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 7. Comparative analysis in terms of security functionalities. https://doi.org/10.1371/journal.pone.0314475.t007 One problem with the work proposed in [31] is that a privileged insider attacker can create session keys with every other drone if they can access the identities of every registered drone. A problem with the work proposed in [42] is that the attacker can independently compute the session key if they register with the GCS for a previous session, which means there will be no security for the next session. However, the involvement of the GCS is no longer required in our scenario, highlighting the efficiency of our proposed D2D protocol and offering a promising solution. The inability to obtain session key agreement is an issue that arises in the work proposed in [38]. Furthermore, crucial data, such as long-term secret keys for the subsequent session, are kept in the drone’s memory in work proposed by Jan et al. [31, 37], Amin et al. [38], and Alzahrani [41], making the protocols susceptible to physical threats. When the proposed method is compared with the methods in [48, 49], the results show that the proposed D2D protocol has higher security requirements than the previous protocols do. Additionally, [49] is weak against insider attacks while safe against all attacks, and all the features are shown in Table 7; overall, our scheme is superior to its competitors. Conclusion This article presents a synergistic-assisted authentication protocol for the IoD environment, a context where drones are utilized for complex task completion. The protocol, designed using elliptic curve cryptography (ECC), a one-way hash cryptography function, and XOR operations, ensures the security of drone-to-done communication. Each drone is first registered with the ground control station (GCS) offline via a secure channel and then deployed in the IoD environment. However, a real-time secure exchange of information is crucial, necessitating rigorous authentication, which is the focus of this article. The security of the proposed protocol is thoroughly analyzed via two methods, i.e., BAN logic and ProVerif simulation, instilling confidence in its effectiveness. Its performance is evaluated in terms of communication and computation costs. Upon comparison with recent schemes from the perspective of both performance and security, it has been demonstrated that the proposed approach is robust and lightweight, ensuring secure communication in the real world for drone technology. Looking ahead, the protocol will be tested via the Scyther tool, random oracle (ROM), and real-or-random (ROR) models, and operationalized for the Quantum Key Distribution (QKD) method using a quantum key distribution network, offering a promising future for secure drone communication. Supporting information S1 File. ProVerif simulation code. https://doi.org/10.1371/journal.pone.0314475.s001 (TXT) Acknowledgments Ali Algarni and Fahad Algarni are thankful to the University of Bisha, Saudi Arabia, for their support and encouragement, while the second author, Nisreen Innab, would like to express sincere gratitude to AlMaarefa University, Riyadh, Saudi Arabia.
TI - A verifiably secure and robust authentication protocol for synergistically-assisted IoD deployment drones
JF - PLoS ONE
DO - 10.1371/journal.pone.0314475
DA - 2025-03-10
UR - https://www.deepdyve.com/lp/public-library-of-science-plos-journal/a-verifiably-secure-and-robust-authentication-protocol-for-rARxtKlVY8
SP - e0314475
VL - 20
IS - 3
DP - DeepDyve
ER -