Next Article in Journal
A Novel Deep Reinforcement Learning Based Framework for Gait Adjustment
Next Article in Special Issue
Lattice Enumeration with Discrete Pruning: Improvements, Cost Estimation and Optimal Parameters
Previous Article in Journal
Measure of Similarity between GMMs Based on Geometry-Aware Dimensionality Reduction
Previous Article in Special Issue
A Delegation Attack Method on Attribute-Based Signatures and Probable Solutions
 
 
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

Secure Authentication in the Smart Grid

by
Mehdi Hosseinzadeh
1,2,3,†,
Rizwan Ali Naqvi
4,†,
Masoumeh Safkhani
5,6,†,
Lilia Tightiz
7,* and
Raja Majid Mehmood
8,*
1
Institute of Research and Development, Duy Tan University, Da Nang 550000, Vietnam
2
School of Medicine and Pharmacy, Duy Tan University, Da Nang 550000, Vietnam
3
Computer Science, University of Human Development, Sulaymaniyah 0778-6, Iraq
4
School of Intelligent Mechatronics Engineering, Sejong University, Seoul 05006, Republic of Korea
5
Faculty of Computer Engineering, Shahid Rajaee Teacher Training University, Tehran 16788-15811, Iran
6
School of Computer Science, Institute for Research in Fundamental Sciences (IPM), P.O. Box 19395-5746, Tehran 16788-15811, Iran
7
School of Computing, Gachon University, 1342 Seongnamdaero, Seongnam 13120, Republic of Korea
8
Information and Communication Technology Department, School of Computing and Data Science, Xiamen University Malaysia, Sepang 43900, Malaysia
*
Authors to whom correspondence should be addressed.
These authors contributed equally to this work.
Mathematics 2023, 11(1), 176; https://doi.org/10.3390/math11010176
Submission received: 1 December 2022 / Revised: 21 December 2022 / Accepted: 23 December 2022 / Published: 29 December 2022
(This article belongs to the Special Issue Frontiers in Network Security and Cryptography)

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.
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.

2.2. Elliptic Curve Cryptography

Given a curve y 2 = x 3 + a · x + b , a distinguished point at infinity O , and a prime number q, the Elliptic Curve Cryptography (ECC) E F q is defined as an additive group G over the finite field F q including the set of all ( x , y ) F q × F q such that λ 2 = μ 3 + a μ + b , where a , b F q and 4 a 3 + 27 b 2 m o d q 0 , along with O . The order of G has been defined by the size of the subgroup, which is defined as the smallest positive number n such that n · G = O , G is the generator of this subgroup [10].
Regarding the security of ECC, for large values of n, given any natural scalar a 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 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.
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 B S S , H 1 ( · ) , H 2 ( · ) } , where p k B S S = s k B S S · G .

2.6. User Registration

User registration is required to register an electric bike rider (EBR) in BSS. EBR inputs I D E B R and P W E B R on the smart glass, which includes a microchip MC, during this protocol step. The MC generates random numbers a M C and b M C and computes H I P = H 2 ( I D E B R P W E B R ) , v = H I P a M C , d = H I P b M C and C = H 2 ( I D E B R P W E B R a M C ) . Next, using a secure channel, EBR submits { p k E B R , I D E B R , d } to BSS.
BSS checks the uniqueness of I D E B R and H 2 ( I D E B R ) after receiving the message then it computes l = H 1 ( s k B S S ) d H 2 ( s k B S S I D E B R ) , stores { H 2 ( s k B S S I D E B R ) , I D E B R } and sends l to EBR.
On the other hand, EBR calculates l = l b M C = H 1 ( s k B S S ) H I P H 2 ( s k B S S I D E B R ) 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 S K as shown in Figure 3:
  • The EBR user enters its I D E B R and P W E B R on the smart glass. MC computes H I P = H 2 ( I D E B R P W E B R ) , a M C = H I P v , and verifies whether C = ? H 2 ( I D E B R P W E B R a M C ) . Assuming that verification was successful, MC generates a random number r M C and computes U E B R = r M C + s k E B R , R = r M C · p k B S S , C I D E B R = l H I P = H 1 ( s k B S S ) H 2 ( s k B S S I D E B R ) and A u t h E B R = H 2 ( I D E B R R C I D E B R T M C ) , where T M C is the current timestamp. Next, using a public channel, EBR sends { A u t h E B R , C I D E B R , U E B R , T M C } to BSS.
  • Once received the message, BSS verifies T M C , calculates H 2 ( s k B S S I D E B R ) = C I D E B R H 1 ( s k B S S ) and R E B R = U E B R · G p k E B R = r M C · G and R * = s k B S S · R E B R and verifies whether A u t h E B R = ? H 2 ( I D E B R R * C I D E B R T M C ) . Next, it generates a random number r B S S and computes R B S S = r B S S · G , S K B S S = r B S S · R E B R and A u t h B S S = H 2 ( I D E B R R * S K B S S T B S S ) , where T B S S is the current timestamp. Next, using a public channel, BSS sends { A u t h B S S , R B S S , T B S S } to EBR.
  • EBR verifies T B S S , calculates S K E B R = r M C · R B S S and verifies whether A u t h B S S * = ? H 2 ( I D E B R R S K E B R T B S S ) to authenticate BSS. After successful authentication, EBR calculates s k = k d f ( I D E B R S K E B R T M C T B S S ) and A u t h E B = H 2 ( I D E B R R s k T M C ) , where  T M C is the current timestamp. Next, using a public channel, EBR sends { A u t h E B , T M C } to BSS.
  • BSS verifies T M C and computes s k = k d f ( I D E B R S K B S S T M C T B S S ) and checks whether A u t h E B = ? H 2 ( I D E B R R * s k T M C ) to authenticate EBR and store the session key s k , 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 E B R and P W E B R on the smart glass. MC computes H I P = H 2 ( I D E B R P W E B R ) , a M C = H I P v , and verifies whether C = ? H 2 ( I D E B R P W E B R a M C ) to authenticate EBR. If authentication was successful; MC requests EBR to provide a new password P W n e w . Then it computes H I P n e w = H 2 ( I D E B R P W n e w ) , v n e w = H I P n e w a M C , n e w = H I P n e w b M C , C n e w = H 2 ( I D E B R P W n e w a M C ) and l n e w = l H I P H I P n e w = H 1 ( s k B S S ) H I P n e w H 2 ( s k B S S I D E B R ) . At the end, EBR stores l n e w along v n e w and C n e w 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 E B R and P W E B R . 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 = H 1 ( s k B S S H I P H 2 ( s k B S S I D E B R ) ) , v = H I P a M C , and  C = H 2 ( I D E B R P W E B R a M C ) , where H I P = H 2 ( I D E B R P W E B R ) .
