Next Article in Journal
Approximate Computing Circuits for Embedded Tactile Data Processing
Previous Article in Journal
Transfer Learning with Social Media Content in the Ride-Hailing Domain by Using a Hybrid Machine Learning Architecture
 
 
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

Secure Authentication Scheme Using Diffie–Hellman Key Agreement for Smart IoT Irrigation Systems

Computer Science Department, College of Computer and Information Sciences, Jouf University, Sakaka 42421, Saudi Arabia
Electronics 2022, 11(2), 188; https://doi.org/10.3390/electronics11020188
Submission received: 4 December 2021 / Revised: 21 December 2021 / Accepted: 6 January 2022 / Published: 8 January 2022
(This article belongs to the Section Networks)

Abstract

:
Smart irrigation is considered one of the most significant agriculture management systems worldwide, considering the current context of water scarcity. There is a clear consensus that such smart systems will play an essential role in achieving the economic growth of other vital sectors. In general, the consequences of global warming and the unavailability of clean water sources for the agricultural sector are clear indications that the demand for these systems will increase in the near future, especially considering the recent expansions in the use of the Internet of Things (IoT) and Wireless Sensor Network (WSN) technologies, which have been employed in the development of such systems. An obvious result is that security challenges will be one of the main obstacles to attaining the widespread adoption of such systems. Therefore, this paper proposes a secure authentication scheme using Diffie–Hellman key agreement for smart IoT irrigation systems using WSNs. This scheme is based on Diffie–Hellman and one-way hash cryptographic functions in order to support the basic security services with a high data rate and ability to resist well-known attacks. The Burrows–Abadi–Needham (BAN) logic model is used to verify the proposed scheme formally. Based on various possible attack scenarios, a resistance analysis of the proposed scheme is discussed. Further analyses are performed in terms of the storage size, intercommunication, and running time costs. Therefore, the proposed scheme not only can be considered a secure authentication scheme but is also practical for smart IoT irrigation systems due to its reasonable efficiency factors.

1. Introduction

Increased demand for clean water in various vital sectors and the risks of climate change in particular geographic areas are considered the main factors that are directly affecting water availability [1]. Particularly, the consumption of fresh water in the agricultural sector is a rising concern, especially in poor and developing countries with reduced water quality and increased salinity of water [1,2]. These reasons have led to the usage of smart irrigation systems, such as smart fogging and fertigation systems [3].
The main benefit of smart internet of things (IoT) based irrigation systems consists of the remote monitoring of water usage in order to reduce water waste according to the actual needs of various crops. This applies regardless of whether the irrigation system depends on flood irrigation, spray irrigation, drip irrigation, or nebulizer irrigation. Moreover, smart IoT irrigation systems can improve agricultural productivity, provide the ability to monitor agriculture in a continuous manner, and allow for human interventions in real-time for remediation actions [4].
In general, smart IoT irrigation systems utilize a set of agricultural sensors to collect the most relevant environmental and climatic information in order to decide the amount of water that should be pumped to the crop. Different types of sensors are used for this purpose, such as humidity, rain, soil moisture, soil pH, illumination, and temperature sensors [5,6,7,8]. This environmental and climatic information is transmitted and analyzed by the service provider of the system (i.e., the system analyzer server), which forwards the processed results to the responsible agriculture professional, who can provide immediate orders to the water pumping actuators. The system analyzer server in such a system can analyze the arriving environmental and climatic information in order to predict the level of required water by utilizing different machine learning algorithms, such as decision trees, k-nearest neighbors (KNN), random forest, and support vector machine [9]. Furthermore, with recent advances, most existing smart irrigation systems have employed the Internet of Things (IoT) and Wireless Sensor Network (WSN) technologies in their development in order to achieve communication lines between the system elements [1,2,3,4,5,6,7,8].

1.1. Architecture of Smart IoT Irrigation Systems

Figure 1 shows the proposed smart IoT irrigation system architecture, where each cluster head node is responsible for a specific type of crop and requires specific environmental and climatic data. These data are collected using specific sensors, which are then analyzed to determine the required quantity of water by the service provider for such a crop. Thus, the cluster head collects the required environmental and climatic data and forwards them to the service provider periodically using an internet connection. The system analyzer server then analyzes the received data and predicts the required water quantity. According to the irrigation scheduling of the crop, the responsible agriculture professional sends a request to receive the predicted required water quantity from the service provider. The irrigation orders are then sent by the responsible agriculture professional to the assigned water pumping actuators in order to irrigate the crop by a specific cluster head node. Therefore, each agriculture professional is responsible for specific types of crops, operating through specific cluster heads.
In the same context, each cluster head should be managed and maintained by a specific operator. Finally, the authentication center server (AuC) provides authentication services to validate the identity and authority of the communication elements. Therefore, based on the characteristics of such system environments, which are proposed using IoT and WSN technologies, addressing security issues are considered an essential mission to protect the system from different attack scenarios [10].

1.2. Vulenrabilities of Samrt IoT Irrgation Systems

In terms of crop growth, smart irrigation plays a vital role in increasing crops yield but can also cause crop damage. Excessive pumping or a lack of water can lead to malnutrition, eventually causing agricultural production to become unusable [1,2,3,4,5,6,7,8,9].
An unauthorized party could also modify exchanged messages throughout insecure communication channels to transmit a wrong order by impersonating agriculture professionals. In the same context, an unauthorized party could also access the environmental and climatic information collected by sensors and cluster head nodes, leading to consequences such as the loss of private business data.
The limited capabilities of the sensor nodes themselves are considered another source of weakness. Different types of attacks can exploit these weaknesses, such as cloning of pump water data; malicious substitution of the sensor nodes, cluster head nodes, and agriculture professionals; and man-in-the-middle (MiTM) and denial-of-service (DoS) attacks [9,10,11].
The agriculture professional, cluster head nodes, and sensor nodes must be authenticated by the irrigation system to ensure their legality before transmitting the actual environmental and climatic data in order to ensure and maintain the quantity of pumped water. Therefore, authentication and a key agreement scheme provide an optimal solution to protect and achieve a high level of security in smart IoT irrigation systems [12,13,14,15,16,17,18].

1.3. Related Work

Numerous authentication schemes were proposed for IoT and WSN environments for different critical systems such as healthcare, smart homes, retail and supply chain management, and industrial IoT solutions systems [10,12]. Unfortunately, few researchers have specifically proposed authentication schemes to protect the irrigation systems and address the associated security concerns.
The healthcare IoT system is considered a closely similar system to IoT irrigation systems in terms of the used system elements and connectivity. In 2018, Amin et al. [13] proposed a new two-factor authentication scheme for WMSNs. They claimed that their authentication scheme could resist existing well-known attacks. In 2018, Ali et al. [14] demonstrated that the authentication schemes that were proposed by [13] could not withstand password guessing attacks, identity guessing, and user impersonation attacks, and proposed an enhanced three factor-based authentication protocol using wireless medical sensor networks for healthcare monitoring.
In 2019, Shuai et al. [15] proposed a three-factor authentication scheme to observe the patient remotely using WSNs. Shuai et al. [15] showed that the authentication schemes that were proposed in [13,14] cannot support the forward security and cannot resist the desynchronization attack. In 2020, Fotouhi et al. [16] showed that the authentication schemes that were proposed in [13,14] could not support sensor anonymity or perfect forward secrecy services. Therefore, they proposed a lightweight, secure two-factor authentication scheme for healthcare monitoring systems in order to prevent the mentioned attacks.
In 2021, Nashwan [17] demonstrated that the authentication schemes that were proposed by [15,16] could not withstand fully mutual authentication, sensor node anonymity, and resist the sensor node impersonation attack, and suggested an authentication scheme to support a high level of security for healthcare IoT systems using WMSNs.
According to the literature review, the only authentication scheme for irrigation systems was in 2018 and was proposed by Ali et al. [18]. It is called secure user authentication and a key-agreement scheme using wireless sensor networks for agricultural monitoring. Authors claimed that their scheme could withstand well-known attack types, providing user anonymity and other attractive security features. However, this scheme cannot fully support mutual authentication between all system elements and is susceptible to various types of attacks, such as desynchronization and smart card attacks.
It can be noticed that none of the above-proposed schemes can achieve full authentication services between all communication elements of a system (i.e., sensor nodes, authentication center, and agriculture professionals) and establish secure session keys between them to protect the exchanged data streaming. Therefore, this research paper proposes a secure authentication scheme using Diffie–Hellman key agreement for a smart IoT irrigation system in order to achieve a high level of full authentication services with plausible performance and efficiency.

1.4. Motivations and Contributions

The smart IoT irrigation systems are important in developing the agricultural sector to achieve economic growth at the global level, as they can reduce water waste according to the actual needs of various crops, improve agricultural productivity, provide the ability to monitor agriculture in a continuous manner, and allow for human interventions in real-time for suitable remediation actions. An authentication scheme by integrating the smart IoT irrigation systems with WSN features can make such systems more secure and widely used. The main contributions of this research can be summarized as follows.
  • An architecture for the smart IoT irrigation systems using WSN is proposed, including the main authentication components and the communication flow;
  • An authentication scheme for smart IoT irrigation is proposed to achieve simultaneous full authentication services for all elements in the system;
  • The proposed scheme used Diffie–Hellman cryptographic method to achieve the key agreement service in an innovative way wherein all cryptographic parameters were hidden using a set of one-way-hash functions;
  • The Burrows–Abadi–Needham (BAN) logic model was used to verify mutual authentication between the components of the system;
  • Informally, common attack scenarios were assumed and discussed in order to demonstrate that the proposed scheme can resist all related well-known attacks. Comparisons with other existing schemes in terms of security and efficiency features are presented;
  • Finally, the results obviously show that the proposed scheme is feasible to use, with reasonable computation and communication outcomes.

