LIKA: Lightweight Identity Based Key Agreement Protocol for Secure Data Transmission in Advanced Metering Infrastructure of Smart Grid

Abstract

Integration of information communication technology via the Internet of Things devices and sensors can enable an efficient power service for utility providers to consumers in advanced metering infrastructure. Authentication and cryptographic mechanisms protect identity, data security and privacy from unauthorised interception for smart meters to servers. In the last couple of years, many key agreement protocols have been prescribed and deployed to fix those issues. Unfortunately, the deployed protocols did not work inside the same protocols, specifically parameter detection and recognition for session key generation, as they entail high computation time and communication bits overheads. Furthermore, the absence of forward secrecy and user anonymity affects the authentication. Therefore, we have proposed a lightweight identity-based key agreement (LIKA) utilising the Diffie–Hellman cryptography with a trusted authority. It seeks to cover both the security and performance criteria with equal weight. The protocol is evaluated by the Canetti and Krawczyk adversarial model, Avispa and cryptographic analysis released the session keys that were not considered as an adversary during mutual authentication. Moreover, as compared to related work, the proposed protocol took the least amount of time (5.319 ms and 1056 bits) for the entire process of session key generation. Furthermore, comparative analysis has shown that the LIKA adequately encompasses computation, communication, and security assessments. Consequently, it is more convenient for practical implementation for a smart grid.

1. Introduction

A smart grid assembles an electrical grid that is superefficient, trustworthy, and secure for supplying information to consumers and utility providers, or vice versa. Researchers and industrialists are interested in smart grids because of their diverse roles. Integration of information communication technology plays a remarkable exordium in a smart grid by turning a traditional grid into a smart modern platform [1]. Instead, it has a next-generation power system [2]. Within a smart grid, one of the vital components is the advanced metering infrastructure (AMI), which is a kind of middle-wire communication platform between the consumer and the service provider [3]. There are a lot of device sensors applied to the generation centres among consumer premises to transfer services and monitor in terms of scalable grid environments [4]. The architecture of the AMI is planned by the service provider, customer premises and cognitive device, server and smart meter with a communication system [5,6]. Additionally, some resource-constrained devices perform end-user to server-end functions, such as smart meters [7].

Meanwhile, heterogeneous devices and sensors exist in advanced metering infrastructure, where authentication is of utmost important for checking and verifying between both the active number of entity service providers, smart meter, customer, computers, gateways, servers etc [8]. The primary goals of authentication are identifying the accurate entity in the system, robustness and versatility for data security-preservation and protection [9]. Additionally, there is a key security concern in the advanced metering infrastructure that helps protect user anonymity, key exchange security, forward personal privacy, confidentiality, credibility, non-repudiation, and secure user authentication in order to provide reliable data transmission between two parties in smart grid environments [10]. Besides, it is crucial that data transmission should remain encrypted end to end between two parties [11]. An encryption mechanism is a quick tool to defend against cyber attacks [12]. Public cryptography-based approaches, namely encryption and decryption policy, are important to keep smart grid requirements for better message transmission without unauthorized access [13].

The performance and security aspects of the situation were the starting point for this investigation. This work endeavours to examine and analyse previous work to address its strengths and weaknesses. It has made significant progress in overcoming the aforementioned limitations [14]. Experts have already delivered ways to make advanced metering infrastructure more lightweight and resistant to unwanted access, although there are some drawbacks depicted, such as key constraints resulting in inadequate authentication between two parties causing security flaws triggered by the delay of time and bit operations, which give an opportunity to reveal the parameter identification during the key session or key generation in terms of either failure anonymity or forward secrecy. Moreover, hampered efficiency due to high latency of cryptographic operations has resulted in high computation time and communication bits, which were overwhelming for limited processing devices in the AMI.

The latest solution of encryption and authentication mechanisms, such as key agreement protocols, have been shown to fill security holes by using cryptographic operations, public keys, and authentication techniques [10,11]. This study focuses on adapting encryption and authentication to overcome the solution in terms of both security and performance considerations in the AMI. Therefore, a novel lightweight identity-based key agreement protocol adopting the Elliptic curve Diffie–Hellman cryptography and a trusted authority is proposed. The following contributions are made by this research.

• The proposed protocol takes less time and bit operation compared to existing protocols. The LIKA decreased the additional cryptographic operation burden for AMI context devices.
• According to its construction, the LIKA ensures mutual authentication between two parties, known as a smart meter and aggregator point, in terms of preserving forward secrecy and user anonymity.
• The proposed protocol was evaluated by the widely adopted security assessment tool, Avispa, and CK-adversarial confirmed formal security evaluation. Moreover, informal analysis proves multiple security features handled by LIKA against identified attacks.
• To draw against past records, the obtained results reflect the proposed protocol security and performance efficiency, both criteria equally utilised within the same protocol. These would serve as a fresh route for the AMI to improve the reliability and convenience of a smart grid.

The study is organised as follows: in the second section, we conducted literature research on the background of the proposed protocol. In the third section, we designed a brief methodology covering the current flaws. Afterwards, in the fourth section of the study, we critically examined the planned work in three separate parts, formal and informal, for security evaluation. Furthermore, the efficiency evaluation was related to comparing the existing protocols. Lastly, the fifth section draws a conclusion and future research direction is portrayed, respectively.

2. Literature Review

In recent years, numerous unique authentication and key agreement solutions have emerged to address performance and security concerns in smart grids of AMI environments. The authors of the [1,5,9,15,16,17,18,19,20,21,22,23,24,25,26,27] protocols primarily relied on the three-phase mechanism, which are initialization, registration, and authentication/key agreement with assistance of trusted authority or self-development of each phase. These protocols used the ECC, Diffie–Hellman, bilinear pairing and identity-based cryptography to build key agreements between smart meters to utility aggregator points.

Table 1. Related work.

Schema	Research Objectives	Compromise Method	Results: Performance and Security Assessments	Advantage	Limitations
[16]	Propose an efficient authentication with key agreements protocol for privacy and security issues of smart grid entity.	-Encryption: ECC with Diffie Hellman key exchange. -Authentication: Basis on ECDSA.	-Computation time: 30.80 ms. -Communication bit: 3744. bits -Authentication: Mutual authentication SM to AG. -Security proof: No security proof presented.	-Efficiently achieved Mutual authentication. -Comparative analysis presented for security and performance aspect.	-Session key generation requires more extensive time than other protocols. -Due to high latency and delay during key generation, the unauthorized party makes scope for taking over the session key.
[17]	Proposed an authentication and key agreement protocol utilizing an identity-based mechanism with public key infrastructure to improve efficiency and security.	-Encryption: Public key infrastructure. -Authentication: Based on self-signature.	-Computation time: 27.78 ms. -Communication bit: 1152 bits. -Authentication: authentication between SM and AG. -Security proof: security proof by Avispa.	-Total execution time covered the whole process of smart meter to the utility server. -Effectively minimize communication bits.	-Various cryptographic operations are required for each transmission. -Mathematical complexity of self-signature pinch for intruders.
[18]	Propose a novel key management protocol to resolve the man in the middle and replay attack in AMI infrastructure.	-Encryption: ECC with symmetric encryption. -Authentication: Needham-Schroeder authentication Protocol.	-Computation time: 7.56 ms. -Communication bit: 100 bits each handshaking. -Authentication: Only the sender (smart meter) authenticates. -Security proof: No security proof presented.	-Strongly managed MITM and replay attacks. -System model suitable for smart grid requirement.	-Need an extra server for authentication purposes thus increasing the processing of computation time cost. -Disclose the session key and vulnerable for DoS attack.
[19]	Proposed lightweight key agreement protocol in order to assure SM privacy, security, efficiency.	-Encryption: RSA with modular exponential. -Authentication: Not presented properly.	-Computation time: 18.31 ms. -Communication bit: 2457 bits. -Authentication: Did not mention. -Security proof: No security proof presented.	-RSA based approach covered tight security assessment. -The system architecture is a new path in the further research.	-RSA encryption takes more significant time for session key generation. -Vulnerable for session key due to no such parameter covered the session key security.
[20]	Proposed secure communication between the smart meter and service provider by using an identity base self-signatures mechanism.	-Encryption: ECC based cryptography -Authentication: Hash function	-Computation time:10.53 ms. -Communication bit: Required 4 steps per handshaking, took 100 bits. Authentication: Mutual authentication. -Security proof: Random oracle security proof presented.	-Competently discovered mutual authentication. -This protocol kept smart meter anonymity in a public channel.	-Utilized two different cryptosystems for authentication, raised time and bits operation. -Due to identity disclose utility server, faced guessing attack. -provide fewer security features.
[21]	Proposed identity based probably key agreement protocol to tackle session key security by trusted authority based approached.	-Encryption: ECC with ECQV properties. -Authentication: Hash function.	-Computation time: 23.81 ms. -Communication bit: 832 bits. -Authentication: Acquire trusted authority-based authentication. -Security proof: Random oracle, Avispa (formal), parameter-based (informal).	-Resist MITM and replay attack. -Demonstrated three-way security proof.	-Does not support forward secrecy and did not show DoS attack mitigate evaluation. -In every phase, utilized cryptographic operation for parameter detection increased computation time.
[1]	Presented ECC based anonymous key agreement for secure transmission smart meter to a service provider.	-Encryption: ECC based ECDSA cryptographic properties. -Authentication: Hash function.	-Computation time: 13.34 ms. -Communication bit: 1440 bits. -Authentication: Trusted authority handle the mutual authentication. -Security proof: Random oracle model, Proverif.	-Preserve mutual authentication between a smart meter to aggregator point. -Emerged self-signature for parameter identification.	-Following protocol owned several time hash operation, which is generated and retrieved raised time and bits cost.
[14]	Propose lightweight and key agreements with ECC based cryptography for cyber security in smart grid.	Encryption: ECC based cryptography Authentication: Hash function.	-Computation time: 28.83 ms. -Communication bit 1940 bits. -Authentication: authentication between smart meters to service provider server. -Security proof: Under random oracle model.	-Significantly reduced computation time in smart meter side.	-Take long time for established session key generation scope for vulnerable in attack scenarios.
[22]	The proposed paper deals with protection and privacy issues are the key subject of the smart gird.	-Encryption: Symmetric key with biometric approaches. -Authentication: HMAC.	-Computation time: 8.92 ms. -Communication bit: 1152 bits. -Authentication: Mutual authentication. -Security proof: only measures security features as informal assessment.	-Utilized hybrid encryption scalable the metering infrastructure beside it take low computation power.	-The symmetric key encryption vulnerable for many attack scenarios like: eavesdropping, MITM. -There is less attention to protect key security.
[9]	Propose Fully ECC Hashed Menezes-Qu-Vanstone key exchange for reduced computation overheads problem.	Encryption: ECC with FHMQV scheme. Authentication: Hash function.	-Computation time: 12.00 ms. -Communication bit: 322 bits (key generates by TA). -Authentication: present a mutual authentication between smart meter to NAN. -Security proof: Avispa and informal cryptographic analysis.	-Significantly reduced communication bits in term of less delay than above protocol. -Resists number of attacks scenario.	-Did not concentrate on massage integrity. -CA certificate revocation and generation increase the computation time instead. of unauthorized scope for intercepting the message.
[5]	Propose multi-factor authentication scheme for smart meter physical and data privacy.	Encryption: Fuzzy extractor-based cryptography. -Authentication: One way Hash function.	-Computation time:14.13 ms Communication bit: 908 bits. -Authentication: Acquire smart meter authentications. -Security proof: Utilized random oracle proof for security measures.	+Preserve the smart meter physical security.	-Increased computation time due to high mathematical complexity. -Do not reached massage integrity.
[15]	Propose password based key agreements protocol to ensure reduce computation time and communication bits.	-Encryption: ECC with symmetric block cipher cryptography. -Authentication: HMAC.	-Computation time: 17.80 ms. -Communication bit: 1184 bits. -Authentication: Mutual authentication. -Security proof: Avispa and informal cryptographic analysis.	-Mitigates multiples number of attacks.	-[23] argue that this protocol have problem in registration and authentication due to incorrect ECC point multiplication, which is not applicable for presence of multiple devices.
[24]	Proposed identity based key agreement protocols by using elliptic curve with bilinear pairing cryptography.	-Encryption: Public key infrastructure -Authentication: HMAC	-Computation time: 15.76 ms. -Communication bit: 621 bits. -Authentication: Mutual authentication. -Security proof: There is no security proof presented.	-The protocol eliminates highest number of time and bits operation.	-Though efficiently managing performance issues but unfortunately do not present any security model.
[25]	This study provides a novel secure authenticated key agreement mechanism for smart grids that considers the possibility of a hostile third party.	-Encryption: Bilinear pairing cryptography. -Authentication: One way hash.	-Computation time: 20.98 ms. -Communication bit: 1120 bits. -Authentication: Not present.-Security proof: Avispa and BAN logic (formal analysis).	-This protocol managed computation, communication overheads and security criteria at same time within their protocol.	-Every phase used cryptographic operation raised computation latency. -Proposed protocol offers limited security features. -Lack of forward secrecy due to inattention of session key security.
[26]	Proposed a certificate less key agreement protocol for solved a key escrow issues.	-Encryption: Bilinear pairing cryptography. -Authentication: Not available.	-Computation time: 13.04 ms. -Communication bit: 160 × 8 bits. -Authentication: Not presented. -Security proof: Security proof by eCK.	-The security model and proof offered by this paper will lead to a new paradigm for dealing with the following security assessments.	-Each phase were accommodate bilinear operation increased gradually computation time operation.
[27]	This protocol proposed ID-2PAKA protocol to ensure additional burden of cryptographic operation.	-Encryption: ECC with bilinear pairing cryptography. -Authentication: Trusted authority covers the two parties authentication.	-Computation time: 13.816 ms. -Communication bit: 1274 bits. -Authentication: Mutual authentication. -Security proof: security proof under random oracle model and informal analysis.	-Comparative analysis illustrated the protocol equally maintain performance and security aspect.	-The author stated that bilinear paining increased the computation cost that would be avoided in metering infrastructure especially for the fewer computation devices in AMI.

presents the work related to this study to understand their objectives, methods, approaches, results, advantages and limitations. A broad analysis about the existing work is shown below.

According to Table 1 summarizing existing work, we discovered that most of the researchers have recently presented solutions managed by cryptographic mechanisms. Unfortunately, the time and bit operation costs associated with the security features evaluated were not equitably acquired earlier. Notably, past methods either concentrated on the authentication element or decreasing the time and bit issues, while paying little attention to the performance and security features of the same protocols in both instances. Most typical faults suffer from high computation time and communication bit overheads due to the excessive latency of cryptographic operations that are disrupting performances. In addition, security vulnerabilities caused by delays in parameter checking and identification operations, created opportunities for unauthorised users to intercept the session are also part of the faults. In terms of failures of forward secrecy and user anonymity, there was inadequate authentication between the smart meters and aggregator points.

3. Methodology

This methodology aims to provide the best degree of protection by improving proper authentication during the session key generation between smart meters and aggregator points by using the elliptic curve Diffie–Hellman (ECDH) cryptography mechanism with assistance of trusted authority-based access token approaches. Meanwhile, the proposed protocol intends to preserve security and performance within the protocol. Our chosen methods aims to reduce time and bits overheads compared to other schemes. Additionally, formal, and informal assessment shows the proposed protocol conserves mutual authentication in terms of maintaining forward secrecy and anonymity, respectively. Moreover, the proposed protocol offers numerous security features and multiple performance features compared to existing work.

3.1. System Component

This methodology is applicable in the smart grid context, which is a core field for advanced metering infrastructure. Figure 1 demonstrates the proposed system model. In this work, we look at three entities: one trusted authority connected to a secure channel with a utility provider. The second component of this methodology is called the data aggregator point, while the smart meter is the third component.

Our proposed protocol is responsible for monitoring electric flows and transmitting real-time electric data to users as a smart meter and aggregator point, such that it acts as a utility side entity situated in a neighbourhood area network for executing multiple work scenarios. Besides, the smart meter is a computationally constrained electrical device that controls minimum processing power and is capable of collecting data and controlling smart appliances, which are installed in a home area network.

3.2. Initialization Phase

This is the initial phase based on y² = x³ + 2x + 2 (mod), which is executed first by selecting G, which subsequently generates a public/secret key with the help of an elliptic curve {P, a, b, G, n, h}; here p is large prime numbers in a specific elliptic curve. The first coefficient of the curve is a, whereas b is the second. Parameter G is the generator point (base point) where the parameter G denotes <a, b>, while n is the prime order of G and h is the cofactor of the group. The following parameter computes a private and public key pair and stores it in a directory for later use in the authentication phase. It is used to perform scalar multiplication via the ECDH properties in the basic two-group function, which are point addition and point doubling, with the aid of a generator point G. Scalar multiplication should be used to generate shared session keys [28]. The next phase follows these parameters effectively by utilising them.

