1 Introduction

The recent years witnessed the widespread use of Internet of Things (IoT) paradigm in many applications such as smart home, smart healthcare, smart grid, smart transport, smart logistics, supply chain in industries, and so on. A study reveals the number of IoT devices worldwide would be more than 75 billion by the year 2025 [1]. Meanwhile, various security attacks are reported in the IoT devices of different applications [2, 3]. Thus, security in the field of IoT is an indispensable and crucial requirement. Authentication and access control are the two main security requirements to ensure authorized and restricted accesses to limited and pivotal resources in IoT. In an attempt to partially fulfill these requirements, some IoT device manufacturers made IoT device products with built-in authentication mechanism. However, several security vulnerabilities are disclosed in the firmware implementation of authentication in IoT such as weak, guessable, or hardcoded passwords leading to unauthorized access, insecure ecosystem interfaces resulting to lack of authentication/authorization or weak encryption (broken authentication), lack of firmware validation on device, insecure network services, insecure default settings that may allow the operators to modify the configurations, and so on [4]. Hence, the built-in authentication mechanism in IoT devices is not reliable. On the other hand, the current authentication approaches for IoT [2, 3, 5,6,7,8,9,10] which are not firmware, are also vulnerable to certain security attacks among the prevalent ones namely Man-in-the-Middle (MITM), replay, traceability, session-key computation, secret disclosure, impersonation, gateway bypass, Denial-of-Service (DoS), and dictionary attacks in IoT. Moreover, some present access control approaches for IoT [11, 12] show limitations in terms of context-awareness, scalability, interoperability, and security. Therefore, there is a need for a robust authentication and access control system to safeguard the fast growing number of IoT devices.

In this paper, we propose a secure, unified authentication and access control system based on capability for IoT, called SUACC-IoT. The system is based on the concept of capability token which holds the access rights granted to the entity holding it. In the proposed system, the capability token is generated in the authentication stage. The generated token is used in mutual authentication and access control to ensure authorized and restricted access to limited resources in IoT. The system uses only lightweight Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) performed using a highly performance optimized and fast elliptic curve, symmetric encryption/decryption, message authentication code and cryptographic hash primitives.

The proposed SUACC-IoT can be applied in a cloud-enabled IoT healthcare system, where the health-related information collected from smart IoT devices (wearable devices) is typically outsourced to the cloud in order to facilitate the timely sharing of health information with the healthcare service providers as well as the medical practitioners [13, 14]. The data security and privacy are very important in such environment as the health-related information is confidential and private. In addition, there are the challenges for handling the expensive computational time and energy consumption for the resource-limited IoT wearable devices that are deployed in the patient and doctor side in a smart healthcare system [15]. To handle these issues, we have applied the capability tokens that can be used in mutual authentication and access control in order to ensure authorized and restricted access to the limited resources in IoT-enabled healthcare system.

1.1 Research contributions

Various security vulnerabilities are reported in the built-in authentication mechanism in IoT devices such as weak, guessable, or hardcoded passwords, insecure ecosystem interfaces, lack of firmware validation on device, insecure network services, insecure default settings, and so forth [4]. Hence, the built-in mechanism is not reliable. For instance, recent IoT smart devices, such as fitness tracker and smartwatch often rely on the “Bluetooth Low Energy (BLE)” for transmission of the data. Wang et al. [16] designed the BlueDoor method that can obtain illegal information from the IoT smart devices via the BLE vulnerability. Michalevsky et al. [17] suggested some applications for the purpose of cryptographic secret handshakes among the mobile devices on the top of “Bluetooth Low-Energy (LE)”. The present authentication approaches for IoT [2, 3, 5,6,7,8,9,10] that are not firmware are vulnerable to some security attacks among the prevalent ones viz., MITM, replay, traceability, session-key computation, secret disclosure, impersonation, gateway bypass, DoS, and dictionary in IoT. Some recent access control approaches for IoT [11, 12] show limitations in terms of context-awareness, scalability, interoperability, and security.

The following are the major contributions in this research work:

  • We propose a secure unified authentication and access control system based on capability for IoT, called SUACC-IoT to address the limitations in the current authentication and access control approaches.

  • We assess the security strength of the proposed protocol to computationally bounded probabilistic polynomial-time (PPT) adversaries using the universal Real-Or-Random (ROR) model [18].

  • We carry out the security analysis of the proposed protocol for various attack vectors predominant in IoT namely MITM, replay, traceability, session key computation, secret disclosure, device impersonation, gateway impersonation, gateway bypass, offline dictionary, and DoS using the widely accepted Scyther automated software validation tool [19] and by intuitive reasoning.

  • We also evaluate the proposed protocol for key performance parameters namely CPU usage, memory usage, computational overhead and communication cost in our IoT testbed involving Raspberry Pi.

1.2 Structure of the paper

The remainder of the paper is structured as follows: The closely related authentication and access control schemes are discussed in Sect. 2. The network model of the proposed protocol is presented in Sect. 3. The proposed system, SUACC-IoT, is discussed in detail in Sect. 4. The security strength of the proposed system to PPT adversaries and multiple attack vectors in IoT is demonstrated in Sect. 5. The performance/features of the proposed system are compared with the closely related existing schemes in Sect. 6. Section 7 concludes the paper.

2 Related work

In this section, the authentication and access control schemes that are closely related to our work are discussed.

A “user authentication scheme for multi-gateway Wireless Sensor Network (WSN)” was presented by Srinivas et al. [5]. Their scheme offers mutual authentication and key agreement. It is secure against MITM, replay, session key computation, traceability, device impersonation, gateway node impersonation, offline dictionary, and DoS attacks. It also supports anonymity. However, it is vulnerable to secret disclosure, and gateway bypass attacks. Also, it requires offline device registration with a system administrator which introduces some security threats.

Aman et al. [6] designed a “mutual authentication protocol for IoT using Physical Unclonable Functions (PUF)”. It enables secret key establishment among the IoT devices. Their scheme is resistant to eavesdropping, replay, MITM, tampering, secret disclosure, and cloning attacks. However, it does not analyze anonymity, traceability, session key computation, gateway impersonation and bypass, offline dictionary, and DoS attacks.

Alotaibi [7] devised an “anonymous user authentication scheme for WSN”. The scheme provides key agreement along with mutual authentication. It supports security features like user anonymity and resistance to replay, MITM, session key computation, user impersonation, gateway impersonation, DoS attacks. But, traceability, secret disclosure, gateway bypass, and offline dictionary attacks are not examined. Also, the scheme requires an additional hardware since biometric is used in user authentication.

Gope et al. [8] introduced a “privacy-preserving two-factor authentication scheme” for IoT devices. The scheme considers PUFs as one of the authentication factors. The scheme provides security features such as support for anonymity and resilience to replay, tampering, traceability, secret disclosure, cloning, impersonation attacks. But, MITM, session key computation, gateway impersonation and bypass, offline dictionary and DoS attacks are not investigated in the work.

A “lightweight and secure authentication scheme for IoT” was presented by Adeel et al. [9]. Their scheme provides mutual authentication and session key agreement. It is resistant to replay, MITM, session key computation, forgery, impersonation, and DoS attacks. However, it is vulnerable to traceability, secret disclosure, gateway impersonation and bypass, and offline dictionary attacks. Also, offline device registration with an authentication server is required in the scheme which poses security threats.

Aghili et al. [2] designed a “lightweight authentication, access control and access permissions transfer scheme for the e-health systems in IoT”. It supports anonymity and exhibits resilience to MITM, replay, traceability, session key computation, impersonation, offline dictionary, and DoS attacks. But, it is not secure against secret disclosure, and gateway impersonation and bypass attacks. Their scheme’s access permission transfer phase lacks scalability feature.

Feng et al. [20] pointed out that the serial computing mode is the primary concern for “slow decryption speed of the outsourced decryption” as well as the “parallel computing mode of outsourced decryption”. To mitigate these issues, they designed an attribute-based encryption (ABE) model that relies on the parallel outsourced decryption for edge intelligent Internet of Vehicles (IoV) paradigm. Their scheme is suitable for all the ABE schemes with the tree access structures. Yin et al. [21] proposed a method for hybrid privacy preservation which is based on both the “functional encryption” and “Bayesian differential privacy” techniques. For the federated learning, they suggested a new function that can ensure that the server cannot extract the gradient parameters of each user’s local training model as well as the weights of users’ datasets. Moreover, they applied a local quantification mechanism for privacy loss in Bayesian differential privacy, that can permit the users to adapt the privacy budget based on the “data distribution of the datasets”.

Bao et al. [22] suggested an intrusion-resilient server-aided attribute-based signature (ABS) scheme for an industrial IoT environment. In their approach, an adversary cannot forge a legitimate signature of the previous and future time period even if both the helper device and the server are compromised by the adversary.

Mohajer et al. [23] suggested a reputation based routing protocol that is based on CDS Connected Dominating Set (CDS) for mobile ad-hoc networks (MANETs). They also suggested a weight heuristic that can be applied to each node in MANET in order to choose CDS based on the use of the reputation value. It helps in achieving the selective forwarders’ detection.

Kumar et al. [24] designed an energy efficient smart building architecture using the IoT technology. In their approach, the “Datagram Transport Layer Protection (DTLS)” and “Secure Hash Algorithm (SHA-256)” are integrated along with the optimizations from the “Certificate Authority (CA)” for improving security of their proposed architecture.

A “user authenticated key establishment protocol for smart home environment” was introduced by Wazid et al. [3]. Their scheme offers both mutual authentication and key agreement. The scheme provides support for anonymity and security against MITM, replay, traceability, session key computation, user and device impersonation, gateway impersonation, gateway bypass, and offline dictionary attacks. But, it does not investigate secret disclosure and DoS attacks. The scheme assumes the gateway node is fully trusted and compromise of this node would compromise everything. Moreover, the scheme requires the devices to do offline registration with a registration authority which invites further security threats. Kim et al. [10] also designed an “authentication scheme based on lightweight signcryption protocol for IoT environment”. It is resistant to MITM, replay, session key computation, and impersonation attacks. However, traceability, anonymity, secret disclosure, gateway, offline dictionary, and DoS attacks are not studied in the scheme.

Kurniawan and Kyas [25] proposed a trust-based access control mechanism that is based Bayesian decision theory for a large scale IoT environment. Their mechanism is applied for access control on uncertainty environment where the identities are not known in priori. Imani and Ghoreishi [26] suggested a framework that relies on the combination of the graphical model, the “Bayesian optimization”, and the “mean objective cost of uncertainty (MOCU)”. Their proposed framework satisfies scalability, fast decision making as well as efficiency.

Xu et al. [11] proposed a “capability-based access control framework for federated IoT environment”. The framework considers two IoT domains. The framework is lightweight, context-aware, and fine grained. However, it is not scalable because there is only one coordinator who creates the capability token for all the devices in a particular IoT domain. Besides, interoperability and security are not examined in the framework. A attribute-based access control scheme using blockchain for IoT was presented by Yang et al. [12]. The scheme is context-aware, fine-grained, scalable, and secure. However, interoperability between the different parties in the system model is not examined.

Bao et al. [15] devised a “secure and lightweight fine-grained searchable data sharing for IoT-oriented and cloud-assisted smart healthcare system”. The scheme realizes fine-grained access control and ciphertext search concurrently. It significantly reduces the computational time of IoT devices in the data user and patient side. The scheme’s security is formally analyzed. Other authentication schemes in IoT-related environments have been also suggested in [27, 28].

The above discussion demonstrates that many authentication approaches in the literature are vulnerable to some security attacks among the prevalent ones namely MITM, replay, traceability, session-key computation, secret disclosure, impersonation, gateway bypass, DoS, and dictionary in IoT. The recent access control approaches have limitations in context-awareness, scalability, interoperability, and security. Thus, there is a need for a robust authentication and access control system that safeguards rapidly growing number of IoT devices. This has motivated us to design a secure unified authentication and access control system that fulfills the aforesaid criteria in this research work.

3 Network model

The proposed system’s network model is depicted in Fig. 1. It presents an IoT environment where a device such as clinical smartphone would want to access a resource, for instance the file containing the readings of patient’s biological parameter, in a healthcare device say glucometer or heart rate monitor or blood pressure monitor or spirometer or others to present the patient’s health status to the physician for necessary action. The communication between the clinical smartphone and healthcare device happens via the gateway node. The gateway node acts as the protocol bridge to ensure protocol compatibility across the devices. Thus, the gateway node takes the responsibility of ensuring device interoperability.

As the major step to achieve the necessary security level, the two devices (clinical smartphone and healthcare device) and gateway node undergo mutual authentication. Two types of mutual authentication take place: 1) between the device and gateway node and 2) between the devices. The device (clinical smartphone) requests access to the resource in the healthcare device. The healthcare device then grants or denies access based on the access control rule.

Fig. 1
figure 1

Network model

Table 1 Table of notations and their descriptions
Fig. 2
figure 2

Summary of authentication phase 1

4 Proposed SUACC-IoT system

In this section, the proposed authentication and access control system based on capability for IoT environment, SUACC-IoT, is presented. The system is based on the concept of capability token which holds the access rights granted to the entity holding it. In the proposed system, the capability token is generated in the authentication stage. The generated token is used in mutual authentication and access control to ensure authorized and restricted access to limited resources in IoT. The system uses only ECDHE performed using a highly performance optimized and fast elliptic curve, symmetric encryption/decryption, message authentication code and cryptographic hash primitives. The proposed protocol is split into three stages: (1) setup, (2) authentication, and (3) access control. Table 1 provides the description for the notations used in the protocol.

4.1 Setup phase

In this stage, the device D1 and gateway node GWN agree upon a secret key \(dk_1\) using lightweight ECDHE which they use in the authentication stage. Similarly, the device D2 and GWN agree upon a secret key \(dk_2\). In the proposed system, GWN stores several secrets and sensitive information. Hence, GWN is equipped with tamper-proof device so that all the sensitive information stored in its secure databased is protected from the adversary.

  • Step 1. The participating entities D1, GWN, and D2 generate their EllipticCurveCryptography (ECC) private and public keys \(\{pr\_k_{D1},pu\_k_{D1}\}\), \(\{pr\_k_{GWN},pu\_k_{GWN}\}\), and \(\{pr\_k_{D2},pu\_k_{D2}\}\) using a highly performance optimized, fast, and safe elliptic curve. These keys are ephemeral keys generated freshly in every key exchange. D1 and GWN exchange their public keys \(pu\_k_{D1}\) and \(pu\_k_{GWN}\). In the same way, GWN and D2 exchange their public keys \(pu\_k_{GWN}\) and \(pu\_k_{D2}\). This is the only instance in the proposed protocol, where the messages are exchanged through secure channels (established using the Transport Layer Security (TLS) protocol) to prevent possible MITM attacks. This is acceptable because the setup phase is only one-time process. However, the remaining messages in the proposed protocol are exchanged via open channels. In this manner, the proposed protocol makes very limited use of TLS.

  • Step 2. D1 and GWN individually compute the shared secret key, \(s_1\), as in \(s_1=pr\_k_{D1} \times pu\_k_{GWN}\) and \(s_1=pr\_k_{GWN} \times pu\_k_{D1}\). In a similar manner, GWN and D2 independently compute the shared secret key, \(s_2\), using \(s_2=pr\_k_{GWN} \times pu\_k_{D2}\) and \(s_2=pr\_k_{D2} \times pu\_k_{GWN}\).

  • Step 3. Subsequently, D1 and GWN independently derive another key, \(dk_1\), from \(s_1\) via \(dk_1=h(s_1,pu\_k_{D1},pu\_k_{GWN})\). GWN and D2 individually derive key, \(dk_2\), from \(s_2\) through \(dk_2=h(s_2,pu\_k_{GWN},pu\_k_{D2})\). The keys \(dk_1\) and \(dk_2\) are used in the authentication process of D1, GWN, and D2.

Fig. 3
figure 3

Summary of authentication phase 2 (mutual authentication)

Fig. 4
figure 4

Summary of access control phase

4.2 Authentication phase

In this stage, D1 and GWN, D2 and GWN, and eventually D1 and D2 are mutually authenticated. Besides, D1 and D2 establish a session key \('sk'\) at the end of authentication as outlined in Figs. 2 and 3. Consider D1 requests access to resource \('r'\) in D2.

  • Step 1. D1 generates its universally unique identifier \(uid_{D1}\) and a random, one-time nonce \(\eta _1\). Universally unique identifiers are used to identify the IoT devices, large in number, because they are unique, random and collision-resistant. D1 computes the messages \(M1=E(uid_{D1} \Vert r,dk_1)\) and \(M2=MAC(dk_1,M1 \Vert \eta _1)\). D1, then, sends \(M1,M2,\eta _1\) to GWN.

  • Step 2. GWN computes the message \(M3=MAC(dk_1,M1 \Vert \eta _1)\) and checks if \(M3==M2\). This verification ensures that \(M1,M2,\eta _1\) is not replayed and the sender, D1, is a legitimate holder of the key \(dk_1\). If the verification is successful, D1 is authenticated to GWN. GWN generates its identifier \(id_{GWN}\) and \(\eta _2\). Next, GWN computes the messages \(M4=D(M1,dk_1), M5=E(M4,dk_2),\) and \(M6=MAC(dk_2,M5 \Vert \eta _2)\) and sends \(M5,M6,\eta _2\) to D2.

  • Step 3. D2 computes the message \(M7=MAC(dk_2,M5 \Vert \eta _2)\) and checks if \(M7==M6\). If the verification is successful, GWN is authenticated to D2.

  • Step 4. D2 computes the message \(M8=D(M5,dk_2)\). Consequently, D2 obtains \(id_{GWN}, uid_{D1},\) and \('r'\). D2 decides the context \('ctxt'\) and access rights AR for \(uid_{D1}\)’s access to its resource \('r'\). \(ctxt \in \{null,\{ctxt1,ctxt2\}\}\) where \('ctxt1'\) and \('ctxt2'\) are context-awareness information like time, location and \(AR \in \{null,read,write,\{read,write\}\}\). Then, D2 computes the capability token of D1 as in \(Cap_{D1}=h(uid_{D1},r,ctxt,AR,Rnd)\).

  • Step 5. D2 generates its universally unique identifier \(uid_{D2}\) and \(\eta _3\). Thereafter, it computes the messages \(M9=E(uid_{D2,dk_2})\) and \(M10=MAC(dk_2,M9 \Vert Cap_{D1} \Vert \eta _3)\). D2 sends \(M9,M10,Cap_{D1},\eta _3\) to GWN.

  • Step 6. GWN computes the message \(M11=MAC(dk_2,M9 \Vert Cap_{D1} \Vert \eta _3)\) and verifies if \(M11==M10\). If the verification is successful, D2 is authenticated to GWN. GWN generates \(\eta _4\) and computes the messages \(M12=D(M9,dk_2), M13=E(id_{GWN} \Vert M12,dk_1),\) and \(M14=MAC(dk_1,M13 \Vert Cap_{D1} \Vert \eta _4)\). It sends \(M13,M14,Cap_{D1},\eta _4\) to D1.

  • Step 7. D1 computes the message \(M15=MAC(dk_1,M13 \Vert Cap_{D1} \Vert \eta _4)\) and checks if \(M15==M14\). If this verification succeeds, GWN is authenticated to D1. Thus, the mutual authentication of D1 and GWN, D2 and GWN and D1 and D2 is achieved. D1 computes \(M16=D(M13,dk_1)\) to get \(id_{GWN},uid_{D2}\). Lastly, D1 and D2 independently compute the session key sk using \(sk=h(uid_{D1},M16)\) and \(sk=h(uid_{D2},M8)\) respectively. The session key so established is used for secure communication in the access control process.

4.3 Access control phase

The capability token \(Cap_{D1}\) generated in the authentication process is used to control the access of D1 to resource \('r'\) of D2 at this instance. Figure 4 presents the steps in the access control process. The sequence charts in this section are drawn using the msc package [29].

  • Step 1. D1 sends GWN, the generated \(\eta _5\), randomly chosen message \('msg'\) and computed message \(M17=MAC(sk,msg \Vert \eta _5)\) along with \(Cap_{D1},r_A\) to prevent possible replay attack in this communication.

  • Step 2. GWN computes the message \(M18=MAC(sk,msg \Vert \eta _5)\) and checks if \(M18==M17\). If this verification succeeds, GWN generates \(\eta _6\), randomly chooses \('msg'\) and computes the message \(M19=MAC(sk,msg \Vert \eta _6)\). It then sends \(Cap_{D1},r_A,M19,msg,\eta _6\) to D2.

  • Step 3. D2 computes the message \(M20=MAC(sk,msg \Vert \eta _6)\) and \(Cap_{D1}=h(uid_{D1},r,ctxt,AR,Rnd)\). It checks if \(M20==M19\) and and computed \(Cap_{D1}==\) received \(Cap_{D1}\). If the verification is successful, D2 checks if the current context \(==ctxt\) and and the access requested \(r_A \in AR\). If this verification also succeeds, the requested access to \('r'\) is granted to D1.

5 Security analysis

In this section, we rigorously analyze the SUACC-IoT system in terms of its security. We perform the formal security analysis using the widely-recognized Real-Or-Random (ROR) random oracle model [18] and the formal security verification using the broadly-accepted automated software validation tool, known as the Scyther tool [19]. We also carry out security analysis by intuitive reasoning through the non-mathematical (heuristic) approaches. Wang et al. [30] in their seminal work stated that the widely-used formal security methods, such as the “random oracle model” and “Burrows–Abadi–Needham (BAN) logic” [31] can not always capture some structural mistakes in the analyzed authentication protocols, and thus, ensuring the soundness of authentication protocols still remains an open problem. Due to this, we need to analyze the proposed protocol using all the possible security methods (formal analysis, formal security verification and informal analysis) to show that it is robust against various potential attacks with high probability.

5.1 Formal security analysis using ROR model

The security strength of the proposed protocol to computationally bounded PPT adversaries is evaluated in this section using the universal ROR model.

5.1.1 ROR model

In the proposed protocol, there are three participants namely D1, GWN, and D2.

  • Instances: Let \(\varPi ^{w_{1}}_{D1}\), \(\varPi ^{w_{2}}_{GWN}\), and \(\varPi ^{w_{3}}_{D2}\) be the instances of D1, GWN, and D2 respectively. \(w_{1}\), \(w_{2}\), and \(w_{3}\) are called oracles.

  • Accepted state: An instance \(\varPi ^{w}\) is known to be accepted, if it goes into an accepted state on receiving the last protocol message. All the messages sent and received by \(\varPi ^{w}\), concatenated in order, is the session-identification (s-id) of \(\varPi ^{w}\) for the ongoing session.

  • Partnering: Two instances \(\varPi ^{w_{1}}\) and \(\varPi ^{w_{2}}\) are said to be partnered, if they meet the following three conditions simultaneously: (i) \(\varPi ^{w_{1}}\) and \(\varPi ^{w_{2}}\) are in accepted state, (ii) \(\varPi ^{w_{1}}\) and \(\varPi ^{w_{2}}\) undergo mutual authentication and share an identical s-id, and (iii) \(\varPi ^{w_{1}}\) and \(\varPi ^{w_{2}}\) are mutual partners.

  • Instance freshness: The instance \(\varPi ^{w_{1}}_{D1}\) or \(\varPi ^{w_{3}}_{D2}\) is considered fresh, if the session key between D1 and D2 is not revealed to \(\mathcal {A}\) via \(Reveal(\varPi ^{w})\) query.

  • Adversary: The adversary \(\mathcal {A}\) is a PPT Turing machine which has the ability to read, modify, intercept, delay, delete the protocol messages, fabricate new messages and inject them into the network. In addition, it can ask an instance to reveal the session key. These abilities of \(\mathcal {A}\) are modeled using a predetermined set of oracles. These oracles are accessible to \(\mathcal {A}\) and all the participants. They are:

    • Enc: This oracle represents the symmetric key encryption \(E(\cdot )\) of the proposed protocol.

    • Gen: This oracle corresponds to the code generation part of message authentication code \(MAC(\cdot )\) of the proposed protocol.

    • Ver: This oracle represents the code verification part of message authentication code \(MAC(\cdot )\) of the proposed protocol.

    • h: This oracle corresponds to the cryptographic hash function \(h(\cdot )\) of the proposed protocol.

    In addition, \(\mathcal {A}\) has access to the following queries:

    • \(Execute(\varPi ^{w_{1}}_{D1}, \varPi ^{w_{2}}_{GWN} and \varPi ^{w_{3}}_{D2})\): This query represents a passive eavesdropping attack on the protocol messages. \(\mathcal {A}\) runs this query to acquire the messages exchanged between D1, GWN and D2.

    • \(Send(\varPi ^{w}_{E}, message)\): The Send query models active attacks on the protocol. It sends message to an instance \(\varPi ^{w}_{E}\). On receiving message, \(\varPi ^{w}_{E}\) advances as per the specifications of the protocol. Any message generated by \(\varPi ^{w}_{E}\) is regarded as the output and given to \(\mathcal {A}\).

    • \(Reveal(\varPi ^{w}_{E})\): An instance \(\varPi ^{w}_{E}\), on receiving this query, reveals the session key that it has established with its partner to \(\mathcal {A}\).

    • \(TestAKE(\varPi ^{w}_{E})\): This query represents the indistinguishability-based semantic security of the session key \('sk'\) between \(\varPi ^{w}_{E}\) (D1) and its partner (D2). The TestAKE oracle chooses value for the random bit \(b_{r}\). If \(b_{r}=1\), the actual session key is returned as response to the query, Otherwise, a random key chosen from the session key sample space is returned.

5.1.2 Cryptographic preliminaries

The following cryptographic preliminaries are used in the security proof in the subsequent section.

  1. (1)

    Elliptic Curve Computational Diffie Hellman Problem (ECCDHP): Consider G be an elliptic curve of prime order \('q'\) and Q be a base point on the elliptic curve G. Let \('u'\) and \('v'\) be the private keys of the two communicating parties chosen randomly from \(Z^{{*}}_{{q}}\), where \(Z^{{*}}_{{q}}\) is the set of integers over \('q'\). The ECCDHP for G, when given two elements \((uQ, vQ) \in G^{2}\), is to compute the shared secret key viz., \(uvQ \in G\). The advantage of adversary \(\mathcal {A}\) to find the solution to the ECCDHP for G is given by \(Adv^{{ECCDHP}}_{{G}} (\mathcal {A}) = P[\mathcal {A}(G, Q, uQ, vQ) = uvQ]\). The ECCDHP assumption holds in G if for all the PPT adversaries, \(Adv^{{ECCDHP}}_{{G}} (\mathcal {A})\) is negligible.

  2. (2)

    Hash collision (HASH): Consider \(h: \{0,1\}^{*} \rightarrow \{0,1\}^{l}\) be a one-way cryptographic hash function which inputs a string of random length, say, \(x \in \{0,1\}^{*}\) and outputs a fixed length \(l-bit\) hash, say, \(h(x) \in \{0,1\}^{l}\). Let \('x1'\) and \('x2'\) be strings of random length randomly chosen. The advantage of \(\mathcal {A}\) in finding HASH for \(h(\cdot )\) is given by \(Adv^{{HASH}}_{{h(\cdot )}} (\mathcal {A}) = P[(x1, x2) \leftarrow \mathcal {A}: x1 \ne x2\) and \(h(x1)=h(x2)]\). \(h(\cdot )\) is collision-resistant if for all the PPT adversaries, \(Adv^{{HASH}}_{{h(\cdot )}} (\mathcal {A})\) is negligible.

  3. (3)

    Indistinguishability of encryption under Chosen Plaintext Attack (\(IND-CPA\)): Let \(\varOmega \) denote a symmetric key encryption scheme. Let the encryption key be \(ek_{1}\). Let \('p_i'\) denote a plaintext input and \(\phi \) indicate the choice of choosing 0 or 1 for \('i'\). The advantage of \(\mathcal {A}\) in carrying out \(IND-CPA\), as a single eavesdropper, is given by \(Adv^{{IND-CPA}}_{\varOmega } (\mathcal {A}) = |2.P[\mathcal {A} \leftarrow {Enc_{ek_{1}}}; ({p_{0}}, {p_{1}}) \leftarrow \mathcal {A}; \phi \leftarrow {\{0,1\}}; \beta \leftarrow {Enc_{ek_{1}}}(p_{\phi }): \mathcal {A}(\beta ) = \phi ]-1 |\). The scheme \(\varOmega \) is \(IND-CPA\) secure if for all the PPT adversaries, \(Adv^{{IND-CPA}}_{\varOmega } (\mathcal {A})\) is negligible.

  4. (4)

    Existential Unforgeability under Chosen Plaintext Attack (\(EU-CPA\)): Let \(\varDelta \) denote a MessageAuthenticationCode (MAC) scheme. \(\varDelta \) involves the message authentication code generation and verification processes. Gen oracle inputs a \(l-bit\) key \('k'\) and a message \('msg'\), and generates a code \(\delta \). Ver oracle inputs key \('k'\), message \('msg'\) and code \(\delta \), and verifies if \(\delta \) is the correct code for \('msg'\) under \('k'\). If yes, it outputs 1 else outputs 0. Let the advantage of \(\mathcal {A}\) in performing \(EU-CPA\) on \(\varDelta \) be \(Adv^{{EU-CPA}}_{\varDelta } (\mathcal {A})\). It is given by \(Adv^{{EU-CPA}}_{\varDelta } (\mathcal {A}) = P[(msg, \delta ) \leftarrow \mathcal {A}: {Ver_{k}}(msg, \delta ) =1\) and \(\delta \ne \{\delta _{1}, .., \delta _{n}\}]\), where \(\delta _{1}, .., \delta _{n}\) are the previously outputted \(\delta \)s by \(Gen_{k}\). The scheme \(\varDelta \) is \(EU-CPA\) secure if for all the PPT adversaries, \(Adv^{{EU-CPA}}_{\varDelta } (\mathcal {A})\) is negligible.

5.1.3 Security proof

In this section, we present the formal security proof for the proposed protocol. The main goal of such a proof is to prove that the proposed protocol is robust against the sesssion-key (SK) security against PPT adversaries. If \(\mathcal {A}\) be a PPT adversary running in polynomial-time \(t_p\) against the proposed protocol and the advantage (success probability) of \(\mathcal {A}\) in breaking the proposed protocol in time \(t_p\) is negligible, we call the proposed scheme offers the SK-security.

Theorem 1

Let \(\mathcal {A}\) be a PPT adversary running in polynomial-time \(t_p\) against the proposed protocol \(\psi \) in the random oracle. The advantage of \(\mathcal {A}\) in breaking the proposed authenticated key exchange (AKE) protocol, \(\psi \)’s security is \({Adv^{AKE}_{\psi }}(\mathcal {A}) \le 2.[{Adv^{ECCDHP}_{G}}(t_p) + q_{Send}.Adv^{HASH}_{h(\cdot )}(t_p) + {q_{Send}}.{Adv^{EU-CPA}_{\varDelta }}(t_p) + Adv^{IND-CPA}_{\varOmega }(t_p)],\) where \(Adv^{{ECCDHP}}_{{G}}(t_{p})\), \(Adv^{HASH}_{h(\cdot )}(t_p)\), \(Adv^{{IND-CPA}}_{{\varOmega }}(t_{p})\), \(q_{Send}\), \(Adv^{{EU-CPA}}_{{\varDelta }}(t_{p})\) are the advantage of \(\mathcal {A}\) in solving ECCDHP for G, the advantage of \(\mathcal {A}\) in finding the hash collision in \(h(\cdot )\), the advantage of \(\mathcal {A}\) in breaking the \(IND-CPA\) security of \(\varOmega \), the number of Send queries, and the advantage of \(\mathcal {A}\) in violating the \(EU-CPA\) of \(\varDelta \), respectively.

Proof