1.5. Paper Organization

The remainder of this paper is organized as follows: The proposed scheme is presented in Section 2. In the first part of Section 3, the formal analysis using BAN logic is presented, while an informal analysis of the security achievements, resistance against well-known attacks, and comparisons with recently proposed schemes are provided in the second and third parts of Section 3. Section 4 details the performance evaluation of the proposed scheme. Finally, the conclusion is given in Section 5.

2. Proposed Scheme

This section proposes a secure authentication scheme using Diffie–Hellman key agreement for a smart IoT irrigation system using WSNs. The smart IoT irrigation system contains four main communication elements, namely, the agriculture professional (AP), authentication server (AuC), cluster head (CH), and agriculture sensor (AS).
Furthermore, the proposed scheme includes nine phases, namely, the registration phase for AP, registration phase for CH, the registration phase for AS, login phase for AP, login phase for CH, authentication and session key agreement phase, AS authentication phase, password change phase for AP, and password change phase for CH. The main cryptographic techniques that are used to achieve the desired security services are the discrete logarithm problem (Diffie–Hellman technique) and one-way hash functions [12]. Finally, the basic notation used to present the proposed scheme in the following is listed in Table 1.

2.1. Registration Phase of Agriculture Professional

In this phase, the agriculture professional (APi) is registered by the authentication center (AuC). This phase is accomplished over a secure channel, according to the following steps:
Step1: A new (APi) chooses their identity (APIDi), password (PWi), and secret code (Si). Then, the APi generates a random number (R0) and computes Ci = h (APIDi‖PWi‖R0). The APi then sends the registration request message [APIDi, Ci, Si] to the AuC.
Step2: In response to the registration request, the AuC verifies the presence of the identity (APIDi) in the agricultural professional database. If present, the AuC refuses the registration request and prompts the APi to choose another identity number. Otherwise, the AuC chooses a big prime number (P), selects a generator number α, where α is an integer number (2 ≤ α ≤ P − 2). Then, the AuC selects an integer number βi, where βi is a private integer number (2 ≤ βi ≤ P − 2).
Next, the AuC generates the Ai0 value, where Ai0 = ((α ^ βi) mod P). Then, the AuC generates a random number (R1), initiates the session number SeNi = h (R1), and computes APFi = (Ai0 ⊕ Si) and APVi = h ((SeNi‖Si) ⊕ (Ci‖Ai0)). Next, the AuC initiates the pseudonym identities APIDip = h (APIDi‖SeNi) and APIDis = Φ, where Φ is an empty value. Then, the AuC inserts the APi’s record (APIDi, APIDip, APIDis, SeNi) into the agriculture professional database. The AuC then personalizes the smart card (SCi) with authentication parameters (α, P, SeNi, APFi, APVi), initiates the counter (C0ij = 0), create the cluster head list to connect the APi with their cluster heads as [CHIDj, C0ij], and provides the SCi to the APi.
Step3: The APi receives the SCi and then inserts R0 and the cluster head list into the memory of their device securely.

2.2. Registration Phase of Cluster Head

In this phase, the cluster head (CHj) is registered by the AuC, and the operator of the CHj becomes an authorized user. This phase is accomplished over a secure channel, according to the following steps:
Step1: The operator of a new CHj selects their identity (CHIDj), password (PWj), and secret code (Sj). Then, CHj generates a random number R2 and computes Cj = h (CHIDj‖PWj‖R2). CHj then sends the registration request message (CHIDj, Cj, Sj) to the AuC.
Step2: In response to the registration request, the AuC verifies the presence of the identity (CHIDj) in the cluster head database. If present, the AuC refuses the registration request and prompts the CHj to choose another identity number. Otherwise, the AuC selects an integer number βj, where βj is a private integer number (2 ≤ βj ≤ P − 2). Then, the AuC generates the value Aj0, where Aj0 = ((α ^ βj) mod P), generates a random number R3, initiates SeNj = h (R3), and computes SeN = (Sj ⊕ SeNj), CHFj = (Aj0 ⊕ Sj), and CHVj = h ((SeNj‖Sj) ⊕ (Cj‖Aj0)). Then, the AuC initiates the pseudonym identities CHIDjp = CHIDjs = Φ, assigns a specific APi to the CHj, and updates the cluster head list for APi securely.
Next, the AuC inserts CHj’s record (CHIDj, CHIDjp, CHIDjs, SeNj) into the cluster head database, personalize the authentication parameters (α, P, SeN, CHFj, and CHVj) into a new SCj, and provides the SCj to the CHj.
Step3: The operator of CHj receives the SCj, saves R2 into their device, and initiates CH1j = 0.

2.3. Registration Phase of Agriculture Sensor

This phase prevents the agriculture sensor (ASk) from being used by someone other than the actual cluster head CHj. This phase is accomplished over a secure channel, according to the following steps:
Step1: A new ASk sends the registration request message (ASIDk) to the CHj, where the identity value (ASIDk) of ASk was determined when it had been created by the service provider.
Step2: In response to the registration request, CHj initiates a session number, Snk0 = R7, randomly and the sequence numbers Sn0 = Sn1 = 0. Next, CHj inserts the ASk’s record into its sensors table [ASIDk, Sn0, Snk0] and sends the response message (Sn1, SNk0) to the SNk.
Step3: A new ASk saves [Sn1, Snk0] into its memory securely.

2.4. Login Phase of Agriculture Professional