3.3. Registration Process with Trusted Authority

In this phase, the smart meter and aggregator point asks a trusted authority for permission to join the mutual authentication process. The smart meter and aggregator point send credentials to a trusted authority which are verified, based on pre-loaded databases and generates TokenSM and TokenAG. The registration process is shown below.

Process SM to TA: Smart meter selects ID_SM and corresponding password hash to request for registration. Here, ID_SM and PW_SM are considered as identification and the security parameter, therefore, SM send as: (ID_SM∥PW_SM) to the TA in a secure channel.

Process TA to SM: After receiving the credentials, TA checked ID_SM and PW_SM into the database. If matched with the TA database, then it will generate the service token for the smart meter Token_SM; if it is not true, the request will be aborted.

Process SM: Upon receiving a message from TA, it will store the Token_SM into the directory. The Token_SM consists of the smart meter ID and MAC address, token generation and expiry time, and destination identification, mean aggregator point ID are all included in the token header. Furthermore, the following token serves as an access control for the SM between AG to initiate the authentication phase. At this stage, it is ready for mutual authentication with the aggregator point. According to the above, the same process is done by the aggregator point (AG) with a trusted authority (TA) for registration purposes when it communicates with the smart meter. Figure 2 illustrates the entire process of registration and mutual authentication phase between smart meters and aggregator points.

3.4. Mutual Authentication Process Smart Meter with AG

Once the registration process is completed, a mutual authentication is performed between the smart meters belonging to the home area network and aggregator points that exist in the neighbourhood area network. This is known as a utility side regional server; it collects data from the smart meter after a bunch of data is finally sent to the utility main server for the next process. In this section, the following work will focus on smart meters and aggregator points moving to a mutual authentication between both sides together with passing valuable parameters and vice versa for session key generation.

Step 1: The smart meter initiates a mutual authentication and key agreement to AG. According to help of the initialization phase, it selects a prime number to compute private key d_SM into P∈ ×G point and public key Q_SM of smart meter to d_SM × G^P point.

