Scalable, password-based and threshold authentication for smart homes

Abstract

Smart homes are a special use-case of the IoT paradigm, which is becoming more and more important in our lives. Although sensors, devices and applications make our daily lives easier, they often collect our sensitive data, which may lead to security problems (e.g., hacked devices, botnets, etc.). In several cases, the appropriate security mechanisms are missing within the devices. Therefore, security measures have become a central topic in the field of IoT. The most essential requirements are secure user–device authentication and confidentiality of transferred sensitive data. Passwords are the most widely used factors in various areas, such as user authentication, key establishment, and also secret sharing. Password-based protocols that are resistant to typical threats, such as offline dictionary, man-in-the-middle and phishing attacks, generate new session keys. The major aim of these solutions is to guarantee high-level security, even if a user applies a single low-entropy human memorable password for all their accounts. We introduce a threshold and password-based, distributed, mutual authenticated key agreement with key confirmation protocol for a smart home environment. The proposed protocol is a scalable and robust scheme, which forces the adversary to corrupt $l-1$ smart home devices, where l is the threshold, in order to perform an offline dictionary attack. The protocol is designed to achieve password-only setting, and end-to-end security if the chosen IoT devices are also authenticated besides the user. We also provide a security analysis of the protocol in AVISPA. We apply the on-the-fly model checker and the constraint-logic-based attack searcher to perform protocol verification for bounded numbers of sessions. We show that the proposed protocol provides session key secrecy and mutual authentication of the user and the device manager. Since efficiency is a crucial aspect, we implemented our protocol to measure the computation and communication costs and demonstrate that our solution is appropriate and eligible for smart homes.

1 Introduction

Nowadays, the Internet of things (IoT) is becoming more and more important in our lives. Smart homes are a special use-case of the IoT paradigm. Users control their home’s electronic systems (smart bulbs, smart locks, sensors, etc.) by using smartphone applications and even from remote locations. In smart homes, large variety of devices interact over the local network using different communication technologies (e.g., Wi-Fi, Bluetooth, Zigbee, Z-Wave, LoRa, cellular network, etc.) to allow data flow between other devices [54]. Zigbee or Z-Wave IoT devices are usually connected to a smart home hub constructing a mesh network [54] and access LAN through the hub. There are IoT devices that are connected directly to the home Internet router and communicate with the smart home hub via the LAN or the cloud.

Smart home systems also have other unique features that place additional design requirements. Since most devices have limited computing resources and lack or have minimal security functionalities (no authentication and plain text data transmission), several recommendations are available to handle these aspects, such as software-defined networking (SDN), which offers programmability, agility and centralized management. In [39], a privacy-preserving communication scheme is proposed for SDN-enabled smart homes (PCSS), which aims at provisioning user and smart device authentication, privacy for data and user queries. In most cases, there is a central node or a smart home hub which is responsible for managing communications with the other nodes of the local network and outside. This proposition applies lightweight cryptography (xor, hash function, AES) for the authentication between the user and the smart device with the use of a central controller, focuses on data storage and provides privacy to the searchable encrypted user queries. Moreover, this scheme does not use the distributed properties of the smart home and addresses other issues that we consider. Smart devices send sensitive data via wireless connection to the central node, where immediate analysis and decision are performed to send back control commands [51, 64]. In smart homes, EdgeOS_H [22] and HomePad [68] are two solutions to address edge-based IoT issues.

In wireless physical communication, attackers can intercept communications more easily and channels may reveal sensitive information regarding user interaction, behavior, lifestyle or physical activity. IoT devices are often very vulnerable due to weak protection (weak or default passwords) and poor maintenance. Numerous studies have addressed the security vulnerabilities of IoT devices [2, 45, 46]. Bugs have been found in a wide range of devices including routers [66], smartcams [61], baby monitors [14] and smart plugs [52]. However, there are many propositions and ideas which try to fix these vulnerabilities.

Recently, several security vulnerabilities are exploited in smart home hub devices. The smart home hub is an appealing target for cybercriminals that can serve as an entry point for remote attacks. In July 2019, researchers at Black Marble found weakness with Zipato’s ZipaMicro smart hubs where exploiting pass-the-hash security flaws an adversary could open a smart lock connected to the hub [49]. ESET IoT research has also found several vulnerabilities in three different hubs [32]. Attackers could gain hardcoded passwords or could change passwords.

Only those with the appropriate access control should be able to retrieve confidential data, which increases the role of authentication.

1.1 Motivation and related works

Arabi [3] defined edge computing broadly as all computing outside the cloud happening at the edge of the network, and more specifically in applications where real-time processing of data is required. The devices in the smart homes collect and transmit data to the edge who preprocesses the data and transmits it to the cloud. Some device data, such as camera shots, are also available locally on the edge for a while. The edge tool can not only process data from sensors but also give it certain instructions. Therefore, establishing a proper authentication between the user and the edge device is of paramount importance. After authentication, a session key agreement must be provided between the user and the edge device because the user can request confidential information or instruct the edge.

In the case of key agreement, both entities contribute to the joint secret key by providing information from which the key is derived. In mutual authentication, parties who engage in a conversation always make sure that it is the other with whom he speaks. In protocols providing implicit key authentication, each participant is assured that only the intended parties can learn the value of the session key. A key agreement protocol that provides mutual implicit key authentication is called an authenticated key agreement protocol (or AK protocol). A key agreement protocol provides key confirmation between two participants where the participants make sure that the other participant possesses the secret key. A protocol that provides mutual key authentication as well as mutual key confirmation is called an authenticated key agreement with key confirmation protocol (or an AKC protocol).

In the scientific literature, a wide variety of authentication schemes can be found, where the mutual authentication is processed between a user and a service provider consisting of several devices, servers or participants. Usually centralized, one-factor [38, 47] or two-factor identity verification protocols [23, 29] are proposed. Xavier Boyen applies blind signatures for a hidden credential retrieval protocol [19] that uses a user password. Saeed et al. [60] recommended an authenticated key agreement for IoTs (AKAIoTs). The proposed AKAIoTs can be used to establish a secure shared key between WSNs client and cloud server. The shared key can be used for secure data transmission between WSNs client and cloud server. The concept of distributed authentication of multiple devices (sensors, servers, etc.) enhances the security level, since multiple devices simultaneously have to be broken. Multifactor authentication can also provide an enhanced level of assurance in higher-security scenarios because a multifactor protocol is designed to remain secure even if all but one of the factors has been compromised.

Brainard et al. suggested a two-server approach in [21], where two servers together decide on the correctness of the password submitted for authentication as well. Katz et al. [44] demonstrated a two-server protocol with a password-only setting, in which the user needs to remember only the password, and not the servers’ public keys. In Acar et al. solution [1], the secret key is securely stored and blinded by some function of user password at storage provider(s) different from the login server. In this paper [50], a threshold MFA key exchange protocol is recommended which is built on the top of a threshold oblivious pseudorandom function and an authenticated key exchange protocol. The authors can directly assume an authenticated and secure channel between clients and devices, and typically, smart home environments are not fit for this assumption.

Shen et al. [62] proposed a one-to-many group authentication protocol with a group key establishment between personal digital assistance and each sensor node. They demonstrated a certificateless authentication protocol without pairings based on certificateless cryptography between PDA and application provider, using ECC algorithms. In [37], a multi-server authentication protocol is designed, where one-time passwords are shared among the cloud servers. A Merkle tree or a hash tree [56] is applied for verifying the correctness of the one-time password. A variant of authenticated key exchange is demonstrated in [67], which includes a permanent control server and cloud servers on 5G network. Our solution differs from these papers since we can scale the generated long-lived keys on the user’s and the provider’s sides as well.

A novel security protocol is introduced by Rathore et al. [59], which simplifies the mutual authentication and key exchange among smart home devices. The protocol leverages identity-based cryptography (IBC), thus alleviating the requirement of storing and managing public key certificates. The protocol maintains the security of the honest devices’ private keys, even when the admin device is compromised. They used a secret sharing technique for the new device registration and applied bilinear pairing in the authentication phase. In our solution, the advantages of Mazhar’s protocol are provided. Moreover, we formalize the security analysis of our protocol via AVISPA tool and in our protocol the devices do not have to compute the bilinear pairing, which would be costly for the devices. A cross-platform identity-based system using Webassembly is suggested in [65]. They introduced a new library, called CryptID, which is an open-source IBC implementation for desktops, mobiles and IoT platforms.

Nowadays, password is an important factor in user authentication. There are several suggestions for implementing password-authenticated key exchange (PAKE), which was proposed first by Bellovin and Merritt [13]. Passwords have a number of vulnerabilities which can be reduced in several ways. In [20], a Diffie–Hellman-based password-authenticated key exchange protocol is proposed. Their protocol provides a formal proof of security in the random oracle model against the passive and active adversaries. A number of two-factor authentication schemes have been proposed that depend on a long cryptographic secret and a short password [48, 57]. Furthermore, forward secrecy is crucial and appears in several schemes [36, 43, 58]. Pointcheval and Zimmer [58] demonstrated a multifactor authentication scheme applying a password, a long cryptographic secret and biometric data as well. Stebila et al. [63] took a form of authenticated key exchange into consideration which is based on multifactor password-authenticated key exchange. The session establishment depends on successful authentication of multiple short secrets, which are based on a long-term password and a one-time response. However, there would still be a problem with the required additional piece of biometric data or other equipment (e.g., smart card), which would bring burden to users.

A threshold variant of PAKE is recommended in [53]. They apply multiple servers in a threshold scheme to prevent the threat of server corruption and handle password vulnerability. These solutions expect that threshold-number servers may become corrupt, so not all servers are colluding. Most of these propositions are not forward secure or perfect forward secure. Two threshold password-authenticated key exchange schemes are proposed by Mario Di Raimondo and Gennaro [30], where the protocols require $n > 3t$ servers, where n denotes the number of servers and t is the threshold. They enforce the transparency property: From the client’s point of view, the protocol should look exactly like the centralized protocol of Katz, Ostrovsky and Yung (KOY protocol) [44]. They provide formal security analysis of the protocol, but the scheme is not a suitable choice for IoT or smart home environment since it applies fifteen exponentiations and uses digital signatures that are resource-intensive tasks.

A threshold password-protected secret sharing (PPSS) scheme was formalized by Bagherzandi et al. [9]. Jarecki et al. [42] present the first round-optimal PPSS scheme, requiring just one message from user to server and from server to user, and prove its security in the challenging password-only setting where users do not have access to an authenticated public key. Although it is not scalable, they demonstrate that their protocol is very efficient. These recommendations [40, 41] consider similar contributions to our proposition (scalability, robustness, password usage, etc.). These solutions are more suitable in the cloud environment, and their protocols contain storage providers. However, our solution is recommended typically for a smart home environment.

The comparison of the existing threshold password-based authenticated key exchange solutions is demonstrated with various attributes in Table 1.

Table 1 Summary of threshold password-based authenticated key exchange solutions

1.2 Our contribution

Our goal is to propose a password-based multi-device authentication scheme for smart homes to reduce security vulnerabilities.

The proposed protocol is designed typically for smart home environment (Fig. 1). There are several IoT devices and at least one central node or edge; therefore, instead of centralized authentication (e.g., Kerberos), we propose a multi-device authentication. The central node or edge is called the device manager. If one or more devices break down or become compromised, the system will still be able to authenticate the user in a secure way. Hence, we thoroughly utilize the capabilities of these systems like robustness and greater availability.

Fig. 1

Smart home

The scheme is an authenticated key exchange protocol with key confirmation (AKC) which takes advantage of the distributed IoT system. The client’s password is shared among the smart home devices. Thus, several sensors and devices together verify the correctness of the user password. Attackers need to attack multiple devices simultaneously in order to impersonate the user successfully. Distributed storage of the passwords provides resistance against offline attacks as well. We accomplish the password-only setting; hence, a user needs to know only a password. Since smart home devices (e.g., cameras) generate a lot of sensitive data, confidentiality of data needs to be ensured during the communication between the parties, and besides the identity verification of the user and the smart home a session key is also generated.

Our scheme is designed to be an AKC between the user and the device manager. However, if the user would like to connect to an IoT device directly, the proposed protocol provides end-to-end security as well.

Since there are resource-constrained devices, we put a great emphasis on efficiency during the design. The session key is generated by elliptic curve Diffie–Hellman key exchange; moreover, hash, MAC, XOR operations and raising to a power are applied.

The protocol consists of two phases: setup and authentication. During the setup phase, the password is chosen by the user and split among the devices. Whenever the user logs in to the smart home system, the authentication phase is run and the password given by the user is verified by the devices.

The number of devices in a smart home system is changing. The more the devices, the higher security the system should provide, i.e., the password verification should be processed by more devices. The proposed protocol is scalable in an efficient way. The password is not necessarily changed every time the number of devices is increased; hence, the shares already set for the installed devices are not changed. For the newly registered devices, new shares of the same password are set.

To provide higher security level, during the authentication phase the user chooses a random value called authentication value, which is securely split among the devices. For the authentication value, a threshold based on the number of devices, called authentication threshold, is set. At least threshold number of devices are necessary to construct the authentication value from its shares. The authentication threshold is greater than or equal to the password threshold. A device calculates its authentication share with the help of its symmetric key based on its password share. Consequently, the smart home system authenticates the user successfully only if the authentication value is calculated, i.e., only if at least authentication threshold number of devices participate. Increasing the number of devices results in a larger authentication threshold; hence, greater security level is achieved. Similarly, the number of devices can be decreased. Reregistration is required only if it goes below the threshold of the password secret sharing.

The smart home is also authenticated. The user verifies whether the devices are able to correctly calculate the password and the authentication value. Valid verification value is constructed only if the devices possess valid password shares.

Secret sharing algorithm and bilinear map are adopted to provide resistance against offline attacks. To construct the password, at least threshold number of shares are necessary. Let l denote the password threshold and assume that $l-1$ devices are compromitted. With the knowledge of $l-1$ password shares, the adversary can launch a dictionary attack. For each possible password, the authentication value should be constructed from its shares for the verification. Besides the hash, these calculations are also required for each dictionary element that slows down the attack. We apply a bilinear map for storing the hash value of the password and the salt. A hash and a bilinear map calculation together should be carried out for each possible password that also slows down the attack.

We have validated the security properties of the proposed protocol by using an automated, security protocol validation tool, named AVISPA. We show that our protocol provides mutual authentication of the participants and the generated fresh session key is kept secret. We formalize the protocol in HLPSL and also define the above security goals for the analysis. AVISPA supports four types of goal predicates: witness (for weak authentication), request (for strong authentication) and secret.

1.3 Outline of article

In Sect. 2, the necessary preliminaries are detailed. In Sect. 3, the steps of the protocol are described in detail. In Sect. 4, we provide a security analysis, which contains the description of AVISPA with the security requirements. We also formalize the protocol in HLSPL and introduce the security goals. In Sects. 5 and 6, practical issues and the conclusion are presented.

2 Preliminaries

We review some of the theory of elliptic curves over finite fields; further details can be found in [55]. Let $\mathbb {F}_q$ denote the finite field containing q elements. We apply E to define elliptic curve over $\mathbb {F}_q$, where $q = p^m$ and p is the characteristic of $\mathbb {F}_q$. If $p > 3$, then $E(\mathbb {F}_q)$ is the set of all solutions in $\mathbb {F}_q \times \mathbb {F}_q$ to an affine equation

$$\begin{aligned} y^2 = x^3 + ax + b, \end{aligned}$$

with $a, b \in \mathbb {F}_q$ and the $4a^3 + 27b^2 \ne 0$, together with an extra point O, called the point at infinity. The main advantage of applying elliptic curves in cryptography is that the same level of security is ensured with shorter key lengths compared to other public-key systems. Hence, elliptic curve cryptographic primitives work on most of the resource-constrained devices.

Elliptic curve cryptography (ECC) is based on the infeasibility of elliptic curve discrete logarithm problem, where the definition is the following:

Definition 1

Let $G\in E(\mathbb {F}_q)$ be a point of order n, and let $<G>$ be the subgroup of $E(\mathbb {F}_q)$ generated by G. The elliptic curve discrete logarithm problem is to determine the value of $a\in \mathbb {Z}_n$ in the equation $A = aG$, for a given point $A \in <G>$.

One of the most often used key agreement protocols is the Diffie–Hellman protocol. The purpose of the Diffie–Hellman protocol is to enable two parties to securely exchange a session key which can then be used for encrypting and authenticating messages. The security of the elliptic curve Diffie–Hellman protocol is based on the infeasibility of calculating elliptic curve discrete logarithms. The algorithm works as follows:

• Alice and Bob select random secret values a,  $b \in \mathbb {Z}^*_q$, respectively.

• Alice and Bob calculate aG and bG, respectively, where G is a generator in $E(\mathbb {F}_q)$ and sends their values to each other.

• Both of them compute the shared secret $K= a(bG) = a(bG) = abG$.

For storing password information on the devices, bilinear pairings are applied. Let us review the definition of the admissible bilinear map [18].

Definition 2

Let $G_1$ and $G_2$ be two groups of order q for some large prime q. A map $\hat{e} : G_1 \times G_1 \rightarrow G_2$ is an admissible bilinear map if satisfies the following properties:

• 1. Bilinear We say that a map $\hat{e} : G_1 \times G_1 \rightarrow G_2$ is bilinear if $\hat{e}(aP,bQ) = \hat{e}(P,Q)^{ab}$ for all $P,Q \in G_1$ and all $a,b \in \mathbb {Z}$.

• 2. Non-degenerate The map does not send all pairs in $G_1 \times G_1$ to the identity in $G_2$. Since $G_1$, $G_2$ are groups of prime order, if P is a generator of $G_1$ then $\hat{e}(P,P)$ is a generator of $G_2$.

• 3. Computable There is an efficient algorithm to compute $\hat{e}(P,Q)$ for any $P,Q \in G_1$.

It is important to note that bilinearity can be restated for all $P,Q,R \in G_1$ $\hat{e}(P+Q,R)=\hat{e}(P,R)\hat{e}(Q,R)$ and $\hat{e}(P,Q+R)=\hat{e}(P,Q)\hat{e}(P,R)$. We can find $G_1$ and $G_2$ where these properties hold. The Weil and Tate pairings prove the existence of such constructions. Typically, $G_1$ is an elliptic curve group and $G_2$ is the multiplicative group of a finite field. Bilinear map is chosen due to its one-wayness and bilinear properties.

The bilinear Diffie–Hellman Problem is strongly related to the bilinear map.

Definition 3

Let $\hat{e}: G_1 \times G_1 \rightarrow G_2$ be a bilinear map on $(G_1,G_2)$ and $a,b,c\in Z^*_q$. Given (P, aP, bP, cP), compute $\hat{e}(P, P)^{abc}$.

Using a (k, n) threshold scheme, a secret S can be divided into n shares in a way that $k\le n$ will be the threshold number of the shares we must be able to compute S. Thus, $k-1$ or fewer shares leave S completely undetermined. We apply secret sharing for the IoT devices to construct the password.

Shamir’s Secret Sharing threshold scheme is based on polynomial interpolation. We need at least k points to define a polynomial of degree $k-1$. To divide a secret S into shares, a polynomial degree $k-1$ is set: $f(x) = a_1 + a_1x + \cdots + a_{k-1}x^{k-1}$, where $a_i\in \mathbb {Z}_q$, where q is a large prime and $i=1,\ldots ,k-1$ are randomly chosen. Secret $S=f(0)=a_1$ and the shares will be: $s_1=f(1), \ldots , s_n=f(n)$.

To find the secret S, Lagrange polynomials are applied. There is an optimized approach, where

$$\begin{aligned} S=f(0)=\sum _{j = 0}^{k-1} f(x_j) \prod _{\begin{array}{c} m = 0 \\ m \ne j \end{array}}^{k-1} \dfrac{x_m}{x_m-x_j}. \end{aligned}$$

3 The proposed scheme

In this section, an AKC protocol is proposed that is carried out between a user and a smart home environment including a device manager connected to the IoT devices. During the setup phase, the user sets up his smart home system and chooses a password that is split into shares. The shares are securely stored on each device including the device manager. From the stored value, a password share-based long-lived symmetric secret key $K_i$ is calculated, where $i=1, \ldots , n$, where n is the number of devices.

A share-based long-lived key $K_i$ depends on a secret share of the password and the salt value. The shares are static until the password is valid. Whenever the password is changed, new shares are generated. If the number of devices is increased, the user with the help of the setup module sets a new share of the same password for the new device. The stored values, hence the long-lived keys of the other IoT devices that are already installed, are not modified, i.e., by increasing the number of devices the password threshold is still the same.

In the authentication phase, mutual authentication of the user and the smart home system is processed. The authentication is run by the user and m randomly chosen devices, where $k\le m\le n$ (k is the authentication threshold, i.e., at least k devices are necessary for calculating the authentication value). The authentication threshold is based on the number of devices and set by the device manager. Hence, by increasing the number of devices the authentication threshold is also increased. In case the number is decreased, the authentication threshold can also be decreased. The authentication threshold is greater than or equal to the password threshold.

At the beginning of the authentication phase, short-lived symmetric keys ($\overline{K}_i$) are exchanged securely between the edge and each device; moreover, the user chooses a random authentication value that is split among all the devices. The secret shares of the authentication value are sent securely to the edge that randomly chooses m devices, where m is greater than or equal to the authentication threshold. The edge transmits the authentication shares securely to the devices, which are able to calculate the authentication share only with the password share-based long-lived keys. The m devices together calculate a value which depends on the user’s password, the salt and the chosen authentication value and send it to the user. If this value is correct, devices prove the knowledge of the password share-based long-lived keys; hence, the smart home system is authenticated. Moreover, the hash of this value is also transmitted to the edge. If it is correct, then the password and the salt are also valid; hence, the user is authenticated as well.

In addition to mutual authentication of the participants, a secret session key is also exchanged between the user and the device manager applying elliptic curve Diffie–Hellman key exchange.

It is assumed that client software is running on the client device (e.g., laptop, mobile phone, etc.) that requires the password from the user to initiate the authentication process. Having the password, the share-based long-lived keys $K_i$ are calculated with the help of a salt value stored by the client software and the execution of authentication begins.

3.1 Setup phase

There are two participants in our protocol. One of them is the IoT system including the manager device and the IoT devices ($J_{1}, \ldots , J_{n}$) and the other one is the user (I), which queries services and data. The set of all binary strings of arbitrary length is denoted by $\{0,1\}^*$. If x, y are strings, then x||y denotes the concatenation of x and y. Let $\oplus$ denote an exclusive or calculation. During setup, all system parameters and long-lived keys are generated. Let E denote an elliptic curve defined over a finite field $\mathbb {F}$ and $G\in E(\mathbb {F})$ be a point of order $\mathbf{n}$. Elliptic curve parameters are chosen in a way that the system resists all known attacks on the elliptic curve discrete logarithm problem in $<G>$. Let $G_1$ and $G_2$ be two groups of order q for some large prime q, map $\hat{\hat{e}} : G_1 \times G_1 \rightarrow G_2$ be an admissible bilinear map. System parameters par are given by $par=(E, \mathbb {F}, \mathbf{n} , G, G_1, G_2, \hat{e}, H, H_0, H_1, Mac)$, where $H : \{0, 1\}^* \rightarrow \{0, 1\}^\nu$, $H_0 : \{0, 1\}^* \rightarrow \{0, 1\}^\iota$, $H_1 : \{0, 1\}^* \rightarrow \{0, 1\}^\sigma$ are cryptographic hash functions and $\nu ,\iota ,\sigma$ are not necessarily different, and $\iota$ is the size of the secret session key being exchanged. $Mac:\{0, 1\}^* \rightarrow \{0, 1\}^\nu$ is a MAC function. The system parameters are publicly known.

During the setup phase, the user chooses a password psw, and the client software generates and securely stores a random salt value z and a random polynomial for the Shamir’s Secret Sharing of psw. The secret shares $s_i$, where $i=1,\ldots ,n$, are generated, and values $\hat{e}(P,Q_z)$, where $Q_z=H(psw||z)$, and $\hat{e}(s_iP,Q_z)$ are sent and stored by the devices. The password share-based long-lived symmetric secret keys $K_i$ = $H (\hat{e} (s_iP,$ $Q_z))$ are calculated for the authentication during the authentication scheme. If a user wants to set new devices to the smart home system, they need to give the password to the client software, which generates new extra shares $s_i$ for the same polynomial, where $i>n$. This way the construction includes the property of scalability.

3.2 Authentication phase

We assume that $\hat{e}(P,Q_z)$ and $\hat{e}(s_iP,Q_z)$ are stored by the devices and $K_i=H(\hat{e}(s_iP,Q_z))$ are calculated by the client software whenever the password is given. Moreover, all IoT devices possess symmetric encryption keys ($\overline{K}_{1}, \ldots , \overline{K}_{n}$) for authenticated encryption of the messages sent to the manager device. These are short-term keys and exchanged securely in the beginning of the authentication phase.

The authentication phase consists of three main subphases. The first subphase is carried out by the client software. A secret, random authentication value w is chosen and split into shares with Shamir’s Secret Sharing. These shares and a hash value $m_0$ based on the w, the password and the salt value are transferred securely to the manager device.

During the second subphase, randomly chosen smart home devices calculate their password share-based long-lived symmetric secret keys $K_i=H(\hat{e}(s_iP,Q_z))$, construct and also verify the user’s knowledge of the value $\hat{e}(P,Q_z)^{w+psw}$ that is based on the password, the salt and the secret, random authentication value w.

In the third subphase, a secret symmetric key is exchanged between the user and the manager device and the user verifies whether the smart home system is able to calculate $\hat{e}(P,Q_z)^{w+psw}$, i.e., whether the devices possess the password shares and the salt.

3.2.1 First subphase

$J_{v}$ denotes the manager device, which manages the authentication process on the IoT side. It communicates with the user and the other $n-1$ devices. After entering the correct password to the client software, it calculates $K_i=H(\hat{e}(s_iP,Q_z))$, where $\hat{e}(s_iP,Q_z)$ is stored securely and $s_i$, $i=1,\ldots ,n$ are the secret password shares.

For the Shamir’s Secret Sharing of a randomly chosen value w, the client software generates a random polynomial g(x) with a degree large enough, where $w=g(0)$. The degree, hence also the threshold, depends on the number of devices. The larger the number of devices, the larger the threshold is. The threshold—the authentication threshold—is greater than or equal to the password threshold. The secret shares are calculated and denoted by $w_i$, where $i=1,\ldots ,n$.

I creates the first message $M_1$, and it is sent to the manager device $J_v$. I computes $m_0= H_0(\hat{e}(P,Q_z)^{psw+w})$, where $Q_z=H(psw||z)$, and also calculates $m_v= Mac_{K_v}(r_v\oplus xG\oplus J_v) \oplus w_v || r_v ||xG$, where MAC is calculated with the password share-based long-lived symmetric key $K_v$. Moreover, $m_v$ comprises xG, which is an elliptic curve point represented by a bitstring that is necessary for the key agreement and it is the client message of the elliptic curve Diffie–Hellman key exchange and an $r_v$ random value. The first message also contains $m_i=Mac_{K_i}(r_{i}\oplus J_i) \oplus w_{i}||r_{i}$, where $r_i$ is random and $i=1, \ldots , n$ and $i\ne v$ (Fig. 2).

Since w is chosen randomly, for each authentication value w and the shares $w_i$ are different. Therefore, values $m_i$, $i=0,\ldots ,n$ are random (Fig. 3).

Fig. 2

Authentication—client process

3.2.2 Second subphase

During the second phase, the identity of the user is verified by the smart home system. The device manager chooses m devices randomly, where $k\le m\le n$ and k denotes the authentication threshold. These devices—which might include the manager device as well—together authenticate the user.

The device manager also receives $m_v$. If the manager device is in the set of chosen devices, then $\hat{m}=m$, i.e., m devices verify value $m_0$, otherwise $\hat{m}=m+1$, i.e., besides the chosen devices’ shares the manager device’s share is also applied for the calculation. Hence, the manager device calculates $w_v'=Mac_{K_v}(b\oplus c\oplus J_v)\oplus a$ and $f_v=\hat{e}(P,Q_z)^{w_v'}\hat{e}(s_vP,Q_z)$, where $m_v=a||b||c$, values $\hat{e}(P,Q_z)$, $\hat{e}(s_iP,Q_z)$ are stored by the manager device and $K_v$ is its password share-based long-lived key.

After $J_{v}$ receives message $M_1$, it forwards each $m_i$ along with I to devices $J_{i_j}$, where $i_j\in \{1, \ldots , n\}$ and $j \in \{1, \ldots , m\}$. Each device calculates $K_i=H(\hat{e}(s_iP,Q_z))$ and $w_i'=Mac_{K_i}($ $e\oplus J_i)\oplus d$, where $m_i=d||e$. $J_i$ computes and transmits $f_i=\hat{e}(P,Q_z)^{w_i'}\hat{e}(s_iP,Q_z)$ encrypted with authenticated encryption to the manager device, where values $\hat{e}(s_iP,Q_z)$ and $\hat{e}(P,Q_z)$ are stored by the device. Hence, its message authentication and confidentiality are provided by the short-lived symmetric key $\overline{K}_i$. The manager device checks whether $m_0 = H_0($ $\prod _{l=i_1}^{i_{\hat{m}}} f_i^{t_i})$ holds, where $t_j=\prod _{l=i_1, j\ne l}^{i_{\hat{m}}}\frac{x_l}{x_l-x_j}$ and $\prod _{l=i_1}^{i_{\hat{m}}} f_i^{t_i}=\hat{e}(P,Q_z)^{w+psw}$. If the equality holds, the manager device verifies the identity of the user and the integrity of $c=xG$.

Fig. 3

Authentication—devices’ process

3.2.3 Third subphase

Figure 4 demonstrates the steps of the third subphase. $J_{v}$ generates a random value $y\in \mathbb {Z}^*_n$ and computes the secret session key $ssk=H_0(yxG)$. $J_{v}$ calculates response $M_2=h||yG$, where $h=H(ssk||yG||\prod _{i=i_1}^{i_{\hat{m}}} f_i^{t_i})$ and yG is the manager device message in the EC Diffie–Hellman key exchange.

Fig. 4

Authentication—final process