To receive the predicted required water quantity from the service provider and send the irrigation order to water pumping actuators by a specific cluster head (CHj), the APi authenticates himself to their smart card, SCi, according to the following steps:
Step1: The APi enters their credential parameters (APIDi, PWi, and Si) as a login request into their Sci.
Step2: In the response to the login request, the SCi fetches R0, computes Ci = h (APIDi‖PWi‖R0), Ai0 = (APFi ⊕ Si), and XAPVi = h ((SeNi‖Si) ⊕ (Ci‖Ai0)). Then, the SCi examines whether XAPVi matches with the APVi that was stored in its memory by the AuC. If XAPVi ≠ APVi, the SCi refuses the request and closes the authentication session. Otherwise, the login request will be valid and the APi is considered an authorized user.
Step3: The SCi initiates IDi = h (APIDi‖SeNi) and selects integer numbers δ1 and δ2, where δ1 and δ2 are private integer numbers (2 ≤ δ1, δ2 ≤ P − 2). Next, SCi computes the value Ai1, where Ai1 = ((α ^ δ1) mod P, computes Ai2, where Ai2 = ((α ^ δ2) mod P), and generates the private key value Ki, where Ki = ((Ai0 ^ δ1) mod P).

2.5. Login Phase of Cluster Head

To send the environmental and climatic information collected by the agricultural sensors to the service provider and receive the irrigation orders from the APi, CHj authenticates himself to their smart card SCj, according to the following steps:
Step1: The operator of the CHj enters the credential parameters (CHIDj, PWj, and Sj) as a login request to the SCj.
Step2: In the response to the login request, the SCj fetches R2 and computes SeNj = (Sj ⊕ SeN), Cj = h (CHIDj‖PWj‖R2), Aj0 = (CHFj ⊕ Sj), and XCHVj = h ((SeNj‖Sj) ⊕ (Cj ‖Aj0)). Then, SCj examines whether XCHVj matches with the CHVj that was stored in its memory by the AuC. If XCHVj ≠ CHVj, the SCj refuses the request and closes the authentication session. Otherwise, the login request will be valid, and the CHj will be used by an authorized operator.
Step3: SCj selects an integer number δ3, where δ3 is a private integer number (2 ≤ δ3 ≤ P − 2). Next, SCj computes the value Aj1, where Aj1 = ((α ^ δ3) mod P), stores δ3, and sends Aj1 to the AuC.
Step4: The AuC receives and enters the value of Aj1 into the CHj’s record.

2.6. Authentication and Session Key Agreement Phase

In this phase, the APi needs to achieve mutual authentication with the AuC and CHj, as well as establish a shared session key with the CHj through insecure communication channels. Figure 2 summarizes the authentication and session key agreement phase between the APi, CHj, and AuC. The following steps are executed at this phase after the login phases of the APi and CHj have been executed.
Step1: The APi initiates the authentication request via their SCi by inserting the identity of the CHj (CHIDj). Then, the APi computes CTi0 = EKi (T0‖Ai2‖CHIDj) and Vi0 = h (T0‖Ai2‖SeNi), where T0 is the current timestamp of the APi. Then, the APi sends an authentication request [M1= IDi, Ai1, CTi0, Vi0] to the AuC.
Step2: Upon receiving the APi’s request, the AuC searches in the agriculture professional database to find APIDip and APIDis values based on the IDi received from the APi. One of the following four events will be triggered by the AuC, which were previously employed in [10,17,19] to achieve user anonymity services.
In the first event, wherein IDi ≠ APIDip and IDi ≠ APIDis, the AuC refuses the authentication request and closes the authentication session.
In the second event, wherein IDi = APIDip and APIDis ≠ Φ, the AuC computes SeNi = h (SeNi), generates Ki = ((Ai1 ^ βi) mod P), and decrypts DKi (CTi0) = (T0‖Ai2‖CHIDj). The AuC then examines whether the APi can access CHj with identity CHIDj. If it does not satisfy the conditions, the AuC refuses the authentication request and closes the authentication session. Otherwise, the AuC examines the value of T0. If it does not hold, the AuC refuses the authentication request and closes the authentication session. Otherwise, AuC calculates XVi0 = h (T0‖Ai2‖SeNi) in order to examine whether XVi0 matches with the Vi0 that was received. If XVi0 = Vi0, the AuC updates the following identity values APIDis = APIDip and APIDip = h (IDi‖Ai2), respectively. Otherwise, the AuC refuses the authentication request and closes the authentication session.
In the third event, wherein IDi = APIDip and APIDis = Φ, the AuC generates Ki = ((Ai1 ^ βi) mod P) and decrypts DKi (CTi0) = (T0‖Ai2‖CHIDj). Then, the AuC examines whether the APi can access CHj with identity CHIDj. If not, the AuC refuses the authentication request and closes the authentication session. Otherwise, the AuC examines the value of T0. If it does not hold, the AuC refuses the authentication request and closes the authentication session. Otherwise, the AuC calculates XVi0 = h (T0‖Ai2‖SeNi) in order to examine whether XVi0 matches with the Vi0 that was received. If XVi0 = Vi0, the AuC updates the following identity values APIDis = APIDip and APIDip = h (IDi‖Ai2), respectively. Otherwise, the AuC refuses the authentication request and closes the authentication session.
In the fourth event, wherein IDi = APIDis, the AuC generates Ki = ((Ai1 ^ βi) mod P) and decrypts DKi (CTi0) = (T0‖Ai2‖CHIDj). Then, the AuC examines whether the APi can access CHj with identity CHIDj. If it does not satisfy, AuC refuses the authentication request and closes the authentication session. Otherwise, the AuC examines the value of T0. If it does not hold, the AuC refuses the authentication request and closes the authentication session. Otherwise, the AuC calculates XVi0 = h (T0‖Ai2‖SeNi) to examine whether the XVi0 matches with the Vi0 that was received. If XVi0 = Vi0, the AuC updates the identity value of the APIDip = h (IDi‖Ai2). Otherwise, the AuC refuses the authentication request and closes the authentication session.
Step3: Using the values of APIDi and CHIDj, the AuC fetches CHj’s record from the cluster head database. Then, the AuC calculates Kj = ((Aj1 ^ βj) mod P), initiates the session counter CH0j = (CH0j + 1), computes the pseudonym identity of the cluster head CHIDjp = h (CHIDj‖CHIDjp), and calculates SeNj = h (SeNj). Next, the AuC generates a random number R4 and computes CTj0 = EKj (T1‖R4‖Ai2) and Vj0 = h (T1‖Ai2‖CHIDjp‖R4), where T1 represents the current timestamp of the AuC. The AuC then sends an authentication request [M2 = CH0j, CTj0, and Vj0] to CHj.
Step4: In response to the authentication request, CHj, by its SCj, computes ΔCH01j = (CH0j – CH1j) and checks whether the value of ΔCH01j satisfies (1 ≤ ΔCH01j ≤ µ2), where the value of µ2 is assigned according to the irrigation system specifications. If it does not hold, CHj refuses the authentication request and closes the authentication session. Otherwise, it retrieves the value of the SeNj = (Sj ⊕ SeN) and computes SeNj = h (SeNj) ΔCH01j − 1 times, until (ΔCH01j − 1) = 1. Then, CHj updates SeN = (Sj ⊕ SeNj), generates Kj, where Kj = ((Aj0 ^ δ3) mod P), and computes DKj (CTj0) = (T1‖R4‖Ai2). Next, CHj examines the value of T1. If it does not hold, the CHj refuses the authentication request and closes the authentication session. Otherwise, CHj sets CHIDjs = CHIDjp and computes CHIDjs = h (CHIDj‖CHIDjs) ΔCH01j − 1 times, until (ΔCH01j − 1) = 1. Then, CHj computes XVj0 = h (T1‖Ai2‖CHIDjs‖R4) in order to verify whether XVj0 matches the Vj0 that was received. If XVj0 ≠ Vj0, CHj refuses the authentication request and closes the authentication session. Otherwise, the AuC is considered an authorized server. CHj then chooses an integer number δ4, where δ4 is a private integer number (2 ≤ δ4 ≤ P − 2), computes Aj2, where Aj2 = ((α ^ δ4) mod P), generates a random number R5 and computes CTj1 = EKj (T2‖R5‖Aj2) and Vj1 = h (T2‖Aj2‖CHIDjs‖R5), where T2 is the current timestamp of CHj. Next, CHj sets CHC1ij = CHC0ij and computes the session key Kij with APi, where Kij = (Ai2 ^ δ4) mod P. Finally, CHj sends the response authentication [M3 = CHIDjs, CTj1, and Vj1] to the AuC.
Step5: Upon receiving the response message, the AuC computes DKj(CTj1) = (T2‖R5‖Aj2), where the pseudonym identity CHIDjs = CHIDjp. Then, the AuC examines the value of T2. If it does not satisfy, the AuC refuses the response message and closes the authentication session. Otherwise, AuC computes XVj1 = h (T2‖Aj2‖CHIDjs‖R5) in order to examine whether XVj1 matches Vj1. If XVj1 ≠ Vj1, the AuC refuses the response message and closes the authentication session. Otherwise, the CHj is considered a legitimate node and can be used by an authorized operator. The AuC then generates a random number R6 and computes CTi1 = EKi (R6‖Aj2‖T3), where T3 is the current timestamp of the AuC. Then, the AuC computes Vi1 = h (APIDi‖Aj2‖R6‖SeNi‖T3) and sends the response authentication [M4 = CTi1, Vi1] to the APi.
Step6: When the response message is received, the APi computes DKi (CTi1) = (R6‖Aj2‖T3). Then, the APi examines the value of T3. If it does not hold, APi refuses the response message and closes the authentication session. Otherwise, the APi computes XVi1 = h (APIDi‖Aj2‖R6‖SeNi‖T3), in order to examine whether XVi1 matches with Vi1. If XVi1 ≠ Vi1, the APi refuses the response message and closes the authentication session, Otherwise, AuC is considered an authorized server. APi then computes Vi2 = h (APIDi‖R6‖SeNi‖(T4 − T3)) and Vix = ((T4 ⊕ T3)‖Vi2), where T4 is the current timestamp of the APi. Then, they update SeNi = h (SeNi) and set IDi = h (IDi‖Ai2), sending an acknowledgment [M5 = IDi, Vix] to the AuC. Finally, the APi computes the session key Kij with CHj, as Kij = (Aj2 ^ δ2) mod P.
Step7: Upon receiving M5, the AuC computes T4 = ((T4 ⊕ T3) ⊕ T3) and ΔTP = (T4 − T3). Then, the AuC examines whether the value of ΔTP holds, according to the value of µ3, where µ3 is determined based on the irrigation system requirements. If it does not hold, the AuC sends the response authentication [M4 with a fresh T3] to the APi. Otherwise, the AuC computes XVi2 = h (APIDip‖R6‖SeNi‖ΔTP), in order to examine whether XVi2 matches with the received Vi2. If XVi2 ≠ Vi2, AuC refuses the acknowledgment message and closes the authentication session. Otherwise, the APi is considered an authorized user. Then, the AuC updates SeNi = h (SeNi) and APIDis = Φ.

2.7. Authentication Phase of Agriculture Sensor

In order to exchange the environmental/climatic information and irrigation orders between the CHj and connected sensors (ASk), mutual authentication must be achieved for all sessions between both of them through insecure channels, as shown in Figure 3. The main steps of this phase are achieved as follows:
Step1: To connect with a specific sensor ASk, CHj determines the identity ASIDk of the ASk that wants to connect with it. Then, CHj generates a private key (ASkK) randomly, updates Snk0 = h (Snk0‖ASIDk), and calculates CTk = ((ASkK‖ST) ⊕ h (Snk0‖ASIDk‖Sn0)), where the value of ST is used to determine whether the CHj needs to receive the data or forward the irrigation orders. Next, CHj calculates the IDk = h (ASkK‖ASIDk), wherein Idk is a pseudonym identity for the ASk. Then, CHj calculates Vk0 = h (ST‖ASIDk‖ASkK‖Snk0‖Sn0) and renews Sn0 = Sn0 + 1. Finally, CHj transmits the authentication request [M6 = CTk, Vk0, Sn0] to the ASk.
Step2: In response to the request message, the ASk calculates ΔSn = (Sn0 − Sn1) and examines whether (1 ≤ ΔSn ≤ µ0), where the value of µ0 is determined according to the system specifications. If not, the ASk refuses the request message and closes the authentication session. Otherwise, the ASk initiates the Snk1 = Snk0, and executes Snk1 = h (Snk1‖ASIDk) for ΔSn times, until (ΔSn − 1) = 1.
Next, the ASk computes (ASkK‖ST) = CTk ⊕ h (Snk0‖ASIDk‖Sn1) and computes XVk0 = h (ST‖ASIDk‖Snk1‖ASkK‖Sn0 − 1). Then, the ASk checks whether XVk0 matches Vk0. If XVk0 ≠ Vk0, the ASk refuses the request message and closes the authentication session. Otherwise, the CHj is considered legitimate and can be used by an authorized operator.
The ASk calculates Snk0 = h (Snk1‖ASIDk), Vk1 = h (ST‖ASIDk‖ASkK‖Snk0‖Sn0), and IDk = h (ASkK‖ASIDk). Then, the ASk updates Sn1 = Sn0 and calculates Snk0 = h (Snk1‖ASIDk). Finally, the ASk transmits the response message [M7 = IDk, Vk1] to the CHj.
Step3: Upon receiving the response message, CHj computes Snk0 = h (Snk0‖ASIDk), XVk1 = h (ST‖ASIDk‖ASkK‖Snk0‖Sn0), and checks whether XVk2 matches with Vk1. If Vk2 = Vk1, the ASk is an authorized sensor. Otherwise, the CHj refuses the response message and closes the authentication session.

2.8. Password Change Phase of Agriculture Professional

This phase is accomplished between the APi and their SCi when the APi wants to change their password without increasing the network overhead and back to the AuC. The APi needs to execute the following steps:
Step1: The APi enters their current credential parameters (APIDi, PWi, Si) and a new password (*PWi), as the request to change their password;
Step2: In response to the password change request, the SCi calculates Ci = h (APIDi‖PWi‖R0), Ai0 = (APFi ⊕ Si), and XAPVi = h ((SeNi‖Si) ⊕ (Ci‖Ai0)). Then, the SCi examines whether XAPVi matches the APVi. If XAPVi ≠ APVi, SCi refuses the password change request. Otherwise, SCi computes *Ci = h (APIDi‖*PWi‖R0) and a new verification code *APVi = h ((SeNi‖Si) ⊕ (Ci*‖Ai0)). Finally, the SCi replaces the computed verification code with the previous one (APVi = *APVi).

2.9. Password Change Phase of Cluster Head

This stage is accomplished between the CHj and SCj, when the operator of CHj wants to change their password without increasing the network overhead and back to the AuC. The operator of the CHj needs to execute the following steps:
Step1: The operator enters their current credential parameters (CHIDj, PWj, and Sj) and a new password (*PWj) as the request to change their password;
Step2: In response to the password change request, SCj calculates Cj = h (CHIDj‖PWj‖R2), Aj0 = (CHFj ⊕ Sj), and XCHVj = h ((SeNj‖Sj) ⊕ (Cj‖Aj0)). The SCj then examines whether XCHVj matches with CHVj. If XCHVj ≠ CHVj, the SCj refuses the password change request. Otherwise, the SCj computes *Cj = h (CHIDj‖*PWj‖R2) and *CHVj = h ((SeNj‖Sj) ⊕ (*Cj‖Aj0)). Finally, the SCj replaces the computed verification code with the previous one (CHVj = *CHVj).

3. Security Analysis

This section examines the security features of the proposed scheme. In the first part, the proposed scheme is verified in order to prove that it can provide mutual authentication formally, using the BAN logic model. The second part presents the informal security analysis, demonstrating that the proposed scheme can achieve attractive security features with the ability to resist well-known attacks. Finally, comparisons based on different security features between the proposed scheme and other authentication schemes that were proposed recently are presented.

3.1. Formal Verification Analysis

In the literature review, the BAN logic model is considered the most popular formal verification model that is used to examine the source, freshness, and originality of the authentication messages exchanged during authentication scheme execution [20].
In the proposed scheme, the registration, login, and password change phases are executed through secure channels or are not used frequently. Therefore, this part concentrates on the soundness of the authentication phases between the main elements of the irrigation system. In this section, the BAN logic model is used to demonstrate that the authentication messages that have been exchanged throughout the authentication phases between system elements are original and fresh messages. The main used notation of the BAN logic model can be summarized as follows:
  • X|≡ F means that the statement (X) is considered a true statement for a principle (F);
  • F ⊲ X means that the statement (X) can be received and forwarded by a principle (F);
  • F|~ X means that the principle (F) can send a message containing statement (X);
  • F ⟹ X means that the principle (F) has an authority on statement (X);
  • ⋕(X) means that the statement (X) is an original and fresh statement;
  • (X, Y) means that the statements (X) and/or (Y) are a portion of the formula (X, Y);
  • <X> Y means that the statement (X) has been merged with the statement (Y);
  • {X}K means that the statement (X) has been encrypted by a shared key (K);
  • (F → K ← Q) means that principles (F) and (Q) can communicate with each other using the shared key (K);
  • SK denotes a session key for the current communication session.
The main rules, goals, idealized forms, and assumptions that are utilized in the verification process using the BAN logic model are presented in Table 2, Table 3, Table 4, Table 5, Table 6, Table 7 and Table 8.
The authentication and key agreement phase use different parameters to support mutual authentication between APi, AuC, and CHj. Ki and Kj are symmetric secret keys that are used to encrypt authentication messages between the APi and AuC, and CHj and AuC, respectively. Kij is an agreed symmetric secret key between APi and CHj. The exchanged messages comprise fresh parameters, such as timestamps (T1, T2, T3, T4) and random numbers (R4, R5, and R6).
Meanwhile, to support mutual authentication in the AS authentication phase, both of CHj and ASk utilize a set of sequential numbers (Sn0, Sn1), session numbers (Snk0, Snk1), and a symmetric secret key (ASkK), which is used to encrypt the authentication messages between them. The validation and verification processes of the authentication and key agreement phase can be summarized as follows:
(1) Using M1, a1: (AuC ⊲ IDi, Vi1, CTi1: ⟨ (T0, SeNi) ⟩ Ki) can be seen. From a1, A9, Ru3, and Ru1, a2: (AuC|≡ APi|∼⟨ (T0, SeNi) ⟩ Ki) can be obtained. Using A3 and Ru2, a3: (AuC|≡ #⟨ (T0, SeNi) ⟩Ki) can be obtained. Then, using a2, a3, and Ru4, a4: (AuC|≡ APi|≡ ⟨ (T0, SeNi) ⟩Ki) can be obtained. Thus, from a3, a4, and Ru6, a5: (AuC|≡ (AuC → SK ← Ui) can be deduced, which represents Go1. Considering A4, a5, and Ru4, Q6: (AuC|≡ APi|≡ AuC → SK ← APi) can also be deduced, which leads to Go2.
(2) Using M2, b1: (CHj ⊲ CH0j, CTj0, Vj0: ⟨ (T1, R4) ⟩ Kj) can be seen. Therefore, from b1, A11, Ru3, and Ru1, b2: (CHj|≡ AuC|∼ (⟨ (T1, R4) ⟩ Kj) can be obtained. Next, using A6 and Ru2, b3: (CHj|≡ # (⟨ (T1, R4) ⟩ Kj) can be obtained. Then, using b2, b3, and Ru4, b4: (CHj|≡ AuC|≡ (⟨ (T1, R4) ⟩ Kj) can be obtained. Thus, from b3, b4, and Ru6, b5: (CHj|≡ CHj → SK ← AuC) can be deduced, which represents Go3. Then, using A7, b5, and Ru4, b6: (CHj|≡ AuC|≡ CHj → SK ← AuC) can also be deduced, which leads to Go4.
(3) Using M3, c1: (AuC ⊲ CHIDjs, CTj1, Vj1: ⟨ (T2, R5) ⟩ Kj) can be seen. Thus, from c1, A10, Ru3, and Ru1, c2: (AuC|≡ CHj|∼ (⟨ (T2, R5) ⟩ Kj) can be obtained. Next, using A3 and Ru2, c3: (AuC|≡ # (⟨ (T2, R5) ⟩ Kj) can be obtained. Then, using c2, c3, and Ru4, c4: (AuC|≡ CHj (⟨ (T2, R5) ⟩ Kj) can be obtained. Thus, from c3, c4, and Ru6, c5: (AuC|≡ AuC → SK ← CHj) can be deduced, which leads to Go5. Then, using A5, c5, and Ru4, c6: (AuC|≡ CHj|≡ AuC → SK ← CHj) can also be deduced, which leads to Go6.
(4) Using M4, d1: (APi ⊲ CTi1, Vi1: ⟨ (T3, SeNi, R6) ⟩ Ki) can be seen. Thus, from d1, A8, Ru3, and Ru1, d2: (APi|≡ AuC|∼ (⟨ (T3, SeNi, R6) ⟩ Ki) can be obtained. Next, using A1 and Ru2, d3: (APi|≡ # (⟨ (T3, SeNi, R6) ⟩ Ki) can be obtained. Then, using d2, d3, and Ru4, d4: (APi|≡ AuC|≡ (⟨ (T3, SeNi, R6) ⟩ Ki) can be deduced. Thus, from d3, d4, and Ru6, d5: (APi|≡ APi → SK ← AuC) can be deduced, which leads to Go7. Then, according to A2, d5, and Ru4, d6: (APi|≡ AuC|≡ APi → SK ← AuC) can also be deduced, which leads to Go8.
According to (1), (2), (3), and (4), the authentication and key agreement phase goals can be proven using the BAN logic model and, thus, mutual authentication can be achieved between APi, CHj, and AuC throughout this phase.
The validation and verification processes of the AS authentication phase can be summarized as follows:
(5) Using M6, e1: (ASk ⊲ CTk, Vk0: ⟨Sn0, Snk0⟩ h(ASkK)) can be seen. From e1, A17, Ru3, and Ru1, e2: (ASk|≡ CHj|∼ (⟨Sn0, Snk0⟩) h(ASkK)) can be obtained. Then, using A14 and Ru2, e3: (ASk|≡ # (⟨Sn0, Snk0⟩) h(ASkK)) can be obtained. Then, using e2, e3, and Ru4, e4: (ASk|≡ CHj|≡ (⟨Sn0, Snk0⟩) h(ASkK)) can be obtained. Thus, from e3, e4, and Ru6, e5: (ASk|≡ ASk → SK ← CHj) can be deduced, which represents Go9. Considering A15, e5, and Ru4, e6: (ASk |≡ CHj|≡ Ask → SK ← CHj) can also be deduced, which leads to Go10.
(6) Using M7, f1: (CHj ⊲ Vk2: ⟨ (Sn0, Snk0) ⟩ h(ASkK)) can be seen. Therefore, from f1, A16, Ru3, and Ru1, f2: (CHj|≡ ASk |∼ ⟨ (Sn0, Snk0) ⟩ h(ASkK)) can be obtained. Next, using A12 and Ru2, f3: (CHj|≡ # ⟨ (Sn0, Snk0) ⟩ h(ASkK)) can be obtained. Then, using f2, f3, and Ru4, f4: (CHj|≡ ASk |≡ ⟨ (Sn0, Snk0) ⟩ h(ASkK)) can be obtained. Thus, from f3, f4, and Ru6, f5: (CHj|≡ CHj → SK ← ASk) can be deduced, which represents Go11. Then, using A13, f5, and Ru4, f6: (CHj|≡ ASk |≡ CHj → SK ← ASk) can also be deduced, which leads to Go12.
According to (5) and (6), the goals of the AS authentication phase can be proven using the BAN logic model and, so, mutual authentication can be achieved between the CHj and ASk throughout this phase. Therefore, the proposed scheme can support mutual authentication among the APi, CHj, ASk, and AuC elements during the authentication phases.

3.2. Informal Verification Analysis

This section assures that the proposed scheme can achieve attractive security features and is fully protected against well-known types of attacks.

3.2.1. Security Features Achievement

Proposition 1.
The proposed scheme can achieve session key agreement.
Proof. 
Based on the Diffie–Hellman key agreement technique, elements of the irrigation system generate a set of shared secret keys to execute the authentication and key agreement phase. Ki is used to achieving mutual authentication between the AuC and APi, Kj is used to achieve mutual authentication between the AuC and CHj, and Kij represents the agreed session key between the APi and CHj. During this authentication phase, the AuC generates P with two generator numbers (βi and βj) in order to produce the public keys (Ai0 and Aj0) for APi and CHj, respectively. The APi, according to the P-value, generates two generator numbers (δ1 and δ2) to produce the public keys (Ai1 and Ai2) for AuC and CHj. The CHj, according to the P-value, generates two generator numbers (δ3 and δ4) to produce the public keys (Aj1 and Aj2) for AuC and APi. It should be noted that all the public keys are exchanged between system elements using different one-way hash functions in order to prevent man-in-the-middle and replay attacks. □
In the AS authentication phase, the CHj generates the ASkK key randomly and sends it to the ASk in a secure manner through the use of a one-way hash function in order to achieve the mutual authentication feature between them.
Thus, the proposed scheme is able to provide the key agreement feature between the elements of the irrigation system.
Proposition 2.
The proposed scheme can achieve mutual authentication.
Proof. 
The authentication and session key agreement phase contains set verification checkpoints that are performed to validate a fully mutual authentication between the APi, AuC, and CHj elements. Mutual authentication between the AuC and APi can be achieved as follows: The AuC verifies the M1 message via the received challenge authentication parameters [CTi0 and Vi0] in order to verify the legality of APi. In the same manner, the APi verifies the legitimacy of the AuC by verifying the M4 message via the received challenge authentication parameters [CTi1 and Vi1]. □
Similarly, the mutual authentication between AuC and CHj can be achieved as follows: the CHj verifies the M2 message via the received challenge authentication parameters [CH0j, CTj0, and Vj0] in order to verify the legality of the AuC. Next, the AuC verifies the legitimacy of the CHj by verifying the M3 message via the received challenge authentication parameters [CHIDjs, CTj1, and Vj1].
In the AS authentication phase, both ASk and CHj verify each other through two verification checkpoints, as follows: ASk verifies the authenticity of the CHj by checking the received authentication parameters through the M6 message that contains [CTk, Vk0, and Sn0], while CHj verifies the authenticity of the ASk by checking the received authentication parameters through the M7 message that contains [IDk, and Vk2].
Thus, the proposed scheme is able to support fully mutual authentication between the elements of the irrigation system.
Proposition 3.
The proposed scheme can achieve anonymity and untraceability.
Proof. 
In the authentication and key agreement phase, in order to preserve the anonymity and untraceability for the users of the APi and CHj, all authentication messages exchanged within the authentication process do not include the actual identities, nor that of the APi (APIDi) or the CHj (CHIDj). Instead, the authentication process uses pseudonym identities (IDi and CHIDjs), which are created by one-way hash functions after completing each authentication session for the APi and CHj. Therefore, it is considered impossible for an unauthorized party to extract the actual identities of either the APi or CHj from the messages exchanged. □
Similarly, in the AS authentication phase, the exchanged messages between CHj and ASk do not include the actual identity of the ASk (ASIDk). Instead, the authentication process uses pseudonym identities (IDk).
Thus, the proposed scheme can achieve full anonymity and untraceability for the elements of the irrigation system.
Proposition 4.
The proposed scheme can achieve perfect forward secrecy.
Proof. 
In the proposed scheme, if an adversary obtains one or more keys of the system elements, such as Ki, Kj, or ASkK, in some way, they still cannot acquire the secret session key (Kij) that is generated by the APi and CHj during the next authentication session. The reason for this is that, after completing the authentication and key agreement phase successfully, the generator numbers (δ1, δ2, δ3, and δ4) are changed for each authentication session. □
Similarly, if an adversary obtains the secret key ASkK, they still cannot acquire the secret session key for the next authentication session between the ASk and CHj, wherein this key will be changed in each authentication session between them using a one-way hash function.
Therefore, the proposed scheme can achieve fully perfect forward secrecy in future authentication sessions.

3.2.2. Resistance against Well-Known Attacks

Despite the fact that the exchanged messages between the elements of the system can be blocked, modified, replaced, tracked, and retransmitted over insecure communication channels by the opponent, this section demonstrates that the proposed scheme can withstand well-known attacks.
Proposition 5.
The proposed scheme can resist desynchronization attacks.
Proof. 
In order to support anonymity and untraceability, the proposed scheme uses a set of pseudonym identities, such as APIDi, CHIDj, and ASIDk, along with a set of the one-way hash functions to renew such identities for each authentication session. Furthermore, to support the perfect forward secrecy feature, the proposed scheme uses set verification codes, such as Vi0, Vj0, Vj1, Vi1, Vix, Vk0, and Vk1, with a set of the one-way hash functions, random numbers, and timestamps to renew such codes. Therefore, the synchronization of the computed hash values must be preserved in the proposed scheme between the APi, CHj, ASk, and AuC. In the authentication and key agreement phase, the synchronization of the APIDi and hash chain values of SeNi will be guaranteed by APIDip and APIDis in each authentication session between the APi and AuC. Similarly, in each authentication session between the CHj and AuC, the values of CHIDjp and CHIDjs are used to ensure that the CHIDj and the hash chain value of SeNj are synchronized. In the AS authentication phase, the synchronization of the ASIDk and hash chain values of Snk0 will be guaranteed by IDk in each authentication session between the ASk and CHj. As the one-way hash functions used in the proposed scheme are collision hash functions, even if the opponent can block authentication messages, the APi, CHj, ASk, and AuC can resynchronize the hash values between them. To make the discussion more precise regarding the ability of the proposed scheme to withstand desynchronization attacks, consider the following possible desynchronization attack scenarios:
S1: Suppose the opponent has blocked M1. Obviously, this will not affect the synchronization between APi and AuC during the next authentication session, wherein the elements of the system have not yet begun renewing the values of the IDi nor h(SeNi). Thus, this scenario will be ignored.
S2: Suppose the opponent has blocked M2. Obviously, this will not affect the synchronization between the APi, CHj, and AuC during the following sessions. In this case, the hash values of SeNj and CHIDjs have only been updated on the AuC. However, M3 has not been received by the AuC. Thus, the AuC can resend M2 again, using a new CH0j with distinct values of T1 and R4. Alternatively, the CHj using the value of ΔCH01j can resynchronize and update the hash values of SeNj and CHIDjs, as in the AuC. Thus, the AuC can resynchronize the next session with the CHj.
S3: Suppose the opponent has blocked M3. Obviously, this will not affect the synchronization between the APi, CHj, and AuC during the next session. This scenario is similar to S2. In this case, the hash values of the SeNj and CHIDjs have been renewed in AuC and CHj. However, M3 has not been received by the AuC. Thus, the AuC will send M2 again, using distinct values for T1 and R4. Then, the CHj, using the value of ΔCH01j, can resynchronize and renew the hash values of SeNj and CHIDjs, as in the AuC. Next, the CHj can send M3again, using new values for T2 and R5. Thus, the AuC can resynchronize in the next session with CHj.
S4: Suppose the opponent has blocked M4. Obviously, this will not affect the synchronization between the APi, CHj, and AuC during the next session. In this case, the hash values of SeNi and APIDis have not yet been renewed in the APi nor AuC, and only synchronization is needed for the hash value of IDi in the APi. However, M4has not been received by the APi. Thus, the APi can send M1 again, using a distinct value of T0. As the value of IDi for the AuC is equal to APIDis, the AuC can send M4 using the new values for T3 and R6. Thus, the APi can resynchronize in the next session with AuC.
S5: Suppose the opponent has blocked M5. Obviously, it will not affect the synchronization between the APi, CHj, and AuC during the next session. In this case, the hash values IDi and APIDip have been renewed in the APi nor AuC, wherein IDi = APIDip, and the (SeNi) has been renewed in the APi, but has not yet been updated on the AuC. However, the APi will not be able to receive processed data from the AuC. Therefore, APi can send M1 again, using a distinct value of T0. As the value of IDi for the AuC will be equal to APIDip and APIDis ≠ Φ, the AuC will send M4 again to the APi, using distinct values of T3 and R6. Therefore, the APi can send M5 and resynchronize in the next session with AuC.
S6: Suppose the opponent has blocked M6. Obviously, this will not affect the synchronization between the ASk and CHj during the next session. In this case, the values of CTk, Snk0, and IDk have only been renewed in the CHj. However, M7 has not been received by the CHj. Therefore, the CHj can send M6 using distinct values of ASkK and Sn0. Then, the ASk, according to the ΔSn value, can renew the IDk, S0k1, and Snk1 values, as in the CHj. Thus, the CHj can resynchronize in the next session with ASk.
S7: Suppose the opponent has blocked M7. Obviously, this will not affect the synchronization between the ASk and CHj during the next session. In this case, the values of CTk, IDk, and Snk0 have been updated on both ASk and CHj. However, M7 has not been received by the CHj. Therefore, the CHj can send M6, using distinct values for ASkK and (Snk0. The ASk, using the new value of ΔSn, can renew the hash values of IDk, SSk1, and SNk1, as in the CHj. Next, the ASk can send M7 again. Thus, the CHj can resynchronize in the next session with ASk. □
Thus, based on the analysis of the above-discussed attack scenarios (S1–S7), the proposed scheme can resist desynchronization attacks.
Proposition 6.
The proposed scheme can resist impersonation attacks.
Proof. 
To make the discussion more precise regarding the ability of the proposed scheme to withstand impersonation attacks, consider the following possible impersonation attack scenarios:
S8: Suppose the opponent has intercepted M1, which is sent to the AuC to impersonate the APi, wherein CTi0 = EKi (T0‖Ai2‖CHIDj) and Vi0 = h (T0‖Ai2‖SeNi). The decryption of CTi1 is not an obtainable value, wherein the opponent cannot know Ki. Besides, the actual SeNi and Ai2 values are not available. Thus, the opponent would be unable to impersonate APi by computing Vi0 with completely separate T0 and SeN1values.
S9: Suppose the opponent has intercepted M2, which is sent to the CHj to impersonate the AuC, wherein CTj0 = EKj (T1‖R4‖Ai2) and Vj0 = h (T1‖Ai2‖CHIDjp‖R4). The decryption of CTj0is not an obtainable value, wherein the opponent cannot know Kj, which is considered an invisible value. Besides, the actual CHIDjp and Aj2 values are not available. Thus, the opponent would be unable to impersonate the AuC by computing Vj0 with completely separate T1 and R4 values.
S10: Suppose the opponent has intercepted M3, which is sent to the AuC to impersonate the CHj, wherein CTj1 = EKj (T2‖R5‖Aj2) and Vj1 = h (T2‖Aj2‖CHIDjs‖R5). The decryption of CTj1 is not an obtainable value, wherein the opponent cannot know Kj (an invisible value). Besides, the actual CHIDjp and Aj2 values are not available. Thus, the opponent would be unable to impersonate the AuC by computing Vj0 with completely separate T2 and R5 values.
S11: Suppose the opponent has intercepted (M6), which is sent to the ASk to impersonate the CHj, wherein the CTk = ((ASkK‖ST) ⊕ h (Snk0‖ASIDk‖Sn1)), IDk = h (ASkK‖ASIDk), and Vk0 = h (ST‖ASIDk‖ASkK‖Snk0‖Sn0). Neither of the CTk nor IDK is obtainable values, wherein the opponent cannot know ASkK, which is considered an invisible value. Besides, the actual ASIDk and Snk0 values are not available. Thus, the opponent would be unable to impersonate the CHj by computing Vk0 with completely separate ASkK and ASIDk values. □
Therefore, according to the above-discussed attack scenarios (S8–S11), the proposed scheme can resist impersonation attacks.
Proposition 7.
The proposed scheme can resist replay attacks.
Proof. 
The proposed scheme uses a set of timestamps, random numbers, and serial numbers, which are incorporated into the exchange authentication messages. In order to make the discussion more precise regarding the ability of the proposed scheme to withstand replay attacks, consider the following possible replay attack scenarios:
S12: Suppose the opponent has retransmitted M1 that was sent by the APi. The AuC will refuse the authentication request and close the authentication session, as T0 has become out of range.
S13: Suppose the opponent has retransmitted M2 that was sent by the AuC. The CHj will refuse the authentication request and close the authentication session, as ΔCH01j will be out of the irrigation system specifications and T1 has become out of range.
S14: Suppose the opponent has retransmitted M6 that was sent by CHj. The ASk will refuse the authentication request and close the authentication session, as ΔSn will be out of the irrigation system specifications. □
Thus, based on the analysis of the above-discussed attack scenarios (S12–S14), the proposed scheme can resist replay attacks.
Proposition 8.
The proposed scheme can resist stolen password table attacks.
Proof. 
The proposed scheme does not have an AP password table or a CHj password table stored in the AuC at all. □
Thus, the proposed scheme will not be exposed to stolen verifier table attacks and can resist such attacks.
Proposition 9.
The proposed scheme can resist incorrect password login attacks.
Proof. 
Suppose the opponent tries to use an incorrect password. In the proposed scheme, the password verification code APVi = h ((SeNi‖Si) ⊕ (Ci‖Ai0)) is stored in the smart card of the APi, which is used to validate the APi’s password. If the APi enters an incorrect password (PWi) or security code (Si), the verification codes (XAPVi ≠ APVi) are not equal, and the SCi will refuse the login request. Similarly, the CHj has the password verification code CHVj = h ((SeNj‖Sj) ⊕ (Cj‖Aj0)) stored in the smart card of the CHj, which is used to validate the operator password of the CHj. If the operator enters an incorrect password (PWj) or security code (Sj), the verification codes (XCHVj ≠ CHVj) will not be equal, and the SCj will refuse the login request. □
Therefore, the proposed scheme can resist an incorrect password login attack without increasing the network overhead and going back to the AuC.
Proposition 10.
The proposed scheme can resist smartcard loss attacks.
Proof. 
Suppose the opponent attempts to steal the concealed data from a smartcard, wherein the proposed authentication scheme utilizes three factors (3F) during the login phases (i.e., identity, password, and security code). Even if an opponent is able to steal such concealed data from a smartcard, they will be incapable of logging in, whether as an APi user or CHj operator. This is as the opponent also requires knowledge of the actual user’s identities (APIDi, CHIDj), (PWi, PWj), and (Si, Sj) in order to create a login message. □
Thus, the proposed scheme can resist smartcard loss attacks without increasing the network overhead and going back to the AuC.
Proposition 11.
The proposed scheme can resist man-in-the-middle attacks.
Proof. 
Suppose the opponent tries to forge either legitimate challenge or response messages. As the proposed scheme uses the Diffie–Hellman key agreement technique, the values of public keys (A0i, Aj0, A1i, A1j, A2i, and Aj2) are exchanged as concealed values between the elements of the irrigation system within hash values. Besides, challenge or response messages that have been exchanged are protected by (Ki and SeNi) and (Kj and SeNj), and an opponent without these pairs of keys cannot forge such legitimate messages. □
Thus, the proposed scheme can resist man-in-the-middle attacks.
Proposition 12.
The proposed scheme can resist insider privileged attacks.
Proof. 
Suppose the inside workers within the service provider try to carry out privileged insider attacks. In the proposed scheme, when the APi executes the registration phase, the (PWi, Si) values are sent as hidden values using a hash value Ci = h (APIDi‖PWi‖Si). Similarly, when the CHj executes the registration phase, the (PWj, Sj) values are sent as hidden values using a hash value Cj = h (CHIDj‖PWj‖Sj). The collision feature of the one-way hash function, which is used to compute (Ci, Cj), can stop the insider from revealing the actual values. □
Thus, the proposed scheme can resist insider privileged attacks.

3.3. Security Comparisons

In this section, a comparison of security features between the proposed authentication scheme and other recently proposed schemes [13,14,15,16,18] is presented. The comparisons, in terms of the security features achievements and resistance against well-known attacks, are detailed in Table 9.
It should be noted here that the elements of irrigation systems (agriculture professionals, AuC, cluster heads, and agriculture sensors) are somewhat analogous to the elements of health care systems (healthcare professional; gateway node, GWN; patient’s smart device; and physiological sensors).
The outputs of the comparison in Table 9 illustrate that the proposed scheme can achieve all of the attractive security features, while the other schemes cannot support some of the security features, such as fully mutual authentication among the elements of the system, agriculture sensor node anonymity, and perfect forward secrecy (SF1–SF11). This comparison was proved in Section 3.2.1 from proposition 1 to proposition 4.
Furthermore, the proposed scheme can resist all well-known attacks, while other schemes cannot resist all listed attack types (SF12–SF22). The resistance of the proposed scheme against all well-known attacks according to all attacks scenarios was proved in Section 3.2.2 from Proposition 5 to Proposition 12.
Thus, the proposed scheme displayed more security features and a higher level of resistance than the other recently proposed schemes.

4. Performance Analysis

This section provides estimates of the performance of the proposed scheme, as well as comparing its costs, in terms of the required storage size, running time, and intercommunication, with other authentication schemes that have recently been proposed [13,14,15,16,18]. The estimated costs of the running time and intercommunication were computed for the authentication and key agreement phase, whereas the cost of the storage size needed was computed for the agriculture professional, cluster head, and sensor registration phases. In order to carry out accurate and reasonable comparisons, the following values were assumed [10,17,19,21]:
(1) The size of sequential numbers, security codes, random numbers, passwords, and identities were set to be 128 bits; (2) the output of the used hash functions was equal to 160 bits; (3) the input/output of the encryption/decryption functions were multiples of 128 bits; (4) the running times to execute the fuzzy extractor generating function (Tfe) was set as 0.0171 s; (5) SHA-1 was used as the hash function used, wherein the running time (Th) was 0.00032 s; and (6) the AES cryptographic function was used, with running time (TE/D) of 0.0056 s.

4.1. Storage Size Cost Analysis

Reducing the storage size that is needed, whether for the smart cards of the users or sensor nodes memories, is considered an important issue in such systems. Thus, the storage size costs for the smartcards (i.e., SCi and SCj) and agriculture sensor were calculated for the proposed scheme, as well as for other recently proposed schemes [13,14,15,16,18], as illustrated in Table 10.
It should be noted that the size of the cryptographic functions was omitted from the calculations in order to simplify the analysis. In the proposed scheme, the storage size cost for both SCi and SCJ is (736) bits, while the storage size cost for the agriculture sensor is (256) bits. Table 10 shows that the proposed scheme required the least storage size cost for agriculture sensors. Furthermore, the storage size cost that is required for the smart cards in the proposed scheme is only greater than the scheme presented in [13] but was equal to or less than those of other schemes.

4.2. Intercommunication Cost Analysis

The intercommunication cost can be estimated using the total intercommunication size of the exchanged messages between the elements of the system throughout the authentication and key agreement phase. The total intercommunication costs of the proposed scheme and other recently proposed schemes [13,14,15,16,18] are illustrated in Table 11.
The total intercommunication cost of the proposed scheme was (2848) bits. Wherein Table 11 shows that the needed intercommunication cost for proposed authentication was only greater than that of the authentication schemes in [13,15] but less than other authentication schemes.

4.3. Running Time Cost Analysis

In this section, the estimated running time costs of the authentication phases are calculated in order to conduct a comparison between the proposed scheme and other recently proposed authentication schemes [13,14,15,16,18]. For each element of the system, the number of cryptographic functions was determined, as shown in Table 12. Furthermore, the total running time costs were calculated for the sensor node, as shown in Table 13. Finally, the total running time costs were calculated for all elements of the system, as shown in Table 14.
The sensor node is considered a device with poor computational capabilities. Therefore, the authentication schemes that contain cryptographic functions, except the hash functions such as those in [14,18], cannot be employed in such systems. The results in Table 13 illustrate that the proposed scheme had a greater total running time cost on the sensor side than the authentication scheme proposed in [13] but was equal to or better than the other schemes.
It should be pointed out here that the proposed scheme contains two authentication phases (i.e., the authentication and key agreement phase and the authentication phase of the agriculture sensor), while the other authentication schemes [13,14,15,16,18] used just one authentication phase. This is why the total running time cost of the proposed scheme was greater than that of other authentication schemes, as can be seen from Table 14.
Besides, authentication schemes should not use only a one-way hash function to achieve a high level of security for such unattended systems. Table 14 illustrates that the proposed scheme can be applied in irrigation systems, wherein each element in the system has a reasonable execution time.

5. Conclusions

In order to overcome the existing security concerns of smart IoT irrigation systems, this paper proposed a secure authentication scheme based on Diffie–Hellman key agreement techniques over WSNs. The proposed scheme possesses attractive security features that allow for its use in such systems, wherein fully mutual authentication, full anonymity, and fully perfect forward secrecy were achieved. The BAN logic model was applied to validate the mutual authentication between the elements of the system throughout the authentication phases. According to the possible attack types scenarios that were assumed and discussed, the demonstrated security level of the proposed scheme shows that it not only provides attractive security features but also can resist well-known types of attacks. Furthermore, compared with other recently proposed authentication schemes, the proposed scheme had the highest level of security in terms of the security feature achievements and resistance to the well-known attacks. A performance analysis demonstrated that the proposed scheme has a minimal cost in terms of storage size and also has a suitable level of intercommunication and running time costs, compared with other recently proposed authentication schemes. Finally, the proposed scheme is applicable for use in smart IoT irrigation systems in order to remotely monitor the actual amount of water required to irrigate the crops.

Funding

The author received no specific funding for this study.

Acknowledgments

The author expresses his gratitude to all members of the Computer and Information Sciences College at Jouf University for their support.

Conflicts of Interest

The author declares no conflict of interest to report regarding the present study.

References

  1. Ahmed, I.; Akash, M.S. IoT based smart irrigation system at university of Chittagong, Bangladesh. Int. J. Comput. Appl. 2020, 176, 39–45. [Google Scholar] [CrossRef]
  2. Munir, M.S.; Bajwa, I.S.; Ashraf, A.; Anwar, W.; Rashid, R. Intelligent and smart irrigation system using edge computing and IoT. Complexity 2021, 2021, 6691571. [Google Scholar] [CrossRef]
  3. Manimegalai, V.; Judy, A.L.; Gayathri, A.; Ashadevi, S.; Mohanapriya, V. Smart irrigation system with monitoring and controlling using IoT. Int. J. Eng. Adv. Technol. (IJEAT) 2020, 9, 1373–1376. [Google Scholar] [CrossRef]
  4. Naik, P.; Kumbi, A.; Katti, K.; Telkar, N. Automation of irrigation system using IoT. Int. J. Eng. Manuf. Sci. 2018, 8, 77–88. [Google Scholar]
  5. Rawal, S. IoT based smart irrigation system. Int. J. Comput. Appl. 2017, 159, 7–11. [Google Scholar] [CrossRef]
  6. Goap, A.; Sharma, D.; Shukla, A.K.; Krishna, C.R. An IoT based smart irrigation management system using Machine learning and open source technologies. Comput. Electron. Agric. 2018, 155, 41–49. [Google Scholar] [CrossRef]
  7. García, L.; Parra, L.; Jimenez, J.M.; Lloret, J.; Lorenz, P. IoT-based smart irrigation systems: An overview on the recent trends on sensors and IoT systems for irrigation in precision agriculture. Sensors 2020, 20, 1042. [Google Scholar] [CrossRef] [Green Version]
  8. Hsu, W.-L.; Wang, W.-K.; Fan, W.-H.; Shiau, Y.-C.; Yang, M.-L.; Lopez, D.J. Application of internet of things in smart farm watering system. Sens. Mater. 2021, 33, 269–283. [Google Scholar] [CrossRef]
  9. Gupta, M.; Abdelsalam, M.; Khorsandroo, S.; Mittal, S. Security and privacy in smart farming: Challenges and opportunities. IEEE Access 2020, 8, 34564–34584. [Google Scholar] [CrossRef]
  10. Nashwan, S. AAA-WSN: Anonymous access authentication scheme for wireless sensor networks in big data environment. Egypt. Inform. 2021, 22, 15–26. [Google Scholar] [CrossRef]
  11. Nashwan, S. SAK-AKA: A secure anonymity key of authentication and key agreement protocol for LTE network. Int. Arab. J. Inf. Technol. (IAJIT) 2017, 14, 790–801. [Google Scholar]
  12. Yu, B.; Li, H. Anonymous authentication key agreement scheme with pairing-based cryptography for home-based multi-sensor Internet of Things. Int. J. Distrib. Sens. Netw. 2019, 15, 1550147719879379. [Google Scholar] [CrossRef] [Green Version]
  13. Amin, R.; Islam, S.H.; Biswas, G.P.; Khan, M.K.; Kumar, N. A robust and anonymous patient monitoring system using wireless medical sensor networks. Future Gener. Comput. Syst. 2018, 80, 483–495. [Google Scholar] [CrossRef]
  14. Ali, R.; Pal, A.K.; Kumari, S.; Sangaiah, A.K.; Li, X.; Wu, F. An enhanced three factor based authentication protocol using wireless medical sensor networks for healthcare monitoring. J. Ambient. Intell. Humaniz. Comput. 2018, 2018, 1–22. [Google Scholar] [CrossRef]
  15. Shuai, M.; Liu, B.; Yu, N.; Xiong, L. Lightweight and secure three-factor authentication scheme for remote patient monitoring using on-body wireless networks. Secur. Commun. Netw. 2019, 2019, 8145087. [Google Scholar] [CrossRef]
  16. Fotouhi, M.; Bayat, M.; Das, A.K.; Far, H.A.; Pournaghi, S.M.; Doostari, M.A. A lightweight and secure two-factor authentication scheme for wireless body area networks in health-care IoT. Comput. Netw. 2020, 177, 107333. [Google Scholar] [CrossRef]
  17. Nashwan, S. An End-to-End authentication scheme for healthcare IoT systems using WMSN. CMC-Comput. Mater. Contin. 2021, 68, 607–642. [Google Scholar] [CrossRef]
  18. Ali, A.; Pal, A.K.; Kumari, S.; Karuppiah, M.; Conti, M. A secure user authentication and key-agreement scheme using wireless sensor networks for agriculture monitoring. Future Gener. Comput. Syst. 2018, 84, 200–215. [Google Scholar] [CrossRef]
  19. Xiong, L.; Peng, D.; Peng, T.; Liang, H.; Liu, Z. A lightweight anonymous authentication protocol with perfect forward secrecy for wireless sensor networks. Sensors 2017, 17, 2681. [Google Scholar] [CrossRef] [Green Version]
  20. Nashwan, S.; Alshammari, B.M. Formal analysis of MCAP protocol against replay attack. Br. J. Math. Comput. Sci. 2017, 22, 1–14. [Google Scholar] [CrossRef] [Green Version]
  21. Nashwan, S.; Nashwan, I.I.H. Reducing the overhead messages cost of the SAK-AKA authentication Scheme for 4G/5G mobile networks. IEEE Access 2021, 9, 97539–97545. [Google Scholar] [CrossRef]
Figure 1. Proposed smart IoT irrigation system architecture.
Figure 1. Proposed smart IoT irrigation system architecture.
Electronics 11 00188 g001
Figure 2. Authentication and session key agreement phase.
Figure 2. Authentication and session key agreement phase.
Electronics 11 00188 g002
Figure 3. Authentication phase of agriculture sensor.
Figure 3. Authentication phase of agriculture sensor.
Electronics 11 00188 g003
Table 1. Basic notation and meanings.
Table 1. Basic notation and meanings.
NotationDescription
AuCAuthentication center server.
APiAgriculture professional.
CHjCluster head.
ASkAgriculture Sensor.
SCiSmartcard of APi.
SCjSmartcard of APi.
APIDiIdentity of APi.
PWiPassword of APi.
SiSecurity code of APi.
R0Random number generated by APi.
T0, T4Timestamps of APi.
δ1, δ2Selected Integer numbers by APi over P.
CHIDjIdentity of CHj.
PWjPassword of CHj.
SjSecurity code of CHj.
R2, R4Random numbers generated by CHj.
T2Timestamp of CHj.
δ3, δ4Selected Integer numbers by CHj over P.
R1, R3, R5, R6Random numbers generated by AuC.
T3, T4Timestamp of AuC.
KiSecret Key between APi and AuC.
KjSecret Key between CHj and AuC.
KijSession Key between CHj and APi.
SSnk0, SSnk1Sensor sequence numbers initiated by AuC.
PBig prime number.
α, βi, βjGenerator numbers over P selected by AuC.
T7Random numbers generated by ASk.
‖, ⊕, modConcatenation, XOR, and Modulus operations.
h (∙)One-way hash function.
Ek(∙), Dk(∙)Encryption and Decryption functions.
Table 2. Verification rules of ban logic model.
Table 2. Verification rules of ban logic model.
RuleRule Formula
Meaning (Ru1)If (F|≡ F → K ← Q, F ⊲ <X> K) then (F|≡ Q|~X)
Freshness (Ru2)If (F|≡ #(X)) then (F|≡ #(X,Y))
Belief (Ru3)If (F|≡ X, F|≡ Y) then (F|≡ (X,Y)
Verification (Ru4)If (F|≡ #(X), F|≡ Q|~X) then (F|≡ Q|≡ X)
Jurisdiction (Ru5)If (F|≡ Q ⟹ X, F|≡ Q|≡ X) then (F|≡ X)
Session key (R6)If (F|≡ #(X), F|≡ Q|≡ X) then (F|≡ F → K ← Q)
Table 3. Goals of authentication and key agreement phase.
Table 3. Goals of authentication and key agreement phase.
GoalDescription
Go1AuC|≡ AuC → SK ← APi
Go2AuC|≡ APi|≡ AuC → SK ← APi
Go3CHj|≡ CHj → SK ← AuC
Go4CHj|≡ AuC|≡ CHj → SK ← AuC
Go5AuC|≡ AuC → SK ← CHj
Go6AuC|≡ CHj|≡ AuC → SK ← CHj
Go7APi|≡ APi → SK ← AuC
Go8APi|≡ AuC|≡ APi → SK ← AuC
Table 4. Goals of the authentication phase of agriculture sensor.
Table 4. Goals of the authentication phase of agriculture sensor.
GoalDescription
G9CHj|≡ CHj → SK ← ASk
G10CHj|≡ ASk|≡ CHj → SK ← ASk
G11ASk|≡ ASk → SK ← CHj
G12ASk|≡ CHj|≡Ask → SK ← CHj
Table 5. Idealized form of the authentication and key agreement phase messages.
Table 5. Idealized form of the authentication and key agreement phase messages.
MessageIdealized Form
M1IDi, CTi0, Vi0: ⟨(T0, SeNi)⟩ Ki.
M2CH0j, CTj0, Vj0: ⟨(T1, R4)⟩ Kj.
M3CHIDjs, CTj1, Vj1: ⟨(T2, R5)⟩ Kj.
M4CTi1, Vi1: ⟨(T3, SeNi, R6)⟩ Ki.
Table 6. Idealized form of the authentication phase of agriculture sensor.
Table 6. Idealized form of the authentication phase of agriculture sensor.
MessageIdealized Form
M6CTk, Vk0: ⟨(Sn0, Snk0)⟩ h(ASkK)
M7Vk2: ⟨(Sn0, Snk0)⟩ h(ASkK)
Table 7. Assumptions of the authentication and key agreement phase.
Table 7. Assumptions of the authentication and key agreement phase.
AssumptionDescription
A1APi|≡ #(T3, R6)
A2APi|≡ AuC ⟹ (T3, R6)
A3AuC|≡ # (T0, T2, T4, R5)
A4AuC|≡ APi ⟹ (T0, T4, SeNi)
A5AuC|≡ CHj ⟹ (T2, R5)
A6CHj|≡ #(R4, T1)
A7CHj|≡ AuC ⟹ (R4, T1)
A8APi|≡ APi → Ki ← AuC.
A9AuC|≡ AuC → Ki ← APi
A10AuC|≡ AuC → Ki ← CHj
A11CHj|≡ CHj → Ki ← AuC
Table 8. Assumptions of the authentication phase of agriculture sensor.
Table 8. Assumptions of the authentication phase of agriculture sensor.
AssumptionDescription
A12CHj|≡ #(SnK0, Sn0)
A13CHj|≡ Ask ⟹ (SnK0, Sn0)
A14ASk|≡ #(SnK0, Sn0)
A15ASk|≡ CHj ⟹ (SnK0, Sn0)
A16CHj|≡ CHj → ASkK ← ASk
A17ASk|≡ Ask → ASkK ← CHj
Table 9. Security achievements and resistance to well-known attacks.
Table 9. Security achievements and resistance to well-known attacks.
Security Features[13][14][15][16][18]Proposed Scheme
SF1NoYesYesYesYesYes
SF2YesYesYesYesYesYes
SF3NANANANANAYes
SF4YesYesYesYesYesYes
SF5NANANANANAYes
SF6YesYesYesYesYesYes
SF7NoNoYesYesYesYes
SF8NANANANANAYes
SF9NoNoYesYesNoYes
SF10NoYesYesNoNoYes
SF11NoNoYesYesNoYes
SF12NoNoYesYesNoYes
SF13YesYesYesYesYesYes
SF14NANANANANAYes
SF15YesYesYesYesYesYes
SF16NoYesYesYesYesYes
SF17NoYesYesYesYesYes
SF18NANANANANAYes
SF19YesYesYesYesYesYes
SF20YesYesYesYesYesYes
SF21NoYesYesYesNoYes
SF22NoYesYesYesNoYes
SF1 = Secure session key agreement achievement. SF2 = Correct password change phase for agriculture professional. SF3 = Correct password change phase for cluster head. SF4 = Mutual authentication between Agriculture professional and AuC. SF5 = Mutual authentication between cluster head and AuC. SF6 = Mutual authentication between agriculture sensor and system. SF7 = Agriculture professional anonymity. SF8 = Cluster head anonymity. SF9 = Agriculture sensor anonymity. SF10 = Three authentication factors (3F). SF11 = Perfect forward secrecy feature. SF12 = Desynchronization attack resistance. SF13 = Smartcard loss attack resistance for agriculture professional. SF14 = Smartcard loss attack resistance for cluster head. SF15 = Replay attack resistance. SF16 = AuC impersonation attack resistance. SF17 = Agriculture professional impersonation attack resistance. SF18 = Cluster head impersonation attack resistance. SF19 = Man-in-the-middle attack resistance. SF20 = Incorrect login attack resistance. SF21 = Insider privileged attack resistance. SF22 = Stolen password verifier table attack resistance. a footer.
Table 10. Storage size cost analysis.
Table 10. Storage size cost analysis.
SchemesSmartcard/(SCi)Smartcard/(SCj)Sensor
[13]608 bitsNA288 bits
[14]768 bitsNA288 bits
[15]864 bitsNA256 bits
[16]736 bitsNA800 bits
[18]768 bitsNA288 bits
Proposed scheme736 bits736 bits256 bits
Table 11. Intercommunication cost analysis.
Table 11. Intercommunication cost analysis.
SchemesM1M2M3M4M5Total
[13]896608320800NA2624 bits
[14]10881248578800NA3714 bits
[15]7048004483202882560 bits
[16]768960608800NA3136 bits
[18]10881248578800NA3714 bits
Proposed scheme6726726725442882848 bits
Table 12. Cryptographic functions in each element of the system.
Table 12. Cryptographic functions in each element of the system.
SchemesAgriculture/Healthcare ProfessionalAuC/GWNCluster Head/Access PointSensor
[13]12Th16ThN/A6Th
[14]2TED + 11Th3TED + 16ThN/ATED + 6Th
[15]1Tfe + 15Th12ThN/A17Th
[16]10Th17ThN/A7Th
[18]2TED + 6Th3TED + 8Th2TED + 5Th1TED + 5Th
Proposed scheme2TED + 4Th4TED + 7Th2TED + 8Th7Th
Table 13. Total running time in sensor node.
Table 13. Total running time in sensor node.
SchemesSensorCost (s)
[13]6Th0.00192 s
[14]TED + 6Th0.00752 s
[15]17Th0.00544 s
[16]7Th0.00224 s
[18]1TED + 5Th0.00720 s
Proposed scheme7Th0.00224 s
Table 14. Total running time costs.
Table 14. Total running time costs.
SchemesTotal FunctionsCost (s)
[13]34Th0.01088 s
[14]6TED + 33Th0.04416 s
[15]1Tfe + 30Th0.02670 s
[16]34Th0.01088 s
[18]8TED + 24Th0.05248 s
Proposed scheme8TED + 26Th0.05712 s
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Share and Cite

MDPI and ACS Style

Nashwan, S. Secure Authentication Scheme Using Diffie–Hellman Key Agreement for Smart IoT Irrigation Systems. Electronics 2022, 11, 188. https://doi.org/10.3390/electronics11020188

AMA Style

Nashwan S. Secure Authentication Scheme Using Diffie–Hellman Key Agreement for Smart IoT Irrigation Systems. Electronics. 2022; 11(2):188. https://doi.org/10.3390/electronics11020188

Chicago/Turabian Style

Nashwan, Shadi. 2022. "Secure Authentication Scheme Using Diffie–Hellman Key Agreement for Smart IoT Irrigation Systems" Electronics 11, no. 2: 188. https://doi.org/10.3390/electronics11020188

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop