1 Introduction

Internet of Things and CoAP: Internet of Things (IoT) is an infrastructure of the connected smart objects like—sensor(s), actuator(s), RFID Tags, tiny microprocessor(s), communication device(s), power source(s) etc. called things which are connected through wireless (IEEE 802.15.4, WiFi, Bluetooth Low Energy, Internet, cellular communication etc.) or wired connection for data communication [1,2,3,4]. The term ‘Internet of Things’ was initially recommended by Kevin Ashton in the year 1999 [3]. It is a global dynamic network infrastructure with self-configuring capabilities and supported by various protocols used in communication [1, 2]. IoT uses unique addressing schemes where IoT devices are able to interact with each other for common goals [2, 3]. In this regard, IPv6 is used to provide a unique IP address to each IoT device in the network [1, 3, 5]. For the non-IP situation, ZigBee, Z-Wave etc. are used for setting up connection and communication purposes [3] and RFID (Radio Frequency Identification) is used to identify the physical objects and track its location [2]. In general, following protocols are used in the five layers of IoT [1, 4, 6, 7]—(i) IEEE 802.15.4 protocol is used for both physical and MAC layer, (ii) IPv6 over Low power Wireless Personal Area Networks (6LoWPAN) is used in adaptation layer [2, 7], (iii) Routing Over Low Power & Lossy (ROLL) and IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) are used in network layer and (iv) CoAP is used in application layer. However, due to some limitations of IEEE 802.15.4 protocol and to get high data transfer rate, it is better to associate IPv6 with the 6LoWPAN protocol instead of IEEE 802.15.4 protocol in IoT network. It is to be noted that the Maximum Transfer Unit (MTU) of an IPv6 packet associated with 6LoWPAN is minimum 1280 bytes while the MTU of an IPv6 packet associated with IEEE 802.15.4 protocol is maximum 127 bytes [5, 8].

In application layer, the CoAP is mainly used for secure communication between the constraint smart IoT devices and server because MQTT protocol [9] has some limitations such as it can be used only for very low processor devices and can communicate mainly for Amazon cloud applications for server [10]. CoAP uses RESTful architecture [7] to access the resources from server through URI(Universal Resource Identifier) and message communication. Thus, CoAP architecture is divided into two layers—(1) message layer and (2) request/response layer. The message layer is responsible for controlling the exchange of messages between devices over UDP (User Datagram Protocol). The request/response layer is responsible for handling the requests of IoT devices and corresponding responses from other devices/server through message communication and also maintains the status of the messages like out of order, lost or duplicated etc. [2, 3, 5, 6, 11]. The request/response layer is also responsible for manipulating the resources by using one of the various transmission methods such as GET, PUT, POST and DELETE [6, 7, 12].

Literature Review: Initially, Villaverde et al. [13] proposed that the combination of CoAP/UDP can be associated with DTLS for reliable negotiation of a session, verification and exchanging of packets between IoT devices. However, UDP is unreliable since it does not maintain any specific procedure for setting up reliable connection between two devices. On the other hand DTLS packets cannot be translated directly to TLS and vice versa. To resolve these issues authors further incorporates a proxy, 6LoWPAN Border Router (6LBR), for direct mapping between HTTP and CoAP i.e. application conversion between DTLS and TLS respectively. However, ensuring end-to-end security and key management of CoAP are not considered in this scheme [13].

Further, Moritz et al. [14] and Schneider et al. [15] proposed that both SOAP (Service Oriented Architecture) protocol and the XML standard (version utf-8) can be used along with TCP/UDP for secure communication with server. However, SOAP has some limitations like it affords—(1) huge number of cross domain protocol features, (2) complex data representation and (3) composite data transportation mechanisms compared to CoAP that implies an overhead for web services. Hence, SOAP cannot be applied in IoT network [14,15,16]. To overcome these issues, the combination of CoAP/UDP and a data compression technique such as EXI (Efficient XML Interchange) can be used for possible minimization of payloads for constrained IoT devices.

In 2015, Bhattacharyya et al. [17] proposed that DTLS uses any one of the three security modes—(1) pre-shared key mode, (2) raw public key mode and (3) certificate mode. Among these modes pre-shared key mode is the most low-overhead option since it is based on symmetric key based encryption technique [17]. Authors also mentioned that DTLS has a major drawback for IoT network since it is not compatible with lightweight multicast security [17]. As a solution, they have mentioned Lightweight Establishment of Secure Session (LESS) protocol which may be used to maintain secure communication for message exchange and establish a secure session between IoT devices and server.

In 2015, Granjal et al. [18] proposed that the IPsec protocols [8, 18] along with a security standard X.805 can be used as a replacement of DTLS for the secure CoAP implementation. However, there are some limitations such as—(1) the combination of IPSec and X.805 may not be compatible to meet the security requirements in CoAP, (2) the space limitation and complexity of IPSec and (3) CoAP provides lightweight reliability due to transport of the messages over UDP [18]. Further, considering the functionality limitations of IPSec in wireless communication and web applications, Ray et al. [19], Johnson et al. [20] and Levi et al. [21] focused on the use of Wireless Application Protocol (WAP) along with Wireless Transport Layer Security (WTLS) protocol [19, 21] as a replacement of IPSec/TLS/DTLS. WAP is mainly used in various constraint devices like mobile phone, PDA etc. However, WAP has some limitations such as—(1) functional complexity and (2) security related problems of WTLS like end-to-end security weakness and man-in-the-middle attack at the WAP gateway [16, 19,20,21]. To remove these limitations and reduction of bandwidth requirements, CoAP protocol can be used.

In 2016, Rahman and Shah [6] and later on in 2017 Raza et al. [22] proposed that CoAP/UDP combination along with the encryption techniques—DTLS/IPSec are used to afford confidentiality, integrity, authentication and non-repudiation by means of the following four security modes—(1) NoSec: In this mode, no security service is offered. (2) Pre-shard Key: symmetric keys are generally used in this approach. (3) Raw Public Key: In this mode, authentication is based on public keys and no certificate is used for authentications purposes. A session can be set off for DTLS with pre-shared list of keys for the communicating devices. (4) Certificates: In this mode asymmetric key along with the certificate standard X.509 is used for validation purpose. However, ECC is another public-key cryptography which supports for both the Certificates and Raw Public Key modes. Hence, ECC based system can be used for pre-shared key (PSK) based system while it is integrated with CoAP related environment. Moreover, DTLS can be integrated in Raw Public Key mode for server communication using CoAP [6, 22]. However, the drawback of the CoAP security is key management [7] and the multi-cast messaging which is used to transmit between two hops/objects [6, 22] is not supported by DTLS.

In 2017, Iglesias-Urkia et al. [23] proposed that different open source libraries from different platforms like—C, Java, Python, Java Script etc. are used for the implementation of CoAP related environment. However, based on the performance of server, authors have also analyzed that the C language based open source libraries like ‘lipcoap’ or ‘smcp’ are very user friendly and most of them are surrounded by inbuilt libraries and it handles the response code and maintains handler for those responses. On the other hand, ‘lipcoap’ or ‘smcp’ are the fastest libraries among the other libraries from different platforms like Java, Java Script etc. In 2017 Alabas et al. [24] anticipated a review based on the different existing architecture related to IoT security, vulnerabilities and CoAP based communication with server. Some of the architectures are—(1) SDN Architecture, (2) SEA Architecture, (3) Smart City, (4) Service Oriented Architecture (SOA), (5) OSCAR (Object Security Architecture) with CoAP, (6) Black SDN Architecture etc. However, based on the review of authors it is found that those architectures are still facing some problem related to multicasting, asynchronous data communication, caching, lack of strong encryption techniques, authentication and key management issues related to CoAP header etc.

In 2018, Albalas et al. [25] presented the performance evaluation between the CoAP using ECC and CoAP using RSA based on three different factors—(i) message length, (ii) security services and (iii) residual energy. It is mentioned that the CoAP using the ECC is 47% efficient in saving energy than CoAP using RSA due to smaller key size of ECC.However, the CoAP using ECC is still facing some problems related to multicasting, asynchronous data communication and key management issues related to CoAP [25]. This study has motivated us to develop ECC-CoAP protocol eliminating most of the aforementioned limitations.

In 2019, Harish et al. [26] establishes a secure connection using HTTP between IoT nodes and handles the HTTP request through a proxy which is referred to 6LoBR and maintains the security issues for the CoAP layer by encrypting/decrypting the payload of the corresponding CoAP request/response using ECC. It is managed by an IoT controller which maintains the whole traffic of the wireless network. However, it is found that the scheme [26] is suffering from some key management issues of CoAP.

Recently in 2019, Dey and Hossain [27] have proposed session key establishment for smart home network using LESS [17] protocol and shown that existing LESS protocols are not safe against relevant security attacks [28].

Contribution of the Research: To address all the issues raised from the above discussion on existing CoAP related schemes, we are motivated to design a secure and efficient CoAP using ECC for end-to-end communication and efficient key management between the IoT devices and remote server. We have referred this scheme as ECC-CoAP.

Organization of the Paper: The rest of the paper is organized as follows. Section 2 provides the basic overview of ECC and CoAP. The step-wise ECC-CoAP is proposed in Sect. 3. The security and performance analysis of the proposed scheme are discussed in Sects. 4 and 5 respectively. In Sect. 6, the simulation result of formal security verification of ECC-CoAP using AVISPA tool is conferred. Finally, Sect. 7 concludes the paper.

2 Preliminaries

In this section, the fundamental concepts of ECC and CoAP are illustrated briefly.

2.1 CoAP Overview

In application layer, the constraint application protocol CoAP is mainly used for secure communication between the IoT devices and server. CoAP architecture is divided into two layers—(i) message layer and (ii) request/response layer. The message layer is responsible for controlling the exchange of messages between devices over User Datagram Protocol (UDP). The request/response layer is accountable for handling the requests of objects and corresponding responses from other objects/server through message communication [2, 3, 5, 6, 9] by using one of the following transmission methods such as GET, POST, PUT and DELETE [6, 7, 10].

GET

It is used for CoAP related applications to retrieve resources through URI requests

POST

It generates a new request for the creation of new subroutine to the server under the parent URL for communication with the resource.

PUT

This method is used to communicate with the resources based on the request transferred within the message body. So, there is no separate URL request is required

DELETE

It is used for deletion of the URI requests

In IoT architecture, instead of HTTP protocol CoAP is generally used due to the following:

  1. (i)

    Due to limited size and bandwidth requirement of constraint devices of IoT architecture, HTTP cannot be used. Being a compressed version of HTTP, CoAP provides required size and bandwidth for constrained devices.

  2. (ii)

    HTTP protocol incurs more space consumptions where as CoAP is a lightweight protocol in terms of space overhead.

  3. (iii)

    HTTP generally uses connection oriented reliable TCP protocol where as CoAP uses connectionless UDP.UDP is unreliable that simply carries messages and transmits lost packets.

  4. (iv)

    HTTP protocol is designed for internet-based applications and devices where there is no constraint of power consumption. In IoT environment the nodes are generally power-constrained this makes CoAP suitable for IoT environment.

In general, CoAP uses a pre-shared key (PSK) along with DTLS for secure communication between IoT devices and server [12]. For transfer of data between IoT devices and server, CoAP messages are developed and used as per the specific formats [7] such as—Java Script Object Notation (JSON), Extensible Markup Language (XML), Concise Binary Object Representation (CBOR) etc. These can be secured by using various encryption formats such as—JavaScript Object Signing and Encryption (JOSE), XML-Security (XMLS), Constrained Object Signing and Encryption (COSE) etc. [7] (Table 1).

Table 1 Different steps of LESS protocol [17]
Full size table

In 2015, Bhattacharyya et al. [17] proposed LESS (Lightweight Establishment of Secure Session) protocol for constraint devices which are useful for secure communication between the application layer and transport layer as well as establishment of secure session for CoAP. It pursues the following six steps of action for the establishment of secure session and switches the control from CoAP to DTLS in order to afford the security of the respective channel.

In our scheme we have reduced the number of steps to five of LESS protocol proposed by Bhattacharyya et al. [17] and incorporated ECC to develop ECC-CoAP protocol.

2.2 The Elliptic Curve Cryptography (ECC)

Elliptic Curve Cryptography (ECC) was proposed by Victor Miller and Neal Koblitz in 1985 and 1987 respectively [29,30,31,32].An elliptic curve E over a prime finite field Fp which is denoted as E/Fp and is defined by the following elliptic curve equitation:

$$y^{2} mod \, p \, = \, \left( {x^{3} + \, ax \, + \, b} \right) \, mod \, p$$
(i)

where \(a, \, b, \, x, \, y \in F_{p}\) hat satisfies the equation of the discriminant D where D = 4a3 + 27b2 (mod p) ≠ 0. The additive elliptic curve group curve group Gp is defined as \(\{ (x,y):x, \, y \in F_{p} \,{\text{and}}\,(x,y) \in E/F_{p} \} U\left\{ O \right\}\) where the point “O” is known as “point at infinity”.

Point Addition: Let P, Q be two points on the elliptic curve given in equation(i) then, the straight line joining P and Q i.e. P + Q = R, where the straight line intersects the equation (i) at the point (− R) which reflects at point R with respect to x-axis [33].

Point Subtraction: If the point Q = (− P), then the line formed by joining by P and Q, i.e. P + Q = P + (− P) = O, i.e. the line joined by P and (− P) which intersects the equation (i) at the point O which is called point of infinity [34].

Point Doubling: It is the process of addition of point P on equation (i) with itself to obtain another point Q on equation (i). Let P + P = 2P and Q = 2P. If a tangent straight line is drawn at point P, then it intersects the curve of equation (i) at point (− Q). The reflection of this point with respect to x-axis is at point Q [35].

Scalar point Multiplication: The scalar point multiplication is based on the concept of cyclic group GP which is defined as \(Q \, = \, x.P \, = \, P + P + P \cdots + P\) (x times), where \(x\, \in \;_{R} Z_{p}^{*}\) and P is a generator of the cyclic group [35].

Security strength of ECC reclines on the difficulty of solving the Elliptic Curve Discrete Logarithm Problem (ECDLP) that provides same level of security strength like RSA but with lesser bit-size key. Similar to Diffie–Helman Problem (DHP), ECDLP is based on the discrete logarithm problem and does not pursue any polynomial time algorithm. In ECDLP, two elements P and Q are taken from a random instance \(\left( {P, \, Q} \right) \in G_{p}\), where GP is a cyclic group. It is impossible to find an integer \(q\, \in \,_{R} Z_{p}^{*}\) such that Q = q.P by a polynomial time bounded algorithm where P is the generator for the cyclic group GP.

3 The Proposed Scheme

In this paper, we have overcome the limitations of key management of CoAP [18] using ECC and a fresh ECC-CoAP protocol is developed by improving the efficiency of LESS protocol [17] with reduced the number of steps. This scheme is mainly useful for resource constrained IoT environment for secure communication between IoT devices and server with reduced communication overhead. The proposed scheme contains five steps—(i) Session initiation (ii) Server challenge phase (iii) Client response and challenge phase (iv)Client authentication and server response phase and (v) Key negotiation and server authentication phase. The entire working procedure is explained in the following subsections where the subsequent notations illustrated in Table 2 are used. The steps involved in proposed ECC-CoAP protocol are demonstrated in briefly in Table 3.

Table 2 Notations and respective descriptions
Full size table
Table 3 Different steps of ECC-CoAP
Full size table

Now the pre-requisite of the proposed ECC-CoAP protocol and its step-wise working procedure are explained in the following sub-sections.

3.1 Pre-requisite of ECC-CoAP

Initially, the server selects an elliptic curve Ep(a,b) over a prime finite field Fp, where P is the generator of order n. Next, the private key as \(q_{S} \in {\mathbb{Z}}_{p}^{*}\) selected by the server and calculates its public key as QS = qS.P using ECC based scalar point multiplication (ECPM). Similarly, user/IoT device randomly selects a large random number \(q_{U} \in {\mathbb{Z}}_{p}^{*}\) such as 0 < qU < n as a private key of the user/IoT device and generates the public key QU as QU = qU.P. The user/IoT device then gets the ECC based public key certificate CAU, combining its identity IDU and public key QU from the certificate authority CA.

3.2 Working Procedures of ECC-CoAP

The detail step-wise working procedures of ECC-CoAP for communication between the user/IoT device and server is shown in Fig. 1 and illustrated below where X \(\to\) Y: M denotes that sender X sends a message M to receiver Y.

Fig. 1
figure 1

ECC-CoAP diagram for maintenance of secure session and authentication

Full size image

  • Step 0: U \(\to\) S:IDU, CAU,\(E_{{K_{X} }}\)(HU), T1