In this proof, we consider a sequence of six games namely \(Game_{0}\) - \(Game_{5}\). \(Game_{0}\) is the basic game. The other games viz., \(Game_{1}\), \(Game_{2}\), \(Game_{3}\), \(Game_{4}\), and \(Game_{5}\) are built upon their preceding game(s). Let \(success_{i}\) be an event wherein \(\mathcal {A}\) succeeds in the game \(Game_{i}\) in choosing the random bit \(b_{r}\) correctly. The difference in the success probabilities between the previous and current games is studied every time.

  • \(Game_{0}\): \(\mathcal {A}\) may ask any oracle queries except the following: i) \(\mathcal {A}\) is not permitted to ask a \(TestAKE(\varPi ^{w}_{E})\) query if the instance \(\varPi ^{w}_{E}\) is no more fresh, and ii) \(\mathcal {A}\) is not permitted to ask a \(Reveal(\varPi ^{w}_{E})\) query if \(\varPi ^{w}_{E}\) or its partner has already been asked a \(TestAKE(\varPi ^{w}_{E})\) query. As a result, \(\mathcal {A}\) produces a random output as its guess for the random bit \(b_{r}\). \(\mathcal {A}\) succeeds if its random output\(==b_{r}\) chosen by the TestAKE oracle. At this point, \(\mathcal {A}\)’s advantage in breaking the AKE security of \(\psi \) is given by,

    $$\begin{aligned} {Adv^{AKE}_{\psi }}(\mathcal {A})=2.{P_{\psi , \mathcal {A}}}[success_{0}]-1 \end{aligned}$$
    (1)
  • \(Game_{1}\): The first modified game \(Game_{1}\) represents a passive eavesdropping attack wherein \(\mathcal {A}\) can run the \(Execute(\varPi ^{w_1}_{D1}, \varPi ^{w_2}_{GWN}, \varPi ^{w_3}_{D2})\) oracle query. \(\mathcal {A}\) gets all the messages exchanged between the three participants viz., \(M1,M2,\eta _1,M5,M6,\eta _2,M9,M10,Cap_{D1},\eta _3,M13,\) \(M14,Cap_{D1},\eta _4\). However, the session key \('sk'\) cannot be computed by \(\mathcal {A}\) because \(dk_1,dk_2\) are not known to \(\mathcal {A}\) and the identities \(uid_{D1}\), \(id_{GWN}\), and \(uid_{D2}\), therefore, cannot be extracted from the acquired messages. Thus, \(\mathcal {A}\)’s probability of succeeding in \(Game_{1}\) is not increased. This is given by,

    $$\begin{aligned} {P_{\psi , \mathcal {A}}}[success_{0}]={P_{\psi , \mathcal {A}}}[success_{1}] \end{aligned}$$
    (2)
  • \(Game_{2}\): In this game, the computations of \(pu\_k_{D1}\) and \(pu\_k_{GWN}\) are modified as given below:

    • The simulator picks a random point \(Y \in G\).

    • For every fresh instance, the simulator chooses the random secrets \(r_{1}, r_{2} \in Z^{{*}}_{{q}}\) and then it sets \(pu\_k_{D1}=r_{1}Y, pu\_k_{GWN}=r_{2}Y\). The simulator computes \(pu\_k_{D1}\) and \(pu\_k_{GWN}\) as in \(Game_{1}\) for the other instances.

    Due to the modification in the computations of \(pu\_k_{D1}\) and \(pu\_k_{GWN}\), the simulator is not aware of the ephemeral secrets \(pr\_k_{D1}\) and \(pr\_k_{GWN}\). Hence, it cannot compute the shared secret \(s_1\). Therefore, the simulator cannot compute the secret \(dk_1\). In the same manner, when the computations of \(pu\_k_{D2}\) and \(pu\_k_{GWN}\) are modified, the simulator cannot compute the secrets \(s_2\) and \(dk_2\). Due to this, it cannot obtain \(uid_{D1}, id_{GWN}, uid_{D2}\) and simply sets the session key \('sk'\) to a random \(l-bit\) string. The difference in the success probabilities of \(\mathcal {A}\) between \(Game_{1}\) and \(Game_{2}\) is upper bounded by the below equation.

    $$\begin{aligned}&|{P_{\psi , \mathcal {A}}}[success_{1}]-{P_{\psi , \mathcal {A}}}[success_{2}]| \nonumber \\&\le {Adv^{ECCDHP}_G} (t_p) \end{aligned}$$
    (3)
  • \(Game_{3}\): \(Game_{2}\) is modified into \(Game_{3}\) by adding the simulation of \('h'\) oracle and Send query. For a query to the \('h'\) oracle on a string \('x'\), the simulator first checks if an entry of the kind (xstr) is present in the LList. It is a list that stores the input-output pairs of \('h'\) oracle. If present, the simulator responds the query by producing the string \('str'\). If not present, the simulator responds the query by producing a random \(l-bit\) string \('str'\) and adds (xstr) to the LList. \(Game_{3}\) models an active attack. In this game, the objective of \(\mathcal {A}\) is to trick a participant in accepting a modified message. \(\mathcal {A}\) is permitted to use Send query and query \('h'\) oracle any number of times for this purpose. \(\mathcal {A}\) queries \('h'\) oracle to find the presence of hash collisions. The exchanged messages obtained by \(\mathcal {A}\) in \(Game_{1}\) as a result of Execute query include \(M1,M2,\eta _1,M5,M6,\eta _2,M9,M10,Cap_{D1},\eta _3,M13,\) \(M14,Cap_{D1},\eta _4\). In case of \(Cap_{D1}\), tricking the participant requires finding a hash collision which is very hard. Besides, \(Cap_{D1}\) is used in the messages M10, M14. Therefore, tricking the participant through these messages is computationally infeasible for \(\mathcal {A}\). Hence, the difference in the success probabilities between \(Game_{2}\) and \(Game_{3}\) follows the result of birthday paradox and is given by,

    $$\begin{aligned}&|{P_{\psi , \mathcal {A}}}[success_{2}]-{P_{\psi , \mathcal {A}}}[success_{3}]| \\&\le q_{Send}.\frac{q^2_h}{(2|h|)} \end{aligned}$$

    where \(q_{Send}, {q_h},\) and |h| are the number of Send queries, number of \('h'\) oracle queries and range space of \('h'\) respectively. Therefore,

    $$\begin{aligned}&|{P_{\psi , \mathcal {A}}}[success_{2}]-{P_{\psi , \mathcal {A}}}[success_{3}]| \nonumber \\&\le q_{Send}.{Adv^{HASH}_{h(\cdot )}} (t_p) \end{aligned}$$
    (4)
  • \(Game_{4}\): Let Forge be an event, wherein, \(\mathcal {A}\) forwards a query of the type \(Send(\varPi ^w_E, {E'}||message)\) such that message holds a MAC forgery. In this game, the objective of \(\mathcal {A}\) is to output a MAC pair \((msg, \delta )\) such that \(Ver_{k}(msg, \delta )=1\) and this \(\delta \) was not previously outputted by \(Gen_{k}(msg)\). The secrets \(dk_1,dk_2\) are used as MAC keys in \(\psi \). Let \(k_{n}\) denote the number of MAC keys used for the forgery attempt. It is very clear that \(k_{n} \le q_{Send}\). The oracles \(Gen_k,Ver_k\) are accessible to all the participants and \(\mathcal {A}\). \(\mathcal {A}\) begins the game by picking a random key \(k_{i}\) from the key space \(k_{n}\). It then accesses the \(Gen_{k_i}\) oracle to generate \(\delta \) for \('msg'\) and sends the MAC pair \((msg, \delta )\) to an instance. The process is repeated. If the event Forge occurs against an instance holding the key \(k_{i}\), \(\mathcal {A}\) declares the MAC pair as its forgery. The most crucial thing for \(\mathcal {A}\) to win this game is to guess the key correctly. However, guessing the key \(k_{i}\) such that \(k_{i}=dk_1\) or \(dk_2\) is very hard because the shared secrets \(s_1,s_2\) which are based on ECDHE are not known to \(\mathcal {A}\). As a result, the session key \('sk'\) cannot be computed. The difference in the success probabilities between \(Game_{3}\) and \(Game_{4}\) is given by,

    $$\begin{aligned}&{Adv^{EU-CPA}_{\varDelta }}(\mathcal {A})=\frac{P[Forge]}{k_n} \nonumber \\&P[Forge] \le q_{Send}.{Adv^{EU-CPA}_{\varDelta }}(\mathcal {A}) \nonumber \\&|{P_{\psi , \mathcal {A}}}[success_{3}]-{P_{\psi , \mathcal {A}}}[success_{4}]| \nonumber \\&\le {q_{Send}}.{Adv^{EU-CPA}_{\varDelta }}(t_p) \end{aligned}$$
    (5)
  • \(Game_{5}\): In this game, the objective of \(\mathcal {A}\) is to identify the correct plaintext in the plaintext pair for a given ciphertext. In this game, \(\mathcal {A}\) has access to all the oracles in \(Game_{4}\) in addition to the encryption oracle \('Enc'\). The indistinguishability game is explained below: For each device, \(\mathcal {A}\) produces the true identity uid and random identity uidr as its plaintext pair and forwards it to the challenger. The challenger randomly picks a plaintext from the plaintext pair and encrypts it using \('Enc'\) oracle. Then, the challenger sends the ciphertext to \(\mathcal {A}\). \(\mathcal {A}\) tries to identify the correct plaintext, uid or uidr, for the ciphertext. It could not succeed by mere guessing. In the proposed protocol, for the ciphertext messages namely M1, M5, M9, M13, \(\mathcal {A}\) has no choice other than guessing the correct plaintext due to the use of stateless symmetric cipher for encryption. As a result, it loses the indistinguishability game. \(\mathcal {A}\) would not know \(uid_{D1}, id_{GWN}, uid_{D2}\) and hence, cannot compute the session key \('sk'\). Therefore, it just guesses the random bit \(b_r\) chosen by the TestAKE oracle. The difference in the success probabilities between \(Game_{4}\) and the indistinguishability game \(Game_{5}\) is given by the following equation:

    $$\begin{aligned}&|{P_{\psi , \mathcal {A}}}[success_{4}]-{P_{\psi , \mathcal {A}}}[success_{5}]| \nonumber \\&\le {Adv^{IND-CPA}_{\varOmega }}(t_p) \end{aligned}$$
    (6)

All the six games are simulated. After querying the TestAKE oracle for the session key \('sk'\), \(\mathcal {A}\) has no choice other than guessing the random bit \(b_{r}\) to win the game. Hence,

$$\begin{aligned} P_{\psi , \mathcal {A}}[{success_{5}}]=\frac{1}{2} \end{aligned}$$
(7)

Equation (1) is adjusted to obtain the following equation.

$$\begin{aligned} \frac{1}{2}.Adv^{AKE}_{\psi }(\mathcal {A})=|{P_{\psi , \mathcal {A}}}[{success_{0}}]-\frac{1}{2}| \end{aligned}$$
(8)

According to the triangular inequality,

$$\begin{aligned}&|{P_{\psi , \mathcal {A}}}[{success_{1}}]- {P_{\psi , \mathcal {A}}}[{success_{5}}]|\\&\le |{P_{\psi , \mathcal {A}}}[{success_{1}}]- {P_{\psi , \mathcal {A}}}[{success_{2}}]| \\&+ |{P_{\psi , \mathcal {A}}}[{success_{2}}]- {P_{\psi , \mathcal {A}}}[{success_{3}}]| \\&+ |{P_{\psi , \mathcal {A}}}[{success_{3}}]- {P_{\psi , \mathcal {A}}}[{success_{4}}]| \\&+ |{P_{\psi , \mathcal {A}}}[{success_{4}}]- {P_{\psi , \mathcal {A}}}[{success_{5}}]| \end{aligned}$$

Using Eq. (3) through (6), we obtain

$$\begin{aligned}&|{P_{\psi , \mathcal {A}}}[{success_{1}}]- {P_{\psi , \mathcal {A}}}[{success_{5}}]| \nonumber \\&\le Adv^{ECCDHP}_{G}(t_p) + q_{Send}.Adv^{HASH}_{h(\cdot )}(t_p) \nonumber \\&+ {q_{Send}}.Adv^{EU-CPA}_{\varDelta }(t_p) + Adv^{IND-CPA}_{\varOmega }(t_p) \end{aligned}$$
(9)

Substituting Eqs. (2) and (7) in the L.H.S of Eq. (9), we have

$$\begin{aligned}&|{P_{\psi , \mathcal {A}}}[success_{0}]-\frac{1}{2}| \\&\le Adv^{ECCDHP}_{G}(t_p) + q_{Send}.Adv^{HASH}_{h(\cdot )}(t_p) \\&+ {q_{Send}}.Adv^{EU-CPA}_{\varDelta }(t_p) + Adv^{IND-CPA}_{\varOmega }(t_p) \end{aligned}$$

Using Eq. (8), we get the final equation as follows.

$$\begin{aligned}&{Adv^{AKE}_{\psi }}(\mathcal {A}) \le 2.[{Adv^{ECCDHP}_{G}}(t_p) +\nonumber \\&q_{Send}.Adv^{HASH}_{h(\cdot )}(t_p) + \nonumber \\&{q_{Send}}.{Adv^{EU-CPA}_{\varDelta }}(t_p) + \nonumber \\&Adv^{IND-CPA}_{\varOmega }(t_p)] \end{aligned}$$
(10)

From Eq. (10), it is evident that the advantage of \(\mathcal {A}\) in breaking the AKE security of \(\psi \) is negligible. Thus, the proposed protocol is secure against the PPT adversaries.

5.2 Formal security verification: simulation study using Scyther tool

In this section, the proposed protocol’s resilience to different attack vectors in IoT is assessed using the widely-accepted automated software validation tool, known as the Scyther tool. Through the simulation study using the Scyther tool, we show that the proposed scheme is safe against other types of attacks, such as passive secret disclosure, impersonation, traceability and session key computation attacks.

Scyther [19] is a security tool which can be used for verification, falsification, and analysis of security protocols. It uses a pattern refinement algorithm to produce infinite set of traces. The protocol to be verified is provided to the scyther tool in the form of protocol description written using the “Security Protocol Description Language (SPDL)”. The protocol description comprises a set of roles. Each role consists of a sequence of events. The events can be send or receive of terms (security parameters).

Fig. 5
figure 5

Role for IoT device D1 in SPDL

The entities D1, GWN and D2 are communicating with one another in the proposed protocol. They are modeled as roles D1, GWN and D2 as shown in Figs. 5, 6 and 7, respectively. A role begins with the declaration of the sending and receiving terms, then the exchange of such terms followed by the security claims. The security claims are used to model the protocol’s security properties. These claims are crucial part of the protocol description without which scyther would not know what is to be verified. Fig. 8 confirms that the roles D1, GWN,  and D2 are reachable. This ensures that there is no obvious weakness in the protocol description.

Our claims on role D1 include (i) key \(dk_1\) is secret, (ii) \(uid_{D2}\) is secret, (iii) \(id_{GWN}\) is secret, (iv) session key \('sk'\) is secret, (v) aliveness, and vi) weak agreement. Secondly, our claims on role GWN comprise i) \(dk_1\) is secret, ii) key \(dk_2\) is secret, iii) \(uid_{D1}\) is secret, iv) \(uid_{D2}\) is secret, V) \('sk'\) is secret, vi) aliveness, and vii) weak agreement. Thirdly, our claims on role D2 are i) \(dk_2\) is secret, ii) \(uid_{D1}\) is secret, iii) \(id_{GWN}\) is secret, iv) \('sk'\) is secret, v) aliveness, and vi) weak agreement.