The transferred messages over the public channel are as follows, besides timestamps:
A u t h E B R = H 2 ( I D E B R R C I D E B R T M C ) C I D E B R = l H I P = H 1 ( s k B S S ) H 2 ( s k B S S I D E B R ) U E B R = r M C + s k E B R A u t h B S S = H 2 ( I D E B R R S K B S S T B S S ) R B S S = r B S S · G A u t h E B = H 2 ( I D E B R R s k T M C )
where R = s k B S S · r M C · G and S K B S S = r B S S · r M C · G . Since a M C is a random number, the adversary cannot receive low-entropy information from v and C. On the other hand, s k B S S is the private key of BSS, and, due to that, l 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 from reading the smart glass’s memory and also eavesdrops on C I D E B R = l H I P from the public channel. Hence, the adversary achieves H I P = C I D E B R l . Assuming that the entropy of I D E B R and P W E B R is, respectively, H I D and H P W , then the expected complexity to drive I D E B R and P W E B R using dictionary attack is 2 H I D + H P W .
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 E B R , I D E B R , d } to BSS, where d = H I P b M C . Let’s assume the adversary also eavesdrops on a session and steals the smart glass. Given the transferred messages over the public channel, H I P = H 2 ( I D E B R P W E B R ) is achieved, and the expected complexity of extracting P W E B R using a dictionary attack is 2 H P W . Given I D E B R and P W E B R , 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 H I D + H P W , 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 { A u t h E B R , C I D E B R , U E B R , T M C } to BSS, where C I D E B R = H 1 ( s k B S S ) H 2 ( s k B S S I D E B R ) . 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, E B R i , and BSS and saved C I D E B R i , assuming that it monitors another session between the ith user, E B R i , and BSS, if  C I D E B R i C I D E B R j then E B R i E B R j and if C I D E B R i = C I D E B R j then E B R i = E B 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 M C and r B S S , as well as the messages transferred over the public channel. The message transferred from EBR to BSS includes U E B R = r M C + s k E B R , and given r M C , the adversary achieves s k E B R = U E B R r M C , which is EBR’s secret key. Given r M C , the adversary also computes R = r M C · G . A u t h E B R = H 2 ( I D E B R R C I D E B R T M C ) , on the other hand, is also available from the public channel, and  I D E B R has low entropy, e.g.,  H I D . As a result, the adversary can extract I D E B R with a complexity of 2 H I D . The session key is computed as s k = k d f ( I D E B R S K E B R T M C T B S S ) and S K E B R = r M C · R B S S and R B S S 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 H I D , 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 E B R , s k E B R and C I D E B R = H 1 ( s k B S S ) H 2 ( s k B S S I D E B R ) . It is obvious that the adversary can do the following:
  • The adversary generates a random number r a d v and computes U E B R = r a d v + s k E B R , R a d v = r a d v · p k B S S and A u t h E B R = H 2 ( I D E B R R C I D E B R T a d v ) , where T a d v is the current timestamp. Next, using a public channel, the adversary sends { A u t h E B R , C I D E B R , U E B R , T M C } to BSS.
  • Obviously T M C and A u t h E B R are accepted by B S S and R a d v = r a d v · p k B S S is extracted by BSS from the received U E B R = r a d v + s k E B R . Next, it generates a random number r B S S and computes R B S S = r B S S · G , S K B S S = r B S S · R a v d and A u t h B S S = H 2 ( I D E B R R a d v S K B S S T B S S ) and sends { A u t h B S S , R B S S , T B S S } to EBR (impersonated by the adversary).
  • The adversary calculates S K a d v = r a d v · R B S S , s k = k d f ( I D E B R S K a d v T a d v T B S S ) and A u t h a d = H 2 ( I D E B R R a d v S K a d v T a d v ) , where T a d v is the current timestamp. Next, using a public channel, the adversary sends { A u t h a d , T a d v } to BSS.
  • BSS verifies T a d v , calculates s k = k d f ( I D E B R S K B S S T M C T B S S ) and verifies whether A u t h a d = ? H 2 ( I D E B R R a d v s k T M C ) to authenticate EBR/adversary and store the session key s k , which is used for the secure communication between EBR/adversary and BSS.
Since S K B S S = r B S S · R a d v = r B S S · r a d v · G = r a d v · R B S S = S K a d v , the authentication is completed successfully which confirms the impersonation attack on LLAKEP.

3.2. Key Compromised Impersonation Attack

