Abstract

The integration of IoT with the cloud infrastructure is essential for designing smart applications. However, such integration may lead to security issues. Authentication and session key establishment is an essential security requirement for secure communication between IoT devices and cloud servers. For evaluating authentication key agreement schemes, the extended Canetti–Krawczyk (eCK) adversary model is regarded to be a more strict and relevant adversary model. Many schemes for authenticated key exchange between IoT devices and cloud servers have been proposed in the literature but have been assessed under Dolev and Yoa (DY) adversary model. Recently, Rostampour et al. introduced an ECC-based approach for enabling authentication between IoT devices and cloud servers that is secure and robust to various attacks under the Dolev and Yoa adversary model. In this paper, a detailed review and the automated security verification of the Rostampour et al. scheme are carried out under the eCK adversary model using Scyther-Compromise. The validation indicates that the scheme is not secure and is susceptible to various attacks under the eCK adversary model. To overcome the limitation of the Rostampour et al. scheme, a design of an ECC-based scheme for authentication between IoT devices and cloud servers under the eCK adversary model is proposed. The Scyther verification indicates that the scheme is safe under the eCK adversary model. The soundness of the correctness of the proposed scheme has been analyzed using BAN logic. Comparative analysis indicates that the scheme is resilient under the eCK adversary model with an energy overhead of 278.16 mJ for a resource constraint IoT device and a communication overhead of 1,408 bits.

1. Introduction

The internet of things (IoT) is a new network that provides numerous embedded devices to the Internet to share data. It is based on information and communication technologies. Embedded devices are becoming increasingly complicated as a result of the fast growth of technology, and they are employed in a broad variety of applications. The ability to relate such gadgets to huge resource pools, such as the cloud, is a significant advancement in modern technology. The integration of embedded devices and cloud servers enables the use of IoT in a wide range of commercial and government applications. However addressing the security issues, such as authentication and data privacy is important for the efficient integration of these two systems [13]. IoT has grown significantly over the years because of its relevance in smart applications. The internet of things (IoT) market was valued at USD 250.72 billion in 2019 and is expected to grow to USD 1,463.19 billion by 2027 [4]. This exponential advancement of IoT is governed by its role in developing applications that include smart parking, smart building, smart health, smart environment, smart agriculture, and smart homes [5, 6]. Smart parking can be employed for effective monitoring of parking areas in the city, and smart building applications can be used for monitoring the structural health of a building in terms of vibrations and material conditions. IoT can also be used for real-time motoring the health and the hydraulic parameters of the water bodies and effective monitoring of road conditions in terms of climate conditions [5]. In terms of security and emergency applications, IoT nodes can be deployed for unauthorized perimeter access, detection of harmful chemical and radiation leaks, and detection of gas leaks in industrial surroundings [6]. For smart agriculture, the nodes can be employed for monitoring soil quality, climate control in the greenhouse, and smart irrigation. The various applications in smart homes include surveillance, remote monitoring of appliances, energy, and water conservation. In the medical field, IoT can be employed for developing applications that include wireless body area networks, geriatric assistance, and automatic monitoring of medical freezers [5].

A typical IoT-based smart application comprises a three-tier architecture that includes perception tier, network and server tier, and application tier [5, 7] as shown in Figure 1. The physical parameters are perceived in the perception layer using IoT devices, and the data perceived are further relayed to the server tier. The server tier serves as a communication backbone, employing different communication technologies [7]. As IoT applications generate a large volume of data, the server tier includes features for storing and processing it. A variety of servers, including mobile, web, and real-time communication servers, provide middleware support at the server tier. As the perception layer generates a very large volume of data, cloud servers can also be used at this layer for data storage and management. Various end-users connect to the server tier for offline and online data analysis in the user tier [8, 9]. The security of IoT-based smart applications is of paramount importance [10]. The communication between the server tier and client tier can be made secure using traditional security protocols. However, as IoT devices are resource-constrained, the communication between IoT devices in the perception tier and servers in the server tier becomes an emerging and active area of research [5].

