Secure Authentication in the Smart Grid

Abstract

Authenticated key agreement is a process in which protocol participants communicate over a public channel to share a secret session key, which is then used to encrypt data transferred in subsequent communications. LLAKEP, an authenticated key agreement protocol for Energy Internet of Things (EIoT) applications, was recently proposed by Zhang et al. While the proposed protocol has some interesting features, such as putting less computation on edge devices versus the server side, its exact security level is unclear. As a result, we shed light on its security in this paper through careful security analysis against various attacks. Despite the designers’ security claims in the random oracle model and its verification using GNY logic, this study demonstrates that this protocol has security weaknesses. We show that LLAKEP is vulnerable to traceability, dictionary, stolen smart glass, known session-specific temporary information, and key compromise impersonation attacks. Furthermore, we demonstrate that it does not provide perfect forward secrecy. To the best of our knowledge, it is the protocol’s first independent security analysis. To overcome the LLAKEP vulnerabilities, we suggested the LLAKEP${}^{+}$ protocol, based on the same set of cryptographic primitives, namely the one-way hash function and ECC point multiplication. Our comprehensive security analysis demonstrates its resistance to different threats, such as impersonation, privileged insider assaults, and stolen smart glass attacks, along with its resistance to sophisticated assaults, such as key compromised impersonation (KCI) and known session-specific temporary information (KSTI). The overhead of the proposed protocol is acceptable compared to the provided security level.

1. Introduction

The Internet of Things (IoT) is a new technological concept that aims to provide a communication channel between objects to advance their functionality and enhance the traditional mechanism. It also adapted to different applications with dedicated features, for example, the Internet of Energy or Energy IoT (IoE/EIoT) [1], Internet of Drones (IoD) [2], Industrial Internet of Things (IIoT) [3], Internet of Vehicles (IoV) [4], and Medical Internet of Things (MIoT) [5]. While communication between objects in these technologies provides many advantages, security is a big challenge for all of them, given that different objects have different properties and constraints, and the data should be transferred over the public channel using wireless technologies. Hence, that data could always be accessed by the adversary and used for unauthorized purposes. In addition, the adversary could aim to impersonate any object to just use its capabilities or do malicious activities, e.g., spying, encryption of data for a ransom, total wipeout of disk and data, and abuse for coin mining [6]. Hence, any such application requires an approach to identify friends and foes. Authentication protocols are traditional solutions for providing authorized access to infrastructure while blocking unauthorized access.

The Energy Internet of Things enables the development of new complex communication infrastructures for the modernization and automation of energy infrastructures for producers and manufacturers, as depicted in Figure 1. It results in greater connectivity of these safety-critical systems, allowing for more efficient management of operational processes, service provisioning, and information exchange for various (third-party) actors. EIoT enables more efficient and environmentally friendly energy production with the least amount of waste. This technology, however, raises security concerns, as evidenced by numerous recent cyberattacks on critical infrastructures and utilities [7,8]. The reason for this is that their reliance on information technology (IT) for operation and control is increasing, making them more vulnerable to malicious intent.

Figure 1. The Energy Internet of Things (EIoT) ecosystem.

Zhang et al. [9] recently proposed an authenticated key agreement (AKE) protocol for EIoT in the metaverse era and named it LLAKEP, which is a protocol for secure authentication and key agreement between an electric bike rider and a battery swap station. In the proposed protocol, the client has fewer computing overheads compared to the server. Hence, the expected latency will be reduced. They also formally analyzed the security of the proposed protocol in the random oracle model and evaluated it using GNY logic. The provided security analysis confirms its security in those models. However, it will not guarantee the protocol’s security in a real application because those models do not cover all security concerns. For example, in reality, the adversary can access the device and read its memory or gain the low entropy of passphrases that are used by the users. These types of attacks are not considered in such formal proof because the designers generally consider the protocol environment ideal. Hence, it could be interesting to evaluate the real-world security of this protocol, considering the adversary’s advantage in reality, and we aim to address this point in this study.

1.1. Our Contribution

This paper’s contributions are as follows:

• We propose the first independent security analysis of LLAKEP in various scenarios with varying access to the adversary. Our security analysis demonstrates important security issues in this protocol.
• In terms of efficiency, we show that this protocol could be designed more efficiently and propose a promising solution to address this flaw.
• We propose the LLAKEP${}^{+}$ protocol as an improved protocol that uses the same set of cryptographic primitives as the LLAKEP protocol.
• We carefully evaluate the security of the proposed protocol both informally and formally using a real or random model and confirm its security using the Scyther tool. We also evaluate the security of the proposed protocol and compare it with the state of the art, which shows that the proposed protocol has a low communication cost and a comparable computation cost.

1.2. Paper Organization

The rest of the paper is organized as follows: in Section 2, we represent the required preliminaries, including notations and some background information. Next, in Section 2.4, we look at the LLAKEP scheme. We demonstrate the security flaws of this scheme in Section 3. LLAKEP${}^{+}$, the enhanced protocol, is proposed in Section 4, and its security and efficiency analysis is provided. Finally, the paper is wrapped up in Section 6.

2. Preliminaries

2.1. Notation

We use the list of notations represented in Table 1 in this paper.

Table 1. List of used notations.

Symbol	Description
EBR	Electric bike riders
BSS	Battery swap station
MC	Microprocessor chip
A	Adversary
$I{D}_{EBR}$	Identity of an electric bike rider EBR
$P{W}_{EBR}$	Password of an electric bike rider EBR
$s{k}_X$	Private key of X
$p{k}_X$	Public key of X
$sk$	Session key
$E/F^p$	An elliptic curve E over a prime finite field $F^p$ with p being a large prime
n	Order of base point G
$Z^n$	$1,2,\dots ,n-1$
$k·G$	Scalar multiplication on elliptic curves and G is a base point in $E/Fp$
$A\parallel B$	Concatenation operation between strings A and B
$A\oplus B$	XOR operation between strings A and B
$kdf(·)$	Key derivation function
$H(·)$	A one-way hash function that generates digests

2.2. Elliptic Curve Cryptography

Given a curve $y^2=x^3+a·x+b$, a distinguished point at infinity $\mathcal{O}$, and a prime number q, the Elliptic Curve Cryptography (ECC) $E_{F_q}$ is defined as an additive group $\mathcal{G}$ over the finite field $F_q$ including the set of all $(x,y)\in F_q\times F_q$ such that ${\lambda }^2={\mu }^3+a\mu +b$, where $a,b\in F_q$ and $4a^3+27b^{2}modq\ne 0$, along with $\mathcal{O}$. The order of $\mathcal{G}$ has been defined by the size of the subgroup, which is defined as the smallest positive number n such that $n·G=\mathcal{O}$, G is the generator of this subgroup [10].

Regarding the security of ECC, for large values of n, given any natural scalar $a\in F_q$, it is simple to calculate $y=a·G$ (point multiplication), but given y, $E_{F_q}$, and G, computing the multiplicand a is computationally impossible. The Elliptic Curve Discrete Logarithm Problem (ECDLP) is a difficult problem whose difficulty is determined by the size of the elliptic curve subgroup, i.e., n. The Elliptic Curve Computational Diffie–Hellman Problem (EC-CDHP) is another difficult problem over ECC that aims to compute $a·b·G$ given $a·G$, $b·G$, $E_{F_q}$, and G where $a,b\in F_q$ [11].

2.3. System Model

In this paper, we consider a system that includes a battery swap station (BSS), which is used to provide service to registered electric bike riders (EBR), such as battery swapping, using Figure 2. Furthermore, we assume that, with the exception of the registration phase, the remainder of the messages between EBR and BSS are sent over the public channel. Communication consists of two phases: in the first phase, EBR and BSS authenticate each other to share a secret key.

Figure 2. The used system model.

In this paper, depending on the concept, we use the Dolev–Yao (DY) [12] and Canetti and Krawczyk (CK) [13] adversary models. The main difference between these models is the adversary capabilities: in the DY paradigm, the attacker has complete control over messages sent via public channels, or it can take a valid user’s smart card and retrieve the stored value from it. On the other hand, in the CK adversary model, the adversary can also compromise the session and access random values generated in each session, for instance. We consider a Probabilistic Polynomial Time Adversary (PPTA) in any model that can only perform a polynomial number of operations, including at most a polynomial call to any cryptographic primitive.

In this paper, following Figure 2, we examine a system that includes a Battery Swap Station (BSS), which is used to provide services such as battery switching to registered Electric Bike Riders (EBRs). Furthermore, with the exception of the registration step, we assume that the remaining communications between EBR and BSS are sent via the public channel. The communication process is divided into two stages. In the first stage, EBR and BSS authenticate each other to exchange a secret key. The shared key is then used to encrypt the remainder of the sent data.

As with the designer model, we assume that each entity has a private and public pair of ECC-based public keys. The public key is known to all protocol entities, including the attacker. The owner is the only one who has access to the private key. In addition to this authentication element, each registered EBR has a username and password as a secondary authentication factor. Because the user is expected to remember the username and password, they are picked from a low-entropy feasible space, and the adversary may execute a dictionary search on each of them independently. However, simultaneously scanning the space of their concatenation is not conceivable.

Although the authentication factors should be kept private, they can be compromised at any time. In this situation, the leak of information should not affect the security of earlier sessions.

To account for all possibilities, we assume the adversary has access to the ephemeral keys, which are the random values created at the end of each session. In actuality, side-channel attacks such as power analysis may do this. The opponent should not gain any more knowledge regarding long-term secrets or the shared session key in this situation.

2.4. LLAKEP Description

LLAKEP’s four phases are initialization, user registration, authenticated key agreement, and password update.

2.5. Initialization

The system parameters are chosen by the battery swap station (BSS) during the initialization phase, i.e., $\{E/F_p,G,n,p{k}_{BSS},H_1(·),H_2(·)\}$, where $p{k}_{BSS}=s{k}_{BSS}·G$.

2.6. User Registration

User registration is required to register an electric bike rider (EBR) in BSS. EBR inputs $I{D}_{EBR}$ and $P{W}_{EBR}$ on the smart glass, which includes a microchip MC, during this protocol step. The MC generates random numbers $a_{MC}$ and $b_{MC}$ and computes $HIP=H_2(I{D}_{EBR}\parallel P{W}_{EBR})$, $v=HIP\oplus a_{MC}$, $d=HIP\oplus b_{MC}$ and $C=H_2(I{D}_{EBR}\parallel P{W}_{EBR}\parallel a_{MC})$. Next, using a secure channel, EBR submits $\{p{k}_{EBR},I{D}_{EBR},d\}$ to BSS.

BSS checks the uniqueness of $I{D}_{EBR}$ and $H_2\left(I{D}_{EBR}\right)$ after receiving the message then it computes $l=H_1\left(s{k}_{BSS}\right)\oplus d\oplus H_2(s{k}_{BSS}\parallel I{D}_{EBR})$, stores $\{H_2(s{k}_{BSS}\parallel I{D}_{EBR}),I{D}_{EBR}\}$ and sends l to EBR.

On the other hand, EBR calculates $l^{\prime }=l\oplus b_{MC}=H_1\left(s{k}_{BSS}\right)\oplus HIP\oplus H_2(s{k}_{BSS}\parallel I{D}_{EBR})$ and stores it along v and C in MC.

2.7. Authenticated Key Agreement

To swap batteries, a registered EBR communicates with BSS to share a session key $SK$ as shown in Figure 3:

Figure 3. Mutual authentication phase of LLAKEP scheme to share a session key between $EBR$ and $BSS$ [9].

• The EBR user enters its $I{D}_{EBR}$ and $P{W}_{EBR}$ on the smart glass. MC computes $HIP=H_2(I{D}_{EBR}\parallel P{W}_{EBR})$, $a_{MC}=HIP\oplus v$, and verifies whether $C\stackrel{?}{=}{H}_2(I{D}_{EBR}\parallel P{W}_{EBR}\parallel a_{MC})$. Assuming that verification was successful, MC generates a random number $r_{MC}$ and computes $U_{EBR}=r_{MC}+s{k}_{EBR},R=r_{MC}·p{k}_{BSS},CI{D}_{EBR}=l^{\prime }\oplus HIP=H_1\left(s{k}_{BSS}\right)\oplus H_2(s{k}_{BSS}\parallel I{D}_{EBR})$ and $Aut{h}_{EBR}=H_2(I{D}_{EBR}\parallel R\parallel CI{D}_{EBR}\parallel T_{MC})$, where $T_{MC}$ is the current timestamp. Next, using a public channel, EBR sends $\{Aut{h}_{EBR},$$CI{D}_{EBR},U_{EBR},T_{MC}\}$ to BSS.
• Once received the message, BSS verifies $T_{MC}$, calculates $H_2(s{k}_{BSS}\parallel I{D}_{EBR})=CI{D}_{EBR}\oplus$$H_1\left(s{k}_{BSS}\right)$ and $R_{EBR}=U_{EBR}·G-p{k}_{EBR}=r_{MC}·G$ and $R^{*}=s{k}_{BSS}·R_{EBR}$ and verifies whether $Aut{h}_{EBR}\stackrel{?}{=}{H}_2(I{D}_{EBR}\parallel R^{*}\parallel CI{D}_{EBR}\parallel T_{MC})$. Next, it generates a random number $r_{BSS}$ and computes $R_{BSS}=r_{BSS}·G$, $S{K}_{BSS}=r_{BSS}·R_{EBR}$ and $Aut{h}_{BSS}=H_2(I{D}_{EBR}\parallel R^{*}\parallel S{K}_{BSS}\parallel T_{BSS})$, where $T_{BSS}$ is the current timestamp. Next, using a public channel, BSS sends $\{Aut{h}_{BSS},R_{BSS},T_{BSS}\}$ to EBR.
• EBR verifies $T_{BSS}$, calculates $S{K}_{EBR}=r_{MC}·R_{BSS}$ and verifies whether $Aut{h}_{BSS}^{*}\stackrel{?}{=}{H}_2(I{D}_{EBR}\parallel R\parallel S{K}_{EBR}\parallel T_{BSS})$ to authenticate BSS. After successful authentication, EBR calculates $sk=kdf(I{D}_{EBR}\parallel S{K}_{EBR}\parallel T_{MC}\parallel T_{BSS})$ and $Aut{h}_{EB}=H_2(I{D}_{EBR}\parallel R\parallel sk\parallel T_{MC}^{\prime })$, where $T_{MC}^{\prime }$ is the current timestamp. Next, using a public channel, EBR sends $\{Aut{h}_{EB},T_{MC}^{\prime }\}$ to BSS.
• BSS verifies $T_{MC}^{\prime }$ and computes $s{k}^{\prime }=kdf(I{D}_{EBR}\parallel S{K}_{BSS}\parallel T_{MC}\parallel T_{BSS})$ and checks whether $Aut{h}_{EB}\stackrel{?}{=}{H}_2(I{D}_{EBR}\parallel R^{*}\parallel s{k}^{\prime }\parallel T_{MC}^{\prime })$ to authenticate EBR and store the session key $s{k}^{\prime }$, which is used for secure communication between EBR and BSS.

2.8. Password Change

To change the current password, EBR enters its current $I{D}_{EBR}$ and $P{W}_{EBR}$ on the smart glass. MC computes $HIP=H_2(I{D}_{EBR}\parallel P{W}_{EBR})$, $a_{MC}=HIP\oplus v$, and verifies whether $C\stackrel{?}{=}{H}_2(I{D}_{EBR}\parallel P{W}_{EBR}\parallel a_{MC})$ to authenticate EBR. If authentication was successful; MC requests EBR to provide a new password $P{W}_{new}$. Then it computes $HI{P}_{new}=H_2(I{D}_{EBR}\parallel P{W}_{new})$, $v_{new}=HI{P}_{new}\oplus a_{MC}$, ${}_{new}=HI{P}_{new}\oplus b_{MC}$, $C_{new}=H_2(I{D}_{EBR}\parallel P{W}_{new}\parallel a_{MC})$ and $l_{new}=l^{\prime }\oplus HIP\oplus HI{P}_{new}=H_1\left(s{k}_{BSS}\right)\oplus HI{P}_{new}\oplus H_2(s{k}_{BSS}\parallel I{D}_{EBR})$. At the end, EBR stores $l_{new}^{\prime }$ along $v_{new}$ and $C_{new}$ in MC.

3. On the Security of LLAKEP

LLAKEP has some interesting features, such as putting less computation on edge devices versus the server side. As a result of the authentication process, this protocol achieves low latency. Furthermore, the designers provided a formal security analysis in the random oracle model and validated its security with GNY logic. The disadvantage of such analysis may be its reliance on security analysis assumptions. Furthermore, in such attacks, primitives are regarded as ideal. For example, a hash function is considered one-way in those models, but if the hash function’s input is chosen from a small domain, a dictionary attack on such low entropy input space may be possible. Such an attack is used in password-guessing attacks, such as [14,15]. As a result, it is worthwhile to conduct a third-party analysis of the protocol’s exact security, focusing on more detailed attacks. These types of attacks are significant because of Zhang et al. considered the majority of these attacks to be disadvantages of the related protocols, see ([9], Table 1). As a result, it will be interesting to explicitly evaluate its security against such an attack, which we do in this section.

3.1. Insider Adversary

An insider adversary refers to a cyber-security risk that originates from within an organization. Consider a current or former employee, contractor, vendor, or partner with legitimate user credentials that misuse their access to the detriment of the organization’s networks, systems, and data as an example of insider. A common privilege of an insider over an ordinary adversary is its access to the private channel. If such an adversary achieves a significant advantage to attack a protocol due to such access, that protocol suffers from insider adversaries.

We assume the adversary’s target is to retrieve the user’s credentials, i.e., $I{D}_{EBR}$ and $P{W}_{EBR}$. Let us consider an adversary with access to the transferred messages over the public channel and also the stored values in the smart glass, i.e.,  $l^{\prime }=H_1(s{k}_{BSS}\oplus HIP\oplus H_2(s{k}_{BSS}\parallel I{D}_{EBR}))$, $v=HIP\oplus a_{MC}$, and $C=H_2(I{D}_{EBR}\parallel P{W}_{EBR}\parallel a_{MC})$, where $HIP=H_2(I{D}_{EBR}\parallel P{W}_{EBR})$.

The transferred messages over the public channel are as follows, besides timestamps:

$$\begin{array}{cc}\hfill Aut{h}_{EBR}=& H_2(I{D}_{EBR}\parallel R\parallel CI{D}_{EBR}\parallel T_{MC})\hfill \\ \hfill CI{D}_{EBR}=& l^{\prime }\oplus HIP=H_1\left(s{k}_{BSS}\right)\oplus H_2(s{k}_{BSS}\parallel I{D}_{EBR})\hfill \\ \hfill U_{EBR}=& r_{MC}+s{k}_{EBR}\hfill \\ \hfill Aut{h}_{BSS}=& H_2(I{D}_{EBR}\parallel R\parallel S{K}_{BSS}\parallel T_{BSS})\hfill \\ \hfill R_{BSS}=& r_{BSS}·G\hfill \\ \hfill Aut{h}_{EB}=& H_2(I{D}_{EBR}\parallel R\parallel sk\parallel T_{MC}^{\prime })\hfill \end{array}$$

where $R=s{k}_{BSS}·r_{MC}·G$ and $S{K}_{BSS}=r_{BSS}·r_{MC}·G$. Since $a_{MC}$ is a random number, the adversary cannot receive low-entropy information from v and C. On the other hand, $s{k}_{BSS}$ is the private key of BSS, and, due to that, $l^{\prime }$ does not help the adversary achieve the desired information to extract secret parameters using dictionary attacks. However, combining that information with the transfused messages provides the adversary with some gains. Let’s consider the case where the adversary has $l^{\prime }$ from reading the smart glass’s memory and also eavesdrops on $CI{D}_{EBR}=l^{\prime }\oplus HIP$ from the public channel. Hence, the adversary achieves $HIP=CI{D}_{EBR}\oplus l^{\prime }$. Assuming that the entropy of $I{D}_{EBR}$ and $P{W}_{EBR}$ is, respectively, ${\mathcal{H}}_{ID}$ and ${\mathcal{H}}_{PW}$, then the expected complexity to drive $I{D}_{EBR}$ and $P{W}_{EBR}$ using dictionary attack is $2^{{\mathcal{H}}_{ID}+{\mathcal{H}}_{PW}}$.

Now, let us consider an insider adversary with access to the transferred messages over the public channel during the user registration phase, i.e., $\{p{k}_{EBR},I{D}_{EBR},d\}$ to BSS, where $d=HIP\oplus b_{MC}$. Let’s assume the adversary also eavesdrops on a session and steals the smart glass. Given the transferred messages over the public channel, $HIP=H_2(I{D}_{EBR}\parallel P{W}_{EBR})$ is achieved, and the expected complexity of extracting $P{W}_{EBR}$ using a dictionary attack is $2^{{\mathcal{H}}_{PW}}$. Given $I{D}_{EBR}$ and $P{W}_{EBR}$, the adversary can use the stolen smart glass at any time to impersonate the target EBR. Compared with a generic adversary whose cost was $2^{{\mathcal{H}}_{ID}+{\mathcal{H}}_{PW}}$, an insider adversary has a significant advantage.

3.1.1. Traceability and Anonymity

Assume a protocol party participated in two different protocol sessions, say at times T and T’. In such a protocol, the target party is traceable whenever the adversary can link the transferred messages over those sessions with a high probability. If a party is transferred over the public channel, its constant identifier is a common way to track it down. Hiding such information, however, does not ensure the protocol’s security against this attack. In more detail, during the authentication phase of LLAKEP, the EBR sends $\{Aut{h}_{EBR},CI{D}_{EBR},U_{EBR},T_{MC}\}$ to BSS, where $CI{D}_{EBR}=H_1\left(s{k}_{BSS}\right)\oplus H_2(s{k}_{BSS}\parallel I{D}_{EBR})$. This information is consistent for any EBR user and, with a high probability, unique. Assuming that the adversary eavesdropped on a session between the ith user, $EB{R}_i$, and BSS and saved $CI{D}_{EB{R}_i}$, assuming that it monitors another session between the ith user, $EB{R}_i$, and BSS, if $CI{D}_{EB{R}_i}\ne CI{D}_{EB{R}_j}$ then $EB{R}_i\ne EB{R}_j$ and if $CI{D}_{EB{R}_i}=CI{D}_{EB{R}_j}$ then $EB{R}_i=EB{R}_j$. This means that any EBR can be traced across multiple sessions in LLAKEP.

3.1.2. Known Session-Specific Temporary Information Attack

Assume the adversary is aware of the session-specific temporary values of LLAKEP, i.e., $r_{MC}$ and $r_{BSS}$, as well as the messages transferred over the public channel. The message transferred from EBR to BSS includes $U_{EBR}=r_{MC}+s{k}_{EBR}$, and given $r_{MC}$, the adversary achieves $s{k}_{EBR}=U_{EBR}-r_{MC}$, which is EBR’s secret key. Given $r_{MC}$, the adversary also computes $R=r_{MC}·G$. $Aut{h}_{EBR}=H_2(I{D}_{EBR}\parallel R\parallel CI{D}_{EBR}\parallel T_{MC})$, on the other hand, is also available from the public channel, and $I{D}_{EBR}$ has low entropy, e.g., ${\mathcal{H}}_{ID}$. As a result, the adversary can extract $I{D}_{EBR}$ with a complexity of $2^{{\mathcal{H}}_{ID}}$. The session key is computed as $sk=kdf(I{D}_{EBR}\parallel S{K}_{EBR}\parallel T_{MC}\parallel T_{BSS})$ and $S{K}_{EBR}=r_{MC}·R_{BSS}$ and $R_{BSS}$ is transferred over the public channel. As a result, the first known session-specific temporary information (KSTI) attack on LLAKEP has a complexity of $2^{{\mathcal{H}}_{ID}}$, while the latter KSTI attacks have negligible complexities.

3.1.3. Impersonation Attack after a Successful KSTI Attack

Assume the opponent successfully launched a KSTI attack on LLAKEP. Following the attack, the adversary has $I{D}_{EBR}$, $s{k}_{EBR}$ and $CI{D}_{EBR}=H_1\left(s{k}_{BSS}\right)\oplus H_2(s{k}_{BSS}\parallel I{D}_{EBR})$. It is obvious that the adversary can do the following:

• The adversary generates a random number $r_{adv}$ and computes $U_{EBR}=r_{adv}+s{k}_{EBR}$, $R_{adv}=r_{adv}·p{k}_{BSS}$ and $Aut{h}_{EBR}=H_2(I{D}_{EBR}\parallel R\parallel CI{D}_{EBR}\parallel T_{adv})$, where $T_{adv}$ is the current timestamp. Next, using a public channel, the adversary sends $\{Aut{h}_{EBR},CI{D}_{EBR},U_{EBR},T_{MC}\}$ to BSS.
• Obviously $T_{MC}$ and $Aut{h}_{EBR}$ are accepted by $BSS$ and $R_{adv}=r_{adv}·p{k}_{BSS}$ is extracted by BSS from the received $U_{EBR}=r_{adv}+s{k}_{EBR}$. Next, it generates a random number $r_{BSS}$ and computes $R_{BSS}=r_{BSS}·G$, $S{K}_{BSS}=r_{BSS}·R_{avd}$ and $Aut{h}_{BSS}=H_2(I{D}_{EBR}\parallel R_{adv}\parallel S{K}_{BSS}\parallel T_{BSS})$ and sends $\{Aut{h}_{BSS},R_{BSS},T_{BSS}\}$ to EBR (impersonated by the adversary).
• The adversary calculates $S{K}_{adv}=r_{adv}·R_{BSS}$, $sk=kdf(I{D}_{EBR}\parallel S{K}_{adv}\parallel T_{adv}\parallel T_{BSS})$ and $Aut{h}_{ad}=H_2(I{D}_{EBR}\parallel R_{adv}\parallel S{K}_{adv}\parallel T_{adv}^{\prime })$, where $T_{adv}^{\prime }$ is the current timestamp. Next, using a public channel, the adversary sends $\{Aut{h}_{ad},T_{adv}^{\prime }\}$ to BSS.
• BSS verifies $T_{adv}^{\prime }$, calculates $s{k}^{\prime }=kdf(I{D}_{EBR}\parallel S{K}_{BSS}\parallel T_{MC}\parallel T_{BSS})$ and verifies whether $Aut{h}_{ad}\stackrel{?}{=}{H}_2(I{D}_{EBR}\parallel R_{adv}\parallel s{k}^{\prime }\parallel T_{MC}^{\prime })$ to authenticate EBR/adversary and store the session key $s{k}^{\prime }$, which is used for the secure communication between EBR/adversary and BSS.

Since $S{K}_{BSS}=r_{BSS}·R_{adv}=r_{BSS}·r_{adv}·G=r_{adv}·R_{BSS}=S{K}_{adv}$, the authentication is completed successfully which confirms the impersonation attack on LLAKEP.

3.2. Key Compromised Impersonation Attack

Assume a client $\mathcal{C}$ is in contact with a server $\mathcal{S}$. Assuming that all the secret parameters of $\mathcal{C}$ (resp. $\mathcal{S}$) are given to the adversary, the adversary should not be able to impersonate $\mathcal{S}$ (resp. $\mathcal{C}$) toward $\mathcal{C}$ (resp. $\mathcal{S}$); otherwise, the protocol is vulnerable to key compromise impersonation (KCI) attacks [16,17,18]. This attack is a variant of the Man in the Middle (MitM) attack and has been successfully applied to TLS. For instance, in the KCI-based MitM attack against TLS [19], an attacker with a client certificate’s private key installed on a victim can impersonate any server. Hence, in this section, we investigate LLAKEP’s security against this type of attack.