Initially, user/IoT device generates a random high entropy password PWU. Then user/IoT device computes (i) the symmetric shared key K between user/IoT device and server as K = qU.QS = qU.qS.P = (KX,KY) where qU and QS are the private key of user/IoT device and public key of server respectively, and (ii) HU = h (IDU||PWU||qU)where h is a one way irreversible cryptographic hash function and encrypts HU using KX. Finally, it sends a session initiation request containing IDU, CAU, encrypted HU and T1 to server.

  • Step 1: S \(\to\) U:IDS,\(E_{{K_{X} }}\)(DIDU||RS),T2

After receiving the session initiation request from user/IoT device in time T2, server checks |T2 − T1| ≤ ∆T? If yes the server retrieves the user’s identity IDU and public key QU from CAU and checks retrieved IDU = received IDU? If fails the communication is terminated; Otherwise, the server (i) calculates the symmetric shared key K = qS.QU = qS.qU.P = (KX,KY),(ii) decrypts the encrypted message using KX and gets HU, (iii) generates a dynamic identity of the user/IoT Device DIDU = h(IDU||K||HU),(iv) selects a random number \(r_{S} \in {\mathbb{Z}}_{p}^{*}\) to calculate the server’s random point RS = rS.QS = rS.qS.P using ECPM,(v) stores HU and DIDU at the server’s database for future reference,(vi) concatenates DIDU and RS, then the concatenated message is encrypted using symmetric key KX and finally (vii) sends the IDS, encrypted message and T2 to IoT device as server challenge.

  • Step 2: U \(\to\) S:RU,\(E_{{SK_{X} }}\)(MU), T3

The IoT device receives the server’s challenge in time T3 and verifies the legitimacy of the server’s challenge i.e. checks |T3 − T2| ≤ ∆T? If yes, the IoT device decrypts the encrypted server challenge using KX and gets DIDU and RS. Now, it(i) calculates dynamic identity DIDU = h (IDU||K||HU)and (ii) compares the calculated DIDU with received DIDU. If the comparison is unsuccessful the communication is terminated; otherwise, the IoT device selects a random number \(r_{U} \in {\mathbb{Z}}_{p}^{*}\) and calculates a random point RU = rU.QU = rU.qU.P. It then calculates the session key as \(SK = q_{U.} r_{U.} R_{S} = q_{U} .r_{U} .r_{S} .q_{S.} .P = (SK_{X,} SK_{Y} )\) and MU = h(own RU||own HU||DIDU||T3). Now it encrypts MU using the recently calculated session key SKX and sends the encrypted message with RU and T3 as a response to server’s challenge.

A variable count is initialized with 0 and incremented with 1 after each unsuccessful response message transmission. Each IoT device is allowed to get 3 attempts to authenticate to server otherwise the device will be blocked for a specific period of time. This method is implemented to stop cryptographic attacks like brute-force attack.

  • Step 3: S \(\to {\text{U}}\):\(E_{{SK_{X} }}\) (MS), T4

The server receives the client’s challenge in time T4 and checks |T4 − T3| ≤ ∆T? If yes, server (i) calculates the session key \(SK \, = \, q_{S.} r_{S \, .} R_{U} = \, q_{S.} r_{S} .r_{U} .q_{U} .P = q_{U} .r_{U} .r_{S} .q_{S.} .P \, = (SK_{X,} SK_{Y} )\), (ii) decrypts the encrypted client challenge and gets MU as \(D_{{SK_{X} }} (E_{{SK_{X} }}\)(MU)) = MU (iii) calculates M /U = h(received RU ||Stored HU||Stored DIDU||T3)and (iv) checks M /U = MU? If both are equal, the IoT device is authenticated to server.

Now the server calculates MS = h (RS||MU), encrypts MS using session key SKX and finally sends the encrypted MS and the current timestamp T4 as a server’s response to IoT device.

  • Step 4: U \(\to {\text{S}}\) : Message communication M is done in EXI format

The IoT device receives the server response in time T5 and checks |T5 − T4| ≤ ∆T? If yes, IoT device decrypts the encrypted server’s response using session key SKX and gets MS as \(D_{{SK_{X} }} (E_{{SK_{X} }}\)(MS)) = MS. Now it calculates M /S = h(received RS||sent MU) and checks M /S = MS? If both are equal, the server is authenticated to IoT device; otherwise the communication is terminated. All the further message communication M is done in EXI format using SKX between the server and IoT device.

4 Security Analysis

All the relevant security features and security attacks are considered in this section to prove the robustness of the proposed ECC-CoAP. The ECC-CoAP is formally verified using well-known BAN logic as well as using mathematical procedures. Finally the result demonstrates that the scheme is well protected against all relevant security breaches and preserves all the significant security features. The following subsections describe—(i) Informal security analysis and (ii) Formal security analysis using BAN logic.

4.1 Informal Security Analysis

This section illustrates informal security analysis of ECC-CoAP protocol using mathematical procedures. Some practical assumptions are taken into account for proving the security strength of the protocol as given in the literature [36,37,38,39,40,41,42].

4.1.1 Man-in-the-Middle Attack

Let an adversary Ã, present between user/IoT device and server, intercepts the session initiation message containing \(ID_{U,} CA_{U,} E_{{K_{X} }} \left( {H_{U} } \right),T_{1}\) and intends to modify it in such a way that it seems to be coming from a legitimate user containing valid identity IDU of the legitimate user but with the replaced value of CAU and HU of the adversary. However, after receiving the message, server retrieves IDU from CAU and checks retrieved IDU = received IDU?. It results failed verification and communication will be terminated. Moreover, if the adversary à only tries to modify the parameter HU it will not be possible as it is communicated by encrypting using ECDH based contributory symmetric key which is hard to forge in polynomial time. Hence, the ECC-CoAP scheme is robust against Man-in-the-Middle Attack.

4.1.2 Denial-of-Service (DoS) Attack

In the client response and challenge phase of ECC-CoAP scheme, if the IoT device fails to be authenticated by server within three attempts then the IoT device will be blocked for a specific period of time. A variable count is initialized with 0 and incremented by 1 after each of the unsuccessful response message transmission by the server. Every IoT device gets at most 3 attempts to be authenticated. Hence, an adversary à will not be able to send multiple fuzzy requests (more than three) to make the system resource overloaded to make the services unavailable to the legitimate user, thus ECC-CoAP restricts the DoS attack.

4.1.3 Replay Attack

In the client response and challenge phase of the proposed ECC-CoAP scheme, if an adversary à acquires the authentication message of the user \(\{ R_{U} ,E_{{SK_{X} }} \left( {M_{U} } \right),T_{3} \}\) where MU = h(RU||HU||DIDU||T3) and tries to replay it in later session just changing the current recorded time from T3 to T3′ \(\{ R_{U} ,E_{{SK_{X} }} \left( {M_{U} } \right),T_{3}^{\prime } \}\). After receiving this authentication request by the server, it will check ||T4 − T3′| ≤ ∆T, which would be successful. However, after checking the timestamp it will calculate MU′ = h(RU||HU||DIDU||T3′) which will not be same as the received MU. Hence, the session will be terminated. As in the proposed scheme, current timestamp is not only sent as a parameter of the message it also included as a parameter of MU it is resilient to reply attack.

4.1.4 Insider Attack

Users provide their valid credentials to be authenticated to the remote server by assuming the remote server is trusted. However, sometimes it is noted that any insider of the remote server acts as an adversary à after getting some crucial credentials of the user stored into the remote server. In proposed ECC-CoAP, the server stores HU and DIDU as the crucial credentials for further authentication of IoT device. In this scenario, if HU and DIDU are acquired by the insider, still it cannot be authenticated as a legitimate user. For generating a valid authentication request, it is required to generate a random nonce say RU′=rU′.QU and MU′ = h(RU′||HU||DIDU||T3).Then MU′ is encrypted using SK where SK is ECDH based session key calculated as SK = qU.rU.RS where qU is the private key of the valid user. So, it is impossible for the insider to somehow calculate the session key SK due to hardness of ECC as well as it includes private key of the valid user. Hence ECC-CoAP is safe against insider attack.

4.1.5 User Impersonation Attack

If an adversary à pretends to be an authorized user of the system. The adversary à impersonates the transmitted message and re-transmits it pretending as a valid user. User impersonation attack cannot be possible in client side due to the following reasons:

  1. (i)

    At the time of session initiation, user/IoT device sends the session initiation message \(\{ ID_{U} ,CA_{U,} E_{{K_{X} }} \left( {H_{U} } \right),T_{1} \}\) to server. If the identity of the IoT device is modified then the server can easily track it from the ECC based public key certificate CAU (containing identity IDU and public key QU) as it is certified from the certificate authority and cannot be forged. .

Moreover, hash digest of the identity of the user HU (containing identity IDU, password PWU and private key qU) cannot be replaced by the adversary à as it is transmitted in encrypted form by using the symmetric key KX. However, KX cannot be calculated due to hardness of ECDLP. So, HU cannot be decrypted.

  1. (ii)

    In client’s response and challenge phase of ECC-CoAP, user/IoT device sends authentication request message containing \(\{ R_{U} ,E_{{SK_{X} }} (M_{U} ),T_{3} \}\).If the adversary à intends to generate the masked identity of the user MU it will not be able to compute it as it is encrypted using SK which is ECDH based session key where SK = qUrU. rS.qS.P composed of private of the user qU.

Hence, proposed ECC-CoAP is CoAP scheme is robust against user impersonation attack.

4.1.6 Server Impersonation Attack

In this type of attack, an adversary à acts as a server by knowing some secret credentials of the server and further communicates with the user to exchange the messages. At first, the server sends a challenge message \(ID_{S,} E_{{K_{X} }} (DID_{U} || \, R_{S} ),T_{2}\) as a response of the session initiation request \(\{ ID_{U} ,CA_{U} ,E_{{K_{X} }} \left( {H_{U} } \right),T_{1} \}\) of the user/IoT device. However, to forge the server challenge to user the adversary à needs to decrypt the value of HU to compute valid DIDU = h(IDU||K||HU)using the symmetric key KX. However, K is tough to compromise due to the hardness of ECDLP. So, the adversary à cannot be able to determine the dynamic identity of IoT device valid DIDU. So, ECC-CoAP is safe against server impersonation attack.

4.1.7 Offline Password Guessing Attack

This is one of the most popular attacks that mainly occur at the password based authentication schemes due low entropy passwords chosen by the user. So, a strong password based scheme can restrict this type of attack. In ECC-CoAP, password PWU is only used to calculate HU where HU = h (IDU ||PWU||qU) which stored for further communication. Hence, the adversary à cannot be able to generate HU only by randomly guessing the password the user/IoT device as HU requires qU, the private key of the user. Thus, ECC-CoAP is protected against offline password guessing attack.

4.1.8 Known Session Specific Temporary Attack

To avoid the occurrence of known session-specific temporary information attack, session key in ECC-CoAP is calculated in IoT device end as SK = qU.rU.RS = qU.rU.rS.qS.P and from server end as SK = qS.rS.RU = qS.rS.rU.qU.P = qU.rU.rS.qS.P which contains the private keys of each end. Although any one of the secret random values like rs or rU of the server and user respectively are accidentally exposed to adversary Ã, still the session key cannot be generated due to the unavailability of the private keys. So, ECC-CoAP is free from known session specific temporary attack.

4.1.9 Session Key Computation Attack

ECC-CoAP is designed to agree upon a common secret session key SK = qU.rU.RS = qS.rS.RU = qU.rU.rS..qS.P to carry out further data exchange securely between the user/IoT device and server. The proposed scheme provides ECDLP based secure session key which is hard to compromise due to hardness of ECDLP. Further, the session key cannot be computed it is generated based on two private keys and two random numbers both from user/IoT device and server end. If any of the secret parameters are somehow guessed or acquired in polynomial time, the other parameters are not available to the adversary à for session key computation. Hence, ECC-CoAP is resilient to session key computation attack.

4.1.10 Efficient Mutual Authentication

ECC-CoAP provides a mutual authentication between the user/IoT devices and server based on two secret credentials MU and MS which are calculated based on secret values, mutually shared between them. During client authentication the server receives MU encrypted using negotiated session key SKX. M /U is then calculated by the server using stored parameters DIDU and HU as M /U = h(received RU ||Stored HU||Stored DIDU||T3). If M /U and MU are equivalent then only the user/IoT device is authenticated. Similarly, during server authentication M /S is calculated by the user/IoT device M /S = M /S = h(received RS||sent MU). If M /S and MS are equivalent then only the server is authenticated. From the above discussion it is clear both server and client validate each other with the prior knowledge as well as received values. So, ECC-CoAP comprises of efficient mutual authentication.

4.1.11 Non-repudiation

Non-repudiation is a property which prevents a sender or entity from denying sending a message to the receiver. Use/IoT device sends the session initiation message containing \(\{ ID_{U} ,CA_{U} ,E_{{K_{X} }} \left( {H_{U} } \right),T_{1} \}\) to server. As the message contains the public key certificate of the message includes public key certificate containing valid identity of the user/IoT device it cannot deny about the sending of the message. On the other hand, in server challenge phase, server sends the reply composed of \(\{ ID_{S,} E_{{K_{X} }} (DID_{U} || \, R_{S} ),T_{2} \}\) to user/IoT devices with server identity IDS. So, in case also the server cannot deny the sending of message. So, ECC-CoAP comprises of non-repudiation.

4.1.12 Perfect Forward Secrecy

In the proposed ECC-CoAP the symmetric contributory key K is compromised the adversary à cannot calculate the session key SK where SK = qU.rU.RS = qS.rS.RU = qU.rU.rS..qS.P because with the knowledge of symmetric key K the adversary à does not know the secret private key (qU,qS) or the random number of the particular session (rU.,rS). Even if the adversary Ãcan decrypt the message using the compromised symmetric key K to obtain random nonce RU and RS where RU = rU.QU and RS = rS.QS, it cannot acquire the knowledge of session specific random numbers (rU.,rS) due to the hardness of ECDLP. So, ECC-CoAP achieves the property of perfect forward secrecy.

4.2 Formal Security Analysis

In formal security analysis we have analyzed the security of ECC-CoAP protocol by using through Burrows–Abadi–Needham (BAN) logic [43, 44].For analyzing security related to key agreement and authentication protocol, BAN logic is most widely used mathematical model.

  • BAN Logic Based Authentication Proof

The concerned following rules and notations of BAN logic are described in Tables 4 and 5 respectively, where X and Z are the general instances that participate in a protocol.

Table 4 Notations for BAN logic
Full size table
Table 5 Primitive formulae used in BAN logic
Full size table

Following goals are required to be satisfied by aforesaid rules in order to prove the robustness of the ECC-CoAP under BAN logic.

Goals

  • Goal 1: \(S| \equiv S\overset {SK} \longleftrightarrow C\)

  • Goal 2: \(S| \equiv C| \equiv S\overset {SK} \longleftrightarrow C\)

  • Goal 3: \(C| \equiv C\overset {SK} \longleftrightarrow S\)

  • Goal 4: \(C| \equiv S| \equiv C\overset {SK} \longleftrightarrow S\)

Idealized form of communicated messages

Message 1

\(C\; \to \;S:ID_{U} ,H_{U} ,T_{1} :\left\{ {\left\langle {H_{U} } \right\rangle_{{(ID_{U} ,PW_{U} ,q_{{_{U} }} )}} } \right\}_{K}\)

Message 2

\(S\; \to \;C:ID_{S} ,DID_{U} ,R_{S} ,T_{2} :\left\{ {\left\langle {DID_{U} } \right\rangle_{{(ID_{U} ,K,H_{U} )}} } \right\}_{K}\)

Message 3

\(C\; \to \;S:M_{U} ,R_{U} ,T_{3} :\left\{ {\left\langle {M_{U} } \right\rangle_{{(R_{U} ,H_{U} )}} ,\left\langle {R_{U} } \right\rangle_{{(r_{U} .q_{U} .q_{S} .P)}} } \right\}_{K}\)

Message 4

\(S\; \to \;C:M_{S} ,T_{4} :\left\{ {\left\langle {M_{S} } \right\rangle_{{(R_{S} ,M_{U} )}} } \right\}_{SK}\)

Following assumptions are required to authenticate the BAN logic for ECC-CoAP.

  • A1: S |≡ # T2,T4

  • A2: C |≡ # T1,T3

  • A3: S |≡ # qS

  • A4: S |≡ # rS

  • A5: C |≡ # qU

  • A6: C |≡ # rU

  • A7: S |≡ C # QU, RU

  • A8: C |≡ S # QS, RS

  • A9: C |≡ C \(\,\mathop \leftrightarrow \limits^{K} \,\) S

  • A10: S |≡ S \(\,\mathop \leftrightarrow \limits^{K} \,\) C

  • Proof of the Proposed Scheme using BAN Logic