Authentication and session key establishment are bedrock for all other security services between IoT nodes in the perception layer and the various servers in the server tier [11]. Many schemes have been suggested for securing communication between IoT devices and cloud servers. Liao and Hsiao [12] proposed a mutual authentication scheme with ID verifier protocol. However as indicated by [13], the scheme suffers from server impersonation attacks.

Kalra and Sood [14] presented a mutual authentication scheme based on ECC. The scheme is resilient to various attacks. However, the scheme has design issues in terms of mutual authentication, insider, and traceability attacks. Chang et al. [15] pointed out the limitations of Kalra and Sood and highlighted its weakness in terms of mutual authentication and mistress of the session key. Chang et al. suggested an improved scheme that overcame the limitations of Kalra and Sood. Kumari et al. [16] pointed out the deficiencies of Kalra and Sood in terms of insider attacks, device anonymity, session key agreement, and mutual authentication. Kumari et al. also suggested an ECC-based scheme to overcome these limitations. Wang et al. [17] highlighted the deficiencies of the Chang et al. scheme in terms of impersonation attacks and suggested an improved scheme. Recently, Rostampour et al. [11] proposed an ECC-based scheme for authentication of IoT edge devices with the cloud server. Rostampour et al. made a detailed review of the schemes of Kalra and Sood, Chang et al., Kumari et al., and Wang et al. and highlighted their limitations. Rostampour et al. pointed out that all the existing schemes suffer from traceability attacks.

When connecting an embedded system to the cloud, security is the main consideration. Mutual authentication must also be established between the cloud server and the embedded devices. To address these security concerns, many authentication systems for IoT and cloud servers have been developed. However, there are several faults in the existing approaches that must be addressed. When memory and power are limited and greater security with a low key length is required, elliptic curve cryptography (ECC) is the best public-key cryptography solution [18, 19]. The existing schemes presented in the literature have been analyzed under Dolev and Yoa (DY) [20, 21]. However, the eCK [22] adversary model is a more stringent model for authentication key agreement schemes [23]. In this paper, a detailed review of the Rostampour et al. scheme has been made. The Rostampour et al. scheme has been formally validated using Scyther-Compromise [24] under the eCK adversary model. Scyther-Compromise validation depicts that the Rostampour et al. scheme is not secure under the eCK adversary model. Furthermore, an improved scheme for authentication and key agreement between IoT devices and the server under the eCK adversary model has also been proposed.

1.1. Contributions

The major highlights of the paper are as follows:(a)A review of the Rostampour et al. scheme has been made carried out. The scheme has been modeled on Scyther-Compromise and analyzed under the eCK adversary model.(b)An ECC-based authentication scheme for IoT and cloud servers has been designed. The designed scheme provides better functionality and security specifications.(c)The proposed scheme has been modeled on Scyther-Compromise. The results indicate that the scheme is safe under the eCK adversary model.(d)The soundness and correctness of the proposed protocol have also been evaluated using BAN [25] logic.

1.2. Paper Organization

The remainder of the paper is laid out as follows. The preliminaries are presented in Section 2. Section 3 reviews the Rostampour et al. scheme and discusses its formal security verification under the eCK adversary model. In Section 4, the design of the proposed ECC-based scheme for authentication between IoT devices and cloud servers is presented. In Section 5, an informal security analysis has been carried out. Section 6 provides the simulation details of formal security analysis using the Scyther under the eCK adversary model. In Section 7, security analysis using BAN logic has been carried out. Finally, Section 8 presents the comparison of the proposed scheme with other relevant schemes in terms of functional and security specifications.

2. Preliminaries

2.1. Notations

The notations used in the paper are tabulated in Table 1.

2.2. Adversary Model

An adversary model formulates the potential capabilities an attacker can have. Various adversary models exist that include Dolev and Yoa (DY) [20, 21], Canetti–Krawczyk (CK), and extended Canetti–Krawczyk models (eCK) models [22]. In all the models, the communication channel is completely insecure; however, they differ in their adversary query capabilities. In DY threat model, the communication parties are considered to be honest and can run multiple sessions with each other. The communication channel is completely insecure and totally under the adversary’s control, with the ability to record, delete, replay, redirect, rearrange, and completely control message schedule. The adversary can act as an active adversary in the middle and lead various man-in-the-middle attacks. The CK and eCK models are the most widely accepted models for authentication and key agreement protocols. In this adversary model, an attacker has abilities to compromise PRNG and get access to the secret randomness of the session. It is also assumed that an adversary can compromise the session and get access to it. An attacker can also get access to the long-term keys [26]. The major difference between the CK model and the eCK model is that in the eCK model, the adversary is capable of accessing ephemeral secrets, thus leading to an ephemeral-secret-key-leakage attack. An ephemeral key leakage indicates the weaknesses of a random number generator where the attacker can determine the randomness generated correctly with a high probability [26].

2.3. Elliptical Curve Cryptography

Koblitz [27] and Miller [28] introduced elliptical curve cryptography (ECC). ECC is a powerful cryptographic technology. It establishes security between key pairs for public-key encryption using elliptic curve mathematics. ECC has grown in popularity in recent years due to its smaller key size and ability to maintain security. This trend is expected to continue as the need for devices to be secure develops in response to the rising size of keys, putting pressure on limited mobile resources. This is why it is vital to understand elliptic curve cryptography in context of low power devices [29]. When compared to RSA, ECC is highly efficient with low overheads. With a key size of 160 bits, elliptical curve cryptography provides the same level of security as RSA with a key size of 1,024 bits, making it ideal for devices with limited resources [29]. Over a finite prime field Fp, an elliptical curve EP(a, b) is defined as follows [29]:where ▲ = .

Some of the essential definitions related to elliptical curve cryptography are listed below [29]:(a)Point addition: point addition (+) between any two points defined as follows:where is a reflection of the point at which the line joining and intersects the curve . The algebraic computation is given as follows:(b)Scalar multiplication: for any scalar number and the scalar multiplication is defined as follows:(c)Elliptical discrete logarithmic property (ECDLP): given points , ECDLP is a computational problem to find a scalar n such that . ECDLP has been a prominent field of research in cryptography over many decades, and it is the essential foundation for elliptic curve cryptography (ECC) and pairing-based cryptography. ECDLP has exponential time complexity.

2.4. Scyther Simulation

Scyther is a tool for validating and verifying security protocols that was created by Cremers [24]. It is a software that provides security risk assessments and attack simulation capabilities. Scyther uses an infinite number of sessions to verify security protocols. Scyther also allows multiprotocol assaults to be verified. Figure 2 depicts the Scyther Tool’s design in its most basic form. To verify and validate a security protocol in Scyther, it is modeled using Scyther protocol description language (SPDL). The tool accepts the SPDL model to be validated as well as simulation settings. As an output, the Scyther tool generates a summary report showing if the necessary security assertions are valid. If an attack is discovered, it generates a trace pattern in the form of a visual graph or an XML representation. An SPDL model of security protocol comprises roles that define the communication pattern of sender and receiver principals. The term claim is used to specify the various security requirements. Claim secret declares the parameters that must remain confidential from the adversary. The claim alive ensures that the claimant is executing events with the intended party. Nisynch ensures that all the intended messages in the session are sent and received in a synchronized manner, whereas Niagree indicates that the communicating parties agree on the messages exchanged. Finally, the weakagree ensures resilience against impersonation attacks. SKR claim indicates whether the session key designated using SKR can be revealed using the session key adversary rule. To verify this claim, the session key rule in the adversary model setting must be enabled. More details about Scyther are given in [24].

The adversary model by default in the Scyther standard version is Dolev and Yoa. The Scyther-Compromise provides extended support for various adversary models as compared to the standard Scyther version. In this paper, Scyther-Compromise version 0.9.2 has been used.