Based on the initialisation and registration phase, the SM select a Token_SM, which is collect from TA during registration phase. Then it computes the public key of the aggregator point in Q_AG.G point. After this, it selects the current T_SM of the smart meter and generates and computes a pseudo-random number R_SM × G^P using ECC point multiplication. Then a one way hash is generated that relies on function h: {0, 1}*→ {0, 1} = (.h) and wrapped following parameter as: {h(Token_SM∥T_SM∥R_SM).Lastly, the encryption M1 is sent as: {Q_AG (Token_SM∥T_SM∥R_SM∥(.h)} to the aggregator point.

Step 2: Following the credentials received from the SM, it will first decrypt the packet by d_AG; after it validates the received hash (.h), if the value has changed it will drop the session. Otherwise, true check the value for the current time-stamped T_SM ≤ T_AG and probe the pseudo random number find in R_SM×G point. Afterwards, save the Token_SM for further processing. Subsequently for the next round of validation the AG selects its own identity Token_AG afterwards, it selects the current time-stamp T_AG and calculates the session key by help of the initialisation phase using scalar multiplication operation. The AG computes the shared session key as: {SK_AG = d_AG × Q_SM × G}. Next, it computes a random number R_AG × G^P for key freshness and wrap the parameter by M2 send as: {R_AG (Token_AG∥T_AG∥SK_AG)} to the SM.

Step 3: Upon receiving the appended message from AG, the smart meter validates the authenticity of the R_AG × G^P, which belongs to SM in G^P point. Then, it compares the current T_AG≤ T_SM; if the appended parameter values match, further the Token_AG is stored for next handshaking. Finally, it computes the shared session key of SK_SM as: {SK_SM = d_SM × Q_AG × G}; if the session key SK_AG and SK_SM are the same, it moves toward to the next section, otherwise the session will fail. Afterwards, SM takes B_M which contains real-time billing information. Then, select T_SM along the wrapped parameter by M3 send as: {SK_SM (B_M∥Token_AG∥T_SM)}to the AG.

Step 4: Afterwards, AG takes the message; it is extracted by SK_AG if equivalent with SK_SM, then is computed T_SM ≤ T_AG, then the equality of Token_AG and Token_AG is checked to see if it is true to ensure the received message source is real. Otherwise, if the values do not match, the session will fail.

Step 5: Finally, the aggregator points send the ACK_SM to the smart meter. The overall steps are shown in Algorithms 1 and 2, which further explains the proposed method.

Algorithm 1. Registration Smart Meter to Trusted Authority

1: SM inputs IDSM 2: SM inputs PWSM 3: SM sends {IDSM, PWSM } towards to TA 4: TA Check the credential by TA database 5: if (IDSM = IDSM, PWSM = PWSM match in TA database) then 6: TA accept the SM request, creates: (Token) for SM 7: TA send {TokenSM } toward to SM 8: SM store {TokenSM } into own dashboard 10: return (Success) 11: return (Failure) 12: else 13: end if

Algorithm 2. Mutual Authentication and Data Transmission

1: initiate private key dSM of SM by PSM ∈ Zp*

2: calculates public key QSM = dSM × G

3: select inputs SM = TokenSM then

4: select public key of AG = QAG on key directory

5: generates time-stamp TSM for verification purpose

6: computes SM = RSM × GP for session freshness

7: SM send M1 = (TokenSM‖QAG‖TSM‖RSM‖(.h)) appended with hash toward to AG

8: while AG extract the M1 by own private key dAG and do

9: check = TSM ≤ TAG then

10: if received RSM with generated AG computes RSM × GP same

11: if received hash((.h) = (h)) generated true then

12: AG store TokenSM into dashboard

13. return (Success)

14:    else

15:     return (declined)

16:    end if

17: select current AG = TAG

18: AG computes RAG = AG × GP

19: calculates AG = SKAG then

20: AG send M2 = (TokenAG‖RAG‖TAG‖SKAG‖(.h)) toward to SM.

21: end while

22: while SM compares (TAG ≤ TSM) belonging G*p do then

23: verify pseudo number SM = RAG × GP then

24: store = TokenAG

25. return (Success)

26:    else

28:     return (declined)

29:    end if

30. end while

31: if calculatesSKAG = SKSM true then

32: select = TokenAG

33. select current time-stamp = TSM

34. send M3 = SKSM‖TokenAG‖TSM

35: if AG verify (SKAG = SKSM) truethen

36: compare to = TSM ≤ TAG

37: check = TokenAG= TokenAG

38. return (Success)

39:     else

40:      return (declined)

41:     end if

42. return (Success)

43:     else

44:      return (declined)

45:     end if

4. Results and Analysis

This section shows the results of security analyses and performance efficiency analyses based on the authors of [15,27,28]. It is accomplished by the steps: an evaluation of security and its functionality aspects, after comparison of computation and communication overheads are deployed. Additionally, we add comparative demonstrations at the end of the analysis. The security analysis section illustrates an informal interpretation wherein the ECDH parameters are given mathematical complexity known as an Elliptic curve discrete logarithm problem and an Elliptic curve Diffie–Hellman problem [29], A one-way hash function with an appended pseudo random number, a time-stamped parameter were built as an additional burden for the unknown user in the session key generation in both the smart meter and aggregator points. The CK adversarial model and Avispa were employed in the formal analysis. Furthermore, the formal study examines how forward secrecy and user anonymity deal with well-recognised tools to maintain mutual authentication according to the suggested technique. The performance analysis section contains two analysis criteria, which are commutation time and communication bits, both of which are assessed to compare the proposed protocol against existing schema.

4.1. Assumption

This study is based on the following assumptions.

• The threat model is deduced to be Dolve–Yao, with an adversary having connected to the channel and being able to interrupt the message in the smart meter and aggregator point.
• The smart meter and aggregator point in the registration phase with TA build in secure channel.
• The intruder can resend and disrupt messages to the SM and aggregator point. The intruder also can eavesdrop and inject harmful messages into the relayed communication between the two parties during session key generation.
• The intruder can impersonate the SM and/or aggregator point, the AG is securely connected to the utility server. On the other hand, the channel between the AG and the SM is assumed to be public is insecure as a result, the configured proposed protocol guarantees security between the two parties.

4.2. Mathematical Complexity

According to the elliptic curve cryptography (ECC), one of the major Elliptic curve discrete logarithm problem-based properties includes the ECDH. This provides some mathematical functionality without the knowledge value of ECDH parameter and does not reach into the point, which is given below.

4.2.1. Elliptic Curve Discrete Logarithm Problem (ECDLP)

Let P be the large prime integer number, g is an additive cyclic group G is the generator point or in terms of base point of the curve with prime order G. For the given point a, bX where X∈G and a ∈ Z_P, it is computationally not feasible to find a, [1]. In this proposed scenario, if we have a prime number and generator point of G like d_SM × G, then it will be easy to find Q_SM, but we have reached G and Q_SM, which is not an easy process to get d_SM points for the ECDLP problem.

4.2.2. Elliptic Curve Diffie–Hellman Problem (ECDHP)

Let P be the large prime integer number, g is an additive cyclic group and G is the generator point or in term of base point of the curve with prime an order G. For the given point aX and bX where X ∈ Z and a, b ∈ Z* the point is computationally not infeasible to find abX [23,24].

4.2.3. Hash Function

The hash function is a collision-resistant one-way hash function. Hence, finding x is hard in a hash-based function like h(x): Hash function = h is secured one-way = h: {0, 1}*→{0, 1}ⁿ. This object takes the output of x ∈ {0, 1} and h(x) {0,1}ⁿ of a certain range of length n.

4.3. Security Analysis (Informal)

This section discusses the informal security analysis that relies on ECDH mathematical complexity, time stamp, pseudo random number, and hash operation. By combining these features, the proposed system is protected from unauthorized access. Additionally, the proposed protocols provide mutual authentication between the smart meter and the aggregator point. The following section describes an informal examination strategy searching the relevance of the security criteria.

4.3.1. Mutual Authentication

The proposed protocol preserved mutual authentication in smart meters between aggregator points. Additionally, the proposed mechanism is supported in an insecure channel as it keeps domain authentication because in a smart grid, millions of smart meters and thousands of aggregators exist, so it should be able to identify the exact source and destination. The proposed mechanism proved domain authentication during the registration phase of smart meter (SM) to a trusted authority (TA) by using SM identity =ID_SM, which was previously stored in TA. The same process for AG can confirm the domain authentication in an insecure channel. Another feature confirms that the system mutually transmits information generated by the smart meter sign TOKEN_SM and TOKEN_AG, which were rechecked in the authentication phase; if the SM= TOKEN_SM = AG = TOKEN_AG is the same, then exchange the message, otherwise the session will be aborted.

After that, we introduced the mutual authentication, which made it more evident that a smart meter initiates the process and calculates the key P_SM ∈ Z*_P, the private key d_SM, and the public key are calculated by Q_{SM =} d_SM × G for the secret key generation, the same as on the AG side to generate the session key = SK_AG, if the appended values and SK_AG = SK_SM mutually match, then it is authenticated. Supposing the adversary tries to intercept the value, it will be computationally infeasible to retrieve the hash values without a private key in this scenario, as only the private key knows their own.

4.3.2. Replay Attack

A replay attack is kinds of network attack, whereby attackers send a malicious or dishonest transmission of the valid data over the network. The malicious entities shall replay or postpone the transmitted data that retrieves and sends the information [30]. The proposed protocol in smart meters for aggregator points resists the replay attack following the proposed mechanism that provides every message transferred between them a check of time-stamped values T =T_SM = T_AG. If the values change, the connection is dropped immediately. Another way to avoid the attack is by refreshing in every step on the SM to AG to generate key freshness in R_SM = R_SM × P and R_AG = R_AG × P without previous knowledge of the parameter, it did not retrieve. Hence, the proposed system is saved from replay attack.

4.3.3. Man in the Middle Attack

In security and cryptography, a man in the middle intervention is an attack where the perpetrator secretly intercepts, transmits messages or changes communication between two domains [29,30]. Both users think they are communicating with each other individually. The proposed protocol resists the MITM attack for the following reason: somehow A gets the message same as M1 = (TOKEN _SM∥Q_AG∥T_SM∥R_SM∥(.h)) but A gets the Q_SM and Q_AG which is only a parameter publicly available in the channel. In terms of the adversary A trying to extract the appended value, due to the ECDLP and ECDHP they do not acquire the private key. Therefore, A cannot open and adjust the other parameter if a change happened, which is a mess for all parameters, so he/she perceives to receive the value that did not come from an exact source; hence, the process is immediately stopped. Thus, the proposed protocol withstands the MITM attacks.

4.3.4. Impersonation Attack

In this attack, the attacker attempts to mark himself as an authorized device or individual to communicate with other entities on the network [31]. The designed system also resists type of impersonation attack in between SM and AG as well during registration with TA. In this phase, A can try to impersonate as a legitimate user to interact with others; it is quite impossible because this system mutually authenticates by (TOKEN_SM∥Q_AG∥T_SM∥R_SM∥(.h)) with (TOKEN_SM∥Q_SM∥T_AG∥R_A∥(.h)). Here creates the SK_AG = SK_SM contained all the appended value if match then create the session otherwise not. Without previous knowledge of the parameter, it does not get it, only the SM and AG kept the information, so this protocol saves from impersonation attack.

4.3.5. Support Forward Secrecy

Forward secrecy, also known as perfect forward secrecy, is a precise feature of key agreement protocol. It gives assurance that the session key will not be compromised in short- or long-term considerations in terms of without any parameter information [32]. The proposed protocol supports forward secrecy as the session key SK_AG = SK_SM is built by (TOKEN_SM∥Q_AG∥T_SM∥R_SM∥(.h)) and (TOKEN_AG∥Q_SM∥T_AG∥R_AG∥(.h)). The following information that are time-stamped T_SM = T_AG and random number R_AG = R_SM ensure each message session freshness along both private keys (d_SM, d_AG) provide confidentiality to both entities. Thus, the adversary will have trouble cracking the combination of constantly shifting variables and highly protected private keys.

4.3.6. Support Anonymity

To prevent a hacker who has recorded previous conversations from learning the identity of those involved, computer security and encryption provide a feature known as forward secrecy [33,34]. The proposed designed protocol considers anonymity issues by following the method we mentioned earlier in the smart meter (SM) and aggregator (AG) point conversation during the authentication and data transmission phases. There is SM with AG passing all messages between them to accommodate with the time-stamped value T_SM =T_AG. Due to the cause of randomness, this will return different values to execute each conversation. Thus, A cannot get the real identity of the user, so this protocol kept the identity anonymous. Moreover, SM and AG collect TOKEN from TA as it relies on anonymity performed in a public channel.

4.3.7. Key Freshness

Each step uses a new key in this proposed scheme, which is a time-stamped relay random number. Thus, for each session, key freshness condition prevails.

4.3.8. Message Authentication

The AG receives the message M1 = (TOKEN_SM∥Q_SM∥T_AG∥R_AG∥(.h)). The first private key d_SM opens the message after verifying the time-stamped value T_SM = T_AG by matching with the hash value (.h) = (H). The SM receives the credential M2= (TOKEN_AG∥R_AG∥T_AG∥SK_AG∥(.h)). Here, the originality of the time-stamped T_SM = T_AG is checked with the hash value (.h) = (H), with the verifier SM = R_SM × P and R_AG = R_AG × P. Through this, stable messages can be achieved under authentication conditions and hash values that are not an attempt to guess at any adversary. Hence, the proposed protocol stands with secure message authentication with uncompromised message security and privacy.

4.3.9. Denial of Service Attack

A denial-of-service (DoS) attack is one that attempts to shut down a system or network, rendering it inaccessible to its intended users. The DoS attacks happen by flooding the target with traffic, or by flooding the target with information, which can cause a crash [35]. This proposed protocol is active in mitigating DoS attacks within SM to AG as well as transmission. Because of (M1, M2, M3), when any entity receives the first check validated time-stamped as T_SM = T_AG, it will have to verify the pseudo random number R_SM = R_AG. In this case, A tries to send a request to the intended user, but this is not possible without any knowledge of the above parameter. Besides, each execution generates new values and if somehow A can perform, the scenario request information will not match as it will detect an illegitimate user.

4.3.10. Session Key Security

This proposed scheme smart meter (SM) and aggregator point (AG) computes its session key by ECC based scalar multiplication group operation [36] thereby append such as, (TOKEN_SM∥Q_AG∥T_SM R_SM∥(.h)) and (TOKEN_AG∥R_AG∥T_AG∥SK_AG∥(.h)).This clearly indicates that SK_AG = SK_SM is similar in both directions, Thus, communication between (SM) and (AG) is secure. Furthermore, if SK_AG = SK_SM smart meter appended his/her TOKEN_SM and received TOKEN_AG, it will match session keys for the next message transmission. After getting the session key with appended message, the aggregator point (AG) checks the smart meter (SM),which is stored previously, if the same value appears, it will look a safe session key as well as during transmission, no values change. Hence, TOKEN_SM and TOKEN_AG preserve the session key security.

4.4. Security Analysis A (Formal)

The possibility of an attacker is included in the CK model. Three participants were involved in the proposed protocol: SM, AG, and TA. The act of TA is only performed in the registration phase. After that, handshaking between SM and AG is frequent. A can interact with a protocol participant Ѻ which is SM_i AG_j. Into the attacker interactions with the queries, every oracle backs to one of them, which is reject, accept, and ⊥. A can gain access to the public communication channel like an outcome, the message can be improved, replayed, new messages launched, and some messages rejected. Furthermore, because the trust authority is considered secure, A does not obtain any TA private information, thus, A can access all component and TA publicly available information; A can be an intruder or dishonest user for any system of the environment. Following queries are essential for description:

• h (messages): For this oracle inquiry, A supposes compute a random value 1 ≤ d ≤ n − 1 and h:{0, 1}^L as message hash value.
• Execution (SM, AG): This quiz is used to translate passive attacks, where the adversary detects messages that the participant changes during the protocol real-time execution.
• Transmit (Ѻ, messages): The query is fit for summarize an active attack, and it allows A to send message to Ѻ and received a response in accordance with the protocol description.
• Session key-Reveal (Ѻ): Provides oracle with information about an ephemeral secret to A.
• Session-Reveal (Ѻ): In this examination, A can be informed of the session key construct by Ѻ.
• Corrupt-Massage (Ѻ): This module indicates A can be used to obtain an oracle inlong time halt secret attributes from Ѻ.
• Expire-session (Ѻ): This operation deletes the session secret parameter from the oracle-built session.
• Test-Session (Ѻ): Assuming that the goal of this query is to determine well-formed security of SK,Ѻ. When a Test SK () request is issued, a neutral coin c is tossed; if c equals 1, the real SK is returned; if c equals 0, A randomly generated value of identical length is chosen and returned.

The following security definitions are addressed in order to ensure the proposed protocol conceptual security.

(1)

If the Oracle Ѻ = SM and the Oracle Ѻ = AG are mutually checked and identified establish a similar SK_SM and SK_AG that are said to be partners.

(2)

If the session key and corresponding session does not reveal any situation, we can call the session key is fresh.

(3)

If Pr(succ.) imply the possibility that the opponent will succeed in achieving goal, then the opponent advantage in breaching LIKA semantic security is a)Adv_LIKA (A) = |2_Pr(success) − 1|.

(4)

The proposed protocol is secure against the adversarial model if Adv_LIKA(A) ≤ ɛ holds [37].

Lemma 1.

(Difference Lemma). Suppose K₁, K₂ are the context of potential function K be the error event, in such a way: K₁˄¬ K⇔K₂˄ ¬, K Then |Pr[K1] − Pr[K2]| Pr ≤ [K].

Theorem 1.

Assume that A is a computation adversary of semantic security that comes close to challenges like to M_S sending the query, M_E executing query, M_H hash inquiries, and M_T pseudo-random number inquiries. |D| denotes the set equally spaced attributes. $Ad{v}_{EK}^{SE}$ Is advantage A over encryption or decryption ENC_K [38]. The benefits from LIKA protocol A are taken by:

$$\frac{\left({\mathrm{M}}_{\mathrm{L}}+{\mathrm{M}}_{\mathrm{P}}\right)}{\mathrm{L}+1}+\frac{{({\mathrm{M}}_{\mathrm{P}}+{\mathrm{M}}_{\mathrm{E}})}^2}{\mathrm{q}}+\frac{2{\mathrm{M}}_{\mathrm{P}}}{\left|\mathrm{D}\right|}+{\mathrm{Adv}}_{\mathrm{EK}}^{\mathrm{SE}}+2{\mathrm{M}}_{\mathrm{H}}\max \{{\mathrm{Adv}}_{\mathrm{ECDLP}}(\mathrm{A}), {\mathrm{Adv}}_{\mathrm{ECDHP}}(\mathrm{A})\}$$

Proof. 

To demonstrate LIKA semantic security, we present the game theory progression, where game 0 represents the active and passive attack holt behind game 5 represents the game in which A has no advantage. □

Game 0: The simulation of GM 0 is similar to the actual attack in the random oracle model we have

Adv_LIKA(A) = |2Pr [Succ₀] 1|

(1)

Game 1: In GM1, the following outcomes of emulating oracles for multiple executions of the queries are stored and recorded, making it impossible for an opponent to distinguish between two games. As a result:

Pr [Succ1] = Pr [Succ0]

(2)

Game 2: Game 2 scenarios are similar to game 1, with the exception that GM2 terminates if there is a collision across hash queries. According to the birthday paradox, the possibility of hash collision is at maximum and $\frac{\left({\mathrm{M}}_{\mathrm{L}}+{\mathrm{M}}_{\mathrm{P}}\right)}{\mathrm{L}+1}$ the likelihood of a transcribed collision is at $\frac{{({\mathrm{M}}_{\mathrm{P}}+{\mathrm{M}}_{\mathrm{E}})}^2}{\mathrm{q}}$ maximum, where L is the number of the hash function length.

Game 3: GM3 simulation is parallel to GM2 except that GM3 will be terminated if the verifier conditions are correctly predicted without consulting the oracle. Unless this valid authentication value is declined by the server instance, GM3 and the last game are indistinguishable. Thus:

$$\mathrm{Pr} [\mathrm{Succ}3]=\mathrm{Pr} [\mathrm{Succ}2] \le \frac{\left({\mathrm{M}}_{\mathrm{P}}\right)}{\mathrm{L}}$$

(3)

Game 4: In GM4, we consider the suggested protocol session key reliability. The security goal of LIKA is that A cannot achieve the mutual session key. The goal SK wrap, zero knowledge by A thus the SK holds by

Pr [Succ4] = Pr [Succ3] holds SK_SM × Q_AG.G and SK_AG × Q_SM.G = SK_{SM =} SK_AG

(4)

Event 1: Corrupt (SM) and Corrupt (AG). This event is supposed to be A obtaining SM and AG private keys, i.e., (Ѻ) and SK, but not their temporal secrets in terms of them being hidden by Q_AG×G point without having knowledge that it does not reveal.

Event 2: Session-reveal (SM) and session-Reveal (AG). In this case, we assume that A obtains SM and AG public parameter but not their secret keys. Without initially getting the session key, it is impossible to solve the SK in the following instances it should settle the hash function or crack ECDLP and ECDHP mathematical solution which is infeasible due to the hard and complex equation. As a result, the ECDHP or ECDLP holds, and it is concluded that:

Pr [Succ4] = Pr [Succ4] ≤ SK_AG × Q_SM.G +M_L {Adv_ECDLP (A), Adv_ECDHP (A)}

Game 5: GM5 is the same as the previous game, except that if you publish a test ID instead into the act as anonymous SM_TOKEN, AG_TOKEN query to get the actual identity which is not easy to retrieve due to it exits secure channel between trusted authority, the otherwise revealed test inquiry of this game will be disclose and A will win the game 5. As a result, we deduce:

$$\mathrm{Pr} [\mathrm{Succ}5]=\mathrm{Pr} [\mathrm{Succ}4] \le \frac{2{\mathrm{M}}_{\mathrm{P}}}{\left|\mathrm{ID}\right|}+{\mathrm{Adv}}_{\mathrm{EK}}^{\mathrm{PE}}(\mathrm{A})$$

(5)

As a result, A without performing a hash query and private key with the true input has no position in distinguishing the actual SK from use by a random one, Pr [Succ6]. We can conclude that the theorem holds by adding all of these probabilities. In Algorithm 3 illustrate the random oracle simulation model.

Algorithm 3. Simulation of Random Oracles.

Simulation Queries

Hash queries (p). If p is found in the index list of TL (p), the value L (p) is returned. Otherwise, a randomly generated value will be appended to L:{0, 1} for A

For the send(SM, start) query, the SM oracle must first log in(Registration) to the server with a login request attemptID and PW are chosen Select ID = SMID Select pw = SMPW Then respond with message C = { SMID, SMPW}

For the send (SM, {SMID, SMPW}) query the TA oracle simulate the following process: Check IDSM= IDSM into TA database Check PW = PW into corresponding ID ComputeTokenSM Then respond with message C = {TokenSM}

For the send (TA, {TokenSM}) query the SM oracle simulate: Store TokenSM

For the send(SM, start) query, the SM oracle secondly toward to mutual authentication: A random number PSM ∈ Zp* private key, and public key is calculated by as QSM = dSM × G Select = TokenSM Select public key = QAG Compute = TSM Compute SM = RSM × P Compute hash (H) = (.h) Then respond with message E { M1 = TokenSM∥QAG∥TSM∥RSM∥(.h)}

For the send (SM, { TokenSM∥QAG∥TSM∥RSM∥(.h)}) query the AG oracle simulate the following steps: Calculates private key = dAG to extract message Validity check of (H) = (.h) Validity check of = TSM ≤ TAG Verify pseudo number AG = RSM × GP StoreTokenSM Generates RAG = RAG × P Select = TAG

Select = TokenAG Calculates = SKAG Then respond with message E { M2= TokenAG∥RAG∥TAG∥SKAG}

For the send (AG, { TokenAG∥ RAG ∥ TAG∥ SKAG query the SM oracle simulate Compare TAG ≤ TSM Calculates SKAG = SKSM Select = TokenAG Select = TSM Then respond with message E { M3 =SKSM∥TokenAG∥TSM}

For the send (SM, { SKSM∥TokenAG∥TSM}) query the AG oracle simulate Verify SKAG = SKSM Verify = TSM ≤ TAG Check = TokenAG= TokenAG Send:M4 = ACK_massage to SM

For execute (SM and AG) using the following send queries first retain {TokenSM } ← TA in secure channel then {M1, M2,}← send (SM, start), and {M1, M2,}← send (AG, start) then return them to A

For a Session-Reveal(Ѻ) inquiry, re-back the session key if Ѻ has actually generated the session key and both Ѻ and its partner have not been asked by a test query or return null.

For a Session key-𝑅𝑒𝑣𝑒𝑎𝑙(Ѻ) inquiry, if Ѻ= SM return ai; else; if Ѻ= AG return.

For a 𝐶𝑜𝑟𝑟𝑢𝑝𝑡 (Ѻ) inquiry, if Ѻ= SM return SM𝑟; else, if Ѻ= AG return AG𝑟

For a 𝑇𝑒𝑠𝑡 (Ѻ) queries, firstly get the session key of Ѻ from the session (Ѻ) test; then, tossed a coin, if 𝑐 = 1, return value of the session key, or else, return generated value with the same length to A

4.5. Security Analysis B (Formal)

Formal assessment 2 was adopted based on schemes [9,14,29] to propose a protocol of mutual authentication and forward secrecy between a smart meter and an aggregator point. This section critically verified the proposed protocol used by Avispa, which is a kind of role-based tool that measures the security of a cryptographic method automatically like public key infrastructure, encryption, decryption, and signature generation, hash function while symmetric encryption and decryption handled within the system. It supports unlimited simulation of session keys and message basements and is effective in determining protocol accuracy. Avispa is a set of applications that enable automatic verification with different backsides of Internet security protocols and applications.

Some examples include the On-the-Fly Model Checker (OFMC) and the Constraint-Logic-based Attack Searcher (Cl-AtSe). Avispa scripting is done entirely in a role-based language known as high level protocol specification language (HLPSL). According to principles of Avispa, specifications are based on the protocol that all states whether it is acceptable in terms of active and passive attackers with the assistance of the given proposed protocol. Further, this suggested protocol provides forward secrecy and authentication for the SK1, SK2 during smart meter and aggregator point session.

To validate the proposed protocol, Avispa was implemented usingSpan-Ubuntu10.10 light into OracleVM virtual box version 6.1.18 which is open source application developed by University of Genova from FET project. Span is a core application for written scripting according to setup protocol (refer to

Table 2. Avispa role specification.

role smart meter (A, B: agent, m1: text, %H is SHA512 hash function %ECDH is elliptic curve DH function H: hash_func. EC: hash_func Ka, Kb: public_key, SND_B, RCV_B: channel (dy)) played_by the initiator smart meter def= local State: nat ID, Qag, Tsm, Rsm: text, H: hash_func M1: text, init State:= 0 transition 1. State = 0 /\ RCV_B(start) =|> State’:= 1 /\ M1:= new() % Send the mutual authentication request to AG /\ ID’:=(ID) /\ Qag’:= (dsm × G=Qsm) /\ Tsm’: = (Tsm × G) /\ Rsm’: = (Rsm × G) /\ Snd_A(ID’.Qag’.Tsm’.Rsm’.H) 2. State = 0 /\ RCV_M2 (ID, Tsm, Rsm, Sk1) =|> State’:= 1 /\ M2:= new() % Received acknowledgement from AG /\ ID’:=(ID) /\ Tsm’: = (Tsm × G) /\ Snd_M3 (M, ID, Tsm, SK2) role session(A, B: agent, Ka, Kb: public_key, G: text, H: hash_func) def= local ID, Tsm, Rsm, H: channel (dy) composition SM(ID, Tsm, Rsm, a, b, p, G, n, h) /\ AG(ID, Tsm, Rsm, a, b, p, G, n, h) end role

role environment() def= const sk1,sk2: protocol_id, a, b: agent, ka, kb, Qsm: public_key, M1,M2,M3: text, H: hash_func Intruder_knowledge = {Qsm, Qag, a, b, G, h, n, p} composition session(a, b, G, n, h, p, Qsm, Qag, Tsm, Rsm, H) /\ session(M, Tsm, ID, SK1, SK2) end role goal %secrecy_of SK2 secrecy_of sec_a_SK,2 sec_b_SK1 % Smart meter authenticates on Ag sk1 authentication_on sk1 % Addresses M1, M2, M3 %Aggregator point authenticates on sk2 authentication_on sk2 % Addresses M1, M2, M3 end goal environment() >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> role aggregator point (B, A:agent, m1: text, %H is SHA512 hash function %ECDH is elliptic curve DH function H: hash_func. EC: hash_func. Kb, Ka: public_key, SND_A, RCV_A: channel (dy)) played_by responder aggregator point def= local State: nat ID, Qsm, Tsm, Rsm: text, H: hash_func M1: text, init State:= 1 transition % Mutual authentication phase % Received the authentication request 1. State = 0 /\ RCV_M1(ID’.Qag’.Tsm’.Rsm’.H) =|>

State’:= 1 /\ secret {ID, Tsm, Rsm, H}(A) /\ secret {H, Tsm, Rsm, Tsm}(B) %send the mutual authentication acknowledgement to SM /\ ID’: = TA(ID) /\ Qag’:= dsm × G(Qag) /\ Tsm’:= Tsm × G /\ Rag’:= Rsm × Gp /\ H’:= H=h’ % Send M2 to SM /\ Snd (ID, Tsm, Rsm, SKag) 2. State = 0 /\ RCV_M3 (M, ID, Tsm, Sk1) =|> State’:= 1 /\ M3:= new() % Received acknowledgement from SM /\ ID’:=(ID) /\ Tsm’: = (Tsm × G) /\ Rsm’: = (Rsm × Gp) /\ SK2′: = (SK1=SK2) role session(A, B: agent, Ka, Kb: public_key, G: text, H: hash_func) def= local ID, Tsm, Rsm, H: channel (dy) composition SM(ID, Tsm, Rsm, a, b, p, G, n, h) /\ AG(ID, Tsm, Rsm, a, b, p, G, n, h) end role role environment() def= const sk1,sk2: protocol_id, a, b: agent, ka, kb, Qsm: public_key, M1,M2,M3: text, H: hash_func intruder_knowledge = {Qsm, Qag, a, b, G, h, n, p} composition session(a, b, G, n, h, p, Qsm, Qag, Tsm, Rsm, H) /\ session(M, Tsm, ID, SK1, SK2) end role goal %secrecy_of SK1 secrecy_of sec_a_SK2, sec_b_SK1 % Aggregator point authenticates on Ag sk2 authentication_on sk2 % Addresses M1, M2, M3 % Smart meter authenticates on sk1 authentication_on sk1 % Addresses M1, M2, M3 end goal environment()

) for superior perception, which is performed in HLPSL, while the Dolve–Yao model has been considered an intruder model [39]. The security of this protocol is discussed under the role of the user agent (SM) and for another user (AG) as dummies named A and B, respectively. There are four roles in Span to justify the testing protocol, namely user agent, smart meter, and aggregator point. In this role section, both parties contain their parameters to transfer the value between them to verify the purpose in Span. Then, the state section describes which parameters pass by using SND () and RCV () functions within the two parties to establish the session. After validating a specific function and formulating it, the composition event section declares the number of identical parameters this event occupied to a common parameter, which are examined prior to each other in order to initiate a session. Moreover, the results section responsible for analysing the proposed protocol by two model checkers are known as (OFMC) and (Cl-AtSe). Lastly, after evaluating those sections, Span will declare the status as safe or unsafe. Notable in the case for LIKA, it produced a safe status from active and passive attackers, while it evaluated the number of sessions and piles operation handled by A, B to strongly manage authentication between SK1, SK2 and forward secrecy. Figure 3 shows that the proposed protocol is safe for attack scenarios.

4.6. Security Features Comparison

In this section, the security features offered by the built authentication and key agreement protocol are evaluated based on the current solution.

Table 3. Notation of the Security Features.

A1	Replay attack
A2	MITM (Man in the middle)
A3	Impersonation Attack
A4	Forward secrecy
A5	Support Anonymity
A6	Eavesdropping
A7	Massage authentication
A8	Session key security
A9	Key freshness
A10	Dos Attack
A11	Guessing attack
A12	Mutual Authentication
A13	Three-way security proof

demonstrates the notation of the security comparison based on [40], the names of the attacks in forming from A1 to A13. Additionally, √ is presented for able to protect the following protocols, beside × used for unable to fix the attack scenario.

Table 4. Comparison Security Features.

Protocols	A1	A2	A3	A4	A5	A6	A7	A8	A9	A10	A11	A12	A13
[16]	√	√	×	×	×	√	×	×	×	×	√	×	×
[40]	√	√	×	√	√	×	×	×	×	×	√	√	×
[17]	√	√	√	√	√	×	×	√	×	×	×	√	×
[41]	√	√	√	√	√	√	√	×	×	×	×	√	√
[1]	√	√	√	√	×	×	×	×	×	√	√	×	×
[12]	√	√	√	√	×	×	×	×	×	√	×	×	×
[42]	√	√	√	√	√	√	×	×	×	×	√	×	×
[43]	√	√	√	√	√	×	×	√	×	√	×	√	×
[9]	√	√	√	√	√	√	×	×	√	√	√	√	×
[14]	√	√	√	√	×	×	×	√	√	×	√	√	×
[15]	√	√	√	√	√	√	√	×	√	√	√	×	×
[25]	√	√	√	√	√	√	×	×	×	×	√	×	√
[27]	√	√	√	√	×	×	×	√	×	×	×	×	×
Proposed	√	√	√	√	√	√	√	√	√	√	√	√	√

indicated that the [16] protocol covered A1, A2, A6, A11, although it does not withstand the rest of the security features. Similarly [40] protocol kept A1, A2, A4, A5, A11, A12 and others features were unable to manage in their methodology. Then [17] worked efficiently maintain A1 to A4 and A8, A12 but failed against A6, A7 and A9 to A12. Protocol [41] was able to protect A1 to A7, A12, A13 beside failing against A8 to A11. Then protocol [1] achieved A1, A2, A3, A4, A7, A9, A11, but was unable to protect A5, A6, A8, A10, A12, A13 [12]. According to the protocol [42] security analysis claimed that kept A1 to A6, A11 and protocol [43] preserve A1-A5, A8, A10, A12 but the rest of the features was not covered by the following work. After protocols [25] managed A1 to A6, A11, A13 along does not withstand the rest of the security features. Then the protocol [27] withstand A1 to A4 and A8 but unfortunately unable to protect the rest of the features. Similarly the protocol [9] performed almost the same with the proposed protocol, but unfortunately it does not secure against A7, A8, A13. Moreover, The [14] protocol managed A1, A2, A3, A4, A7, A11, and A12, but does not withstand A5, A6, A8, A9, A10. After that [15] tackled a number of multiples attack known as A1 to A7, A9, A10 before it failed against A8, A12, A13, this is nearly close to the proposed protocol where the proposed work provides larger security features that ensures three-way security confirmation, namely informal cryptographic parameter analyses and CK adversarial basis, and then formal assessment employed by Avispa to following protocol to withstand A1 to A13 security features.

4.7. Performance Analysis

This section discusses the performance analysis of the proposed protocol against previous works.

I.

Computation Time

In order to use the implementation model and platform scenario for smart meter to aggregator point for LIKA adopted from protocol [24], which are the SM and AG point, consider two devices (1) computer Asus Intel(R) Core i5-8265U, [email protected] GHz and 4 GB RAM (2) Raspberry PI 4, type B terminal with RAM 4GB. The purpose of data pre-processing for [12,17,18,40,41] schemes computation time were taken from [9,15,27] portal. The computation time of the previous protocols along with the proposed protocol based on various cryptographic operations run time performed using python version 3.4 into crypto library with associating import time module function [44], which is open sources programming language developed by python software foundation 20 February 1991. Following cryptographic execution operation performed among SM to AG as follow: T_PA: Times for point addition ≅0.097 ms, T_PM: Times for point multiplication≅0.141 ms, T_E/D: Time for encryption/decryption ≅2.270 ms. Moreover, hashlib was used for generating T_HO: Time of hash operation ≅0.024 ms, then T_RN: Time of random number generator ≅ 0.009 ms and Ti: Time stamp expenses are ≅0.048 ms, T_BP= Time of bilinear pairing ≅3.32 ms [1,17] then T_PK^E/D= Time public key encryption/decryption = 3.85 ms [14,15], and 1T_HMAC = Time for keyed hash message authentication code ≅ 0.0046 ms [12,14,42].

Part of the production of access tokens from the trusted authority setting are accomplished through the use of OpenSSL that acts as TA, according to link and preservation ID and password of smart meter and aggregator point information utilized structured query languages and hypertext processors database system.

According to

Table 5. Computations Time of the Previous/Proposed Protocols.

Serial Number	Protocols	Cryptographic Operation	Time (ms)	Compares*
1	[16]	4TME + 4TPKED + 2THO	≈30.80	−25.48
2	[40]	10TPM + 2TESED + 5THO	≈22.28	−16.96
3	[17]	5TPM + TB+ 2ECC PA + 10H	≈25.28	−19.96
4	[41]	6TME + 4TESED+ 4TPKED + 2THMAC	≈22.39	−17.07
5	[1]	2ECC PM + 2ECC PA + 10H	≈18.34	−13.02
6	[42]	1TPM+ THMAC+ TH	≈16.16	−10.84
7	[43]	3Tm + 3Ta + 3TH	≈11.92	−6.60
8	[12]	6TME + 4TESED + 2THO + 2THMAC	≈26.96	−21.64
9	[14]	4TME + 4TPKED + 2THMAC	≈15.01	−9.69
10	[9]	4Tm + 8Th	≈11.91	−6.59
11	[15]	TPA + TESED + THMAC + TME + TPKED + TPM + THO	≈17.80	−12.48
12	[25]	5Tsm + 3Th+5Tsm + 3Th	≈20.98	−15.66
13	[27]	2ECC PM+ 3TB+3Th	≈17.86	−12.54
14	Proposed	2TPA+ 2TPM+ 2TE/D+ 2TPRNG+ 3TTS+ 1TTOKEN+ 2HO	≈5.319	0

Compare* mean = proposed protocol minus (-) computation time from given protocols.

the heading interpretation proposed protocol required cryptographic operation, 2 times for point multiplication = 0.141 × 2 ms + 1 time encryption/decryption = 2.270 × 2 ms + 1time of hash operation = 0.024 ms + 2 time random number generator + 0.009 × 2 ms + 3 time-stamp ≅0.048 × 3 ms. This brings the total time expenses = (5.319 ms) for session key generation between smart meter to aggregator point. Existing works refs. [16,17,40] protocol took 30.80, 25.28, 22.28 ms. While protocols [1,12,14,41,42,43] expenses were approximately 18.34, 26.96, 15.01, 22.39, 16.16 and 11.92 ms. Furthermore, refs. [9,15,25,27] took 11.91, 17.80, 20.98, 17.86 ms respectively. According to the data link in Figure 4, the yielded value shows that the proposed protocol needed fewer computation times than existing protocols.

• The computation cost proposed protocol 2T_PA+ 2T_PM+ 2T_E/D+ 2T_PRNG+ 3T_TS+ 2_TOEKN is 5.319 ms.
• The computation cost of the protocol [16] 4T_ME + 4T_PKED + 2T_HO is 28.80 ms which is 82.73%higher than the proposed protocol.
• The computation cost of the protocol [40] 10T_PM + 2T_ESED + 5T_HO which is 76.12%higher than the proposed protocol.
• The computation cost of the protocol [17] 5T_PM + TB+ 2^ECC _PA + 10_H which is 78.95% higher than the proposed protocol.
• The computation cost of the protocol [41] 6T_ME + 4T_ESED+ 4T_PKED + 2T_HMAC which is 76.24% higher than the proposed protocol.
• The computation cost of the protocol [1] 2^ECC _PM + 2^ECC _PA + 10_H which is 70.99% higher than the proposed protocol.
• The computation cost of the protocol [42] 1T_PM + T_HMAC + T_H which is 27.91% higher than the proposed protocol
• The computation cost of the protocol [43] 3Tm + 3Ta + 3Th which is 55.37% higher than the proposed protocol
• The computation cost of the protocol [12] 6T_ME + 4T_ESED + 2T_HO + 2T_HMAC which is 80.27% higher than the proposed protocol.
• The computation cost of the protocol [14] 4T_ME + 4T_PKED + 2T_HMAC which is 64.56% higher than the proposed protocol.
• The computation cost of the protocol [9] 4Tm + 8^Th which is 55.34% higher than the proposed protocol.
• The computation cost of the protocol [15] T_PA + T_ESED + T_HMAC + T_ME + T_PKED + T_PM + T_HO which is 70.11% higher than the proposed protocol.
• The computation cost of the protocol [25] 5Tsm + 3Th+5Tsm + 3Thwhich is 74.64% higher than the proposed protocol
• The computation cost of the protocol [27] 2^ECC _PM+ 3T_B+3T_h which is 70.21% higher than the proposed protocol

II.

Communication Bits

The communication bits cost of the proposed protocol is presented in

Table 6. Comparison Communication Bits among Previous Protocols.

Serial Number	Protocols	Forward Massage	Communication Cost (bits)	Compares*
1	[16]	3	≈4416	−3360
2	[40]	4	≈3158	−2102
3	[17]	4	≈2897	−1841
4	[41]	2	≈1792	−736
5	[1]	3	≈1440	−384
6	[42]	2	≈832	+224
7	[43]	2	≈544	+512
8	[12]	2	≈2752	−1696
9	[14]	2	≈1984	−928
10	[9]	3	≈1250	−194
11	[15]	2	≈1152	−96
12	[25]	2	≈1120	−64
13	[27]	2	≈1465	−409
14	Proposed	3	≈1056	0

Compare* mean = proposed protocol minus (-) communication bits from given protocols.

and compared with against existing protocols. This calculation was dependent on the number of messages sent and received by the smart meter and aggregator point, the number of bits connected with each transmission process during the session key generation in terms of which is performed in the key generation, registration and authentication phases. The size of the parameter constructed into the proposed protocol is carried on random 128 bits, ECC encryption and decryption 320 bits, time-stamps taken 64 bits with access token that consist of 64 bits and hash function 128 bits. The protocols communication costs transmission is determined by the number of messages 1, 2 and 3 transmitted bits associated with each handshaking process for session key generation. According to Table 6 value schemes [1,9,16] utilized three message expense are 1440, 1250 and 4416 bits. Consequently [17,40] protocols used four message that took 2897 and 3158. Protocols [12,14,15,25,27,41,42,43] forwarded two massage needed 1752, 1984, 1152, 1120, 1465, 1792, 832 and 544 bits respectively. Finally, the proposed protocol employed three messages transmitted between the smart meter and aggregator point for entire session key generation, which is cost 1056 bits. As per displayed in Table 6 the proposed methodology efficiency is depicted in Figure 5. We conclude that, the proposed protocol requires less communication bits than other related existing schemes.

• The communication cost of the proposed protocol used 3 message which is required 1056 bits
• The Protocol [16] utilized 4416 bits, which is approximately 76.08% higher than the proposed protocol
• The Protocol [40] utilized 3158bits, which is approximately 66.56% higher than the proposed protocol
• The Protocol [17] utilized 2897 bits, which is approximately 63.54% higher than the proposed protocol
• The Protocol [41] utilized 1792 bits, which is approximately 41.07% higher than the proposed protocol
• The Protocol [1] utilized 1440 bits, which is approximately 26.66% higher than the proposed protocol
• The Protocol [42] utilized 832 bits, which is approximately 21.22% lower than the proposed protocol
• The Protocol [43] utilized 544 bits, Which is approximately 48.48% lower than the proposed protocol
• The Protocol [12] utilized 2752 bits, which is approximately 61.62% higher than the proposed protocol
• The Protocol [14] utilized 1984 bits, which is approximately 46.77% higher than the proposed protocol
• The Protocol [15] utilized 1152 bits, which is approximately 8.33% higher than the proposed protocol
• The Protocol [25] utilized 1120 bits, which is approximately 5.71% higher than the proposed protocol
• The Protocol [27] utilized 1465 bits, which is approximately 27.91% higher than the proposed protocol

III.

Performance Comparison

In this section, we compare the systems performance of prior schemes to the proposed protocol.

Comparative performance comparison depend on features F1: Mutual authentication; F2: Forward secrecy; F3: Anonymity; F4: Three-way security proof (CK, Avispa/ProVerif and Informal); F5: Computation time= compare*; F6: Communication bits= compare*; F7: Lightweight Computation time Yes = 15>, No = <15; F8: Lightweight Communication bits Yes = 1500>, No =< 1500; NA: Not available; Hence, Yes is specify to reserve and No is unable to reserve following protocol. Since this comparison conducted from Table 4, Table 5 and Table 6, then we get the

Table 7. System Performance Comparison.

	2011 [16]	2012 [40]	2014 [17]	2016 [41]	2018 [1]	2018 [12]	2019 [42]	2019 [43]	2019 [14]	2020 [9]	2020 [15]	2021 [25]	2021 [28]	Proposed
F1	Yes	Yes	Yes	NA	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	Yes	Yes
F2	Yes	No	No	NA	No	Yes	Yes	No	Yes	Yes	Yes	No	Yes	Yes
F3	No	No	No	NA	Yes	No	Yes	Yes	No	Yes	Yes	Yes	No	Yes
F4	No	No	No	No	No	Yes	No	No	Yes	No	Yes	Yes	Yes	Yes
F5	−25.48	−16.96	−19.96	−17.07	−13.02	−9.69	−1084	−6.60	−9.69	−6.59	−12.48	−15.66	−12.54	0
F6	−3360	−2102	−1841	−736	−384	−928	+224	+512	−928	−194	−96	−64	−409	0
F7	No	No	No	No	Yes	Yes	Yes	Yes	Yes	Yes	No	No	No	Yes
F8	No	No	No	No	Yes	No	Yes	Yes	No	Yes	No	Yes	No	Yes

. Based on the table proposed protocol is ahead from entire competitive scheme. The proposed protocol retains greater number system features than existing work. Additionally, it demonstrated that it covers both security and performance aspects within the protocol. Besides, as per table interpretation previous schemes unable to integrate full of features into their schema.

5. Conclusions

Smart grids are a perfect fit for our rapidly connecting world and assure security and performance within the following field of utmost important to governments, businesses, academia, and so on. To address existing security and performance constraint, this paper proposed a lightweight identity based key agreement protocol that leverages on the elliptic curve Diffie–Hellman cryptography and used obey parameters for smart meter to aggregator points premises in advanced metering infrastructure. The proposed protocol combines security and performance features halt inside the same protocol. Security assessments were evaluated both in formal and informal aspects. In order to ensure security functionality, the proposed protocol was thoroughly tested by the CK adversary model and cryptographic parameters, which returned strong evidence to maintain forward secrecy and anonymity in term of preserving the mutual authentication. Furthermore, random oracle judgment declared that the session key does not consider any unauthorized user for interruption during session key generation. Consequently, the Avispa tool confirmed the designed key agreement approach is safe from multiple attacks scenarios. Further, performance analyses illustrated proposed protocol substantially reduced computation time and bit overheads. The execution depends on undergoing a three phase mechanism for the entire parameter computation operation expenses 5.319ms. Moreover, communication progression involved 3-way handshaking which took 1056 bits. Surprisingly, the outcome of the assessments indicated that the overheads cost 1/3 of the previous scheme for session established among smart meter to aggregator point.

Despite this, a security evaluation ensures that reciprocal authentication is maintained within minimum time and bits expenses compare than other protocols. However, the protocol for smart meter and aggregator point side overheads are mostly similar. Besides, a smart meter contains limited resources, power and processing capabilities, the suggestion of this study though proposed work noteworthy, decreased overall time and bits operation. Besides, it will be diminished more in the smart meter end. In the near future, a smart grid context will be able to comply with the proposed protocol in a broad manner. With one recommendation, the mutual identity is balanced for vice versa devices, sensor, machine, and platform in smart grid of AMI. Finally, it is hoped that hierarchical architecture of key agreement protocols should improve the smart grid platform, robustness dynamism and secure.