Message 3

$$C\, \to \,S:M_{U} ,R_{U} ,DID_{U} ,T_{3} :\left\{ {\left\langle {M_{U} } \right\rangle_{{(R_{U} ,H_{U} ,DID_{U} )}} ,\left\langle {R_{U} } \right\rangle_{{(r_{U} .q_{U} .P)}} ,\left\langle {DID_{U} } \right\rangle_{{(ID_{U} ,H_{U} ,K)}} } \right\}_{K}$$

By applying seeing rule:

$$S1:S \triangleleft \left\{ {\left\langle {M_{U} } \right\rangle_{{(R_{U} ,H_{U} ,DID_{U} )}} , \left\langle {R_{U} } \right\rangle_{{(r_{U} ,q_{U} )}} } \right\}$$

By applying message meaning rule, S1, A10:

$$S2:S| \equiv C \sim\left\{ {\left\langle {M_{U} } \right\rangle_{{(R_{U} ,H_{U} ,DID_{U} )}} ,\left\langle {R_{U} } \right\rangle_{{(r_{U} .q_{U} .P)}} } \right\}$$

According to A5, A6, S2 and freshness rule

$$S3: \, S| \equiv C| \equiv \# \left\{ {\left\langle {M_{U} } \right\rangle_{{(R_{U} ,H_{U} ,DID_{U} )}} ,\left\langle {R_{U} } \right\rangle_{{(r_{U} .q_{U} .P)}} } \right\}$$

According to S3, S2 and nonce verification rule

$$S4: \, S| \equiv C| \equiv \left\{ {\left\langle {M_{U} } \right\rangle_{{(R_{U} ,H_{U} ,DID_{U} )}} ,\left\langle {R_{U} } \right\rangle_{{(r_{U} .q_{U} .P)}} } \right\}$$

According to A7, S4 and jurisdiction rule

$$S5: \, S| \equiv \left\{ {\left\langle {M_{U} } \right\rangle_{{(R_{U} ,H_{U} ,DID_{U} )}} ,\left\langle {R_{U} } \right\rangle_{{(r_{U} .q_{U} .P)}} } \right\}$$

As the session key is calculated as

$$SK = \, q_{s} .r_{S} .r_{U} .q_{u} .P$$

According to S5, S3 and session key rule

$$S6: \, S| \equiv S| \equiv S\mathop \leftrightarrow \limits^{K} C$$
(Goal 1)

According to S6 and session key rule

$$S7: \, S| \equiv C| \equiv S \equiv S\mathop \leftrightarrow \limits^{K} C$$
(Goal 2)

By applying seeing rule:

$${\text{S}}8:C \triangleleft R_{S} ,M_{S} ,T_{4} \left\{ {\left\langle {R_{S} } \right\rangle_{{(rs,q_{U} ,qs.P )}} , \left\langle {M_{S} } \right\rangle_{{(R_{S} ,M_{U} )}} } \right\}_{K}$$

By applying message meaning rule, S8, A10:

$$S9: \, C| \equiv S\,\sim\,R\left\{ {_{S} ,M_{S} ,T_{4} :\left\{ {\left\langle {M_{S} } \right\rangle_{{(R_{S} ,M_{U} )}} ,\left\langle {R_{S} } \right\rangle_{{(r_{S.} r_{U} .q_{U} .q_{S} .P)}} } \right\}_{K} } \right\}$$

According to A3, A4,S9 and freshness rule

$$S10:C| \equiv S| \equiv \# \left\{ {R_{S} ,M_{S} ,T_{4} :\left\{ {\left\langle {M_{S} } \right\rangle_{{(R_{S} ,M_{U} )}} ,\left\langle {R_{S} } \right\rangle_{{(r_{S} .r_{U} .q_{U} .q_{S} .P)}} } \right\}_{K} } \right\}$$

According to S9, S10 and nonce verification rule

$$S11: \, C| \equiv S| \equiv \left\{ {R_{S} ,M_{S} ,T_{4} :\left\{ {\left\langle {M_{S} } \right\rangle_{{(R_{S} ,M_{U} )}} ,\left\langle {R_{S} } \right\rangle_{{(r_{S} .r_{U} .q_{U} .q_{S} .P)}} } \right\}_{K} } \right\}$$

According to A8, S11 and jurisdiction rule

$$S12: \, C| \equiv \left\{ {R_{S} ,M_{S} ,T_{4} :\left\{ {\left\langle {M_{S} } \right\rangle_{{(R_{S} ,M_{U} )}} ,\left\langle {R_{S} } \right\rangle_{{(r_{S} .r_{U} .q_{U} .q_{S} .P)}} } \right\}_{K} } \right\}$$

As the session key is calculated as

$$SK = \, q_{s} .r_{S} .r_{U} .q_{u} .P$$

According to S10, S12 and session key rule

$$S13:C| \equiv C\mathop \leftrightarrow \limits^{K} S$$
(Goal 3)

According to S13 and session key rule

$$S14: \, C| \equiv S| \equiv C\mathop \leftrightarrow \limits^{K} S.$$
(Goal 4)

5 Simulation for Formal Security Verification of ECC-CoAP Using AVISPA Tool

In this section, formal security verification by using the Automated Verification Internet Security Protocol and Applications (AVISPA) simulator tool is used for ECC-CoAP to ensure that ECC-CoAP is secure against all relevant attacks. AVISPA is a role-based simulator [45,46,47,48,49] that denotes that each participant plays a specific role and supports a language called High Level Protocol Specification Language (HLPSL).

5.1 Brief Discussion of the AVISPA Simulation Tool