3. Review and Security Validation of Rostampour Et Al.’s Scheme

3.1. Review of Rostampour Et Al.’s Scheme

The Rostampour et al. scheme comprises two phases given as below:(1)Registration phase(2)Login and authentication phase

3.1.1. Registration Phase

The registration phase is carried out between the device and the server over a secure channel. The steps are given below:(i) generates a random number and computes as (4): sends to the server as follows:(ii)The server generates a random number and calculates (7) and (8):Server stores , and in a secure database.(iii)The server sends to the device as follows:The device stores along with generated .

3.1.2. Login and Authentication Phase

(i) generates a random number and computes (10)–(12):And sends it to the server as follows:(ii)The server finds the entry of in its database and verifies . If the evaluation is false, then the process stops, and if true, then the device is authenticated.(iii)The server generates a random number N2 and computes (14) and (15):Also, it sends it to the device as follows:(iv)Device verifies . If the evaluation is false, then the process stops, and if true, then the device is authenticated. The device computes as in the following equation and sends it to the server:(v)The server receives and verifies . If the evaluation is false, then the process stops, and if true, then the device is authenticated.(vi)The server computes its session key: , and the device computes its session key: , such that .

The schematics of the Rostampour et al. scheme are given in Figure 3.

3.2. Formal Validation of Rostampour Et Al.’s Scheme Using Scyther under the eCK Adversary Model

The SPDL model of the Rostampour et al. protocol is shown in Figure 4. The SPDL modeling comprises two roles: role I and role R. role I models the communication of the , and role R models the . sends to the using send_1(). The receives the using recv_1() function. sends to the using send_2(). The receives the using recv_2() function. Finally, sends to the using send_3(). The receives the using recv_3() function. The claim_i1 in role I and claim_r1 in role I and R indicates that the must remain secret during the communication. The claim_i2 and claim_r2 in roles I and R indicate that can be revealed using the session key adversary rule. claim_r3, claim_r4, claim_r3, and claim_r4 are to verify whether the authentication in terms of Nisynch and Niagree is maintained.

The SPDL model has been initially executed under Dolev and Yoa setting as shown in Figure 5. The Scyther-Compromise verification results of the Rostampour et al. scheme under the Dolev and Yoa setting indicate that the scheme is safe and does not have any attacks. Subsequently, the model was executed under the eCK adversary setting shown in Figure 6. The Scyther verification results under eCK are shown in Figure 7.

The results indicate that the scheme is not safe. The attack trace is shown in Figure 8. The attack trace indicates that the Rostampour et al. scheme under the eCK adversary model is not resilient to session key reveal attack; thus, the adversary can reveal the session key. This is primarily due to the design issue in the Rostampour et al. scheme for computing the session key. In the Rostampour et al. scheme, the session key is computed as . The session key (SK) depends only on short-term session secrets and . SK must also be dependent on long-term term secrets so that the reveal of short-term secrets does reveal session key.

4. Proposed Scheme

The proposed scheme comprises two phases that include(1)Registration phase(2)Login and authentication phase

4.1. Registration Phase

The registration phase includes the registration of an IoT device with the server. As with other schemes, the registration is performed on a secure channel [11]. The need for a secure channel for registration is highlighted as there is no preshared secret in the IoT device or any trusted third party is employed. The steps taken between the device and the server during the registration are listed as below:(i)Device chooses its private key and its identity.(ii)The device calculates as in (19) and sends it to the server:(iii)The server calculates the hash of and splits its private key into two unequal halves such that The server further computes (20) and (21):The server stores and sends to the device as follows:(v)The device receives and stores the parameters along with in its memory.

4.2. Login and Authentication Phase

During this phase, the device initiates to log in to the server. Subsequently, the server authenticates the device, and if the device is authenticated, a session key is subsequently established between the device and the server. The steps undertaken between the device and the server during the login and authentication phase is shown as below:(i)Device chooses its ephemeral secret and calculates and as (23) and (24):The device sends and to the server as follows:(ii)The server receives from and authenticates as follows:(a)The server finds the corresponding entry of and calculates from of the device stored in the database.(b)The server calculates the multiplicative inverse of as and computes as .(c)The server compares . If true, then Step 3 is performed; else, login request from is rejected.(iii)The server chooses its ephemeral secret and calculates and as (26) and (27):(iv)The server computes its session key with as follows:(v)Server sends to the device as follows:(vi)The device receives from the server and authenticates it as follows:(a)The device calculates the multiplicative inverse of as and computes as .(b)The device compares . If true, then S is authenticated; else, login response from S is rejected.(vii)The device computes its session key with as follows:(viii)The device encrypts and sends it to the server as follows:(ix)The server decrypts as and verifies that whether . If true, then the login request is approved, and the device is authenticated.

The schematics of the proposed scheme are given in Figure 9.

5. Security Analysis

5.1. Replay Attack

In a replay attack, an adversary stores the messages exchanged between the communicating parties and retransmits them in the future to gain illegitimate access. In the proposed protocol, three messages are exchanged between the device and the server:

Let us assume during the initiation of the login and authentication phase, an adversary can eavesdrop on the messages and stores and for a replay attack. Let an adversary (A) replay stored of the previous session to gain illegitimate access as follows:

When the server receives , it validates the request and generates with a new ephemeral random secret. The adversary receives a new ephemeral secret. To validate and subsequently generate a session key SK, the adversary needs to know PIDi and the ephemeral random secret previously used for computing . The adversary does not have access to either due to the exponential time complexity of ECDLP [3032]. As the adversary cannot generate a legitimate session key SK of the current session, cannot be computed by the adversary. Moreover, if the adversary replays the old , the server will not authenticate it as the current SK is based on the fresh ephemeral random secret of the server. Thus, the design of the scheme thwarts replay attacks.

5.2. Impersonation Attack

In an impersonation attack, an adversary tries to impersonate a legitimate device. The login and authentication phase starts by computing For computing , an adversary must have access and knowledge of and . The and are shared between the device and the server over a secure channel. Moreover, even if the adversary eavesdrop on of any previous login and authentication session between the device and the server, the and cannot be extracted from due to the computational difficulty of ECDLP. Thus, without the knowledge of and , a valid cannot be computed as such an adversary cannot impersonate any legitimate device by computing a malicious .

5.3. Traceability Attack

In a traceability attack, the message with constant values may reveal the context of communication or the communication pattern. To avoid traceability attacks, messages exchanges must be randomized by incorporating pseudorandom numbers. In the proposed protocol, the ephemeral random secrets induce the required randomness in the messages for each login session. Thus, the traceability attack is mitigated in the proposed scheme.

5.4. Message Integrity Attack

The message exchanged between the device and the server cannot be masqueraded. During the communication, the following messages are exchanged between the device and the server: and . Let us say an adversary intercepts the and and wants to create malicious: . However, to create , the adversary must have access to and . The adversary does not have access to and Moreover, extraction of the private key of from is having exponential time complexity due to the computational complexity of ECDLP. Thus, the integrity of is upheld by the computational infeasibility of ECDLP. Moreover, the message can also not be altered as it is protected by a symmetric encryption technique and one-way hash.

5.5. Man-in-the-Middle Attack

In a man-in-the-middle attack, an attacker can eavesdrop, disguise, and change communication in the middle by forging the key established between the device and the server. An adversary would be successful in executing the man in the middle attack if the adversary in the middle of the communication can create malicious: . However, to create malicious , the adversary must be able to forge as follows:

To forge , adversary must have access to . The adversary does not have access to . Moreover, from , cannot be extracted due to the exponential complexity of ECDLP. As the adversary cannot forge and proper authentication is employed prior to the key establishment, the man-in-the-middle attack is mitigated in the proposed scheme.

6. Formal Validation of the Proposed Protocol Using Scyther

The designed protocol has been modeled using SPDL to validate its security on Scyther-Compromise under the eCK adversary model. The SPDL model of the proposed protocol is shown in Figure 10. The role Device and role Server model the communication pattern of the Di and S, respectively. The role Device initiates the login and authentication phase by sending (P1, P2) using the send_1 function. On receiving (P1, P2) using the recv1 function, the role server sends (P3, P4) using send_2 functions to the device. Finally, the device sends ESK[H(SK)] to the server using the send_3 function. The claim_i1 in role Device and claim_r1 in role Server indicate that the and must remain secret during the communication. The claim_i2 in role Device and claim_r2 in role Server indicate whether can be revealed using the session key adversary rule. claim_r3, claim_r4, claim_r3, and claim_r4 is to verify whether the authentication in terms of Nisynch and Niagree is maintained.

The SPDL model of the designed protocol was simulated on the compromise 0.9 under the eCK adversary model as indicated in Figure 6. The verification results are shown in Figure 11. From Figure 11, we can infer that the protocol is safe and does not have any attack under the stringent eCK adversary model.

7. Formal Security Analysis Using BAN Logic

Burrows et al. proposed BAN logic to validate the soundness and correctness of a security protocol. This section employs BAN logic to determine the security validity of the proposed scheme. and denote the communicating principles, where and denote their private keys, respectively. The BAN notations are tabulated in Table 2 [31], and the BAN postulates are given in Table 3. Besides that, as derived in [33], synthesis rules are tabulated in Table 4.

7.1. Assumptions

(A1)(A2)A3) (A2)A5) (A6)

7.2. Idealized Form

7.3. Goals

G1) G2) G3) G4)

7.4. BAN Analysis

From (MSG1), we get that(1)(2)From (2), (A1), and (R1), we get(3) is a part of ; thus, as per (A3) and (R6), we get(4)From (3) and (5), we get(5)From (7) and (S4), we get(6)From (3) and (6) on applying (R2), we get(7) is the part of the ; thus, on applying (R5), we get(8)Now as per (A5), (8), and (R3), we get(9)From (S3) and (3), we get(10)From (A3) and (10), we get(11)As per (R4) and (11), we get(12)SI is a part of (); thus, as per (R6), we get(13)From (13), (8), and (R7), we get(14)(Goal G1)Due to the symmetry of the protocol,(15)(Goal G2)From (MSG2), we infer that(16)(17)From (17), (A2), (R1), we get(18) is a part of ; thus, as per (A4) and (R6), we get(19)From (17) and (19), we get(20)From (20) and (S4), we get(21)From (18) and (21) on applying (R2), we get(22)SS is the part of the formulae ; thus, on applying (R5), we get(23)Now, as per (A6) and (23) and (R3), we get(24)From (SR3) and (18), we get(25)From (A4) and (25), we get(26)As per (R4) and (26), we get(27)From (R6), we get(28)From (28) and (22) and on applying (R7), we get(29)(Goal G3)Due to the symmetry of the protocol,(30)(Goal G4)

8. Comparison with Other Schemes

8.1. Security Comparison

The security comparison of the proposed scheme with relevant existing schemes is shown in Table 5. Kalra and Sood [14] do not support any security resistance. Chang et al. [15] are not resilient to traceability and impersonation attack. Kumari et al. [16] support only AK3 and AK4 features. Among the existing schemes, Rostampour et al.’s [11] scheme is the only scheme that supports AK1–AK5. However, from Table 5, we can infer that Kalra and Sood [14], Chang et al. [15], Kumari et al. [16], Wang et al. [17], and Rostampour et al. [11] have not been evaluated under the eCK adversary model. The formal validation of Rostampour et al. [11] under eCK adversary indicates that the scheme is not safe under the eCK model. The proposed scheme supports all the security requirements from AK1 to AK5 and is also safe under the eCK model.

8.2. Computation and Communication Overhead

The comparison in terms of computational and communication overhead is shown in Table 6. The time complexities of various critical operations considered include TECM: scalar multiplication, TEADD: point addition, THASH: one-way hash, TSENC/TSDEC: symmetric encryption, and Tinv: multiplicative inverse. TECM is the most computationally intense operation. As IoT devices are resource constraints in nature, the computational overhead on these devices plays an important role in determining the efficiency of the scheme as the server is considered computationally more powerful. From Table 6, we can infer that a computational overhead of 4 TECM for the IoT device and 8 TECM in total is required in the proposed scheme. The highest device overhead is that of the Rostampour et al. scheme with 7 TECM and the lowest is that of Kalra and Sood [14]. However, from Table 5, we can infer that none of the security specifications are supported by Kalra and Sood [14]. In terms of scalar multiplication (TECM) overhead, the proposed scheme is required the same no of scalar multiplication as compared to other schemes considered for comparison. The communication cost is estimated based on the number of bits transmitted. We consider an elliptical curve E(a,b) of 160 bit. The size of an ECC point P(x,y) on the 160 bit curve is 320 bits (X[160], Y[160]). The symmetric encryption considered generates a ciphertext of 128 bit. In the proposed scheme, 03 messages are exchanged that include (P1, P2), (P3, P4), and ESK[H(SK)]. The 03 messages requires [(320 + 320),(320 + 320)+128] = 1,408 bits.

8.3. Energy Overhead

To compare estimated energy consumed on an IoT device, the time consumed by various critical operations as indicated in [34] on a MicaZ mote [35] is shown in Table 7. The energy is consumed using E = V ∗ I ∗ T, where V is the voltage, I is the current drawn, and T is the time taken for the operation. For a MicaZ mote, V = 3 V and I = 8 mA. The proposed scheme has an energy overhead of 278.16 mJ for the IoT device. The comparison of the energy analysis of the proposed scheme with the relevant existing scheme is shown in Figure 12. The highest energy overhead is that of the Rostampour et al. scheme with 477.6 mJ. Rostampour et al. is not secure under the eCK adversary model. Though Kalra and Sood [12] have the lowest energy overhead for the IoT device, it has a high communication overhead and suffers from various security limitations that include AK1, AK2, AK3, AK4, and AK5. Kalra and Sood [12] have not been evaluated under the eCK model. Chang et al. [15], Kumari et al. [16], and Wang et al. [17] have the energy overheads of 271.44 mJ, 271.2 mJ, and 271.68 mJ, respectively. However, Chang et al. [15], Kumari et al. [16], and Wang et al. [17] do not suffice to all security requirements and have not been modeled under the eCK model. The designed scheme supports all the security specifications and is the only scheme that is formally validated under the eCK adversary model. Thus, with the computational requirement of 278.16 mJ and communication overhead of 1,408 bits, the proposed scheme supports all the security requirements and is also safe under eCK adversary.

9. Conclusion

Authentication between IoT devices in the perception layer and the cloud server is critical for developing secure IoT-based smart applications. The existing schemes presented for authenticated key agreements between IoT devices and the cloud services have not been validated using the eCK adversary model. Recently, Rostampour et al. presented a scheme for authenticated key agreement between IoT devices and the cloud server that is secure under the Dolev and Yoa model. A formal security validation of Rostampour et al. has been carried out using Scyther-Compromise under the eCK model. The verification indicates that the scheme susceptible to session key disclosure attacks under the eCK model. A lightweight ECC-based authentication technique for IoT devices and the cloud server has been presented in this paper. The Scyther-Compromise simulation indicates that the proposed scheme is secure under the eCK model. BAN logic analysis and evaluation indicate that the design of the proposed scheme is sound and correct. The overhead analysis indicates that the proposed scheme requires 199.44 mJ and 512 bits less in terms of energy and communication overhead as compared to the scheme presented by Rostampour et al.

Data Availability

The data used to support the findings of this study are included within the article.

Conflicts of Interest

The authors declare no conflicts of interest.