Assume the adversary is given all of the user’s information, i.e., the stored information in the smart glass: $l^{\prime }=H_1\left(s{k}_{BSS}\right)\oplus HIP\oplus H_2(s{k}_{BSS}\parallel I{D}_{EBR})$, $v=HIP\oplus a_{MC}$, $C=H_2(I{D}_{EBR}\parallel P{W}_{EBR}\parallel a_{MC})$, where $HIP=H_2(I{D}_{EBR}\parallel P{W}_{EBR})$, the  user’s credentials which are $I{D}_{EBR}$ and $P{W}_{EBR}$ and the stored information in the MC’s memory which is $s{k}_{EBR}$. The adversary does the following to impersonate BSS:

• The EBR user enters its $I{D}_{EBR}$ and $P{W}_{EBR}$ on the smart glass. MC verifies them, generates a random number $r_{MC}$ and computes $U_{EBR}=r_{MC}+s{k}_{EBR},R=r_{MC}·p{k}_{BSS},CI{D}_{EBR}=l^{\prime }\oplus HIP=H_1\left(s{k}_{BSS}\right)\oplus H_2(s{k}_{BSS}\parallel I{D}_{EBR})$ and $Aut{h}_{EBR}=$$H_2(I{D}_{EBR}\parallel R\parallel CI{D}_{EBR}\parallel T_{MC})$ and sends $\{Aut{h}_{EBR},CI{D}_{EBR},U_{EBR},T_{MC}\}$ to BSS.
• The adversary extracts $r_{MC}=U_{EBR}-s{k}_{EBR}$, computes $R_{EBR}=r_{MC}·G$ and $R^{*}=r_{MC}·p{k}_{BSS}$, generates a random number $r_{adv}$, computes $R_{adv}=r_{adv}·G$, $S{K}_{adv}=r_{adv}·R_{EBR}$ and $Aut{h}_{adv}=H_2(I{D}_{EBR}\parallel R\parallel S{K}_{adv}\parallel T_{adv})$ and sends $\{Aut{h}_{adv},R_{adv},T_{adv}\}$ to EBR.
• EBR verifies $T_{adv}$, calculates $S{K}_{EBR}=r_{MC}·R_{adv}$ and verifies whether $Aut{h}_{adv}^{*}\stackrel{?}{=}{H}_2(I{D}_{EBR}\parallel R\parallel S{K}_{EBR}\parallel T_{adv})$ to authenticate BSS/adversary which authenticates.

Following the aforementioned attack, the adversary could impersonate BSS toward EBR, assuming it has access to EBR’s secret parameters but no knowledge of BSS secrets.

3.3. The Lack of Perfect Forward Secrecy

A security protocol provides perfect forward secrecy if compromising a protocol participant’s long-term secrets at time $T^j$ does not affect the security of the shared session keys at any time $T^i<T^j$ [10]. It is worth noting that Zhang et al. considered this attack when comparing related protocols ([9], Table 1). As a result, it will be interesting to explicitly evaluate LLAKEP’s security against such an attack, which we do in this section. We assume the adversary intercepted the following messages over the public channel at time $T^i$, along with the timestamps $T_{MC}^i$, $T_{BSS}^i$ and $T_{MC}^{\prime i}$:

$$\begin{array}{cc}\hfill Aut{h}_{EBR}=& H_2(I{D}_{EBR}\parallel R\parallel CI{D}_{EBR}\parallel T_{MC}^i)\hfill \\ \hfill CI{D}_{EBR}=& H_1\left(s{k}_{BSS}\right)\oplus H_2(s{k}_{BSS}\parallel I{D}_{EBR})\hfill \\ \hfill U_{EBR}^i=& r_{MC}^i+s{k}_{EBR}\hfill \\ \hfill Aut{h}_{BSS}=& H_2(I{D}_{EBR}\parallel R^i\parallel S{K}_{BSS}\parallel T_{BSS}^i)\hfill \\ \hfill R_{BSS}^i=& r_{BSS}^i·G\hfill \\ \hfill Aut{h}_{EB}=& H_2(I{D}_{EBR}\parallel R\parallel s{k}^i\parallel T_{MC}^{\prime i})\hfill \end{array}$$

where $s{k}^i=kdf(I{D}_{EBR}\parallel S{K}_{BSS}\parallel T_{MC}^i\parallel T_{BSS}^i)$ and $S{K}_{BSS}=r_{MC}^i·R_{BSS}^i$. Obviously, given $U_{EBR}^i=r_{MC}^i+s{k}_{EBR}$, $R_{BSS}^i$ and $s{k}_{EBR}$, the adversary is able to compute $r_{MC}^i=U_{EBR}^i-s{k}_{EBR}$ and $S{K}_{BSS}=r_{MC}^i·R_{BSS}^i$. Next, given the revealed $I{D}_{EBR}$, the eavesdropped $T_{MC}^i$ and $T_{BSS}^i$ and the computed $S{K}_{BSS}$ the adversary can extract the session key of the ith session, i.e., $sk=kdf(I{D}_{EBR}\parallel S{K}_{BSS}\parallel T_{MC}^i\parallel T_{BSS}^i)$. Hence, LLAKEP does not provide perfect forward secrecy.

3.4. A Note on the LLAKEP Efficiency

The efficiency of the protocol should be considered when designing the messages. BSS stores $\{H_2(s{k}_{BSS}\parallel I{D}_{EBR}),I{D}_{EBR}\}$ during the LLAKEP registration phase, and during the authentication phase, EBR sends $CI{D}_{EBR}=l^{\prime }\oplus HIP=H_1\left(s{k}_{BSS}\right)\oplus H_2(s{k}_{BSS}\parallel I{D}_{EBR})$ as a part of the message, which is used to identify the target $EBR$’s records. In this regard, BSS first computes $H_1\left(s{k}_{BSS}\right)\oplus CI{D}_{EBR}=H_2(s{k}_{BSS}\parallel I{D}_{EBR})$ and searches its database for related records. This means that BSS should compute this value for all authentications. However, if it stores $H_1\left(s{k}_{BSS}\right)\oplus H_2(s{k}_{BSS}\parallel I{D}_{EBR})$ in the registration phase rather than $\left\{H_2(s{k}_{BSS}\parallel I{D}_{EBR})\right\}$, that computation is not required, and the resulted protocol could be more efficient.

4. LLAKEP${}^{+}$ Description

LLAKEP${}^{+}$, the proposed protocol, includes initialization, user registration, authenticated key agreement, and password change. While designing the proposed protocol, we avoided the weaknesses in LLAKEP. To avoid insider attacks, we never send $I{D}_{EBR}$ to BSS in plain text. Furthermore, we avoid using $U_{EBR}=r_{MC}+s{k}_{EBR}$ because it could be a source for a KSTI attack. We will include both long-term and ephemeral keys to provide security against KSTI and KCI.

4.1. Initialization

During the startup phase, the battery swap station (BSS) selects the system parameters, which are $\{E/F_p,G,n,p{k}_{BSS},H(·)\}$, where $p{k}_{BSS}=s{k}_{BSS}·G$. The only difference in this phase is that a single hash function $H(·)$ is used instead of two, which might be any one-way cryptographic hash function. We suppose n is the order of the group $\mathcal{G}$’s basis point G, and the output of $H(·)$ may be transformed to an integer in $0,\dots ,n-1$. In other circumstances, though, we may want lengthier output from the hash function to mask a pattern, in which case we use $H^e(·)$.

4.2. User Registration

During the registration phase, we use the Elliptic Curve Digital Signature Algorithm (ECDSA) [20], which is a version of the Digital Signature Algorithm (DSA). During this phase, EBR chooses its $I{D}_{EBR}$ and $P{W}_{EBR}$ as randomly as possible and enters them into the smart glass containing a microchip MC. The embedded MC generates a random number $a_{MC}$ and computes $HID=H(I{D}_{EBR}\parallel a_{MC})$. Next, using a secure channel, EBR submits $\{p{k}_{EBR},HID\}$ to BSS. It selects a random integer $k\in [1,n-1]$ and calculates $k·G=(x,y)$ and sets $r=xmodn$. If $r=0$, BSS selects another random number. Next it computes $s=k^{-1}(HID+r\times s{k}_{BSS})modn$ and sends $(r,s)$ to EBR. $(HID,p{k}_{EBR})$ is stored in a secure Non Volatile Memory (NVM) of BSS also.