I receives $M_2=h||yG$ and calculates the secret session key $ssk'=H_0(yxG)$ and $h'=H(ssk'||yG||\hat{e}(P,Q_z)^{w+psw})$. If $h=h'$, then I confirms that manager device $J_{v}$ knows the secret session key, and the IoT devices possess the password share-based long-lived secret keys; hence, they are authenticated.

Eventually, $M_3 = H_1(ssk' || yG || xG)$ is computed and forwarded to $J_{v}$. $J_{v}$ verifies the message received from the client and if it is correct, $J_{v}$ confirms that I knows the secret session key.

In the authentication phase, the random value $\hat{e}(P,Q_z)^{w+psw}$ can be calculated by the manager device only if the devices possess the password share-based long-lived symmetric keys; hence, the user is able to verify the identity of multiple devices just by checking h. On the other hand, $m_0$ is checked by calculating $\hat{e}(P,Q_z)^{psw+w}$ involving keys $K_i$. Correct $m_0$ proves that the user knows psw and the client software accesses the salt value z; hence, the identity of the user is verified as well. Value $r_{i}$ ensures that the MAC value $m_{i}$ is fresh for every authentication in order to avoid replay attack. Basically, the secret session key is created via an authenticated key agreement protocol based on random values (x, y) generated by the user and the edge. These values are sent securely so the attacker is not able to gain any information about them.

The authentication phase is also proved to be efficient in terms of time complexity since there are only symmetric encryptions and exponentiations. Both sides use hash, MAC and xor operations, which are also fast operations. Our protocol can be considered robust, because m out of n IoT devices are required for authentication. If a device is not available, the manager device will not choose it.

4 Security analysis

In this section, a detailed security analysis of the proposed AKC protocol is provided. One of the indispensable security requirements is the mutual authentication of the participants. Secure mutual authentication of participants prevents adversaries from impersonating a legal user or the device manager and gaining illegal access to sensitive data.

Another security goal is key secrecy, i.e., an adversary should not possess any information about the new key. During a protocol run, a new randomly chosen session key should be exchanged between the participants, and a protocol execution could not be successfully completed with an old key exchanged before. At the end, parties should be able to verify that the other party knows and is able to use the new session key. We also consider known-key security and forward secrecy properties. Known-key security preserves the security of session keys after disclosure of a session key. Disclosure of a session key should not jeopardize the security of other session keys. Forward secrecy holds if long-term secrets of one or more entities are compromised and the secrecy of previous session keys is not affected.

Formal methods have been proved to be a good choice for uncovering flaws of incorrectly designed security protocols. There are many tools available that can analyze and identify attacks against protocols, such as Automated Validation of Internet Security Protocols and Applications [4] and ProVerif [15]. In the following subsection, we introduce AVISPA, which is an automated formal verification tool used to verify the security properties of the protocols. After presenting AVISPA, we provide the security analysis.

4.1 AVISPA

AVISPA contains four different formal verification approaches (i.e., on-the-fly model checker, constraint-logic-based attack searcher, SAT-based model checker and tree automata-based protocol analyzer) that can formally validate security properties of a protocol. It applies the high-level protocol specification language (HLPSL) which is a modular, role-based language. With the use of HLPSL, correct protocol behavior described in the specification is achieved.

The on-the-fly model checker (OFMC) [10,11,12, 31] executes protocol forgery and bounded session verification as well, where OFMC considers both typed and untyped protocol models. OFMC’s effectiveness is due to the integration of a number of symbolic, constraint-based techniques, which are correct and complete, in the sense that no attacks are lost nor new ones are introduced by them. These techniques are the lazy intruder technique or the constraint differentiation technique. OFMC also implements a number of efficient search heuristics. It also provides support for modeling an intruder who is capable of performing guessing attacks on weak passwords, and for the specification of algebraic properties of cryptographic operators. OFMC can be employed for protocol falsification and also for verification for a bounded numbers of sessions—without bounding the messages an intruder can generate.

The constraint-logic-based attack searcher (CL-AtSe) is different from the OFMC since it uses constraint solving to perform the protocol falsification and verification for bounded numbers of sessions [24,25,26,27,28]. The protocol messages can be typed or untyped, and the pairing can be considered to be associative or not. It is significant that several properties of the XOR operator can be handled as well. CL-AtSe is built in a modular way and is thus open to extensions for handling algebraic properties of cryptographic operators. CL-AtSe performs several kinds of optimizations to reduce and often eliminate redundancies or useless branches in the protocol’s symbolic execution.

In AVISPA, the SAT-based model checker (SATMC) [5,6,7,8] could be also applied which considers the typed protocol model and performs both protocol falsification and bounded session verification by reducing the input problem to a sequence of invocations and state-of-the-art SAT solvers. Finally, the TA4SP (Tree Automata based on Automatic Approximations for the Analysis of Security Protocols) back-end [16, 17] performs unbounded protocol verification by approximating the intruder knowledge with the help of regular tree languages and rewriting. Genet and Klay introduced an extension of an approximation method based on tree automata [33, 34] for verifying security protocols.

Internally, the attack conditions are specified in terms of temporal logic, but useful and concise macros are provided for the two most frequently used security goals, authentication and secrecy. Among the goal facts, secrecy declares which values should be kept secret. This goal declaration in the goal section describes that anytime the intruder learns a secret value, even if it is not explicitly given, then it should be considered an attack.

The witness and request events are goal facts related to authentication. They are used to check whether a participant is right in believing that its intended peer is present in the current session, has reached a certain state, and agrees on a certain value, which typically is fresh. They always appear in pairs with identical third parameter.

4.2 Security validation

In this part, we analyze the security properties of our protocol. Our main goal besides mutual authentication of participants is providing that at the end of the protocol the attacker is not able to gain any information about the exchanged new session key. We formalize the protocol, the security goals and the full version of them can be checked in the Appendix. The following part shows the user’s role, the user’s steps in the protocol formalized in AVISPA. We apply the OFMC and CL-AtSe and execute the attacker simulation. The results of the security analysis show that the attacker cannot impersonate the legal participants or get the session key.

Let us move on to the formalization of the key secrecy and authentication goals with the AVISPA tool. We formalize the protocol in HLPSL. This language is based on roles: basic roles for representing each participant role and composition roles for representing scenarios of basic roles. Each role is independent from the others, getting some initial information by parameters, communicating with the other roles by channels. The intruder is modeled using the Dolev–Yao model. In AVISPA, we can apply the secret, witness and request goal facts. We use these facts to demonstrate that our protocol is secure and we verify the $m_0, h, SSK$ values in the AVISPA model . The secret is used to show that the session key (SSK) is secret and witness and request serve to prove authentication of participants ($m_0, h$). In the goal section, four goals for authentication and one goal for secrecy are specified:

• secrecy_of sec_1

• authentication_on user_dm_w

• authentication_on dm_user_He

• authentication_on dm_user_SSK

• authentication_on user_dm_SSK

The $m_0$ value contains the password and w fresh value, and we try to find an attack with the authentication_on user_dm_w. The authentication_on dm_user_He goal is similar to authentication_on user_dm_w, and we would like to check He (which we denote with h in the protocol) value. Finally, the authentication_on dm_user_SSK and authentication_on user_dm_SSK are used for the verification of the key confirmation requirement; therefore, the mutual authentication is achieved in our protocol as well. In our protocol, we have used witness and request for three purposes:

• The user authenticates the device manager on the value of He.

• Device manager authenticates the user on the value of w.

• The device manager authenticates the user and vice versa on the value of SSK. We abuse strong authentication on SSK here to express that SSK should be generated freshly (and not replayed).

We formalized these statements:

• $secret(Secret,sec\_1,\{U,DM\})$

• $witness(DM,U, dm\_user\_He, HE)$

• $witness(U,DM, user\_dm\_w, W')$

• $request(DM,U, dm\_user\_SSK, SSK)$

• $request(U,DM, user\_dm\_SSK, SSK)$

We describe an example of these statements. The goal fact $secret(Secret,sec\_1,\{U,DM\})$ declares the information “Secret” as secret shared by the agents of the set containing U and DM; moreover, sec1 protocol id identifies the secrecy goal in the goal section. We check with this fact whether the intruder can calculate the session key SSK. The goal fact $witness(DM,U, dm\_user\_He, HE)$ is for a (weak) authentication property of the device manager DM by user U on HE. The fact declares that the device manager, who is an agent, is a witness to the information HE. The goal will be identified by the constant $dm\_user\_He$ in the goal section. The goal fact $request(U,DM, user\_dm\_SSK, SSK)$ is for a strong authentication property of the device manager DM by user U on SSK, it declares that agent user U requests a check of the value SSK and this goal will be identified by the constant $user\_dm\_SSK$ in the goal section. The declaration witness represents that value h in the protocol is fresh and generated by the device manager for the user and request represents the user’s acceptance of the session key (SSK) that was created by the device manager for the user. The other request and witness statements are working in a similar way. We need to require the strong authentication which prevents replay attacks. Applying the back-ends model checker (OFMC, ATSE) we check whether the intruder can execute the replay attack. Using the Dolev–Yao model, the back-ends model checkers verify whether there is any man-in-the-middle attack possible by the intruder. If any of the back-end tools finds a trace in which the request event is preceded by a witness event originated by an agent other than U, an attack will be reported.

In OFMC’s case, the total number of nodes visited is 2262, while the depth is 4 piles with 5.48 s search time. The results of CL-AtSe protocol analysis demonstrate that the number of states analyzed is 26, out of which 15 states can be reached, the translation time is 0.07 s and the computation time is 0.15 s. The output proves that the proposed protocol is safe against active and passive attacks. The known-key and forward secrecy hold in the proposed protocol as well. The parameters xG and yG of the session key are chosen independently and randomly for every protocol run; hence, the new session keys are also independent and random. The session key can be calculated by the adversary from xG and yG only if he or she computes ECCDH function. The adversary faces ECCDH assumption for the previous session keys even if long-term secret keys are compromised.

5 Computation and communication cost analysis

Since efficiency is an important aspect, evaluation of the computation and communication cost of the protocol is essential. Overall, the session key is generated by ECDH key exchange, and there are hash, MAC, XOR calculations and exponentiations, which are considered to be fast operations.

In the efficiency analysis, the number of devices participating in the identity verification is an important parameter.

5.1 Devices

We implemented the steps of the protocol in Python program language in order to test it in a real environment. We applied and focused on three devices (PC, Raspberry PI 4 and ESP32). We used a PC with the following parameters: AMD Ryzen 5 2600—6 cores, 12 threads, 3.4 GHz—3.9 GHz 16 GB RAM and an M.2 NVMe SSD with 3200 MB/s writing—3500 MB/s reading speed. The Raspberry Pi is a popular small on-board computer (SBC). In a smart home, we assume that a manager device is a more powerful device that can be matched with a Raspberry PI. Raspberry has all the software you need for basic computing. Although Raspbian is the OS officially recommended by the manufacturer, countless other operating systems are available. In our case, we apply a RasPi, which includes Broadcom BCM2711, Quad core Cortex-A72 (ARM v8) 64-bit SoC @ 1.5GHz processor. It has 2 GB RAM and a class 10 memory card. The ESP32-WROOM-32 is a high-performance, generic Wi-Fi + BT + BLE MCU module that targets a wide range of applications, from low-performance sensor networks to the most demanding tasks such as audio encoding, music streaming and MP3 decoding. The essence of the module is the ESP32-D0WDQ6 chip. The embedded chip is scalable and adaptive. There are two CPU cores that can be controlled separately, and the frequency of the CPU clock can be adjusted from 80 MHz to 240 MHz.

5.2 Communication and computation costs of the protocol

In this section, we detail the communication and computation costs of the protocol. During the identity verification, we can parallelize the operations on the IoT side. Even if we apply more devices, the time does not increase. Furthermore, this parameter denoted by m can be adjusted dynamically in our protocol.

5.2.1 Computation cost

Table 2 summarizes the computational requirements for each device.

Table 2 Number of operations

We demonstrate the execution time of the operations in seconds. The authentication protocol can be executed within 1 s even for a large number of devices. In addition to mutual authentication, this execution time also includes the session key exchange and the key confirmation. This is considered acceptable for the user (Table 3).

Table 3 Execution time of protocol’s operations (second)

Figure 5 shows the execution time for the client depending on the number of IoT devices.

Fig. 5

Execution time for the client with different numbers of sensors

Table 4 shows the computational performance of the authentication phases with different devices.

Table 4 Performance evaluation of our threshold authentication (in seconds)

We have selected a threshold authentication system [41] from Table 1 in Sect. 1.1 that is similar to our system. Their runtime results are compared to our ones for different numbers of devices and thresholds. According to [35] in 2022, on average 500 devices will be connected per household; hence, large number of devices and threshold should be considered. Our proposition provides a better result for $n \ge 10$ number of devices and for $m \ge 5$ threshold (Table 5).

Table 5 Performance comparison (in seconds)

Today, achieving computing capacity and adequate security is an important consideration for IoT devices. The cost of manufacturing affects the capabilities of these devices; however, we need to ensure security. These aspects were also taken into account during the design of our protocol.

5.2.2 Communication cost

We assume that the identifiers of participants are 32-bit. In this case, 4,294,967,296 ($2^{32}$) unique IDs are possible. During authentication, the hash and MAC values are 256 bits, the AES symmetric ciphertexts are 128 bits, and the elliptical curve points are 448 bits. Table 6 summarizes the bits sent by the client, device manager and the devices. The manager always participates in the authentication. If the manager is among the randomly chosen m devices, then $m-1$ IoT devices are chosen, otherwise m.

Table 6 Communication cost of the protocol

We can see that the costs of communication and computation depend largely on the number of devices involved in the authentication. The computation cost is negligible because the manager device and the client device can execute these operations extremely quickly. Moreover, we emphasize that the IoT devices compute in parallel and this phase does not increase significantly the execution time of the protocol even if we add more devices to the smart home. Figure 6 demonstrates how communication cost and data traffic are growing on the network.

Fig. 6

Communication cost of the protocol with different numbers of sensors

In order to make communication secure and message size acceptable, the appropriate value has to be specified. We propose to apply around ten to fifty devices for the protocol, because the communication cost is still small and also ensures security.

6 Conclusion

We have introduced a mutual authentication protocol for smart homes. This environment has special characteristics; it contains a device manager and several resource-constrained devices. In most cases, the device manager behaves as an edge preprocessing data received from the devices. The number of IoT devices is increasing, and some of them might also break down. The proposed protocol is designed for this environment; it is a threshold and password-based distributed AKC protocol that is scalable and robust with a password-only setting. We formalized the protocol in AVISPA, and we examined the security of this based on different security goals. The AVISPA did not find any kind of vulnerability or attack; hence, the protocol achieves the security goals (mutual authentication, key secrecy). Finally, we implemented the protocol and measured the performance of our proposed solution instance.

Fig. 7

HLPSL specification of user’s role

Fig. 8

HLPSL specification of device manager’s role

Fig. 9

HLPSL specification of device’s role

Fig. 10

HLPSL Specification of role environment

Fig. 11

OFMC output of the proposed protocol verified in AVISPA

Fig. 12

CL-AtSe output of the proposed protocol verified in AVISPA

Appendix

• The elliptic curve what we use: $y ^ 2 = x ^ 3 + x$, which is a supersingular curve (Figs. 7, 8, 9).

• The prime: $p= 7313295762564678553220399414112155363840682896273128302543102778210584118101444624864132462285921835023839111762785054210425140241018649354445745491039387$.

• The order: q = 730750818665451459101842416358141509827966402561 (Figs. 10, 11, 12).