Fig. 6
figure 6

Role for gateway node GWN in SPDL

Fig. 7
figure 7

Role for IoT device D2 in SPDL

Fig. 8
figure 8

Scyther results: verification of reachability of the roles for D1, GWN and D2

Fig. 9
figure 9

Scyther results: verification of claims

From the scyther verification results in Fig. 9, we have drawn useful insights which are summarized in Table 2. Firstly, the keys \(dk_1,dk_2\) derived from \(s_1,s_2\) are secret. As a result, the passive secret disclosure attack is prevented in the system. Secondly, the system is secure against impersonation attack because the identities \(uid_{D1},id_{GWN}\) and \(uid_{D2}\) are declared secret. Thirdly, the system is protected from traceability attack since no attacks are reported on \(uid_{D1}\), \(uid_{D2}\). In fact, these identities are freshly generated every time. Lastly, the system is resistant to session key computation attack since the identities required to compute \('sk'\) are secret.

Table 2 Inferences from Scyther results

5.3 Informal security analysis

In this section, we show that the proposed protocol is secure against various attack vectors in IoT environment by intuitive reasoning. It is worth noticing that we follow the informal (non-mathematical heuristic) security analysis to show the proposed protocol is secure against other attacks that are not covered so far in Sects. 5.1 and 5.2.

Proposition 1

SUACC-IoT prevents brute-force attack.

Proof

The private keys \(pr\_k_{D1}\) and \(pr\_k_{GWN}\) of D1 and GWN respectively are of at least \(k-1\) bits, where k is large. Now, even if \(\gcd (pr\_k_{D1}, pr\_k_{GWN}) = pr\_k_{D1}\), \(pu\_k_{GWN}\) cannot be expressed in term of \(pu\_k_{D1}\) by brute-forcing approach, where \(\gcd (x,y)\) represents the greatest common divisor of two numbers x and y. In the same manner, considering D2 and GWN, \(pu\_k_{GWN}\) cannot be also expressed in term of \(pu\_k_{D2}\) with \(\gcd (pr\_k_{D2}, pr\_k_{GWN}) = pr\_k_{D2}\). Thus, the brute-force attacks based on the key sizes are prevented in the proposed protocol.

Proposition 2

SUACC-IoT is resilient to man-in-the-middle (MITM) and replay attacks.

Proof

Suppose an adversary \(\mathcal {A}\) intercepts the exchanges messages during the communication among the various entities in the network and tries to modify the messages on the fly so that the recipients will not be aware of the modified messages and the adversary \(\mathcal {A}\) will force the recipients to believe that the messages are genuine. In order to do so, in the authentication stage, if \(\mathcal {A}\) carries out an active MITM attack like “intercept and modify” on the exchanged parameters exchanged, such as M1,  \(\eta _1,\) M5,  \(\eta _2,\) M9,  \(Cap_{D1},\) \(\eta _3,\) M13,  \(\eta _4\), he would not succeed because the integrity of these parameters is guaranteed by the respective message authentication codes \(M2 =\) \(MAC(dk_1,\) \(M1 \Vert \eta _1),\) \(M6 =\) \(MAC(dk_2,\) \(M5 \Vert \eta _2),\) \(M10 =\) \(MAC(dk_2,\) \(M9 \Vert Cap_{D1}\) \(\Vert \eta _3),\) \(M14 =\) \(MAC(dk_1,\) \(M13 \Vert \) \(Cap_{D1} \Vert \) \(\eta _4)\), and the adversary needs to know the secret credentials. On the other hand, the replay attack is also prevented by random one-time nonces \(\eta _1,\) \(\eta _2,\) \(\eta _3,\) \(\eta _4\) and the respective message authentication codes. Therefore, in the access control stage, the replay attack is prevented using the random nonces \(\eta _5\) and \(\eta _6\), and the corresponding message authentication codes. As a result, the proposed protocol resists both replay and MITM attacks.

Proposition 3

SUACC-IoT prevents traceability attack.

Proof

Traceability attack is prevented in the system by the use of universally unique identifiers for IoT devices and dynamic messages created by the entities during the communication. The universally unique identifier is a cryptographically strong, random, and unique identifier, which is collision-resistant. In order to have a collision with a probability of 0.5, 2.71 quintillion identifiers are to be generated which is computationally infeasible. Due to the above reasons, \(uid_{D1}\) and \(uid_{D2}\) generated in different sessions would be different and unique. Consequently, the capability token, such as \(Cap_{D1} = h(uid_{D1},\) rctxtARRnd) and MACs: M2,  M6,  M10,  M14 in different sessions would be different. Moreover, in each session, the exchanged messages are dynamic and unique due to usage of the random nonces. Therefore, the traceability is prevented in the proposed SUACC-IoT.

Proposition 4

SUACC-IoT preserves anonymity property.

Proof

During the authentication stage of the proposed SUACC-IoT, whether it is \(uid_{D1}\) or \(uid_{D2}\), the identity of a device is protected by the symmetric key encryption and the corresponding key as \(M1 = E(uid_{D1} \Vert r, dk_1)\) and \(M9 = E(uid_{D2}, dk_2)\). In addition, when a device D2 sends \(Cap_{D1}\) to another device D1, \(uid_{D1}\) is hidden as in \(Cap_{D1} = h(uid_{D1}, r, ctxt, AR, Rnd)\). Moreover, when MACs, such as M10 and M14 are sent, \(Cap_{D1}\) is then hidden; thereby, \(uid_{D1}\) is also hidden. During the access control stage of SUACC-IoT, D1 submits \(Cap_{D1}\) to D2 for granting the requested access where \(uid_{D1}\) is hidden. In this way, anonymity is preserved in the SUACC-IoT. □

Proposition 5

SUACC-IoT prevents session-key computation attack.

Proof

In the proposed SUACC-IoT, the identities \(uid_{D1},\) \(id_{GWN}\) and \(uid_{D2}\) required to compute the session key sk that are protected by symmetric key encryption and the corresponding keys \(dk_1,\) \(dk_2\) in \(M1 =\) \(E(uid_{D1} \Vert r, dk_1),\) \(M5 =\) \(E(id_{GWN} \Vert M4,\) \(dk_2),\) \(M9 =\) \(E(uid_{D2},\) \(dk_2)\) and \(M13 =\) \(E(id_{GWN} \Vert M12,\) \(dk_1)\). Thus, the session key computation is computationally infeasible for an adversary without having the knowledge of the secret credentials \(dk_1\) and \(dk_2\). Hence, the session-key computation attack is prevented in the proposed SUACC-IoT. □

Proposition 6

SUACC-IoT protects the system parameters from passive secret disclosure attack.

Proof

If an adversary \(\mathcal {A}\) eavesdrops or intercepts on the messages during the communication to read the parameters M1,  M5,  M9,  M13,  \(Cap_{D1}\) containing in the exchanged messages, he would not be able to disclose the secrets of the entities in the network due to the following reasons. Firstly, the adversary would need the permanent (long-term) secrets \(dk_1\) and \(dk_2\) which are derived from the keys based on ECDHE to disclose the secrets \(uid_{D1},\) r\(id_{GWN},\) and \(uid_{D2}\) in the M1,  M5,  M9 and M13. Secondly, the secrets contained in \(Cap_{D1}\), such as \(uid_{D1},\) rctxt and AR cannot be disclosed, because \(Cap_{D1}\) uses collision-resistant one way cryptographic hash function. Thus, the system parameters are protected from passive secret disclosure attack in the SUACC-IoT due to the hardness of computational ECDLP and collision-resistant property of one way cryptographic hash function. □

Proposition 7

SUACC-IoT is secure against device impersonation attack.

Proof

An impersonation attack allows an adversary to attempt to falsify a unauthenticated message to defraud other recipient parties in IoT network on behalf of a sending party. In such a scenario, the receiver will be forced to believe that the message has come from a genuine entity [32]. Suppose an adversary \(\mathcal {A}\) intercepts the exchanged messages and gets M1,  M2,  M9,  M10,  \(Cap_{D1}\). After that \(\mathcal {A}\) tries to create valid \(M1',\) \(M2',\) \(M9',\) \(M10',\) \(Cap_{D1}'\) on behalf of D1 and D2. In that case, \(\mathcal {A}\) would be unsuccessful due to the following reasons. Firstly, in order to compute valid ciphertexts M1 and M9, he would need the secrets \(uid_{D1},\) r\(uid_{D2}\) and \(dk_1,\) \(dk_2\) that are not known. Secondly, he would require the unknown (long-term) secret credentials \(dk_1\) and \(dk_2\) to compute valid MACs, such as M2 and M10. Thirdly, for compute valid capability token \(Cap_{D1}\), he would need \(uid_{D1},\) rctxtARRnd which are not known to \(\mathcal {A}\). From these discussions, it is clear that without having the secret credentials, the adversary \(\mathcal {A}\) can not create valid messages on behalf of any IoT devices D1 and D2, and send the messages on behalf of D1 and D2. Thus, SUACC-IoT is secure against device impersonation attack. □

Proposition 8

SUACC-IoT is resistant to gateway impersonation attack.

Proof

Similar to Proposition 7, assume that \(\mathcal {A}\) intercepts the exchanged messages to know M5,  M6,  M13 and M14 in order to create valid \(M5',\) \(M6',\) \(M13',\) \(M14'\) on behalf of the gateway node, GWN. However, \(\mathcal {A}\) would not succeed, because of the following: (i) to compute valid ciphertexts M5 and M13 the adversary \(\mathcal {A}\) would require the secret credentials \(id_{GWN},\) \(uid_{D1},\) \(uid_{D2}\) and \(dk_1,\) \(dk_2\) which are not known to \(\mathcal {A}\), and (ii) to compute valid MACs, such as M6 and M14 he would need the unknown secret credentials \(dk_1\) and \(dk_2\). We then see that without having the secret credentials, it is also infeasible task for the adversary \(\mathcal {A}\) to create legitimate messages on behalf of the GWN. As a result, the proposed SUACC-IoT is resistant to gateway impersonation attack. □

Proposition 9

SUACC-IoT provides protection from gateway bypass attack.

Proof

In the proposed SUACC-IoT, both the devices D1 and D2 establish a session key sk via the gateway node GWN. D1 cannot compute M5 and M6 as it does not know the secret key \(dk_2\). In a similar manner, D2 cannot also compute M13 and M14 since it is not aware of the secret key \(dk_1\). However, the GWN knows both the secrets \(dk_1\) and \(dk_2\). Moreover, D1 receives \(Cap_{D1}\) from D2 via GWN. In addition, during the access control stage, D1 submits \(Cap_{D1}\) to D2 through the GWN. Hence, neither D1 nor D2 could bypass the GWN. As a result, the GWN bypass attack is protected in SUACC-IoT. □

Proposition 10

SUACC-IoT prevents Denial-of-Service (DoS) attack.

Proof

When \(\mathcal {A}\) accesses a particular resource over and over again in the network, DoS can take place. In the proposed SUACC-IoT, DoS attack using single identity is prevented because it restricts access to a resource for an identity to only one session at a time. Moreover, even if an adversary mounts the replay attacks to send old messages to the recipients, due to the lightweight cryptographic primitives used in the proposed SUACC-IoT the adversary can not consume more resource from the recipient side. Thus, DoS attack is resisted in the proposed SUACC-IoT. □

Proposition 11

SUACC-IoT is resilient to dictionary attacks.

Proof

Suppose an adversary \(\mathcal {A}\) carries out a dictionary attack to determine the decryption keys \(dk_1\) and \(dk_2\) so as to decipher the ciphertexts in the system (for example, to compute the parameters like M1, M5,  M9 and M13. However, \(\mathcal {A}\) would not be successful, because the secret keys \(dk_1\) and \(dk_2\) are derived from the shared secrets \(s_1\) and \(s_2\) generated using the ECDHE. Besides, the stateless Cipher Block Chaining (CBC) mode of the applied symmetric encryption is used for symmetric key encryption operations in the system as in [3]. Hence, SUACC-IoT is resilient to dictionary attack due to hardness of the computational ECDLP and “indistinguishability under chosen plaintext attack (IND-CPA) security” of stateless CBC mode of symmetric cipher. □

6 Testbed results and discussions

In this section, the proposed SUACC-IoT is evaluated for key performance parameters, namely CPU and memory usage, and computational overhead in an IoT testbed setup using Raspberry PI 3 [33]. Besides, the communication cost and security features of the system are assessed. Furthermore, the proposed system is also compared with the existing competing schemes.

6.1 Cryptographic standards used in testbed

The proposed system is implemented in Java using Java Cryptography Architecture [34] and BouncyCastle [35] libraries. The cryptographic standards mentioned in Table 3 are used in the implementation of the proposed system. The reasons for the choice of the cryptographic standards are provided below: i) Curve25519 [36] is used for secret key generation using ECDHE since it is a highly performance optimized, fast, and safe elliptic curve, ii) Advanced Encryption Standard (AES-256) [37], which has a key length of 256 bits, in stateless CBC cipher mode is used for symmetric encryption/decryption so that the resultant ciphertext is different every time and satisfies IND-CPA security, iii) Secure Hash Algorithm (SHA-256) [38], which produces 256 bits hash output, is used for finding cryptographic hash so that the generated hash is collision-resistant, and iv) CBC-MAC based on AES is used for finding message authentication code so that EU-CPA is fulfilled.

Table 3 Cryptographic standards used

6.2 IoT testbed experiments

In this section, we provide the IoT testbed experiments using Raspberry PI 3 setting [33] for measuring CPU and memory usage as well as computational time based on the cryptographic standards used in Sect. 6.1.

6.2.1 CPU and memory usage

To the best of our knowledge, the existing schemes did not consider CPU and memory usage parameters in their performance evaluation. We conducted four measurement runs in our IoT testbed to quantify the CPU and memory usage of the proposed system. The experimental results in Fig. 10 indicate that the SUACC-IoT system’s maximum CPU usage is 29.35% and maximum memory usage is 2.79% which are quite acceptable.

Fig. 10
figure 10

CPU and memory usage

Fig. 11
figure 11

Computational overheads

Table 4 Comparison of computational costs among different authentication approaches and SUACC-IoT
Table 5 Comparison of communication costs among different authentication approaches and SUACC-IoT
Table 6 Comparison of security features among different authentication approaches and SUACC-IoT
Table 7 Comparison of features among various access control approaches and SUACC-IoT

6.2.2 Computational cost

The third essential parameter we considered in the performance evaluation is computational overhead. We conducted four measurement runs in our IoT testbed. Fig. 11 presents the overhead in the different measurement runs. The average computational overhead computed from the different overheads is 744.5 ms which is fairly acceptable.

The theoretical computational overhead of the SUACC-IoT system and the different authentication approaches under consideration are presented in Table 4. Let \(T_H\), \(T_{MAC}\), \(T_{ENC/DEC}\), \(T_{FE}\), \(T_{PUF}\), \(T_O\), and \(T_{K.GEN}\) denote the overhead to execute hash, MAC, symmetric encryption/decryption, fuzzy extractor generation and reproduction, physical unclonable function, addition and multiplication, and key generation using ECDHE computations respectively. The computational overhead of SUACC-IoT is \(2T_H+1T_{K.GEN}+4T_{ENC/DEC}+4T_{MAC}\). The time complexities of hash, key generation, symmetric encryption/decryption and MAC are deemed \(\mathcal {O}(n)\) for a n-bit message. Therefore, the overall time complexity of the proposed system is \(\mathcal {O}(n)\). The system involves key generation and symmetric encryption/decryption operations which are avoided in the schemes [2, 5, 9]. However, this is complemented by the security features of the proposed system.

6.3 Communication cost

Communication cost is yet another key parameter. Table 5 shows that the number of messages exchanged in SUACC-IoT is 6 which is reasonably acceptable. Besides, the size of the longest message exchanged \(\{M9,M10,Cap_{D1},\eta _3\}\) or \(\{M13,M14,Cap_{D1},\eta _4\}\) in SUACC-IoT is (384 + 128 + 256 + 104) = 872 bits. This size is less compared to those in the schemes [3, 5,6,7]. Thus, the communication cost incurred for the longest message exchanged in the proposed system is 872 bits which is reasonably acceptable.

6.4 Security and functionality features

Table 6 presents the comparison of security features between the different authentication approaches under consideration and SUACC-IoT. From the table, it can be observed that SUACC-IoT has better security features compared to the other approaches. The proposed system is secure against various attack vectors in IoT namely MITM, replay, traceability, session key computation, passive secret disclosure, device impersonation, gateway impersonation and bypass, offline dictionary, and DoS attacks.

In Table 7, the different access control approaches are compared with the SUACC-IoT system. Five features namely context-awareness, granularity, scalability, interoperability, and security are considered for comparison. SUACC-IoT supports all the features considered while the other approaches do not. In a nutshell, SUACC-IoT performs fairly well and has better security features compared to the closely related existing schemes.

7 Conclusion and future works

In this paper, we presented a new secure unified authentication and access control system based on capability for IoT, called SUACC-IoT. SUACC-IoT brings the following advantages to authentication and access control in IoT:

  • Security: In the proposed protocol, an IoT device communicates with another device through the gateway node. The two devices and gateway node are mutually authenticated to one another. Two types of mutual authentication happen: (1) between the device and gateway node and (2) between the devices. Various attack vectors such as MITM, replay, traceability, session key computation, secret disclosure, device impersonation, gateway impersonation, gateway bypass, offline dictionary and DoS are addressed in the protocol. Security is also ensured during access control.

  • Lightweight: The proposed system involves only lightweight cryptographic operations such as ECDHE using highly performance optimized and fast elliptic curve, symmetric key encryption/decryption, message authentication code, and hash. Furthermore, the proposed system uses TLS only during the setup stage. Thus, the proposed system is a lightweight system suitable for use in resource-constraint IoT.

  • Scalability: The gateway node performs only limited number of lightweight ECDHE, symmetric key encryption/decryption and message authentication code operations in the protocol. The two communicating devices generate the required parameters on their own. The devices do not overload the gateway node. As a result, the proposed system performs fairly well with the increase in the number of devices.

  • Interoperability: The gateway node acts as a protocol bridge to ensure protocol compatibility across various IoT devices. Thus, the gateway node ensures device interoperability.

SUACC-IoT shows promising results in the key performance parameters, namely CPU and memory usage, computational overhead, and communication cost. The protocol’s maximum CPU usage is 29.35%, maximum memory usage is 2.79%, and computational overhead is 744.5 ms which are quite reasonable. The communication cost incurred for the longest message exchanged in the protocol is 872 bits which is fairly acceptable. Furthermore, SUACC-IoT has better security features compared to the closely related existing schemes. These make SUACC-IoT usable in various resource-constraint IoT environments.

Some future works are as follows. The first future work is to design a decentralized framework for the system to make the system more scalable. The mobility management among the heterogeneous network slices in a 5th generation mobile network (5G) network is an important issue [39]. Therefore, second future work may be on the mobility management task in IoT-enaled 5G environment where the subscription-based connectivity services for the end users should be granted based on access capability. Recently, the privacy-preserving bilateral access control with fine-granularity in an IoT-enabled healthcare has been suggested where only authorized counterparts will be able to access the health-related information [13]. As a result, another interesting future work may include to integrate privacy-preserving bilateral access control with fine-granularity with the proposed protocol.