The working procedure of AVISPA by using HLPSL is shown in the following Fig. 2. HLPSL specification is translated into an Intermediate Format (IF) by using a translator called HLPSL2IF, where IF is a lower level language compared to HLPSL [50]. It is used directly by the backends of the AVISPA tool to analyze whether the security goals are satisfied or violated. Based on this result, AVISPA tool produces the output either in SAFE or UNSAFE mode [48]. In current situation, AVISPA tool supports 4 (four) different types of the following back-ends [45, 46] that are (i) On-the-fly Model-Checker (OFMC) (ii) Constraint Logic based attack searcher (CL-At Se) (iii) State of the Art based Model checker (SATMC) (iv) Tree Automata based protocol for the security protocol analysis (TA4SP).

Fig. 2
figure 2

Working structure of AVISPA using HLPSL

Full size image

5.2 Brief Role Wise Specification of ECC-CoAP in AVISPA Simulation Tool

In this section, all the roles are developed in HLPSL language using AVISPA simulator to measure the scheme ECC-CoAP is secure or not. Both in Fig. 3, role U for user/IoT device and Fig. 4, role S for server are implemented in HLPSL. In Fig. 5, various roles regarding the session, goal and the environment in HLPSL language are presented. The current version (2006/02/2013) of HLPSL holds the standard authentication and secrecy goals. In ECC-COAP, the following five authentication procedures and nine secrecy goals are verified and shown in Table 5.

Fig. 3
figure 3

Role specification for the user U in HLPSL

Full size image
Fig. 4
figure 4

Role specification for the server S in HLPSL

Full size image
Fig. 5
figure 5

Role specification for the session and the environment in HLPSL

Full size image

5.3 Simulation Result

In this section, the simulation results of ECC-CoAP for both the back-ends OFMC and CL-AtSe using AVISPA tool are showed in Figs. 6 and 7 respectively. From both the figures it is ensured that our proposed scheme is SAFE in two backend OFMC and CL-AtSe. Hence, ECC-CoAP is secured against all known active and passive attacks and achieves security goals (Table 6).

Fig. 6
figure 6

Screen shot of AVISPA Simulation for the result of OFMC back end

Full size image
Fig. 7
figure 7

Screen shot of AVISPA Simulation for the result of Cl–At Se back end

Full size image
Table 6 Security goals of AVISPA
Full size table

6 Performance Analysis of the Proposed Scheme

In this section, the overall performance of ECC-CoAP is discussed based on some primitive metrics like computation overhead, communication overhead, storage overhead and number of message communication. The evaluation is performed over a platform having an Intel Pentium Dual CPU E2200 2.20 GHz processor, 2048 MB of RAM and Ubuntu 17.04.1 LTS 32 bit operating system [51, 52]. To analyze performance of our scheme we have compared the proposed scheme with the recently proposed Dey and Hossain scheme [27] discussed in literature review. The below subsections illustrates the performance analysis of our scheme in terms of aforementioned parameters separately.

6.1 Computation Overhead

In the proposed scheme, ECC is incorporated for secure communication between low powered constraint IoT devices and remote server. The execution time for different cryptographic operations and computational overhead for the ECC-CoAP are discussed in Tables 7 and 8 respectively. Here, Th is the time for cryptographic hash operation, TE/D(S) is the time for encryption/decryption with symmetric key, TECPM is the time required for elliptic curve point multiplication, TECPA is the time required for elliptic curve point addition and TEMod is the time required for modular exponential operation. The computational overhead of our scheme is calculated in terms of execution time using Table 7 as 28.779 ms which is considerably less than Dey and Hossain scheme [27] due to the use of less expensive cryptographic operations.

Table 7 Execution time in milliseconds (ms) for different cryptographic operation [52]
Full size table
Table 8 Comparison of computational overheads
Full size table

6.2 Communication Overhead

The communication overhead between participating devices depends on the number of messages communicated as well as total number of bits transmitted during conversation as the network congestion also depends on the number of messages exchanged between two devices. The total number of messages communicated during the conversation in our protocol is 4 messages whereas for the LESS protocol by Bhattchariya et al. [17] and Dey and Hossain schemes [27] require 4 messages and 5 messages respectively. Thus, our protocol is efficient in terms of communication overhead than the schemes. In ECC-CoAP, identity of the communicating parties (IDU, IDS)is taken 64 bits long, time stamps(T1, T2, T3,T4)are taken as 32 bits long, random values generated (RU) is taken as 128 bits and encryption done by symmetric keys (K,SK) are taken as 160 bits long [50,51,52,53]. After calculation the message total number of transmitted bits is 1024 bits which is less than Dey and Hossain scheme [27]. The communication overheads are shown in Table 9.

Table 9 Comparison of communication overheads
Full size table

6.3 Security Strength

As stated in Sects. 4.1 and 4.2, ECC-CoAP is well protected against several relevant attacks. However, comparative security strength of the proposed scheme with other related schemes [17, 27, 54] is depicted in Table 10. It is found that ECC-CoAP is very much secured than other related schemes.

Table 10 Comparison of security strength
Full size table

7 Conclusion

A flexible ECC based CoAP for communication between the user/IoT device and server for setting up secure session among constraints IoT devices is proposed. The proposed scheme will be used to solve the key management and related security issues of resource constraint IoT devices as well as securely operated in insecure channel. The proposed scheme is mathematically analyzed to show its strong resilience against relevant cryptographic attacks. Moreover, ECC-CoAP is formally verified using well accepted AVISPA simulator and BAN logic and found well secure. Finally, the performance study demonstrates that our scheme is more effective in terms of communication and computation overheads for resource constrained IoT devices. Thus ECC-CoAP becomes cost-effective solution for highly demanded client side IoT based CoAP applications.