Once received $(r,s)$, EBR computes $u_1=HID\times s^{-1}$ and $u_2=r\times s^{-1}$ and $(x_1^{\prime },y_1^{\prime })=u_1·G+$$u_2·p{k}_{BSS}$. Next, it verifies whether $r\stackrel{?}{=}{x}^{\prime }modn$ to confirm the registration. After that, MC computes $d=H^e(I{D}_{EBR}\parallel P{W}_{EBR})\oplus (a_{MC}\parallel s\parallel r)$ and $v=H(s\parallel r\parallel H(I{D}_{EBR}\parallel P{W}_{EBR}\parallel a_{MC})$ and stores $(d,v)$ in the smart glass’s NVM.

4.3. Authenticated Key Agreement

A registered EBR connects with BSS to share a session key $sk$ to switch batteries, as shown in Figure 4:

Figure 4. Mutual authentication phase of LLAKEP${}^{+}$ scheme to share a session key between $EBR$ and $BSS$.

• The EBR user enters its $I{D}_{EBR}$ and $P{W}_{EBR}$ on the smart glass. MC computes $(a_{MC}\parallel s\parallel r)=$$H^e(I{D}_{EBR}\parallel P{W}_{EBR})\oplus d$, and $HID=H(I{D}_{EBR}\parallel a_{MC})$ and verifies whether $v\stackrel{?}{=}H(s\parallel r\parallel H(I{D}_{EBR}\parallel P{W}_{EBR})\parallel a_{MC})$ to accept the login. If the verification was successful, MC obtains the current time $T_{MC}$, generates a random number $k_{MC}\in [1,n-1]$ and calculates $R_{EBR}=k_{MC}·G$ and $Aut{h}_{EBR}=HID\oplus H(k_{MC}·p{k}_{BSS}\parallel T_{MC})$. Then, it sends $(R_{EBR},T_{MC},Aut{h}_{EBR})$ to BSS over a public channel.
• BSS validates $T_{MC}$ after receiving the message and calculates $HID=Aut{h}_{EBR}\oplus H(s{k}_{BSS}·R_{EBR}\parallel T_{MC})$. If it detects the extracted $HID$ in its database, BSS generates a random number $k_{BSS}\in [1,n-1]$ and calculates $R_{BSS}=k_{BSS}·G$, the temporary session key $sk=H(k_{BSS}·R_{EBR}\parallel k_{BSS}·p{k}_{EBR}\parallel s{k}_{BSS}·R_{EBR})$ and $Aut{h}_{BSS}=H(R_{BSS}\parallel T_{MC}\parallel sk)$. Then, it sends $(R_{BSS},Aut{h}_{BSS})$ to EBR over a public channel.
• EBR computes the session key, after receiving the message, $sk=H(k_{MC}·R_{BSS}\parallel s{k}_{EBR}·R_{EBR}\parallel k_{MC}·p{k}_{BSS})$ and verifies whether $Aut{h}_{BSS}\stackrel{?}{=}H(R_{BSS}\parallel T_{MC}\parallel sk)$ to authenticate BSS. If BSS has been authenticated, EBR returns $V_{EBR}=H(sk\parallel T_{MC}\parallel HID)$ to BSS.
• BSS verifies the received $V_{EBR}$ to authenticate EBR and also confirm the shared session key.

4.4. Password Change

To change the current password, EBR enters its current $I{D}_{EBR}$ and $P{W}_{EBR}$ on the smart glass and requests a run of the password change phase. MC computes $(a_{MC}\parallel s\parallel r)=H^e(I{D}_{EBR}\parallel P{W}_{EBR})\oplus d$, and $HID=H(I{D}_{EBR}\parallel a_{MC})$ and verifies whether $v\stackrel{?}{=}H(s\parallel r\parallel HID\parallel a_{MC})$ to accept the login. Next, the user inputs the new password $P{W}_{EBR}^{new}$. After that, MC computes $d^{new}=H^e(I{D}_{EBR}\parallel P{W}_{EBR}^{new})\oplus (a_{MC}\parallel s\parallel r)$ and $v^{new}=H(s\parallel r\parallel H(I{D}_{EBR}\parallel P{W}_{EBR}^{new})\parallel a_{MC})$ and stores $(d^{new},v^{new})$ in the smart glass’s NVM and sends the password successfully updated message.

5. Security and Cost Analysis of LLAKEP${}^{+}$

We argue the security and cost analysis of LLAKEP${}^{+}$ against various attacks and form different aspects in this section.

5.1. Informal Security Analysis

Through the analysis, we consider two types of adversaries: the first is a common adversary with access to the transferred messages over the public channels, i.e., $R_{EBR}$, $T_{MC}$, $Aut{h}_{EBR}$, $R_{BSS}$, $Aut{h}_{BSS}$, $V_{EBR}$, where:

$$\begin{array}{cc}\hfill R_{EBR}=& k_{MC}·G\hfill \\ \hfill Aut{h}_{EBR}=& HID\oplus H(k_{MC}·p{k}_{BSS}\parallel T_{MC})\hfill \\ \hfill R_{BSS}=& k_{BSS}·G\hfill \\ \hfill sk=& H(k_{BSS}·R_{EBR}\parallel k_{BSS}·p{k}_{EBR}\parallel s{k}_{BSS}·R_{EBR})\hfill \\ \hfill Aut{h}_{BSS}=& H(R_{BSS}\parallel T_{MC}\parallel sk)\hfill \\ \hfill V_{EBR}=& H(sk\parallel TMC\parallel HID)\hfill \end{array}$$

and $k_{MC}\in [1,n-1]$ and $k_{BSS}\in [1,n-1]$. This adversary’s primary goal is to conduct any type of attack, such as tracking an EBR, impersonating it, gaining access to shared secrets, and so on. The second type of adversary, on the other hand, is a privileged adversary, which is more applicable in the CK model. This adversary has access to the secure channel during the registration phase, the ephemeral secrets, the long-term secrets, and so on, depending on the attack type. This adversary’s goal, for example, is to gain access to the secret keys.

5.1.1. Replay Attack

To conduct a replay attack, the adversary must be able to reuse the eavesdropped messages transferred in session i in a subsequent session. The use of a timestamp in the calculation of $Aut{h}_{EBR}=HID\oplus H(k_{MC}·p{k}_{BSS}\parallel T_{MC})$, $Aut{h}_{BSS}=H(R_{BSS}\parallel T_{MC}\parallel sk)$ and $V_{EBR}=H(sk\parallel T_{MC}\parallel HID)$ ensures the time-freshness of the transferred messages in LLAKEP${}^{+}$. As a result, this protocol is resistant to replay attacks.

5.1.2. Impersonation Attack

A passive adversary can perform an impersonation attack, assuming it can perform a replay attack, and Section 5.1.1 demonstrates that LLAKEP${}^{+}$ is secure against replay attacks. As a result, a passive adversary cannot impersonate either EBR or BSS. An active adversary, on the other hand, should forge a valid tuple $R_{EBR},T_{MC},Aut{h}_{EBR},V_{EBR}$ or $R_{BSS},Aut{h}_{BSS}$ such that related $Aut{h}_{BSS}=H(R_{BSS}\parallel T_{MC}\parallel sk)$ or $V_{EBR}=H(sk\parallel T_{MC}\parallel HID)$ is also verified by the receiver. Assume the adversary is attempting to impersonate EBR at time $T_{MC}$. The adversary could do this if it can compute a valid $Aut{h}_{EBR}=HID\oplus H(k_{MC}·p{k}_{BSS}\parallel T_{MC})$ and return the expected $V_{EBR}=H(sk\parallel T_{MC}\parallel HID)$. Assuming the adversary does not have access to $HID$ or $s{k}_{EBR}$, it cannot forge those values. As a result, it cannot compute a valid tuple $R_{EBR},T_{MC},V_{EBR}$ to impersonate EBR. Similarly, to impersonate BSS, the adversary must be able to return a valid $R_{BSS},Aut{h}_{BSS}$ given the EBR’s challenge tuple $(R_{EBR},T_{MC},Aut{h}_{EBR})$. To do so, however, the adversary must either have $s{k}_{BSS}$ or compromise ECDLP or EC-CDHP, which is not possible. As a result, LLAKEP${}^{+}$ protects against impersonation attacks.

5.1.3. Traceability and Anonymity

To trace an object that is participating in an authentication protocol, it should be feasible to relate the transmitted messages over the public channel with a non-zero probability to the object’s identity/unique-parameters. Except for the timestamp, which cannot be used directly to track any object, all parameters in the proposed protocol are either fresh values or distinguished by a one-way hash function or ECC point multiplication. $R_{EBR}=k_{MC}·G$ and $R_{BSS}=k_{BSS}·G$ are fresh values, $Aut{h}_{EBR}=HID\oplus H(k_{MC}·p{k}_{BSS}\parallel T_{MC})$ is masked by $H(k_{MC}·p{k}_{BSS}\parallel T_{MC})$ and $Aut{h}_{BSS}=H(R_{BSS}\parallel T_{MC}\parallel sk)$ and a one-way hash function is used to compute $V_{EBR}=H(sk\parallel T_{MC}\parallel HID)$. If the adversary can extract $HID$ from $Aut{h}_{EBR}$; it will be able to trace the EBR or BSS. To do so, however, the adversary must either have access to $s{k}_{BSS}$ or compute $k_{MC}·p{k}_{BSS}$, as $R_{EBR}=k_{MC}·G$ necessitates compromising ECDLP, which is not feasible for sufficiently large n. As a result, LLAKEP${}^{+}$ protects against traceability attacks.

5.1.4. Secret Disclosure Attack

The EBR secret parameters are $I{D}_{EBR}$, $P{W}_{EBR}$, $HID$ and $s{k}_{EBR}$, whereas the BSS secret parameter is $s{k}_{BSS}$ and the shared session key is $sk=H(k_{BSS}·k_{MC}·G\parallel k_{BSS}·p{k}_{EBR}\parallel s{k}_{BSS}·R_{EBR})$. The attacker clearly cannot get $P{W}_{EBR}$ from the parameters transmitted over the public channel. The only parameter that contains $I{D}_{EBR}$, on the other hand, is $HID=H_2(I{D}_{EBR}\parallel a_{MC})$, which is distinguished by a random value $a_{MC}$. Furthermore, $HID$ is masked by $H(k_{MC}·p{k}_{BSS}\parallel T_{MC})$ and cannot be calculated without knowledge of $s{k}_{BSS}$ or solving the ECDLP issue. $s{k}_{EBR}$ and $s{k}_{BSS}$ are also secret keys that only the owner knows about. To compute $sk$, the adversary must first compute $k_{BSS}·k_{MC}·G$ given $k_{MC}·G$ and $k_{BSS}·G$, which requires overcoming the ECDLP problem once more. As a result, we conclude that LAKEP${}^{+}$ protects against secret disclosure attacks.

5.1.5. Permanent De-Synchronization Attack

In the suggested protocol, successfully updating the password is the only way to desynchronize a valid EBR from its MC. However, it necessitates a login, the complexity of which is $2^{{\mathcal{H}}_{ID}+{\mathcal{H}}_{PW}}$ for an adversary without access to $I{D}_{EBR}$ and $P{W}_{EBR}$. Assuming ${\mathcal{H}}_{ID}={\mathcal{H}}_{PW}=20$, the total complexity is $2^{40}$, which is impractical.

5.1.6. Man-in-the-Middle Attack

To imitate EBR and BSS as a man-in-the-middle adversary, the adversary needs to either perform a replay attack or actively alter the transmitted messages. A PPTA adversary has no possibility of carrying out such assaults if the arguments in Section 5.1.1 and Section 5.1.2 are followed. As a result, it ensures the proposed protocol’s security against man-in-the-middle attacks.

5.1.7. Stolen Smart Glass Attack

Consider the loss or adversarial access to the smart glass. In this case, the adversary can read the smart glass memory and access the stored values, namely $d=H^e(I{D}_{EBR}\parallel P{W}_{EBR})\oplus (a_{MC}\parallel s\parallel r)$ and $v=H(s\parallel r\parallel H(I{D}_{EBR}\parallel P{W}_{EBR}\parallel a_{MC})$. To obtain any information, it must guess $I{D}_{EBR}$ and $P{W}_{EBR}$ at the same time, which costs $2^{{\mathcal{H}}_{ID}+{\mathcal{H}}_{PW}}$.

5.1.8. Insider Adversary

The primary advantage of a privileged insider opponent over a naive attacker is access to data exchanged across a secure channel. The single secret channel in the proposed protocol is utilized during the registration phase, and according to Section 4.2, the data exchanged over this channel are $(HID,p{k}_{EBR})$ sent by the EBR and $(r,s)$ sent by the BSS. Although $HID$ is valuable information, the adversary cannot use it to extract $I{D}_{EBR}$ or $P{W}_{EBR}$ or impersonate EBR since it also requires the secret $s{k}_{EBR}$. As a result, the suggested protocol is safe against insider threats.

5.1.9. Perfect Forward Secrecy

If access to the long-term secrets, such as $s{k}_{EBR}$ and $s{k}_{BSS}$, does not compromise the security of the prior session keys, a protocol is assumed to guarantee complete forward secrecy. The session key in LLAKEP${}^{+}$ is computed as $sk=H(k_{BSS}·k_{MC}·G\parallel k_{BSS}·p{k}_{EBR}\parallel s{k}_{BSS}·R_{EBR})$, where $k_{BSS}$ and $k_{MC}$ are ephemeral session dependent fresh values. Although the adversary has access to $k_{MC}·G$ and $k_{BSS}·G$, to compute $sk$, the adversary must first compute $k_{BSS}·k_{MC}·G$, which requires overcoming the ECDLP issue. As a result, we conclude that LLAKEP${}^{+}$ offers complete forward secrecy.

5.1.10. Known Session-Specific Temporary Information Attack

In LLAKEP${}^{+}$, the session-specific temporary information is the timestamps and $k_{BSS}$ and $k_{MC}$. However, to compute the session key, the adversary must first compute $s{k}_{BSS}·R_{EBR}$ and $s{k}_{EBR}·R_{BSS}$ given $R_{EBR}=k_{MC}·G$, $R_{BSS}=k_{BSS}·G$, $p{k}_{EBR}$ and $p{k}_{BSS}$ which again needs to overcome ECDLP problem. Hence we conclude that LLAKEP${}^{+}$ provides security against Known session-specific temporary information attacks.

5.1.11. Key Compromised Impersonation Attack

To mimic $BSS$ in a KCI attack, the adversary must be able to return a valid $Aut{h}_{BSS}=H(R_{BSS}\parallel T_{MC}\parallel sk)$. However, the adversary must compute valid $sk$, which is a factor of $s{k}_{BSS}·R_{EBR}$. Given $R_{EBR}=k_{MC}·G$ and $p{k}_{BSS}$, solve the ECDLP issue is required to compute $s{k}_{BSS}·R_{EBR}$. As a result, we conclude that LLAKEP${}^{+}$ protects against key compromised impersonation attacks.

5.2. Formal Security Evaluation

5.2.1. Scyther

Scyther is a tool for formal analysis of security protocols under the assumption of perfect cryptography, where it is assumed that all functions and cryptographic primitives used are perfect in terms of cryptographic properties. In the sense that the defined symmetric and asymmetric encryption functions are secure enough, that is, an adversary cannot gain anything from a ciphertext unless s/he knows the decryption key. Both hash and one-way functions have all the features of a secure hash function. This means that the adversary cannot reach the input of the one-way functions, such as the hash function and PRNG, from their output.

It should be noted that most of the time, protocol designers use the Scyther tool to find and fix problems caused by the way the protocol is made. In practice, many protocol problems can be found using the Scyther tool and either prove their authenticity or find attacks.

Standard Version and Compromise Version Comparison:

The difference between these two versions is that in the standard model, the adversary model is the Dolo–Yao model, and in the Compromise version, in addition to the Dolo–Yao model is also possible to check forward secrecy scenarios. The meaning of forward secrecy is that if the main and long-term keys of the parties participating in the protocol are revealed to the adversary, s/he cannot obtain the values of the temporary session keys that were used in the previous meetings. There is a concept of backward secrecy in security discussions, which means that if the main and long-term keys of the parties participating in the protocol are revealed to the attacker, s/he will not be able to obtain the values of the temporary session keys used in future meetings. A protocol that has both backward and forward secrecy properties is called a perfect secure protocol.

By using the Compromise version of the Scyther, the security of the discussed protocol can be seen in the following attacks:

• Suppose that the long-term key is revealed to the adversary, what attack scenarios are the protocol vulnerable to?
• Assume the session key is exposed, what attack scenarios are the protocol vulnerable to?
• Suppose that the protocol state is exposed, what attack scenarios are the protocol vulnerable to?

Security Claims of Scyther Tool:

Security goals in each application are defined as three important principles of confidentiality, integrity, and availability. In the Scyther tool, the designers have used these three important principles in the form of two properties, Secrecy and Authentication, with the following definitions:

Secrecy: states that certain confidential and secret information will not be revealed to the adversary. Different forms of secrecy can be defined by subtle differences. In the Scyther tool, a secrecy claim event is written as an example $claim(R,Secret,S)$, which is executed in the role of R, which includes the expression S as a secret parameter. This assertion states whether, for all implementations of the protocol role, the S statement remains secret, i.e., it remains unknown to the adversary or not. There is another security claim related to secrecy which is $SKR$. If we assume that we want to verify the confidentiality of the S in the role of I with this claim, we should write $Claim(I,SKR,S)$. The purpose of this assertion is to consider the desired parameter as a session key. The result of this issue is that by using the Reveal session-key rule that exists in the Compromise version of the Scyther tool, the secret parameter phrase written in the $SKR$ claim, i.e., S, is considered as the session key. It should be noted that if the Reveal session-key rule is not active in the Compromise version of the Scyther tool, the $SKR$ claim works the same as the $Secret$ claim.

Authentication: The most studied security feature in the field of security protocol analysis is authentication. However, contrary to the claim of confidentiality, there is no general consensus on the meaning of authentication. In fact, as Lowe showed in [21], there is a hierarchy of authentication features. Authentication focuses on the fact that the implementation of a protocol role actually guarantees that there is at least one communication partner in the network. In most cases, we want to establish a stronger objective, i.e., that the intended partner is aware of our communication and that a protocol is being implemented, and that messages have been exchanged as expected and according to the protocol. These hierarchies are expressed as $Aliveness$, $Synchronization$, and $Agreement$ properties in the Scyther tool. The interested reader can refer to [21,22] to learn more about these security claims.

To verify the security of LLAKEP${}^{+}$ formally, we used Scyther tool [23]. For this purpose, the protocol is first modeled in SPDL, and then its security is evaluated. The SPDL code and the security verification results are depicted in Appendix A and Figure 5, respectively, which confirms the security of the proposed protocol.

Figure 5. Security verification results of LLAKEP${}^{+}$ on Scyther.

5.2.2. Formal Security Analysis in RoR Model

Assume that two parties want to share a session key $sk$ using an authenticated key agreement protocol, as proposed by Abdola et al. [24]. In such a protocol, those parties use long-term secrets along with ephemeral values to genera $Sk$. In our case, we consider the parties to be EBR and BSS. The adversary $\mathcal{A}$ seeks to distinguish between a real protocol ($RP$) and a random protocol or world ($RW$). To determine its ability, on distinguishing a real protocol from a random one, a bit (b) is chosen randomly at the beginning of the experiment, where $b=0$ defines the random world ($RW$) and $b=1$ represents the real protocol or world. Following the proposed adversary’s model in Section 2.3, $\mathcal{A}$ can do several query types, also see  [24,25], to distinguish the real world from the random world. The first query type, $\mathrm{Exe}$, represents a passive adversary $\mathcal{A}$. The second query is $\mathrm{Send}$, which represents an active opponent $\mathcal{A}$. The last query is $\mathrm{Reveal}$, which outputs the session key held by a party. Finally, if $b=1$, $\mathrm{Test}$ returns the session key; otherwise, it returns a random key of the same size. The adversary returns its decision as $b_0$ at the end of the game and wins if $b_0=b$, where b is the hidden bit used in $\mathrm{Test}$. $Ad{v}_{\mathcal{D},\mathcal{P}}^{RoR}(t,R)$, which defines the semantic security in the real-or-random (RoR) model, is defined as follows:

$$\begin{array}{ccc}\hfill Ad{v}_{RW\to RP}^{RoR}& =& \left((Pr(\mathcal{A}\to b_0=1:b=1)-\left(Pr(\mathcal{A}\to b_0=1:b=0)\right)\right)\hfill \end{array}$$

If the adversary’s advantage to win this game is negligible, the target protocol provides RoR semantic security, i.e.:

$$Ad{v}_{RW\to RP}^{RoR}<\epsilon (.)$$

and $\epsilon (.)$ is some negligible function of the protocol’s parameters [25].

To bound the security level of LLAKEP${}^{+}$, we use the above-mentioned Real or Random (RoR) model. This model bounds the adversary’s advantage to distinguish between two worlds, the random world (RW) in which all protocol messages are randomly generated but respecting the message structure of the target protocol and the real world in which those messages are generated by entities in the real protocol (RP), i.e., LLAKEP${}^{+}$ in this case. Following the given model in Figure 6, two worlds are considered. The left world is LLAKEP${}^{+}$ in which the messages are generated using secure cryptographic primitives, i.e., one-way hash function and ECC, and the right world in which a simulator is negotiating with a random oracle (RO) to adapt the response to the LLAKEP${}^{+}$’s structure. Besides that, the adversary can query directly to a one-way hash function or ECC independently in each world. However, in the real world, the responses are computed by the queried cryptographic primitive, while in the random world, RO returns a random value of proper length.

Figure 6. Real or Random (RoR) model; RP: Real Protocol, Sim: Simulator; RO: Random Oracle.

Theorem 1. 

Let $q_{EST}$, $q_H$, and $q_{ECC}$, respectively, represent the number of queries to $RP$/$RW$ of the form $\mathrm{Exe}$, $\mathrm{Send}$ and $\mathrm{Test}$, $H(·)$ and ECC, then considering a polynomial-time adversary’s advantage (Adv) to distinguish these worlds is bounded as follows:

$$\begin{array}{ccc}\hfill Ad{v}_{RW\to RP}^{RoR}& \le & Ad{v}_H^{(q_H+6\times q_{EST})}+Ad{v}_{ECC}^{(q_{ECC}+4\times q_{EST})}\hfill \end{array}$$

where $Ad{v}_H^q$ and $Ad{v}_{ECC}^q$, respectively, denote the adversary’s maximum advantage to distinguish the employed one-way hash function from a random oracle and solve ECDLP or EC-CDHP.

Proof. 

We consider an EBR that is communicating with BSS to be sharing a session key, $sk$, and an adversary, $\mathcal{A}$, aims to compromise the semantic security of $RP$ in the real-or-random model. Flowing [25,26], we follow a game-based approach to prove the theorem, and $\mathcal{A}$ wins the game if it can distinguish $RW$ from $RP$ with a non-negligible probability. Through the proof, a series of games are considered, starting with $RW$ and ending with $RP$. The adversary’s advantage while transient from the ith game (${\mathcal{G}}_i$) to the $i+1^{th}$ game ($G_{i+1}$) is computed as the event $Ad{v}_{{\mathcal{G}}_i\to {\mathcal{G}}_{i+1}}^{RoR}$ on the term of the number of queries. Since the simulator keeps the structure of the messages identical, it is not possible to trivially distinguish $RW$ from $RP$, for example, due to timestamps.

Game ${\mathcal{G}}_0.$ It defines the “random world” ($RW$). Assuming $\left|H\left(x\right)\right|=n_1$ and $|x·G|=n_2$, in this game, the simulator returns the following values on a run of the protocol: $T_{MC}$ which is selected properly, $R_{EBR}\stackrel{\$}{\leftarrow }{\{0,1\}}^{n_2}$, $Aut{h}_{EBR}\stackrel{\$}{\leftarrow }{\{0,1\}}^{n_1}$, $R_{BSS}\stackrel{\$}{\leftarrow }{\{0,1\}}^{n_2}$ and $Aut{h}_{BSS}\stackrel{\$}{\leftarrow }{\{0,1\}}^{n_1}$ and $V_{EBR}\stackrel{\$}{\leftarrow }{\{0,1\}}^{n_1}$. On query x to $H(·)$ the simulator returns $H\left(x\right)\stackrel{\$}{\leftarrow }{\{0,1\}}^{n_1}$ and on query x to $ECC(·)$ it returns $x·G\stackrel{\$}{\leftarrow }{\{0,1\}}^{n_2}$. Then $(R_{EBR},T_{MC},Aut{h}_{EBR},R_{BSS},Aut{h}_{BSS},V_{EBR})$ are returned.

Game ${\mathcal{G}}_1.$ In this game, we assume that when querying x to $H(·)$ or $ECC(·)$, the behavior remains identical to $G_0$. However, on a run of the protocol, the $T_{MC}$ is selected properly, $x_1\stackrel{\$}{\leftarrow }{\{0,1\}}^{n_2}$ and $R_{EBR}\leftarrow ECC\left(x_1\right)$, $y_1\stackrel{\$}{\leftarrow }{\{0,1\}}^{*}$ and $Aut{h}_{EBR}\stackrel{}{\leftarrow }H\left(y_1\right)$, $x_2\stackrel{\$}{\leftarrow }{\{0,1\}}^{n_2}$ and $R_{BSS}\leftarrow ECC\left(x_1\right)$, $y_2\stackrel{\$}{\leftarrow }{\{0,1\}}^{*}$ and $Aut{h}_{BSS}\stackrel{}{\leftarrow }H\left(y_2\right)$ and $y_3\stackrel{\$}{\leftarrow }{\{0,1\}}^{*}$ and $V_{EBR}\stackrel{}{\leftarrow }H\left(y_3\right)$. Then $(R_{EBR},T_{MC},Aut{h}_{EBR},R_{BSS},$$Aut{h}_{BSS},V_{EBR})$ are returned. Given that the inputs of $H(·)$ and $ECC(·)$ are selected randomly and they also return random values on the given input, $Ad{v}_{{\mathcal{G}}_0\to {\mathcal{G}}_1}^{RoR}=0$.

Game ${\mathcal{G}}_2.$ In this game, $H(·)$ is instantiated by the real one-way hash function. However, the rest of the game remains identical. Therefore, ${\mathcal{G}}_2$ is identical to ${\mathcal{G}}_1$ as long as $H(·)$ behaves similarly to a random oracle. However, in reality, most of the hash functions are distinguishable from a random function if there is a collision at their output, for instance. On the other hand, each call to the protocol includes three calls to $H(·)$. If the adversary’s advantage to distinguish the instantiated hash function from random oracle after q queries is denoted by $Ad{v}_H^q$, then

$$Ad{v}_{{\mathcal{G}}_1\to {\mathcal{G}}_2}^{RoR}=Ad{v}_H^q=Ad{v}_H^{(q_H+3\times q_{EST})}$$

where $q_H$ and $q_{EST}$, respectively, denote the total calls to $H(·)$ and a call to the protocol.

Game ${\mathcal{G}}_3.$ In this game, $ECC(·)$ is instantiated by the ECC point multiplication. For example, $x_1\stackrel{\$}{\leftarrow }{\{0,1\}}^{n_2}$ and $R_{EBR}\leftarrow ECC\left(x_1\right)$. However, the rest of the game remains identical. Therefore, ${\mathcal{G}}_3$ is identical to ${\mathcal{G}}_2$ as long as ECDLP or EC-CDHP remains unsolved. In addition, each call to the protocol includes two calls to $ECC(·)$. So, if the adversary’s advantage is to solve ECDLP or EC-CDHP, which is used to distinguish the instantiated ECC from a random oracle, after q queries, as denoted by $Ad{v}_{ECC}^q$, then

$$Ad{v}_{{\mathcal{G}}_2\to {\mathcal{G}}_3}^{RoR}=Ad{v}_{ECC}^q=Ad{v}_{ECC}^{(q_{ECC}+2\times q_{EST})}$$

where $q_{ECC}$ denotes the total calls to $ECC(·)$.

Game ${\mathcal{G}}_4.$ In this game, a constant value is selected as $HID$. Then, on each query, $y_1\stackrel{\$}{\leftarrow }{\{0,1\}}^{*}$ and $Aut{h}_{EBR}\stackrel{\$}{\leftarrow }HID\oplus H\left(y_1\right)$. The rest of the game remains identical to ${\mathcal{G}}_3$. Since the XOR of a constant value to a random value returns a random value, ${\mathcal{G}}_4$ behaves identically to ${\mathcal{G}}_3$, assuming the hash function behaves randomly. Therefore

$$Ad{v}_{{\mathcal{G}}_3\to {\mathcal{G}}_4}^{RoR}=Ad{v}_H^{\left(q_{EST}\right)}$$

Game ${\mathcal{G}}_5.$ In this game $K_{MC}\stackrel{\$}{\leftarrow }{\{0,1\}}^{n_2}$ and $R_{EBR}\leftarrow K_{MC}·G$, $y_1\stackrel{\$}{\leftarrow }{\{0,1\}}^{*}$ and $Aut{h}_{EBR}\stackrel{}{\leftarrow }H\left(y_1\right)$. Clearly, ${\mathcal{G}}_5$ is indistinguishable from ${\mathcal{G}}_4$ if $k_{MC}·p{k}_{BSS}\parallel T_{MC}$ is indistinguishable from $y_1\stackrel{\$}{\leftarrow }{\{0,1\}}^{*}$, which happens as long as ECC remains unaffected due to the expected random behavior of $k_{MC}·p{k}_{BSS}$ and $K_{MC}·G$. Hence

$$Ad{v}_{{\mathcal{G}}_4\to {\mathcal{G}}_5}^{RoR}=Ad{v}_{ECC}^{\left(q_{EST}\right)}$$

Game ${\mathcal{G}}_6.$ In this game, we change the computation on the BSS side compatible with the real world. More precisely, $k_{BSS}\stackrel{\$}{\leftarrow }{\{0,1\}}^{n_2}$ and $R_{BSS}=k_{BSS}·G$ and $sk=H(k_{BSS}·R_{EBR}\parallel k_{BSS}·p{k}_{EBR}\parallel s{k}_{BSS}·R_{EBR})$ and $Aut{h}_{BSS}=H(R_{BSS}\parallel T_{MC}\parallel sk)$. Following this modification, ${\mathcal{G}}_6$ is indistinguishable from ${\mathcal{G}}_5$ if $y_2\stackrel{\$}{\leftarrow }{\{0,1\}}^{*}$ and $R_{BSS}\parallel T_{MC}\parallel H(k_{BSS}·R_{EBR}\parallel k_{BSS}·p{k}_{EBR}\parallel s{k}_{BSS}·R_{EBR})$ are indistinguishable. Hence

$$Ad{v}_{{\mathcal{G}}_5\to {\mathcal{G}}_6}^{RoR}=Ad{v}_H^{{\left(q_{EST}\right)}_{ECC}+Ad{v}^{(}{q}_{EST})}$$

Game ${\mathcal{G}}_7.$ In this game, we make the final computation on the EBR’s side compatible with the real world. More precisely, $sk=H(k_{MC}·R_{BSS}\parallel s{k}_{EBR}·R_{EBR}\parallel k_{MC}·p{k}_{BSS})$, and  $V_{EBR}=H(sk\parallel T_{MC}\parallel HID)$. Following this modification, ${\mathcal{G}}_7$ is indistinguishable from ${\mathcal{G}}_6$ if $y_3\stackrel{\$}{\leftarrow }{\{0,1\}}^{*}$ and $sk\parallel T_{MC}\parallel HID$ are indistinguishable. Hence

$$Ad{v}_{{\mathcal{G}}_6\to {\mathcal{G}}_7}^{RoR}=Ad{v}_H^{\left(q_{EST}\right)}$$

Game ${\mathcal{G}}_8.$ This game is identical to the real world, which is identical to ${\mathcal{G}}_7$ actually, and consequently:

$$Ad{v}_{{\mathcal{G}}_7\to {\mathcal{G}}_8}^{RoR}=0$$

Finally, it is obvious:

$$\begin{array}{ccc}\hfill Ad{v}_{RW\to RP}^{RoR}& \le & Ad{v}_{{\mathcal{G}}_0\to {\mathcal{G}}_1}^{RoR}+Ad{v}_{{\mathcal{G}}_1\to {\mathcal{G}}_2}^{RoR}+Ad{v}_{{\mathcal{G}}_2\to {\mathcal{G}}_3}^{RoR}+Ad{v}_{{\mathcal{G}}_3\to {\mathcal{G}}_4}^{RoR}+\hfill \\ & & Ad{v}_{{\mathcal{G}}_4\to {\mathcal{G}}_5}^{RoR}+Ad{v}_{{\mathcal{G}}_5\to {\mathcal{G}}_6}^{RoR}+Ad{v}_{{\mathcal{G}}_6\to {\mathcal{G}}_7}^{RoR}+Ad{v}_{{\mathcal{G}}_7\to {\mathcal{G}}_8}^{RoR}\hfill \end{array}$$

which gives

$$\begin{array}{ccc}\hfill Ad{v}_{RW\to RP}^{RoR}& \le & 0+Ad{v}_H^{(q_H+3\times q_{EST})}+Ad{v}_{ECC}^{(q_{ECC}+2\times q_{EST})}+Ad{v}_H^{\left(q_{EST}\right)}+\hfill \\ & & Ad{v}_{ECC}^{\left(q_{EST}\right)}+Ad{v}_{ECC}^{\left(q_{EST}\right)}+Ad{v}_H^{\left(q_{EST}\right)}+Ad{v}_H^{\left(q_{EST}\right)}+0\hfill \\ & \le & Ad{v}_H^{(q_H+6\times q_{EST})}+Ad{v}_{ECC}^{(q_{ECC}+4\times q_{EST})}\hfill \end{array}$$

which completes the proof.    □

For example, the adversary’s advantage to find a collision in a hash function after q-queries is bounded by $\frac{q^2}{2^{n_1}}$ and its advantage to ECDLP or EC-CDHP is $\frac{q^2}{2^{n_2}}$. For $n_1=n_2=256$, the adversary’s advantage after $q_{EST}$ queries is at most $\frac{36\times q_{EST}^2+16\times q_{EST}^2}{2^{256}}=\frac{52\times q_{EST}^2}{2^{256}}$. Hence, for these parameters, the provable security bound is almost 122 bits.

5.3. Cost Analysis

Through computational comparison, we designate the cost of ECC point multiplication and the one-way hash function by $T_{em}$ and $T_H$, respectively. Following [27], on a system with 2.20 GHz processor, Pentium dual core E2200, and 2 GB RAM, $T_{em}\cong 2.226$ ms and $T_H\cong 0.0023$ ms.

The computational expenditures of LLAKEP${}^{+}$ and some related protocols, such as LLAKEP, are compared in Table 2 and depicted in Figure 7. The communication overhead (number of transmitted bits) comparison is also offered in Table 2, where the bit lengths of a timestamp, an identifier, a random number, a hash value, and an ECC point are, respectively, 32, 64, 128, 160, and 320 bits. It should be mentioned that we are considering SHA-256 but limiting its output to 160 bits to avoid the current security issues in SHA-1.

Table 2. Cost comparison of LLAKEP${}^{+}$ and other related protocols.

Protocol	Primitives Call	Computations (ms)	Communication (bit)
[28]	$10\times T_H+8\times T_{em}$	17.831	1440 bits
[29]	$5\times T_H+9\times T_{em}$	20.0455	1632 bits
[30]	$11\times T_H+9\times T_{em}$	20.0593	1600 bits
[31]	$8\times T_H+9\times T_{em}$	20.0524	1344 bits
[9]	$12\times T_H+6\times T_{em}$	13.3836	1187 bits
LLAKEP${}^{+}$	$11\times T_H+8\times T_{em}$	17.8333	1152 bits

Figure 7. Comparison of LLAKEP${}^{+}$ and related protocols ([AN,2018] [28], [HWK+,2016] [29], [WXL+,2019] [30], [GKK+,2020] [31], and [ZHY+,2022] [9]) in the term of computation and communication cost, the cost of kdf considered equal to a call to hash function.

According to the findings of Table 2 and Figure 7, LLAKEP${}^{+}$ has the lowest communication overhead and is among the fastest in terms of computational cost. Although LLAKEP is 25% faster than LLAKEP${}^{+}$; however, it does not provide perfect security following the provided arguments in Section 3. In addition, LLAKEP${}^{+}$ has the lowest communication cost among those protocols.

6. Conclusions

In this paper, we focused on the security of LLAKEP, an authenticated key agreement protocol for Energy Internet of Things (EIoT) applications. Our security analysis should be viewed as a supplement to the designers’ security analysis, with a focus on its provable security. Our findings, however, indicate that this protocol has security weaknesses such as traceability, a dictionary, stolen smart glasses, known session-specific temporary information, key compromise impersonation attacks, and a lack of perfect forward secrecy.

Furthermore, we demonstrated that LLAKEP has some efficiency issues. To overcome the LLAKEP vulnerabilities, we suggested the LLAKEP${}^{+}$ protocol. We employed the same set of cryptographic primitives in the proposed protocol, namely the one-way hash function and ECC point multiplication. Our comprehensive security investigation demonstrates its resistance to different threats such as impersonation, privileged insider assaults, and stolen smart glass attacks. It also provides forward secrecy and user anonymity and is resistant to sophisticated attacks such as KCI and KSTI.