Assume a client C is in contact with a server S . Assuming that all the secret parameters of C (resp. S ) are given to the adversary, the adversary should not be able to impersonate S (resp. C ) toward C (resp. 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 = H 1 ( s k B S S ) H I P H 2 ( s k B S S I D E B R ) , v = H I P a M C , C = H 2 ( I D E B R P W E B R a M C ) , where H I P = H 2 ( I D E B R P W E B R ) , the  user’s credentials which are I D E B R and P W E B R and the stored information in the MC’s memory which is s k E B R . The adversary does the following to impersonate BSS:
  • The EBR user enters its I D E B R and P W E B R on the smart glass. MC verifies them, generates a random number r M C and computes U E B R = r M C + s k E B R , R = r M C · p k B S S , C I D E B R = l H I P = H 1 ( s k B S S ) H 2 ( s k B S S I D E B R ) and A u t h E B R = H 2 ( I D E B R R C I D E B R T M C ) and sends { A u t h E B R , C I D E B R , U E B R , T M C } to BSS.
  • The adversary extracts r M C = U E B R s k E B R , computes R E B R = r M C · G and R * = r M C · p k B S S , generates a random number r a d v , computes R a d v = r a d v · G , S K a d v = r a d v · R E B R and A u t h a d v = H 2 ( I D E B R R S K a d v T a d v ) and sends { A u t h a d v , R a d v , T a d v } to EBR.
  • EBR verifies T a d v , calculates S K E B R = r M C · R a d v and verifies whether A u t h a d v * = ? H 2 ( I D E B R R S K E B R T a d v ) 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 M C i , T B S S i and T M C i :
A u t h E B R = H 2 ( I D E B R R C I D E B R T M C i ) C I D E B R = H 1 ( s k B S S ) H 2 ( s k B S S I D E B R ) U E B R i = r M C i + s k E B R A u t h B S S = H 2 ( I D E B R R i S K B S S T B S S i ) R B S S i = r B S S i · G A u t h E B = H 2 ( I D E B R R s k i T M C i )
where s k i = k d f ( I D E B R S K B S S T M C i T B S S i ) and S K B S S = r M C i · R B S S i . Obviously, given U E B R i = r M C i + s k E B R , R B S S i and s k E B R , the adversary is able to compute r M C i = U E B R i s k E B R and S K B S S = r M C i · R B S S i . Next, given the revealed I D E B R , the eavesdropped T M C i and T B S S i and the computed S K B S S the adversary can extract the session key of the ith session, i.e.,  s k = k d f ( I D E B R S K B S S T M C i T B S S 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 B S S I D E B R ) , I D E B R } during the LLAKEP registration phase, and during the authentication phase, EBR sends C I D E B R = l H I P = H 1 ( s k B S S ) H 2 ( s k B S S I D E B R ) as a part of the message, which is used to identify the target E B R ’s records. In this regard, BSS first computes H 1 ( s k B S S ) C I D E B R = H 2 ( s k B S S I D E B R ) and searches its database for related records. This means that BSS should compute this value for all authentications. However, if it stores H 1 ( s k B S S ) H 2 ( s k B S S I D E B R ) in the registration phase rather than { H 2 ( s k B S S I D E B R ) } , 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 E B R to BSS in plain text. Furthermore, we avoid using U E B R = r M C + s k E B R 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 B S S , H ( · ) } , where p k B S S = s k B S S · 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 G ’s basis point G, and the output of H ( · ) may be transformed to an integer in 0 , , 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 E B R and P W E B R as randomly as possible and enters them into the smart glass containing a microchip MC. The embedded MC generates a random number a M C and computes H I D = H ( I D E B R a M C ) . Next, using a secure channel, EBR submits { p k E B R , H I D } to BSS. It selects a random integer k [ 1 , n 1 ] and calculates k · G = ( x , y ) and sets r = x m o d n . If  r = 0 , BSS selects another random number. Next it computes s = k 1 ( H I D + r × s k B S S ) m o d n and sends ( r , s ) to EBR. ( H I D , p k E B R ) is stored in a secure Non Volatile Memory (NVM) of BSS also.
Once received ( r , s ) , EBR computes u 1 = H I D × s 1 and u 2 = r × s 1 and ( x 1 , y 1 ) = u 1 · G + u 2 · p k B S S . Next, it verifies whether r = ? x m o d n to confirm the registration. After that, MC computes d = H e ( I D E B R P W E B R ) ( a M C s r ) and v = H ( s r H ( I D E B R P W E B R a M C ) 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 s k to switch batteries, as shown in Figure 4:
  • The EBR user enters its I D E B R and P W E B R on the smart glass. MC computes ( a M C s r ) = H e ( I D E B R P W E B R ) d , and  H I D = H ( I D E B R a M C ) and verifies whether v = ? H ( s r H ( I D E B R P W E B R ) a M C ) to accept the login. If the verification was successful, MC obtains the current time T M C , generates a random number k M C [ 1 , n 1 ] and calculates R E B R = k M C · G and A u t h E B R = H I D H ( k M C · p k B S S T M C ) . Then, it sends ( R E B R , T M C , A u t h E B R ) to BSS over a public channel.
  • BSS validates T M C after receiving the message and calculates H I D = A u t h E B R H ( s k B S S · R E B R T M C ) . If it detects the extracted H I D in its database, BSS generates a random number k B S S [ 1 , n 1 ] and calculates R B S S = k B S S · G , the temporary session key s k = H ( k B S S · R E B R k B S S · p k E B R s k B S S · R E B R ) and A u t h B S S = H ( R B S S T M C s k ) . Then, it sends ( R B S S , A u t h B S S ) to EBR over a public channel.
  • EBR computes the session key, after receiving the message, s k = H ( k M C · R B S S s k E B R · R E B R k M C · p k B S S ) and verifies whether A u t h B S S = ? H ( R B S S T M C s k ) to authenticate BSS. If BSS has been authenticated, EBR returns V E B R = H ( s k T M C H I D ) to BSS.
  • BSS verifies the received V E B R 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 E B R and P W E B R on the smart glass and requests a run of the password change phase. MC computes ( a M C s r ) = H e ( I D E B R P W E B R ) d , and  H I D = H ( I D E B R a M C ) and verifies whether v = ? H ( s r H I D a M C ) to accept the login. Next, the user inputs the new password P W E B R n e w . After that, MC computes d n e w = H e ( I D E B R P W E B R n e w ) ( a M C s r ) and v n e w = H ( s r H ( I D E B R P W E B R n e w ) a M C ) and stores ( d n e w , v n e w ) 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 E B R , T M C , A u t h E B R , R B S S , A u t h B S S , V E B R , where:
R E B R = k M C · G A u t h E B R = H I D H ( k M C · p k B S S T M C ) R B S S = k B S S · G s k = H ( k B S S · R E B R k B S S · p k E B R s k B S S · R E B R ) A u t h B S S = H ( R B S S T M C s k ) V E B R = H ( s k T M C H I D )
and k M C [ 1 , n 1 ] and k B S S [ 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 A u t h E B R = H I D H ( k M C · p k B S S T M C ) , A u t h B S S = H ( R B S S T M C s k ) and V E B R = H ( s k T M C H I D ) 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 E B R , T M C , A u t h E B R , V E B R or R B S S , A u t h B S S such that related A u t h B S S = H ( R B S S T M C s k ) or V E B R = H ( s k T M C H I D ) is also verified by the receiver. Assume the adversary is attempting to impersonate EBR at time T M C . The adversary could do this if it can compute a valid A u t h E B R = H I D H ( k M C · p k B S S T M C ) and return the expected V E B R = H ( s k T M C H I D ) . Assuming the adversary does not have access to H I D or s k E B R , it cannot forge those values. As a result, it cannot compute a valid tuple R E B R , T M C , V E B R to impersonate EBR. Similarly, to impersonate BSS, the adversary must be able to return a valid R B S S , A u t h B S S given the EBR’s challenge tuple ( R E B R , T M C , A u t h E B R ) . To do so, however, the adversary must either have s k B S S 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 E B R = k M C · G and R B S S = k B S S · G are fresh values, A u t h E B R = H I D H ( k M C · p k B S S T M C ) is masked by H ( k M C · p k B S S T M C ) and A u t h B S S = H ( R B S S T M C s k ) and a one-way hash function is used to compute V E B R = H ( s k T M C H I D ) . If the adversary can extract H I D from A u t h E B R ; it will be able to trace the EBR or BSS. To do so, however, the adversary must either have access to s k B S S or compute k M C · p k B S S , as  R E B R = k M C · 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 E B R , P W E B R , H I D and s k E B R , whereas the BSS secret parameter is s k B S S and the shared session key is s k = H ( k B S S · k M C · G k B S S · p k E B R s k B S S · R E B R ) . The attacker clearly cannot get P W E B R from the parameters transmitted over the public channel. The only parameter that contains I D E B R , on the other hand, is H I D = H 2 ( I D E B R a M C ) , which is distinguished by a random value a M C . Furthermore, H I D is masked by H ( k M C · p k B S S T M C ) and cannot be calculated without knowledge of s k B S S or solving the ECDLP issue. s k E B R and s k B S S are also secret keys that only the owner knows about. To compute s k , the adversary must first compute k B S S · k M C · G given k M C · G and k B S S · 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 H I D + H P W for an adversary without access to I D E B R and P W E B R . Assuming H I D = H P W = 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 E B R P W E B R ) ( a M C s r ) and v = H ( s r H ( I D E B R P W E B R a M C ) . To obtain any information, it must guess I D E B R and P W E B R at the same time, which costs 2 H I D + H P W .

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 ( H I D , p k E B R ) sent by the EBR and ( r , s ) sent by the BSS. Although  H I D is valuable information, the adversary cannot use it to extract I D E B R or P W E B R or impersonate EBR since it also requires the secret s k E B R . 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 E B R and s k B S S , 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 s k = H ( k B S S · k M C · G k B S S · p k E B R s k B S S · R E B R ) , where k B S S and k M C are ephemeral session dependent fresh values. Although the adversary has access to k M C · G and k B S S · G , to compute s k , the adversary must first compute k B S S · k M C · 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 B S S and k M C . However, to compute the session key, the adversary must first compute s k B S S · R E B R and s k E B R · R B S S given R E B R = k M C · G , R B S S = k B S S · G , p k E B R and p k B S S 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 B S S in a KCI attack, the adversary must be able to return a valid A u t h B S S = H ( R B S S T M C s k ) . However, the adversary must compute valid s k , which is a factor of s k B S S · R E B R . Given R E B R = k M C · G and p k B S S , solve the ECDLP issue is required to compute s k B S S · R E B R . 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 c l a i m ( R , S e c r e t , 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 S K R . If we assume that we want to verify the confidentiality of the S in the role of I with this claim, we should write C l a i m ( I , S K R , 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 S K R 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  S K R claim works the same as the S e c r e t 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 A l i v e n e s s , S y n c h r o n i z a t i o n , and A g r e e m e n t 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.

5.2.2. Formal Security Analysis in RoR Model

Assume that two parties want to share a session key s k 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 S k . In our case, we consider the parties to be EBR and BSS. The adversary A seeks to distinguish between a real protocol ( R P ) and a random protocol or world ( R W ). 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 ( R W ) and b = 1 represents the real protocol or world. Following the proposed adversary’s model in Section 2.3, A can do several query types, also see  [24,25], to distinguish the real world from the random world. The first query type, Exe , represents a passive adversary A . The second query is Send , which represents an active opponent A . The last query is Reveal , which outputs the session key held by a party. Finally, if  b = 1 , 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 Test . A d v D , P R o R ( t , R ) , which defines the semantic security in the real-or-random (RoR) model, is defined as follows:
A d v R W R P R o R = ( P r ( A b 0 = 1 : b = 1 ) ( P r ( A b 0 = 1 : b = 0 ) )
If the adversary’s advantage to win this game is negligible, the target protocol provides RoR semantic security, i.e.:
A d v R W R P R o R < ε ( . )
and ε ( . ) 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.
Theorem 1. 
Let q E S T , q H , and q E C C , respectively, represent the number of queries to R P / R W of the form Exe , Send and Test , H ( · ) and ECC, then considering a polynomial-time adversary’s advantage (Adv) to distinguish these worlds is bounded as follows:
A d v R W R P R o R A d v H ( q H + 6 × q E S T ) + A d v E C C ( q E C C + 4 × q E S T )
where A d v H q and A d v E C C 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, s k , and an adversary, A , aims to compromise the semantic security of R P in the real-or-random model. Flowing [25,26], we follow a game-based approach to prove the theorem, and  A wins the game if it can distinguish R W from R P with a non-negligible probability. Through the proof, a series of games are considered, starting with R W and ending with R P . The adversary’s advantage while transient from the ith game ( G i ) to the i + 1 t h game ( G i + 1 ) is computed as the event A d v G i G i + 1 R o R 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 R W from R P , for example, due to timestamps.
Game G 0 . It defines the “random world” ( R W ). Assuming | H ( x ) | = n 1 and | x · G | = n 2 , in this game, the simulator returns the following values on a run of the protocol: T M C which is selected properly, R E B R $ { 0 , 1 } n 2 , A u t h E B R $ { 0 , 1 } n 1 , R B S S $ { 0 , 1 } n 2 and A u t h B S S $ { 0 , 1 } n 1 and V E B R $ { 0 , 1 } n 1 . On query x to H ( · ) the simulator returns H ( x ) $ { 0 , 1 } n 1 and on query x to E C C ( · ) it returns x · G $ { 0 , 1 } n 2 . Then ( R E B R , T M C , A u t h E B R , R B S S , A u t h B S S , V E B R ) are returned.
Game G 1 . In this game, we assume that when querying x to H ( · ) or E C C ( · ) , the behavior remains identical to G 0 . However, on a run of the protocol, the  T M C is selected properly, x 1 $ { 0 , 1 } n 2 and R E B R E C C ( x 1 ) , y 1 $ { 0 , 1 } * and A u t h E B R H ( y 1 ) , x 2 $ { 0 , 1 } n 2 and R B S S E C C ( x 1 ) , y 2 $ { 0 , 1 } * and A u t h B S S H ( y 2 ) and y 3 $ { 0 , 1 } * and V E B R H ( y 3 ) . Then ( R E B R , T M C , A u t h E B R , R B S S , A u t h B S S , V E B R ) are returned. Given that the inputs of H ( · ) and E C C ( · ) are selected randomly and they also return random values on the given input, A d v G 0 G 1 R o R = 0 .
Game G 2 . In this game, H ( · ) is instantiated by the real one-way hash function. However, the rest of the game remains identical. Therefore, G 2 is identical to 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 A d v H q , then
A d v G 1 G 2 R o R = A d v H q = A d v H ( q H + 3 × q E S T )
where q H and q E S T , respectively, denote the total calls to H ( · ) and a call to the protocol.
Game G 3 . In this game, E C C ( · ) is instantiated by the ECC point multiplication. For example, x 1 $ { 0 , 1 } n 2 and R E B R E C C ( x 1 ) . However, the rest of the game remains identical. Therefore, G 3 is identical to G 2 as long as ECDLP or EC-CDHP remains unsolved. In addition, each call to the protocol includes two calls to E C C ( · ) . 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 A d v E C C q , then
A d v G 2 G 3 R o R = A d v E C C q = A d v E C C ( q E C C + 2 × q E S T )
where q E C C denotes the total calls to E C C ( · ) .
Game G 4 . In this game, a constant value is selected as H I D . Then, on each query, y 1 $ { 0 , 1 } * and A u t h E B R $ H I D H ( y 1 ) . The rest of the game remains identical to G 3 . Since the XOR of a constant value to a random value returns a random value, G 4 behaves identically to G 3 , assuming the hash function behaves randomly. Therefore
A d v G 3 G 4 R o R = A d v H ( q E S T )
Game G 5 . In this game K M C $ { 0 , 1 } n 2 and R E B R K M C · G , y 1 $ { 0 , 1 } * and A u t h E B R H ( y 1 ) . Clearly, G 5 is indistinguishable from G 4 if k M C · p k B S S T M C is indistinguishable from y 1 $ { 0 , 1 } * , which happens as long as ECC remains unaffected due to the expected random behavior of k M C · p k B S S and K M C · G . Hence
A d v G 4 G 5 R o R = A d v E C C ( q E S T )
Game G 6 . In this game, we change the computation on the BSS side compatible with the real world. More precisely, k B S S $ { 0 , 1 } n 2 and R B S S = k B S S · G and s k = H ( k B S S · R E B R k B S S · p k E B R s k B S S · R E B R ) and A u t h B S S = H ( R B S S T M C s k ) . Following this modification, G 6 is indistinguishable from G 5 if y 2 $ { 0 , 1 } * and R B S S T M C H ( k B S S · R E B R k B S S · p k E B R s k B S S · R E B R ) are indistinguishable. Hence
A d v G 5 G 6 R o R = A d v H ( q E S T ) E C C + A d v ( q E S T )
Game G 7 . In this game, we make the final computation on the EBR’s side compatible with the real world. More precisely, s k = H ( k M C · R B S S s k E B R · R E B R k M C · p k B S S ) , and  V E B R = H ( s k T M C H I D ) . Following this modification, G 7 is indistinguishable from G 6 if y 3 $ { 0 , 1 } * and s k T M C H I D are indistinguishable. Hence
A d v G 6 G 7 R o R = A d v H ( q E S T )
Game G 8 . This game is identical to the real world, which is identical to G 7 actually, and consequently:
A d v G 7 G 8 R o R = 0
Finally, it is obvious:
A d v R W R P R o R A d v G 0 G 1 R o R + A d v G 1 G 2 R o R + A d v G 2 G 3 R o R + A d v G 3 G 4 R o R + A d v G 4 G 5 R o R + A d v G 5 G 6 R o R + A d v G 6 G 7 R o R + A d v G 7 G 8 R o R
which gives
A d v R W R P R o R 0 + A d v H ( q H + 3 × q E S T ) + A d v E C C ( q E C C + 2 × q E S T ) + A d v H ( q E S T ) + A d v E C C ( q E S T ) + A d v E C C ( q E S T ) + A d v H ( q E S T ) + A d v H ( q E S T ) + 0 A d v H ( q H + 6 × q E S T ) + A d v E C C ( q E C C + 4 × q E S T )
which completes the proof.    □
For example, the adversary’s advantage to find a collision in a hash function after q-queries is bounded by q 2 2 n 1 and its advantage to ECDLP or EC-CDHP is q 2 2 n 2 . For  n 1 = n 2 = 256 , the adversary’s advantage after q E S T queries is at most 36 × q E S T 2 + 16 × q E S T 2 2 256 = 52 × q E S T 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 e m and T H , respectively. Following [27], on a system with 2.20 GHz processor, Pentium dual core E2200, and 2 GB RAM, T e m 2.226 ms and T H 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.
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.

Author Contributions

M.H. and R.A.N.: methodology, designing, validation, supervision, review, and editing; M.S.: conceptualization, methodology, validation, writing—review and editing; L.T. and R.M.M.: conceptualization, validation, writing—review and editing and funding. All authors have read and agreed to the published version of the manuscript.

Funding

The Xiamen University Malaysia Research Fund (XMUMRF) (Grant No.: XMUMRF/2022-C9/IECE/0035).

Institutional Review Board Statement

Not applicable.

Informed Consent Statement

Not applicable.

Data Availability Statement

For any supplementary material, please contact the corresponding authors.

Acknowledgments

We appreciate the time and effort that were put forth to review the paper by the anonymous reviewers. We sincerely thank you for your insightful comments and recommendations, which allowed us to increase the manuscript’s quality.

Conflicts of Interest

The authors declare no conflict of interest. The founding sponsors had no role in the design of the study; in the collection, analyses, or interpretation of data; in the writing of the manuscript, and in the decision to publish the results.

Abbreviations

The following abbreviations are used in this manuscript:
IoTInternet of Things
EIoTEnergy Internet of Things
IoDInternet of Drones
IIoTIndustrial Internet of Things
IoVInternet of Vehicles
MIoTMedical Internet of Things
NVMNon Volatile Memory
ITInformation Technology
EBRElectric Bike Riders
BSSBattery Swap Station
MCMicroprocessor Chip
ECCElliptic Curve Cryptography
KSTIKnown Session-specific Temporary Information
KCIKey Compromised Impersonation
MitMMan in the Middle Attack

Appendix A. SPDL Description of the Proposed Protocol

Listing A1: SPDL description of the proposed protocol.
Mathematics 11 00176 i001
Mathematics 11 00176 i002

References

  1. Bolla, R.; Bruschi, R.; Davoli, F.; Cucchietti, F. Energy Efficiency in the Future Internet: A Survey of Existing Approaches and Trends in Energy-Aware Fixed Network Infrastructures. IEEE Commun. Surv. Tutor. 2011, 13, 223–244. [Google Scholar] [CrossRef]
  2. Boccadoro, P.; Striccoli, D.; Grieco, L.A. An extensive survey on the Internet of Drones. Ad Hoc Netw. 2021, 122, 102600. [Google Scholar] [CrossRef]
  3. Franco, J.; Aris, A.; Canberk, B.; Uluagac, A.S. A Survey of Honeypots and Honeynets for Internet of Things, Industrial Internet of Things, and Cyber-Physical Systems. IEEE Commun. Surv. Tutor. 2021, 23, 2351–2383. [Google Scholar] [CrossRef]
  4. Ji, B.; Zhang, X.; Mumtaz, S.; Han, C.; Li, C.; Wen, H.; Wang, D. Survey on the Internet of Vehicles: Network Architectures and Applications. IEEE Commun. Stand. Mag. 2020, 4, 34–41. [Google Scholar] [CrossRef]
  5. Papaioannou, M.; Karageorgou, M.; Mantas, G.; Sucasas, V.; Essop, I.; Rodriguez, J.; Lymberopoulos, D.K. A Survey on Security Threats and Countermeasures in Internet of Medical Things (IoMT). Trans. Emerg. Telecommun. Technol. 2022, 33, e4049. [Google Scholar] [CrossRef]
  6. Ma, Z.; Ma, J.; Miao, Y.; Liu, X.; Choo, K.R.; Gao, Y.; Deng, R.H. Verifiable Data Mining Against Malicious Adversaries in Industrial Internet of Things. IEEE Trans. Ind. Inform. 2022, 18, 953–964. [Google Scholar] [CrossRef]
  7. Gonzalez Granadillo, G.; Zarzosa, S.G.; Diaz, R. Security Information and Event Management (SIEM): Analysis, Trends, and Usage in Critical Infrastructures. Sensors 2021, 21, 4759. [Google Scholar] [CrossRef]
  8. Zhdanova, M. Security and Trust in Safety Critical Infrastructures. Ph.D. Thesis, Technical University of Darmstadt, Darmstadt, Germany, 2022. [Google Scholar]
  9. Zhang, X.; Huang, X.; Yin, H.; Huang, J.; Chai, S.; Xing, B.; Wu, X.; Zhao, L. LLAKEP: A Low-Latency Authentication and Key Exchange Protocol for Energy Internet of Things in the Metaverse Era. Mathematics 2022, 10, 2545. [Google Scholar] [CrossRef]
  10. Lansky, J.; Rahmani, A.M.; Ali, S.; Bagheri, N.; Safkhani, M.; Hassan Ahmed, O.; Hosseinzadeh, M. BCmECC: A Lightweight Blockchain-Based Authentication and Key Agreement Protocol for Internet of Things. Mathematics 2021, 9, 3241. [Google Scholar] [CrossRef]
  11. Rostampour, S.; Safkhani, M.; Bendavid, Y.; Bagheri, N. ECCbAP: A Secure ECC based Authentication Protocol for IoT edge devices. Pervasive Mob. Comput. 2020, 67, 101194. [Google Scholar] [CrossRef]
  12. Dolev, D.; i-Chih Yao, A.C. On the security of public key protocols. IEEE Trans. Inf. Theory 1983, 29, 198–207. [Google Scholar] [CrossRef]
  13. Canetti, R.; Krawczyk, H. Analysis of Key-Exchange Protocols and Their Use for Building Secure Channels. In Advances in Cryptology—EUROCRYPT 2001, International Conference on the Theory and Application of Cryptographic Techniques, Innsbruck, Austria, 6–10 May 2001; Pfitzmann, B., Ed.; Lecture Notes in Computer Science; Springer: Berlin/Heidelberg, Germany, 2001; Volume 2045, pp. 453–474. [Google Scholar] [CrossRef] [Green Version]
  14. Safkhani, M.; Bagheri, N.; Kumari, S.; Tavakoli, H.; Kumar, S.; Chen, J. RESEAP: An ECC-Based Authentication and Key Agreement Scheme for IoT Applications. IEEE Access 2020, 8, 200851–200862. [Google Scholar] [CrossRef]
  15. Limbasiya, T.; Das, D. Lightweight Secure Message Broadcasting Protocol for Vehicle-to-Vehicle Communication. IEEE Syst. J. 2020, 14, 520–529. [Google Scholar] [CrossRef]
  16. Hlauschek, C.; Gruber, M.; Fankhauser, F.; Schanes, C. Prying Open Pandora’s Box: KCI Attacks against TLS. In Proceedings of the 9th USENIX Workshop on Offensive Technologies (WOOT 15), Washington, DC, USA, 10–11 August 2015. [Google Scholar]
  17. Ma, Z.; He, J. Outsider Key Compromise Impersonation Attack on a Multi-factor Authenticated Key Exchange Protocol. In Applied Cryptography and Network Security Workshops—ACNS 2022 Satellite Workshops, AIBlock, AIHWS, AIoTS, CIMSS, Cloud S&P, SCI, SecMT, SiMLA, Rome, Italy, 20–23 June 2022; Zhou, J., Adepu, S., Alcaraz, C., Batina, L., Casalicchio, E., Chattopadhyay, S., Jin, C., Lin, J., Losiouk, E., Majumdar, S., et al., Eds.; Lecture Notes in Computer Science; Springer: Cham, Switzerland, 2022; Volume 13285, pp. 320–337. [Google Scholar] [CrossRef]
  18. Hosseinzadeh, M.; Ahmed, O.H.; Ahmed, S.H.; Trinh, C.; Bagheri, N.; Kumari, S.; Lansky, J.; Huynh, B. An Enhanced Authentication Protocol for RFID Systems. IEEE Access 2020, 8, 126977–126987. [Google Scholar] [CrossRef]
  19. RISE GmbH. KCI Attacks against TLS. Available online: https://kcitls.org/ (accessed on 20 December 2022).
  20. Johnson, D.; Menezes, A.; Vanstone, S.A. The Elliptic Curve Digital Signature Algorithm (ECDSA). Int. J. Inf. Sec. 2001, 1, 36–63. [Google Scholar] [CrossRef]
  21. Lowe, G. A hierarchy of authentication specifications. In Proceedings of the 10th Computer Security Foundations Workshop, Rockport, MA, USA, 10–12 June 1997; pp. 31–43. [Google Scholar]
  22. Darbandeh, F.G.; Safkhani, M. SAPWSN: A secure authentication protocol for wireless sensor networks. Comput. Netw. 2022, 220, 109469. [Google Scholar] [CrossRef]
  23. Cremers, C. CISPA. Available online: https://people.cispa.io/cas.cremers/publications/index.html (accessed on 20 December 2022).
  24. Abdalla, M.; Fouque, P.; Pointcheval, D. Password-Based Authenticated Key Exchange in the Three-Party Setting. In Public Key Cryptography—PKC 2005, 8th International Workshop on Theory and Practice in Public Key Cryptography, Les Diablerets, Switzerland, 23–26 January 2005; Vaudenay, S., Ed.; Lecture Notes in Computer Science; Springer: Berlin/Heidelberg, Germany, 2005; Volume 3386, pp. 65–84. [Google Scholar]
  25. Bagheri, N.; Kumari, S.; Camara, C.; Peris-Lopez, P. Defending Industry 4.0: An Enhanced Authentication Scheme for IoT Devices. IEEE Syst. J. 2022, 16, 4501–4512. [Google Scholar] [CrossRef]
  26. Rostampour, S.; Bagheri, N.; Bendavid, Y.; Safkhani, M.; Kumari, S.; Rodrigues, J.J.P.C. An Authentication Protocol for Next Generation of Constrained IoT Systems. IEEE Internet Things J. 2022, 9, 21493–21504. [Google Scholar] [CrossRef]
  27. Khan, A.A.; Kumar, V.; Ahmad, M.; Rana, S.; Mishra, D. PALK: Password-based anonymous lightweight key agreement framework for smart grid. Int. J. Electr. Power Energy Syst. 2020, 121, 106121. [Google Scholar] [CrossRef]
  28. Abbasinezhad-Mood, D.; Nikooghadam, M. An Anonymous ECC-Based Self-Certified Key Distribution Scheme for the Smart Grid. IEEE Trans. Ind. Electron. 2018, 65, 7996–8004. [Google Scholar] [CrossRef]
  29. He, D.; Wang, H.; Khan, M.K.; Wang, L. Lightweight anonymous key distribution scheme for smart grid using elliptic curve cryptography. IET Commun. 2016, 10, 1795–1802. [Google Scholar] [CrossRef]
  30. Wu, F.; Xu, L.; Li, X.; Kumari, S.; Karuppiah, M.; Obaidat, M.S. A Lightweight and Provably Secure Key Agreement System for a Smart Grid with Elliptic Curve Cryptography. IEEE Syst. J. 2019, 13, 2830–2838. [Google Scholar] [CrossRef]
  31. Garg, S.; Kaur, K.; Kaddoum, G.; Rodrigues, J.J.P.C.; Guizani, M. Secure and Lightweight Authentication Scheme for Smart Metering Infrastructure in Smart Grid. IEEE Trans. Ind. Inform. 2020, 16, 3548–3557. [Google Scholar] [CrossRef]
Figure 1. The Energy Internet of Things (EIoT) ecosystem.
Figure 1. The Energy Internet of Things (EIoT) ecosystem.
Mathematics 11 00176 g001
Figure 2. The used system model.
Figure 2. The used system model.
Mathematics 11 00176 g002
Figure 3. Mutual authentication phase of LLAKEP scheme to share a session key between E B R and B S S [9].
Figure 3. Mutual authentication phase of LLAKEP scheme to share a session key between E B R and B S S [9].
Mathematics 11 00176 g003
Figure 4. Mutual authentication phase of LLAKEP + scheme to share a session key between E B R and B S S .
Figure 4. Mutual authentication phase of LLAKEP + scheme to share a session key between E B R and B S S .
Mathematics 11 00176 g004
Figure 5. Security verification results of LLAKEP + on Scyther.
Figure 5. Security verification results of LLAKEP + on Scyther.
Mathematics 11 00176 g005
Figure 6. Real or Random (RoR) model; RP: Real Protocol, Sim: Simulator; RO: Random Oracle.
Figure 6. Real or Random (RoR) model; RP: Real Protocol, Sim: Simulator; RO: Random Oracle.
Mathematics 11 00176 g006
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.
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.
Mathematics 11 00176 g007
Table 1. List of used notations.
Table 1. List of used notations.
SymbolDescription
EBRElectric bike riders
BSSBattery swap station
MCMicroprocessor chip
AAdversary
I D E B R Identity of an electric bike rider EBR
P W E B R Password of an electric bike rider EBR
s k X Private key of X
p k X Public key of X
s k Session key
E / F p An elliptic curve E over a prime finite field F p with p being a large prime
nOrder of base point G
Z n 1 , 2 , , n 1
k · G Scalar multiplication on elliptic curves and G is a base point in E / F p
A B Concatenation operation between strings A and B
A B XOR operation between strings A and B
k d f ( · ) Key derivation function
H ( · ) A one-way hash function that generates digests
Table 2. Cost comparison of LLAKEP + and other related protocols.
Table 2. Cost comparison of LLAKEP + and other related protocols.
ProtocolPrimitives CallComputations (ms)Communication (bit)
 [28] 10 × T H + 8 × T e m 17.8311440 bits
[29] 5 × T H + 9 × T e m 20.04551632 bits
[30] 11 × T H + 9 × T e m 20.05931600 bits
[31] 8 × T H + 9 × T e m 20.05241344 bits
[9] 12 × T H + 6 × T e m 13.38361187 bits
LLAKEP + 11 × T H + 8 × T e m 17.83331152 bits
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Share and Cite

MDPI and ACS Style

Hosseinzadeh, M.; Ali Naqvi, R.; Safkhani, M.; Tightiz, L.; Majid Mehmood, R. Secure Authentication in the Smart Grid. Mathematics 2023, 11, 176. https://doi.org/10.3390/math11010176

AMA Style

Hosseinzadeh M, Ali Naqvi R, Safkhani M, Tightiz L, Majid Mehmood R. Secure Authentication in the Smart Grid. Mathematics. 2023; 11(1):176. https://doi.org/10.3390/math11010176

Chicago/Turabian Style

Hosseinzadeh, Mehdi, Rizwan Ali Naqvi, Masoumeh Safkhani, Lilia Tightiz, and Raja Majid Mehmood. 2023. "Secure Authentication in the Smart Grid" Mathematics 11, no. 1: 176. https://doi.org/10.3390/math11010176

APA Style

Hosseinzadeh, M., Ali Naqvi, R., Safkhani, M., Tightiz, L., & Majid Mehmood, R. (2023). Secure Authentication in the Smart Grid. Mathematics, 11(1), 176. https://doi.org/10.3390/math11010176

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop