Hasen Nicanfar IEEE ProofWeb Version - UBC ECEvleung/Accepted_Journals/Hasen_TSG_2013.pdfIEEE...

IEEE

Pro

of

Web

Ver

sion

IEEE TRANSACTIONS ON SMART GRID 1

Multilayer Consensus ECC-Based PasswordAuthenticated Key-Exchange (MCEPAK) Protocol

for Smart Grid SystemHasen Nicanfar, Student Member, IEEE, and Victor C. M. Leung, Fellow, IEEE

Abstract—This paper aims at providing a key agreementprotocol for smart grid to cope with access control of appli-ances/devices located inside a Home Area Network (HAN) bya set of controllers outside the HAN. The commands/packetsinitiated by the controllers in crisis cases should be delivered fastand immune from any interruption. The HAN controller, whichacts as a gateway, should not cause any delay by decrypting andre-encrypting the packets, nor should it has any chance to modifythem. Considering the required level of security and quality of ser-vice, we design our protocol with an Elliptic Curve Cryptography(ECC) approach. We improve and implement the Password Au-thenticated Key Exchange (PAKE) protocol in two steps. First, wepropose an auxiliary mechanism that is an ECC version of PAKE,and then extend it to a multilayer consensus model. We reduce thenumber of hash functions to one, and utilize a primitive passwordshared between an appliance and HAN controller to constructfour valid individual consensus and authenticated symmetric keysbetween the appliance and upstream controllers by exchangingonly 12 packets. Security analysis presents that our protocol isresilient to various attacks. Furthermore, performance analysisshows that the delay caused by the security process is reduced bymore than one half.

Index Terms—Access control, consensus, ECC, ECDH, hierar-chical control, multilayer, PAKE, security, smart grid.

I. INTRODUCTION

R APID developments of smart grid (SG) systems in recentyears have led tomany technical issues that have attracted

much attention from the systems, communications and securityresearch communities. Among these, some of the most impor-tant and challenging issues are concerned with the appropriatesecurity and privacy levels in the SG context [1]. SG is a crit-ical infrastructure, but the widespread incorporation of wirelesstechnologies in SG makes it vulnerable to attacks that can causedifferent levels of harm to the SG system, individual devices oreven society at large [2].Security is one of the key challenges of the SG communica-

tion infrastructures as presented in [3]. In this paper, we pro-pose a key agreement protocol for secured access control in ahierarchical architecture for the SG communication infrastruc-ture with different layers between smart appliances in users’

Manuscript received April 01, 2012; revised September 16, 2012; acceptedOctober 02, 2012. This paper is based in part on a paper appeared in proceedingof the First IEEE International Workshop on Security and Forensics in Com-munication Systems (SFCS), June 2012. This work was supported in part bythe Natural Sciences and Engineering Research Council (NSERC) of Canadathrough grant STPGP 396838. Paper no. TSG-00180-2012.The authors are with the WiNMoS lab, Department of Electrical and Com-

puter Engineering, the University of British Columbia, Vancouver, BC V6T1Z4, Canada (e-mail: [email protected] and [email protected]).Color versions of one or more of the figures in this paper are available online

at http://ieeexplore.ieee.org.Digital Object Identifier 10.1109/TSG.2012.2226252

premises and upstream controllers of the Home Area Networks(HANs), Building Area Networks (BANs) and Neighbor AreaNetworks (NANs), and SG Central Controllers (SGCC), whichare located in distribution networks or substations [4]. Typically,the HAN controller is a smart meter (SM) that serves as thegateway to the user’s premise. Such a protocol provides a se-cured means for controllers upstream of the HAN controllersto access and control the smart appliances in users’ premises,e.g., to modify the thermostat setting of the homes heating, ven-tilation and air condition (HVAC) systems when a brown-out isimpending. This study is independent of the technologies usedfor the SG communications; i.e., our work is equally applicablewhether power line communications (PLC) or wireless tech-nologies are used in any of the layers.Various existing controlling commands that may be sent to a

smart appliance from outside the HAN have been consideredin [5]. For instance, a NAN controller (located outside a HAN)may supervise electric charging of a plug-in electric vehicle(PEV) located inside the HAN. Also, in the case of a disasteror an emergency, SGCC may need to remotely turn off low-pri-ority high-demand appliances. In such operations, the HANcontrollers should not interfere with and delay such commandsby decrypting and re-encrypting the corresponding packets.Therefore, we need to address the appropriate secrecy level inthe SG control system design while providing the quality ofservice (QoS) required in terms of keeping the command-re-sponse delay within an acceptable limit.Contributions: In this paper, we present two protocols. The

first one is an auxiliary model of an Elliptic Curve Cryptography(ECC) based Password Authenticated Key Exchange (PAKE)protocol (EPAK protocol) that can be used in any environmentand application. The second one, which is our main work, isa Multilayer Consensus EPAK (MCEPAK) protocol developedfor communications in the SG control system.The scope of the work is shown in Fig. 1, which addresses

communications in up to four layers between a home appliance, HAN controller , BAN controller , NAN controllerand SGCC . We consider the SG controllers with the hi-

erarchical architecture share common secrets and are designedto be trust-worthy to each other. Precisely, we assume that con-trollers have a pre-established trust relationship; i.e., they are al-ready authenticated to the upstream and downstream controllersif any, and are able to communicate with the neighbors in asecure fashion. When a smart appliance joins a HAN, it alsoneeds to share a common secret (assumed to be a simple pass-word) with the HAN controller for it to be trusted in the HAN.The question is how to extend this trust to multiple controllersin a secure and efficient manner. Moreover, our proposal ad-dresses the requirement that each controller needs to set up asecure and private communication channel with , with any

1949-3053/$31.00 © 2012 IEEE

IEEE

Pro

of

Web

Ver

sion

2 IEEE TRANSACTIONS ON SMART GRID

Fig. 1. Required symmetric keys.

controllers in between simply acting as a part of the commu-nication connection without participating in the security opera-tions. Based on assumption of sharing a primitive password by

and , we derive four individual consensus password-au-thenticated symmetric keys between and the upstream con-trollers.A symmetric key agreement is mostly based on the Diffie

and Hellman (D-H) protocol [6]. Furthermore, the key con-struction utilizing a pre-shared password for mutual authenti-cation is known as the PAKE protocol. This paper is an exten-sion of our preliminary proposal in [7] called the Smart GridMultilayer Consensus Password Authentication Key Exchange(SG-MCPAK) protocol, which is designed based on the D-Halgorithm. The logic behind the SG-MCPAK and MCEPAK al-gorithms are the same, andMCEPAK can be considered as ECCversion of SG-MCPAK.We review ECC along with the D-H and PAKE protocols in

Section II and then present our EPAK protocol in Section III.Then, we describe our MCEPAK protocol, which is an extendedversion of the EPAK, in Section IV. Analysis of our protocolsis presented in Section V, and finally the paper is concluded inSection VI.

II. RELATED WORK AND BACKGROUND REVIEW

There are various solutions for constructing a symmetric keyand an asymmetric key. Generally speaking, most of them areoriginally based on the D-H protocol for symmetric key, andElGamal algorithm [8] and RSA for asymmetric key. Each in-troduction of a new crypto-system has led to further work toaddress various attacks like Man-In-The-Middle (MITM). Toprevent the attacks, the author of [9] proposed a solution that uti-lizes a password to assure the secrecy required for the key agree-ment messages. A two-step PAKE protocol called Simple Au-thentication andKeyAgreement (SAKA) is presented in [10]. InSAKA, both parties convert their shared password to a number.Then, each party randomly selects a number and multiplies it tothe shared number to be used in the D-H algorithm. Authors of[11] showed that SAKA is resistant to password guessing attack.In [12], a light-weight and robust PAKE for smart card (SC) ispresented, which identifies and delivers an entity-server mutualauthentication. The scheme supports only one SC per device andrequires SC management. Furthermore, each SC is only utilizedfor two-party authentication, which limits its usefulness in SG.In [13], a three steps PAKE protocol is presented to resist dictio-nary, password compromise impersonation and ephemeral keycompromise impersonation attacks, and to supply forward se-crecy.

Fig. 2. PAKE Protocol: X.1035 Standard.

The mechanism presented in [14] reduces the number of re-quired hash functions while changing the parameters accord-ingly, which is a concept that we use in our design. The groupPAKE protocol in [15] considers that each user has an individualpassword shared with the server. The model does not meet theSG requirement of having an individual symmetric key betweenan appliance and each controller. The concepts of temporarysession key as well as password verifiers are proposed in [16].In 2009, the IEEE 1363.2 standard [17] for password based

public key cryptographic techniques was released. The standardspecifies primitives and schemes designed to utilize passwordsand other low-grade secrets as a basis for securing electronictransactions. To be more precise, the standard specifies theschemes for password-authenticated key agreement and pass-word-authenticated key retrieval.

A. X.1035 Standard

The PAKE protocol presented in the X.1035 standard [18]presumes that two parties share a password . The four-phasemutual authentication protocol defined in the X.1035 standardconstructs a symmetric cryptographic key via D-H exchangeby employing D-H values and five shared hash func-tions . Depicted in Fig. 2, in the following phases,

are the IDs of two parties named Alice and Bob,respectively, , and are the re-spective random numbers chosen by them:1) Step I: Alice obtains (1) and forwards it to Bob:

(1)

On the other side, Bob extracts “ ” from by (2):

(2)

2) Step II: Bob computes following (3) and (4), andsends them to Alice

(3)

(4)

Alice also similarly obtains “ ” from per (5) andthen calculates per (6) for the verification

(5)

(6)

IEEE

Pro

of

Web

Ver

sion

NICANFAR AND LEUNG: MCEPAK PROTOCOL FOR SMART GRID SYSTEM 3

3) Step III: Alice computes via (7) and sends it to Bob

(7)

Then, Bob calculates via (8) for the verification:

(8)

4) Step IV: The verification of and byAlice and Bob means a mutual authentication derived by .Using the above values, Alice and Bob can obtain the symmetrickey through (9):

(9)

B. Elliptic Curve Cryptography

Due to the many benefits of ECC [19], it has been used in var-ious environments [20], especially where there are resource con-straints [21]–[24] and [25]. One of the most important benefitsof ECC is providing the same level of security with a smaller keysize compared to other cryptography techniques like RSA. Forinstance, ECC with 160 and 512 bit keys provide the same levelof security as RSA, D-H or ElGamal cryptography with 1024and 15360 bit keys, respectively. In addition to addressing theresource constraint issue, ECC is also beneficial in enabling anefficient protocol that supports current and future devices withvarious levels of technology, which is important in emerging SGsystems.Generally, ECC is presented as an Elliptic Curve (EC) nodes/

points over , via the following definition:

National Institute of Standard and Technology (NIST) in theUnited States issued an implementer’s guide that specifiesthe EC Diffie-Hellman (ECDH) key-agreement schemes fromNIST SP 800-56A, which aims at pair-wise key establishmentschemes using discrete logarithm cryptography. The documentspecifies the ECs and domain parameters, key generationmethods, the ECDH primitive, key derivation function, andother auxiliary functions that are necessary for ECDH schemeimplementations to be in compliance with SP 800-56A andSuite B [20]. We refer to the NIST document in our design tospecify the EC parameters.The ECKE-1 protocol [21] improves on the previous pro-

posals in the construction of a mutual authenticated shared sym-metric key between two parties, utilizing EC techniques. TheECKE-1 mechanism uses three point multiplications and twofield multiplications along with twice applications of a hashfunction. Author of [22] provided a password based remote au-thentication scheme for SC based on ECDH. The model aimsat providing a lightweight solution for devices with limited re-sources, which eliminated needs to keep the password tablein server side in order to reduce the side effect of compro-mising the server. Also, the mechanism presented in [23] con-centrated on two-party key designed for sensor networks thatcontain low-resource devices with a heterogeneous large-scaledeployment, based on EC and key management based on AVLtree. The next two-party ECDH based mechanism is ECKE-1Npresented in [24], which improves ECKE-1 by constructing thekey via 2.5 point multiplications, one field multiplication and

TABLE IEPAK PARAMETERS

Fig. 3. ECC-based PAKE (EPAK) protocol.

twice hash function applications. Later on, EECKE-1N [25] fur-ther improves ECKE-1N by constructing the key via only onepoint multiplication and one field multiplication to construct thetwo-party key.Although the above mechanisms are designed efficiently and

follow ECDH, mostly they use a predefined private and publickey, which requires the support of certificates issued by a certifi-cate authority. In this work, we design an ECC-based model ofthe PAKE protocol (as in X.1035 standard) called EPAK, whichuses only a predefined password and delivers an improvementon ECKE-1N and EECKE-1N mechanisms (Section III). Weutilize EPAK as our auxiliary protocol for our main MCEPAKprotocol presented in Section IV.

III. EPAK: ECC-BASED PASSWORD AUTHENTICATEDKEY-EXCHANGE PROTOCOL

In this section, we present the EPAK protocol, which is de-signed as an ECC version of the PAKE protocol presented in theX.1035 standard.Let us consider key agreement between Alice and Bob uti-

lizing a pre-shared password . Similar to the X.1035 stan-dard, we define . Furthermore, we as-sume that both parties have knowledge of the EC parametersset and hash function . Table I presents thelist of parameters and their definitions used in our design.

A. Description of EPAK Protocol

Shown by Fig. 3, the EPAK protocol has the following steps:1) Step I:2) Alice: Let us assume that Alice is the initiator. She picks

a random number (as her private key) andmultiply it to the group generator to obtain her public key

IEEE

Pro

of

Web

Ver

sion


via (10) and an appropriate EC point via (11). Finally,she computes to obtain a symmetric key with which sheencrypts as via (12) and sends it to Bob

(10)

(11)

(12)

3) Bob: Upon receiving packet from Alice, Bob usesto decrypt and obtain following (13), and the ap-

propriate EC point aligned with the value shownby (11)

(13)

4) Step II:5) Bob: Bob picks a random number (as his

private key) and multiplies it to the group generator to obtainhis public key via (14). He also calculates the appropriateEC point aligned with the value based upon (15):

(14)

(15)

Then, he multiplies his private key to the Alice’s public key toobtain shared value through (16), and finds appropriateEC points as per (17). Then, he computes for theverification of having the values , through (18),and finally, uses to encrypt via (19), and sends it toAlice

(16)

(17)

(18)

(19)

6) Alice: Alice uses to decrypt and obtainsthrough (20), and also computes the appropriate EC point

aligned with the given by (15). Then, she multi-plies her private key to Bob’s public key to obtain sharedvalue via (21), followed by given by (17).Finally, she computes for verification of having the valuesof through (22). If the verification holds, shecan be sure that Bob has the required values

(20)

(21)

(22)

7) Step III:8) Alice: Alice needs to make Bob assure that she has the

values as well. Therefore, she performs (23) to calculate outof , and sends it to Bob

(23)

9) Bob: On the other side, Bob calculates via (24) andcompares it with . If the verification holds, Bob is assuredthat Alice has the required values as well

(24)

10) Step IV: So far, both parties have the required parame-ters and have verified each other. Finally, they perform (25) tocalculate the shared symmetric key

(25)

B. A Few Comments About the EPAK Protocol

In the first verification initiated by Bob , we useonly coordinates (and ). Furthermore, in the second verifica-tion initiated by Alice , only coordinates are used(and ). However, in the final step and for calculating the sym-metric key , we have a combination of all values consisting ofand coordinates as well as the initial password and identities

of the parties (as part of the ).Thus far, we have defined neither the mechanism of

nor in the aforementioned design.Since is a point in the form of , for instance to encryptthis pair, we can multiply each coordinate by :

Consequently, on the other side we need to divide them by theand obtain the original values:

C. Brief Analysis of the EPAK Protocol

Comparing to the previous models, we eliminate the fixedinitial private key. To be more precise, each party chooses arandom number to be the private key per session. Also, ourmechanism constructs the key only via one multiplicationgiven by (16) and (21), and one hash function for the key in(25). In fact, other times that hash function is utilized are forverification purposes; this is an add-on to the ECKE-1N andEECKE-1N protocols. Furthermore, other multiplications in(19) and (20) are for encryption, whereas exchanged packetsare not encrypted at all in ECKE-1N and EECKE-1N.

IV. MCEPAK: MULTILAYER CONSENSUS ECC-BASEDPASSWORD AUTHENTICATED KEY-EXCHANGE PROTOCOL

Referring to Section I, our objective is a mutual password-based authenticated key agreement between an applianceand the controllers , , and , resulting in an in-dividual key between the appliance and each one of the upperlayer controllers. Based on Fig. 1, we need four symmetric keys.Our model based on PAKE protocol presented in X.1035 stan-dard (or EPAK in Section III) is shown in Fig. 4. In this abstractmodel and for each key, we need to have a predefined sharedpassword between the two involved parties (appliance and oneof the controllers). At the end of Section VI, we show that ourapproach decreases the number of packets and improves the se-curity of the design.In this section, we extend our EPAK protocol in order to ad-

dress the SG requirements presented in Section I, based on theEPAK protocol described in Section III. We use the same nota-tions as presented in the previous sections. The appliance

IEEE

Pro

of

Web

Ver

sion


Fig. 4. Four keys construction based on PAKE or EPAK.

Fig. 5. MCEPAK Protocol phases and packets.

knows at least the ID of the HAN and can obtain ID of the .Also via our four-phase mechanism, gains access to infor-mation of the other controllers. We assume:• and share a predefined secret password .• The ECC parameter set and areknown and shared by all parties.

• Controllers , , have already been authen-ticated to the upstream and downstream controllers, if any,and can have secure communications with them.

• Controllers are trusted parties that form parts of and arecontrolled by the grid domain; the appliance belongs to thecustomer domain, and is controlled by the customer.

• The following symmetric keys already exist:— : Shared between and .— : Shared between and .— : Shared between and .

Note: Although the secure channels that we assume to alreadyexist between the controllers may not be certain, we need to trustit, otherwise “we would be unable to ever get any work done”[26]. Furthermore, the trust assumption is especially feasible inthe multilayer architecture of SG controllers [4] considered inthis paper.Furthermore, we introduce a new vector (entities identifi-

cations set), which carries the IDs of the entities involved in ourprotocol as a part of the information exchanged between them.Our four-phase MCEPAK protocol depicted in Fig. 5 consistsof the following steps.

A. Phase I: Initial Flow

In MCEPAK, initiates the keys establishment process:1) First Packet: Firstly, follows (26) to utilize the initial

password shared by to calculate temporary key

(26)

also picks a random number , then computesvia (27) and appropriate coordinates given by

(28)

(27)

(28)

Then, puts its own ID in field of given by (29). Finally,forms packet by and all encrypted by the

key as per (30), and then sends the packet to

(29)

(30)

2) Second Packet: First, calculates temporary keyby performing (26), and decrypts received packet from byway of (31) to obtain and

(31)

Then, picks a random number and computesthrough (32)

(32)

(33)

Then, puts its own ID into field of by way of (34), andalso computes via (35)

(34)

(35)

Finally, dispatches along with and to , allencrypted with the shared key following (36)

(36)

3) Third Packet: First, obtains , and by de-cryption of the received packet from via (37):

(37)

Then, chooses random number and com-putes through (38):

(38)

(39)

Then, copies its own ID into the field in (40), and com-putes via (41). Finally, forwards , and to, all encrypted with the predefined shared key of through

(42)

(40)

IEEE

Pro

of

Web

Ver

sion


(41)

(42)

4) Fourth Packet: Firstly, follows (43) to obtain ,and from the packet received from :

(43)

Then, chooses random number to obtainvia (44)

(44)

(45)

Then, updates field with its own ID as depicted by(46), also computes through (47)

(46)

(47)

Finally, forms packet out of , and asshown by (48), encrypts it by , and forwards it to

(48)

B. Phase II: Response Flow

This flow starts with replying to the fourth packet above.1) Fifth Packet: First, obtains the , and

values by decryption of the packet received from thefollowing (49)

(49)

Then, extracts ID of any of the controllers (if needed) as wellas ID of the appliance from , and also calculates

through (50). Beside, inserts its own ID into field ofas presented by (51)

(50)

(51)

Then, picks a random number to obtainand following (52) and (53) respectively

(52)

(53)

(54)

Then, obtains coordinates as shown by (54) andas depicted by (45), and then computes via (55)

for verification purpose

(55)

Finally, follows (56) to form from , and ,in which encrypts the packet by as shown in (56)

(56)

2) Sixth Packet: First, decrypts the packet received fromto obtain the , and values following (57). Then,calculates through (58)

(57)

(58)

Then, utilizes its own random number (fourth step) tocalculate via (59), and via (60). Then, follows(61) to calculate for the verification purpose

(59)

(60)

(61)

Finally, forms out of , , and , andencrypts the packet by as shown in (62) to be sent to theBAN controller

(62)

3) Seventh Packet: First, obtains the parameters ,, and as presented by (63) by decrypting packet

received from . Then, calculates the key via (64)

(63)

(64)

Then, uses its own random number (third step) to obtainthe via (65), through (66) and via (67)

(65)

(66)

(67)

Then, obtains coordinates and asshown by (45) and (39) respectively, and calculatesthrough (68) for verification

(68)

Finally, forms packet by , , , and, encrypted by as shown in (69), and sends the packet to

(69)

4) Eighth Packet: First, decrypts the packet receivedfrom and obtains , , , and as de-picted by (70). Then, calculates through (71)

(70)

(71)

Then, utilizes its own random number (second step) tocompute via (72), through (73), via (74) and

through (75)

(72)

(73)

IEEE

Pro

of

Web

Ver

sion


(74)

(75)

obtains coordinates and as depictedby (39) and (33), respectively, and then computes using(76) for verification

(76)

Finally, forms packet out of , , , ,and , encrypted by as shown by (77), and sends

the packet to

(77)

C. Phase III: Verification

1) Appliance (Ninth Packet): In this phase, verifiesthe received values and dispatches the confirmations to theupstream controllers. First, computes the temporarykey via (71), to decrypt the received packet fromin order to obtain , , , , andfollowing (78)

(78)

Then, utilizes its own random number (first step) tocalculate via (79), through (80), via (81) and

through (82), which are shared by , , and ,respectively

(79)

(80)

(81)

(82)

Then, uses the above shared values to obtain coordinates, , and as shown in (54),

(45), (39) and (33), respectively. Then, utilizes the coordi-nates and performs (55), (61), (68) and (76) to substantiate .If the verification holds, proceeds to the next step. Note that,since has , it is able to obtain , basedupon (35), (41) and (47). Finally, generates four valuesvia (83) for , through (85) for , via (87) forand through (89) for , as verifiers of the shared values,and forwards them to

(83)

(84)

(85)

(86)

(87)

(88)

(89)

TABLE IIINTERNAL ADVERSARY KNOWLEDGE

2) HAN Controller (Tenth Packet): receives the abovesubstantiation values and then verifies based upon (83). Ifthe verification holds, relays the other values to .3) BAN Controller (Eleventh Packets): receives the

above values and then verifies following (85). If theverification holds, relays the other values to .4) NAN Controller (Twelfth Packets): receives the

eleventh packet and then verifies through (87). If theverification holds, relays the other values to .5) SGCC Controller: receives the twelfth packet and

then verifies via (89).

D. Phase IV: Keys Calculation

Thus far, all parties have their verified shared values. Finally,they can generate their appropriate symmetric keys per (90),(91), (92) and (93)

(90)

(91)

(92)

(93)

V. ANALYSIS

Since the proposed MCEPAK protocol is based on ECC,X.1035 standard and D-H algorithm, it inherits most of theirbenefits. In this section, we study and model the adversary,analyze the security of the system mainly in terms of differentattacks, and evaluate the security of the keys. To analyze andevaluate the security of our proposed protocol, we follow theDolev-Yao approach [27]. In the Dolev-Yao model, the adver-sary is capable of recording, deleting, re-playing, re-routing,re-ordering and re-scheduling the messages. All of the mes-sages generated by the honest parties are sent to the adversary,and the honest nodes receive the messages only from theadversary. Also, we analyse the protocol mechanism from thesystem and network overhead point of views.

A. Adversary Models

We consider twomodels for internal and external adversaries.1) Internal Adversary: In this model, our adversary is one of

the trusted parties that has become malicious.2) Objective: The objectives of the adversary are i) Gaining

access to the system resources such as the appliance or any ofthe controllers, ii) Performing a MITM attack to gain access toany of the keys.3) Initial Capabilities: The adversary has complete knowl-

edge about the topology and the exact address/ID of each party.Furthermore, the adversary knows the detail design of the keyagreement mechanism and has access to the system parametersrequired for the key agreement. Depending on which one of theinvolved parties is themalicious one, the adversary’s knowledgein each case is listed in Table II.

IEEE

Pro

of

Web

Ver

sion


4) Capabilities During the Attack: The adversary receivesthe encrypted and unencrypted (plain) data in different stages ofthe keys agreement, or later on during the using of the key. Incase of having control on a controller, the adversary will attemptto perform a MITM attack. She/He can destroy the packets andcause failure in one of the verification phases that yields re-ini-tiation of the key agreement protocol, which is essentially a de-nial of service (DoS) attack. Furthermore in case of a malicious, the adversary can perform DoS attack by initiating the key

agreement protocol continuously.5) Discussion: Referring to the assumptions of theMCEPAK

protocol, controllers are fully trusted parties as parts of the SGdomain, and they are controlled/setup/managed by the grid ad-ministrators. Even a HAN controller, which is usually a SmartMeter that also acts as a gateway, is not under customer control.Therefore, initially they follow the steps of the algorithm anddo not show any misbehaving action. Also, the administratorof the SG monitors them to protect the SG from any maliciouscontroller. So, dealing with malicious controllers is beyond thescope of this paper.However, a malicious can perform a DoS attack easily,

for instance by failing the verification phase. To prevent it, thesystem can define a limit of the key agreement sessions per ap-pliance in each period of time. If after a number of tries, stillthe appliance could not finish the process, it means that eitherthe node is malicious or the initial password between and

does not match. Therefore, the system stops the applianceand cancels its future tries. Having said this, the attack can bedetected at, e.g., level as long as uses the same ID.Initiating the key construction sessions by different IDs is an-other option for to perform DoS attack against the HANcontroller. In this case, can limit the number of open ses-sions in the HAN domain to prevent such an attack.6) External Adversary: In this model, the adversary is not

any of the involved parties, and performs attacks from outsideof the controllers and appliance set.7) Objective: i) Gaining access to the system resources, like

any of the controllers or . ii) Performing a MITM attack togain access to any of the symmetric keys. iii) Performing a DoSattack to overload the system (any of the controllers).8) Initial Capabilities: Similar to the internal model, the

external adversary has complete knowledge about the topologyand the exact address/ID of the parties. The adversary alsoknows the detail design of our mechanisms.9) Capabilities During the Attack: The adversary receives

the encrypted and unencrypted (plain) packets during and afterthe key agreement process.10) Discussion: Since our adversary receives all the packets,

in order to gain access to the system resources, like , she/hecan perform a brute-force attack to find out the pre-shared pass-word between the appliance and the HAN controller. Brute-force attack is a time consuming attack, and the password is usedonly during the first few packet delivery between the two parties( and ). Furthermore, we use a hash function to combinethe password and random numbers to construct the key. There-fore, our model (similar to PAKE protocol) has the forward se-crecy characteristic. Having said this, finding the password doesnot help the adversary to figure out or calculate any of the sym-metric keys. The same situation is applicable to any of the orig-inal keys between the controllers. Indeed, obtaining any of theshared keys between the controllers does not help the adversaryto calculate the constructed symmetric key after the fact. This

Fig. 6. AVISPA results. (a) OFMC. (b) Cl-AtSe.

TABLE IIIOVERHEAD IMPROVEMENT

TABLE IVIMPROVEMENT OF ENCRYPTION/DECRYPTION TIME

is because the packets exchanged by our mechanism do not in-clude all the items required for the key calculation. Besides, theaforementioned discussion shows that an adversary cannot per-form a successful MITM attack.To perform a DoS attack and overload the system (any con-

troller), our adversary should initially run a spoof attack to mas-querade one of the parties as well as performing a brute-force ordictionary attack to steal the shared key between the party andits neighbor. Then, she/he shouldmanage sending the key agree-ment packets to the neighbor to perform the DoS attack. Evenif the adversary is able to manage these attacks, the system canlimit the number of requests from any ID for the key construc-tion and prevents this scenario. Any misbehaviour can be mon-itored by other controllers, where an intrusion detection systemlike [28] would help in this regard.

B. Security Analysis

1) Consensus Key Establishment: Referring to the key con-struction (90), (91), (92), and (93), we need contribution ofother downstream controllers for each controller. For instancein the case of as per (93), we utilize that containsrandom numbers chosen by as well as random num-bers of , (53). Similarly, (92) uses randomvariables as well as (44). Furthermore,

verifies the received shared values all at the same time bychecking . Therefore, if any of the controllers does not co-operate on the key constructions, none of the parties would havean appropriate key.2) Mutual Authentication: The utilization of password

provides a mutual authentication between and . Further-more, since is a part of the calculations that

IEEE

Pro

of

Web

Ver

sion


Fig. 7. Main HLPSL Codes.

are used by other controllers for the verification and key forma-tion, the mutual authentication is endorsed on the entire key-set.3) Hierarchical/Conditional Key Formation: needs to

establish a symmetric key shared by in order to establish akey with any of the higher layers controllers. Furthermore, allof the key construction are initiated by and are forwarded to

as a gateway. To be more precise, only the downstream (andnot the upstream) controller’s random numbers are required byeach controller.

4) Replay Attack: Like D-H algorithm, since MCEPAK uti-lizes random numbers and hash functions to establish the keys,it delivers the replay attack resilience.5) Key Privacy & Insider Attack Resilience: Depicted by

(90)–(93), each key is only known by and the correspondingcontroller. For instance, is only known by and ,which supports the key privacy. Other controllers in-betweenonly attend in the key construction; however, they do not gainaccess to any data to be used to decrypt the messages.

IEEE

Pro

of

Web

Ver

sion


Fig. 8. HLPSL codes of and . (a) New appliance . (b) Home controller .

6) Off-Line Guessing Attack Resilience: An eavesdroppermay perform an off-line dictionary attack over password byhaving access to the (27) and obtains access to ; never-theless, based on ECC-CDH (Elliptic Curve Cryptography Co-factor Diffie-Hellman) assumption [19], s/he is not able to find. As a result, the adversary does not have complete informa-

tion and data to compute any of the keys.7) Denning-Sacco Attack Resilience: If an eavesdropper

gains access to , still she/he is not ableto obtain value used in the key establishment. Further-more, she/he is not able to guess where

, .8) Compromised Impression Resilience: Referring to our ad-

versarymodels as well as (90)–(93), finding any of the keys doesnot enable an intruder to obtain any other controllers key.9) Ephemeral Key Compromise Impersonation: Even if an

adversary finds any of the passwords, she/he is not able tocalculate since she/he does not have access to the randomnumber . Also, is required by the her/him to obtain( is a controller).10) Unknown Key-Share Attack: assures that the

controllers have the required parameters to calculate the keys.On the other hand, parameters , , assurethe controllers that has the required values. So, if a con-troller is able to perform the key formation, the appliance wouldbe able to do it too, and wise versa.11) MITM Attack: Per the aforementioned discussion on the

adversary models, since all of the packets betweenare encrypted by based temporary keys , MCEPAKenjoys MITM attack resilience. Also, the communications

between the controllers required for key formation are securedby the preliminary keys of the controllers.

C. Formal Validation Using Software Tool

To evaluate validity of the keys, we use Automated Valida-tion of Internet Security Protocols and Application (AVISPA)security analyzer package. AVISPA is a tool for the automaticverification and analysis of Internet security protocols [29], andone of themost trusted evaluation tools in the literature. AVISPAanalyzes the scheme and protocols with respect to different at-tacks by combining automatic security analysis and verificationback-end servers like On-the-Fly Model-Checker (OFMC) andConstraint-Logic-based Attack Searcher (Cl-AtSe). To performthe key validation using AVISPA and evaluate it by the back-endservers, the protocol and mechanisms are required to be codedin the High Level Protocol Specifications Language (HLPSL).More information about the AVISPA, its features and HLPSLlanguage can be found in [29].We apply AVISPA to analyse appropriate shared keys of the

five entities , , , and . Simulation results pre-sented in Fig. 6(a) and (b) show that the symmetric keys con-structed by our mechanism are secure and safe to be used by thesystem entities.The evaluation program and AVISPA related HLPSL codes

for the session, environment and goal sections, as well as eachparty HLPSL related codes are presented in Appendix A.

D. Performance Analysis

1) Low Implementation Cost: Let us consider the followingtwo scenarios:

IEEE

Pro

of

Web

Ver

sion


Fig. 9. HLPSL Codes of , and . (a) Building controllers . (b) Neighborhood controller . (c) Central controller .

• : establishes an individual symmetric key byeach controller, following the PAKE or EPAK protocols(refer to Section IV).

• : follows MCEPAK (or SG-MCPAK) protocol.An overall comparison between the two scenarios is presentedby Table III. Based on Fig. 4, performs four iterations toconstruct four symmetric keys between appliance and theupstream controllers. Also, referring to Sections II and III, onepassword between and the controller is required for eachkey agreement. Furthermore, proceeds duringphases and requires five hash functions, while has onlyfour phases and needs only one hash function and one password.In terms of random numbers, in two random numbers perkey are required, and in total eight random numbers are needed.On the other hand, requires only five random numbers.Also, transfers three packets per iteration and in totalneeds packets to be delivered. In contrast,

needs three packets per phase for a total ofpackets.2) Fast Packet Delivery: Packet delivery between andare the same for both scenarios, although MCEPAK pro-

vides a faster packet delivery between and the upper-layercontrollers for regular communications. Let us define as therequired time for the encryption or decryption process at eachparty, which is assumed to be the same. Let us consider the fol-lowing two scenarios:• : System has one symmetric key per layer. If a packetis encrypted by controller to be sent to , shoulddecrypt it by the key between , and then encryptsit again by the key between . Finally, the packetcan be decrypted by using the shared symmetric keybetween .

• : System provides a shared symmetric key between. Therefore, the packet that needs to be sent by

to , needs to be encrypted and decrypted once (by).

Table IV presents the required time in each case by each con-troller, and also presents the time saving (improvement).

Note: An analysis and evaluation on EPAK protocol (cost ofkey agreement) in comparison to the literature is presented atthe end of Section III as well.

VI. CONCLUSION

We have presented the MCEPAK protocol, which enables se-cure communications between a home appliance and differentlayers of the SG control system. The protocol efficiently estab-lishes four multilayer consensus password-authenticated sym-metric keys between an appliance and upper layer controllers inorder to provide a hierarchical authority over an appliance. TheMCEPAK protocol takes advantage of ECC to provide a highsecurity level with a small key size while addressing the poten-tial resource constraints in the devices involved. The protocolcan be easily implemented by adaptation of the current X.1035standard and applying the ECC approach, and it can be extendedto a larger number of layers if required. We have analyzed andshowed that proposed mechanisms reduce the system securityoverhead while providing resilience against most of the well-known attacks. Compared to the X.1035 standard, MCEPAKincurs a lower load for computations of the hash function andrequired passwords. Also, our EPAK protocol presented in thispaper is general in that it can be used and implemented in anyapplication and environment outside of an SG system. We havedeveloped EPAK to facilitate the design of MCEPAK. SinceEPAK is based on ECC, it provides a high security level with asmall key size.

APPENDIXOUR DEVELOPMENT FOR EVALUATION IN AVISPA

Fig. 7 presents our evaluation program and AVISPA relatedHLPSL codes for the session, environment and goal sections.Also, HLPSL codes of the appliance is shown in Fig. 8(a) whileHLPSL codes of the controllers roles are shown in Figs. 8(b)and 9(a)–(c).

IEEE

Pro

of

Web

Ver

sion


REFERENCES[1] “Introduction to NISTIR 7628 guidelines for smart grid cyber se-

curity,” National Institute of Standards and Technology (NIST),2010 [Online]. Available: http://www.nist.gov/smartgrid/upload/ni-stir-7628_total.pdf

[2] P. McDaniel and S. McLaughlin, “Security and privacy challenges inthe smart grid,” IEEE Security Privacy, vol. 7, no. 3, pp. 75–77, May/Jun. 2009.

[3] Y. Yan, Y. Qian, H. Sharif, and D. Tipper, “A survey on smart gridcommunication infrastructures: Motivations, requirements and chal-lenges,” IEEE Commun. Surveys Tuts., to be published.

[4] M.M. Fouda, Z.M. Fadlullah, N. Kato, R. Lu, and X. Shen, “Towards alight-weight message authentication mechanism tailored for smart gridcommunications,” in Proc. IFIP SCNC Workshop, Shanghai, China,Apr. 2011.

[5] Q. Li and G. Cao, “Multicast authentication in the smart grid with one-time signature,” IEEE Trans. Smart Grid, vol. 2, no. 4, pp. 686–696,Dec. 2011.

[6] W. Diffie and M. E. Hellman, “New direction in cryptography,” IEEETrans. Inf. Theory, vol. IT-11, pp. 644–654, Nov. 1976.

[7] H. Nicanfar and V. C. M. Leung, “Smart grid multilayer consensuspassword-authenticated key exchange protocol,” in Proc. IEEE SFCSWorkshop, Ottawa, ON, Canada, Jun. 2012.

[8] T. ElGamal, “A public key cryptosystem and signature scheme basedon discrete logarithm,” IEEE Trans. Inf. Theory, vol. IT-31, pp.469–472, Jul. 1985.

[9] S. M. Bellovin and M. Merritt, “Encrypted key exchange: Pass-word-based protocols secure against dictionary attacks,” in Proc.IEEE Comput. Soc. Symp. Res. Security Privacy, Oakland, CA, May1992.

[10] D. H. Seo and P. Sweeney, “Simple authenticated key agreement algo-rithm,” Electron. Lett., vol. 35, no. 13, pp. 1073–1074, Jun. 1999.

[11] H. Yeh and H. Sun, “Simple authenticated key agreement protocol re-sistant to password guessing attacks,” ACM SIGOPS Oper. Syst. Rev.,vol. 36, no. 4, pp. 14–22, Oct. 2002.

[12] W. Juang, S. Chen, and H. Liaw, “Robust and efficient password-au-thenticated key agreement using smart cards,” IEEE Trans. Ind. Elec-tron., vol. 55, no. 6, pp. 2551–2556, Jun. 2008.

[13] X. Ding, C. Ma, and Q. Cheng, “Password authenticated key exchangeprotocol with stronger security,” in Proc. ETCS Workshop, Wuhan,Hubei, China, Mar. 2009.

[14] L. Liu and Z. Cao, “Improvement of one password-based authenticatedkey exchange protocol,” in Proc. ISISE Symp., Wuhan, Hubei, China,Mar. 2009.

[15] G. Yao, H. Wang, and D. Feng, “A group PAKE protocol using dif-ferent passwords,” in Proc. NSWCTC Conf., Wuhan, Hubei, China,Apr. 2009.

[16] Z. Zhang and Q. Zhang, “Verifier-based password authenticated keyexchange protocol via elliptic curve,” in Proc. ICISIT Conf., Beijing,China, Dec. 2010.

[17] IEEE Standard Specifications for Password-Based Public-Key Cryp-tographic Techniques, IEEE Std 1363.2-2008, 2009.

[18] “Password-Authenticated Key Exchange (PAK) Protocol,” Telecom-munication Standardization Sector of International Telecommunica-tion Union (ITU-T), Recommendation X.1035, 2007, .

[19] A. H. Koblitz, N. Koblitzb, and A. Menezes, “Elliptic curve cryptog-raphy: The serpentine course of a paradigm shift,” Elsevier J. NumberTheory, vol. 131, no. 5, pp. 781–814, May 2011.

[20] “Recommendation for pair-wise key establishment schemes usingdiscrete logarithm cryptography (revised),” National Institute ofStandards and Technology (NIST), 2007 [Online]. Available:http://csrc.nist.gov/publications/nistpubs/800-56A/

[21] M. A. Strangio, “Efficient Diffie-Hellmann two-party key agreementprotocols based on elliptic curves,” in Proc. ACM Appl. Sci., Santa Fe,NM, Mar. 2005.

[22] A. P. Muniyandi, R. Ramasamy, and Indrani, “Password based remoteauthentication scheme using ECC for smart card,” in Proc. ICCCS,Orisa, India, Feb. 2011.

[23] H. Boumerzoug, B. A. Bensaber, and I. Biskri, “A keys managementmethod based on an AVL tree and ECC cryptography for wirelesssensor networks,” in Proc. Q2SWinet, Miami Beach, FL, Oct.–Nov.2011.

[24] S. Wang, Z. Cao, M. A. Strangio, and L. Wang, “Cryptanalysis andimprovement of an elliptic curve Diffie-Hellman key agreement pro-tocol,” IEEE Commun. Lett., vol. 12, no. 2, pp. 149–151, Feb. 2008.

[25] E. J. Yooni and K. Y. Yoo, “A new elliptic curve Diffie-Hellman two-party key agreement protocol,” in Proc. ICSSSM Conf., Tokyo, Japan,Jun. 2010.

[26] C. H. Hauser, “Trust research to address uncertainty in security for thesmart grid,” in Proc. IEEE PES ISGT, Washington, DC, Jan. 2012.

[27] D. Dolev and A. Yao, “On the security of public-key protocols,” IEEETrans. Inf. Theory, vol. IT-29, pp. 198–208, 1983.

[28] P. Jokar, H. Nicanfar, and V. C. M. Leung, “Specification-based intru-sion detection for home area networks in smart grids,” in Proc. IEEESmartGridComm, Brussels, Belgium, Oct. 2011.

[29] AVISPA-Automated Validation of Internet Security Protocols [Online].Available: http://www.avispa-project.org

Hasen Nicanfar (S’11) received his B.A.Sc.degree in electrical engineering from Sharif Uni-

versity of Technology [CITY / STATE/ COUNTRY?] in 1993, and hisMASc. degree in computer networks from Ry-

erson University [CITY / STATE /COUNTRY?] in 2011. He is workingtoward the Ph.D. degree in the Department ofElectrical and Computer Engineering, the Universityof British Columbia.

From 1993 to 2010, he has worked in different positions such as IT and ERPmanager and consultant, project manager, production engineer andmanager, andbusiness and system analyst. Currently, he holds the position of research assis-

tant in WiNMoS Lab [CITY / STATE / COUNTRY?].His research interests are in the areas of the system and network design andmanagement, security and privacy, cryptography, and routing protocol design,for wireless communication and smart grid system.

Victor C. M. Leung (S’75–M’89–SM’97–F’03)received the B.A.Sc. (Hons.) degree in electricalengineering from the University of British Columbia(UBC), Canada, in 1977, and was awarded theAPEBC Gold Medal as the head of the graduatingclass in the Faculty of Applied Science. He attendedgraduate school at UBC on a Natural Sciences andEngineering Research Council Postgraduate Schol-arship and completed the Ph.D. degree in electricalengineering in 1981.From 1981 to 1987, he was a Senior Member of

Technical Staff at MPR Teltech Ltd. In 1988, he was a Lecturer in the Depart-ment of Electronics at the Chinese University of Hong Kong. He returned toUBC as a faculty member in 1989, and currently holds the positions of Pro-fessor and TELUS Mobility Research Chair in Advanced TelecommunicationsEngineering in the Department of Electrical and Computer Engineering. He hasco-authored more than 600 technical papers in international journals and confer-ence proceedings, and several of these papers had been selected for best paperawards. His research interests are in the broad areas of wireless networks andmobile systems.Dr. Leung is a registered professional engineer in the Province of

British Columbia, Canada. He is a Fellow of the Engineering Institute ofCanada, and a Fellow of the Canadian Academy of Engineering. He hasserved/is serving on the editorial boards of the IEEE JOURNAL ON SELECTEDAREAS IN COMMUNICATIONS—WIRELESS COMMUNICATIONS SERIES, IEEETRANSACTIONS ON WIRELESS COMMUNICATIONS, IEEE TRANSACTIONS ONVEHICULAR TECHNOLOGY, IEEE TRANSACTIONS ON COMPUTERS, IEEEWIRELESS COMMUNICATIONS LETTERS, as well as several other journals. Hehas guest-edited many journal special issues, contributed to the organizationof a large number of international conferences, and served on the technicalprogram committee of numerous international conferences. Dr. Leung is arecipient of the 2011 IEEE Vancouver Section Centennial Award and the 2012UBC Killam Research Prize.

IEEE

Pro

of

Prin

t Ver

sion

IEEE TRANSACTIONS ON SMART GRID 1

Multilayer Consensus ECC-Based PasswordAuthenticated Key-Exchange (MCEPAK) Protocol

for Smart Grid SystemHasen Nicanfar, Student Member, IEEE, and Victor C. M. Leung, Fellow, IEEE

Abstract—This paper aims at providing a key agreementprotocol for smart grid to cope with access control of appli-ances/devices located inside a Home Area Network (HAN) bya set of controllers outside the HAN. The commands/packetsinitiated by the controllers in crisis cases should be delivered fastand immune from any interruption. The HAN controller, whichacts as a gateway, should not cause any delay by decrypting andre-encrypting the packets, nor should it has any chance to modifythem. Considering the required level of security and quality of ser-vice, we design our protocol with an Elliptic Curve Cryptography(ECC) approach. We improve and implement the Password Au-thenticated Key Exchange (PAKE) protocol in two steps. First, wepropose an auxiliary mechanism that is an ECC version of PAKE,and then extend it to a multilayer consensus model. We reduce thenumber of hash functions to one, and utilize a primitive passwordshared between an appliance and HAN controller to constructfour valid individual consensus and authenticated symmetric keysbetween the appliance and upstream controllers by exchangingonly 12 packets. Security analysis presents that our protocol isresilient to various attacks. Furthermore, performance analysisshows that the delay caused by the security process is reduced bymore than one half.

Index Terms—Access control, consensus, ECC, ECDH, hierar-chical control, multilayer, PAKE, security, smart grid.

I. INTRODUCTION

R APID developments of smart grid (SG) systems in recentyears have led tomany technical issues that have attracted

much attention from the systems, communications and securityresearch communities. Among these, some of the most impor-tant and challenging issues are concerned with the appropriatesecurity and privacy levels in the SG context [1]. SG is a crit-ical infrastructure, but the widespread incorporation of wirelesstechnologies in SGmakes it vulnerable to attacks that can causedifferent levels of harm to the SG system, individual devices oreven society at large [2].Security is one of the key challenges of the SG communica-

tion infrastructures as presented in [3]. In this paper, we pro-pose a key agreement protocol for secured access control in ahierarchical architecture for the SG communication infrastruc-ture with different layers between smart appliances in users’

Manuscript received April 01, 2012; revised September 16, 2012; acceptedOctober 02, 2012. This paper is based in part on a paper appeared in proceedingof the First IEEE International Workshop on Security and Forensics in Com-munication Systems (SFCS), June 2012. This work was supported in part bythe Natural Sciences and Engineering Research Council (NSERC) of Canadathrough grant STPGP 396838. Paper no. TSG-00180-2012.The authors are with the WiNMoS lab, Department of Electrical and Com-

puter Engineering, the University of British Columbia, Vancouver, BC V6T1Z4, Canada (e-mail: [email protected] and [email protected]).Color versions of one or more of the figures in this paper are available online

at http://ieeexplore.ieee.org.Digital Object Identifier 10.1109/TSG.2012.2226252

premises and upstream controllers of the Home Area Networks(HANs), Building Area Networks (BANs) and Neighbor AreaNetworks (NANs), and SG Central Controllers (SGCC), whichare located in distribution networks or substations [4]. Typically,the HAN controller is a smart meter (SM) that serves as thegateway to the user’s premise. Such a protocol provides a se-cured means for controllers upstream of the HAN controllersto access and control the smart appliances in users’ premises,e.g., to modify the thermostat setting of the homes heating, ven-tilation and air condition (HVAC) systems when a brown-out isimpending. This study is independent of the technologies usedfor the SG communications; i.e., our work is equally applicablewhether power line communications (PLC) or wireless tech-nologies are used in any of the layers.Various existing controlling commands that may be sent to a

smart appliance from outside the HAN have been consideredin [5]. For instance, a NAN controller (located outside a HAN)may supervise electric charging of a plug-in electric vehicle(PEV) located inside the HAN. Also, in the case of a disasteror an emergency, SGCC may need to remotely turn off low-pri-ority high-demand appliances. In such operations, the HANcontrollers should not interfere with and delay such commandsby decrypting and re-encrypting the corresponding packets.Therefore, we need to address the appropriate secrecy level inthe SG control system design while providing the quality ofservice (QoS) required in terms of keeping the command-re-sponse delay within an acceptable limit.Contributions: In this paper, we present two protocols. The

first one is an auxiliary model of an Elliptic Curve Cryptography(ECC) based Password Authenticated Key Exchange (PAKE)protocol (EPAK protocol) that can be used in any environmentand application. The second one, which is our main work, isa Multilayer Consensus EPAK (MCEPAK) protocol developedfor communications in the SG control system.The scope of the work is shown in Fig. 1, which addresses

communications in up to four layers between a home appliance, HAN controller , BAN controller , NAN controllerand SGCC . We consider the SG controllers with the hi-

erarchical architecture share common secrets and are designedto be trust-worthy to each other. Precisely, we assume that con-trollers have a pre-established trust relationship; i.e., they are al-ready authenticated to the upstream and downstream controllersif any, and are able to communicate with the neighbors in asecure fashion. When a smart appliance joins a HAN, it alsoneeds to share a common secret (assumed to be a simple pass-word) with the HAN controller for it to be trusted in the HAN.The question is how to extend this trust to multiple controllersin a secure and efficient manner. Moreover, our proposal ad-dresses the requirement that each controller needs to set up asecure and private communication channel with , with any

1949-3053/$31.00 © 2012 IEEE

IEEE

Pro

of

Prin

t Ver

sion


Fig. 1. Required symmetric keys.

controllers in between simply acting as a part of the commu-nication connection without participating in the security opera-tions. Based on assumption of sharing a primitive password by

and , we derive four individual consensus password-au-thenticated symmetric keys between and the upstream con-trollers.A symmetric key agreement is mostly based on the Diffie

and Hellman (D-H) protocol [6]. Furthermore, the key con-struction utilizing a pre-shared password for mutual authenti-cation is known as the PAKE protocol. This paper is an exten-sion of our preliminary proposal in [7] called the Smart GridMultilayer Consensus Password Authentication Key Exchange(SG-MCPAK) protocol, which is designed based on the D-Halgorithm. The logic behind the SG-MCPAK and MCEPAK al-gorithms are the same, andMCEPAK can be considered as ECCversion of SG-MCPAK.We review ECC along with the D-H and PAKE protocols in

Section II and then present our EPAK protocol in Section III.Then, we describe our MCEPAK protocol, which is an extendedversion of the EPAK, in Section IV. Analysis of our protocolsis presented in Section V, and finally the paper is concluded inSection VI.

II. RELATED WORK AND BACKGROUND REVIEW

There are various solutions for constructing a symmetric keyand an asymmetric key. Generally speaking, most of them areoriginally based on the D-H protocol for symmetric key, andElGamal algorithm [8] and RSA for asymmetric key. Each in-troduction of a new crypto-system has led to further work toaddress various attacks like Man-In-The-Middle (MITM). Toprevent the attacks, the author of [9] proposed a solution that uti-lizes a password to assure the secrecy required for the key agree-ment messages. A two-step PAKE protocol called Simple Au-thentication andKeyAgreement (SAKA) is presented in [10]. InSAKA, both parties convert their shared password to a number.Then, each party randomly selects a number and multiplies it tothe shared number to be used in the D-H algorithm. Authors of[11] showed that SAKA is resistant to password guessing attack.In [12], a light-weight and robust PAKE for smart card (SC) ispresented, which identifies and delivers an entity-server mutualauthentication. The scheme supports only one SC per device andrequires SC management. Furthermore, each SC is only utilizedfor two-party authentication, which limits its usefulness in SG.In [13], a three steps PAKE protocol is presented to resist dictio-nary, password compromise impersonation and ephemeral keycompromise impersonation attacks, and to supply forward se-crecy.

Fig. 2. PAKE Protocol: X.1035 Standard.

The mechanism presented in [14] reduces the number of re-quired hash functions while changing the parameters accord-ingly, which is a concept that we use in our design. The groupPAKE protocol in [15] considers that each user has an individualpassword shared with the server. The model does not meet theSG requirement of having an individual symmetric key betweenan appliance and each controller. The concepts of temporarysession key as well as password verifiers are proposed in [16].In 2009, the IEEE 1363.2 standard [17] for password based

public key cryptographic techniques was released. The standardspecifies primitives and schemes designed to utilize passwordsand other low-grade secrets as a basis for securing electronictransactions. To be more precise, the standard specifies theschemes for password-authenticated key agreement and pass-word-authenticated key retrieval.

A. X.1035 Standard

The PAKE protocol presented in the X.1035 standard [18]presumes that two parties share a password . The four-phasemutual authentication protocol defined in the X.1035 standardconstructs a symmetric cryptographic key via D-H exchangeby employing D-H values and five shared hash func-tions . Depicted in Fig. 2, in the following phases,

are the IDs of two parties named Alice and Bob,respectively, , and are the re-spective random numbers chosen by them:1) Step I: Alice obtains (1) and forwards it to Bob:

(1)

On the other side, Bob extracts “ ” from by (2):

(2)

2) Step II: Bob computes following (3) and (4), andsends them to Alice

(3)

(4)

Alice also similarly obtains “ ” from per (5) andthen calculates per (6) for the verification

(5)

(6)

IEEE

Pro

of

Prin

t Ver

sion


3) Step III: Alice computes via (7) and sends it to Bob

(7)

Then, Bob calculates via (8) for the verification:

(8)

4) Step IV: The verification of and byAlice and Bob means a mutual authentication derived by .Using the above values, Alice and Bob can obtain the symmetrickey through (9):

(9)

B. Elliptic Curve Cryptography

Due to the many benefits of ECC [19], it has been used in var-ious environments [20], especiallywhere there are resource con-straints [21]–[24] and [25]. One of the most important benefitsof ECC is providing the same level of securitywith a smaller keysize compared to other cryptography techniques like RSA. Forinstance, ECC with 160 and 512 bit keys provide the same levelof security as RSA, D-H or ElGamal cryptography with 1024and 15360 bit keys, respectively. In addition to addressing theresource constraint issue, ECC is also beneficial in enabling anefficient protocol that supports current and future devices withvarious levels of technology, which is important in emerging SGsystems.Generally, ECC is presented as an Elliptic Curve (EC) nodes/

points over , via the following definition:

National Institute of Standard and Technology (NIST) in theUnited States issued an implementer’s guide that specifiesthe EC Diffie-Hellman (ECDH) key-agreement schemes fromNIST SP 800-56A, which aims at pair-wise key establishmentschemes using discrete logarithm cryptography. The documentspecifies the ECs and domain parameters, key generationmethods, the ECDH primitive, key derivation function, andother auxiliary functions that are necessary for ECDH schemeimplementations to be in compliance with SP 800-56A andSuite B [20]. We refer to the NIST document in our design tospecify the EC parameters.The ECKE-1 protocol [21] improves on the previous pro-

posals in the construction of a mutual authenticated shared sym-metric key between two parties, utilizing EC techniques. TheECKE-1 mechanism uses three point multiplications and twofield multiplications along with twice applications of a hashfunction. Author of [22] provided a password based remote au-thentication scheme for SC based on ECDH. The model aimsat providing a lightweight solution for devices with limited re-sources, which eliminated needs to keep the password tablein server side in order to reduce the side effect of compro-mising the server. Also, the mechanism presented in [23] con-centrated on two-party key designed for sensor networks thatcontain low-resource devices with a heterogeneous large-scaledeployment, based on EC and key management based on AVLtree. The next two-party ECDH based mechanism is ECKE-1Npresented in [24], which improves ECKE-1 by constructing thekey via 2.5 point multiplications, one field multiplication and

TABLE IEPAK PARAMETERS

Fig. 3. ECC-based PAKE (EPAK) protocol.

twice hash function applications. Later on, EECKE-1N [25] fur-ther improves ECKE-1N by constructing the key via only onepoint multiplication and one field multiplication to construct thetwo-party key.Although the above mechanisms are designed efficiently and

follow ECDH, mostly they use a predefined private and publickey, which requires the support of certificates issued by a certifi-cate authority. In this work, we design an ECC-based model ofthe PAKE protocol (as in X.1035 standard) called EPAK, whichuses only a predefined password and delivers an improvementon ECKE-1N and EECKE-1N mechanisms (Section III). Weutilize EPAK as our auxiliary protocol for our main MCEPAKprotocol presented in Section IV.

III. EPAK: ECC-BASED PASSWORD AUTHENTICATEDKEY-EXCHANGE PROTOCOL

In this section, we present the EPAK protocol, which is de-signed as an ECC version of the PAKE protocol presented in theX.1035 standard.Let us consider key agreement between Alice and Bob uti-

lizing a pre-shared password . Similar to the X.1035 stan-dard, we define . Furthermore, we as-sume that both parties have knowledge of the EC parametersset and hash function . Table I presents thelist of parameters and their definitions used in our design.

A. Description of EPAK Protocol

Shown by Fig. 3, the EPAK protocol has the following steps:1) Step I:2) Alice: Let us assume that Alice is the initiator. She picks

a random number (as her private key) andmultiply it to the group generator to obtain her public key

IEEE

Pro

of

Prin

t Ver

sion


via (10) and an appropriate EC point via (11). Finally,she computes to obtain a symmetric key with which sheencrypts as via (12) and sends it to Bob

(10)

(11)

(12)

3) Bob: Upon receiving packet from Alice, Bob usesto decrypt and obtain following (13), and the ap-

propriate EC point aligned with the value shownby (11)

(13)

4) Step II:5) Bob: Bob picks a random number (as his

private key) and multiplies it to the group generator to obtainhis public key via (14). He also calculates the appropriateEC point aligned with the value based upon (15):

(14)

(15)

Then, he multiplies his private key to the Alice’s public key toobtain shared value through (16), and finds appropriateEC points as per (17). Then, he computes for theverification of having the values , through (18),and finally, uses to encrypt via (19), and sends it toAlice

(16)

(17)

(18)

(19)

6) Alice: Alice uses to decrypt and obtainsthrough (20), and also computes the appropriate EC point

aligned with the given by (15). Then, she multi-plies her private key to Bob’s public key to obtain sharedvalue via (21), followed by given by (17).Finally, she computes for verification of having the valuesof through (22). If the verification holds, shecan be sure that Bob has the required values

(20)

(21)

(22)

7) Step III:8) Alice: Alice needs to make Bob assure that she has the

values as well. Therefore, she performs (23) to calculate outof , and sends it to Bob

(23)

9) Bob: On the other side, Bob calculates via (24) andcompares it with . If the verification holds, Bob is assuredthat Alice has the required values as well

(24)

10) Step IV: So far, both parties have the required parame-ters and have verified each other. Finally, they perform (25) tocalculate the shared symmetric key

(25)

B. A Few Comments About the EPAK Protocol

In the first verification initiated by Bob , we useonly coordinates (and ). Furthermore, in the second verifica-tion initiated by Alice , only coordinates are used(and ). However, in the final step and for calculating the sym-metric key , we have a combination of all values consisting ofand coordinates as well as the initial password and identities

of the parties (as part of the ).Thus far, we have defined neither the mechanism of

nor in the aforementioned design.Since is a point in the form of , for instance to encryptthis pair, we can multiply each coordinate by :

Consequently, on the other side we need to divide them by theand obtain the original values:

C. Brief Analysis of the EPAK Protocol

Comparing to the previous models, we eliminate the fixedinitial private key. To be more precise, each party chooses arandom number to be the private key per session. Also, ourmechanism constructs the key only via one multiplicationgiven by (16) and (21), and one hash function for the key in(25). In fact, other times that hash function is utilized are forverification purposes; this is an add-on to the ECKE-1N andEECKE-1N protocols. Furthermore, other multiplications in(19) and (20) are for encryption, whereas exchanged packetsare not encrypted at all in ECKE-1N and EECKE-1N.

IV. MCEPAK: MULTILAYER CONSENSUS ECC-BASEDPASSWORD AUTHENTICATED KEY-EXCHANGE PROTOCOL

Referring to Section I, our objective is a mutual password-based authenticated key agreement between an applianceand the controllers , , and , resulting in an in-dividual key between the appliance and each one of the upperlayer controllers. Based on Fig. 1, we need four symmetric keys.Our model based on PAKE protocol presented in X.1035 stan-dard (or EPAK in Section III) is shown in Fig. 4. In this abstractmodel and for each key, we need to have a predefined sharedpassword between the two involved parties (appliance and oneof the controllers). At the end of Section VI, we show that ourapproach decreases the number of packets and improves the se-curity of the design.In this section, we extend our EPAK protocol in order to ad-

dress the SG requirements presented in Section I, based on theEPAK protocol described in Section III. We use the same nota-tions as presented in the previous sections. The appliance

IEEE

Pro

of

Prin

t Ver

sion


Fig. 4. Four keys construction based on PAKE or EPAK.

Fig. 5. MCEPAK Protocol phases and packets.

knows at least the ID of the HAN and can obtain ID of the .Also via our four-phase mechanism, gains access to infor-mation of the other controllers. We assume:• and share a predefined secret password .• The ECC parameter set and areknown and shared by all parties.

• Controllers , , have already been authen-ticated to the upstream and downstream controllers, if any,and can have secure communications with them.

• Controllers are trusted parties that form parts of and arecontrolled by the grid domain; the appliance belongs to thecustomer domain, and is controlled by the customer.

• The following symmetric keys already exist:— : Shared between and .— : Shared between and .— : Shared between and .

Note: Although the secure channels that we assume to alreadyexist between the controllers may not be certain, we need to trustit, otherwise “we would be unable to ever get any work done”[26]. Furthermore, the trust assumption is especially feasible inthe multilayer architecture of SG controllers [4] considered inthis paper.Furthermore, we introduce a new vector (entities identifi-

cations set), which carries the IDs of the entities involved in ourprotocol as a part of the information exchanged between them.Our four-phase MCEPAK protocol depicted in Fig. 5 consistsof the following steps.

A. Phase I: Initial Flow

In MCEPAK, initiates the keys establishment process:1) First Packet: Firstly, follows (26) to utilize the initial

password shared by to calculate temporary key

(26)

also picks a random number , then computesvia (27) and appropriate coordinates given by

(28)

(27)

(28)

Then, puts its own ID in field of given by (29). Finally,forms packet by and all encrypted by the

key as per (30), and then sends the packet to

(29)

(30)

2) Second Packet: First, calculates temporary keyby performing (26), and decrypts received packet from byway of (31) to obtain and

(31)

Then, picks a random number and computesthrough (32)

(32)

(33)

Then, puts its own ID into field of by way of (34), andalso computes via (35)

(34)

(35)

Finally, dispatches along with and to , allencrypted with the shared key following (36)

(36)

3) Third Packet: First, obtains , and by de-cryption of the received packet from via (37):

(37)

Then, chooses random number and com-putes through (38):

(38)

(39)

Then, copies its own ID into the field in (40), and com-putes via (41). Finally, forwards , and to, all encrypted with the predefined shared key of through

(42)

(40)

IEEE

Pro

of

Prin

t Ver

sion


(41)

(42)

4) Fourth Packet: Firstly, follows (43) to obtain ,and from the packet received from :

(43)

Then, chooses random number to obtainvia (44)

(44)

(45)

Then, updates field with its own ID as depicted by(46), also computes through (47)

(46)

(47)

Finally, forms packet out of , and asshown by (48), encrypts it by , and forwards it to

(48)

B. Phase II: Response Flow

This flow starts with replying to the fourth packet above.1) Fifth Packet: First, obtains the , and

values by decryption of the packet received from thefollowing (49)

(49)

Then, extracts ID of any of the controllers (if needed) aswellas ID of the appliance from , and also calculates

through (50). Beside, inserts its own ID into field ofas presented by (51)

(50)

(51)

Then, picks a random number to obtainand following (52) and (53) respectively

(52)

(53)

(54)

Then, obtains coordinates as shown by (54) andas depicted by (45), and then computes via (55)

for verification purpose

(55)

Finally, follows (56) to form from , and ,in which encrypts the packet by as shown in (56)

(56)

2) Sixth Packet: First, decrypts the packet received fromto obtain the , and values following (57). Then,calculates through (58)

(57)

(58)

Then, utilizes its own random number (fourth step) tocalculate via (59), and via (60). Then, follows(61) to calculate for the verification purpose

(59)

(60)

(61)

Finally, forms out of , , and , andencrypts the packet by as shown in (62) to be sent to theBAN controller

(62)

3) Seventh Packet: First, obtains the parameters ,, and as presented by (63) by decrypting packet

received from . Then, calculates the key via (64)

(63)

(64)

Then, uses its own random number (third step) to obtainthe via (65), through (66) and via (67)

(65)

(66)

(67)

Then, obtains coordinates and asshown by (45) and (39) respectively, and calculatesthrough (68) for verification

(68)

Finally, forms packet by , , , and, encrypted by as shown in (69), and sends the packet to

(69)

4) Eighth Packet: First, decrypts the packet receivedfrom and obtains , , , and as de-picted by (70). Then, calculates through (71)

(70)

(71)

Then, utilizes its own random number (second step) tocompute via (72), through (73), via (74) and

through (75)

(72)

(73)

IEEE

Pro

of

Prin

t Ver

sion


(74)

(75)

obtains coordinates and as depictedby (39) and (33), respectively, and then computes using(76) for verification

(76)

Finally, forms packet out of , , , ,and , encrypted by as shown by (77), and sends

the packet to

(77)

C. Phase III: Verification

1) Appliance (Ninth Packet): In this phase, verifiesthe received values and dispatches the confirmations to theupstream controllers. First, computes the temporarykey via (71), to decrypt the received packet fromin order to obtain , , , , andfollowing (78)

(78)

Then, utilizes its own random number (first step) tocalculate via (79), through (80), via (81) and

through (82), which are shared by , , and ,respectively

(79)

(80)

(81)

(82)

Then, uses the above shared values to obtain coordinates, , and as shown in (54),

(45), (39) and (33), respectively. Then, utilizes the coordi-nates and performs (55), (61), (68) and (76) to substantiate .If the verification holds, proceeds to the next step. Note that,since has , it is able to obtain , basedupon (35), (41) and (47). Finally, generates four valuesvia (83) for , through (85) for , via (87) forand through (89) for , as verifiers of the shared values,and forwards them to

(83)

(84)

(85)

(86)

(87)

(88)

(89)

TABLE IIINTERNAL ADVERSARY KNOWLEDGE

2) HAN Controller (Tenth Packet): receives the abovesubstantiation values and then verifies based upon (83). Ifthe verification holds, relays the other values to .3) BAN Controller (Eleventh Packets): receives the

above values and then verifies following (85). If theverification holds, relays the other values to .4) NAN Controller (Twelfth Packets): receives the

eleventh packet and then verifies through (87). If theverification holds, relays the other values to .5) SGCC Controller: receives the twelfth packet and

then verifies via (89).

D. Phase IV: Keys Calculation

Thus far, all parties have their verified shared values. Finally,they can generate their appropriate symmetric keys per (90),(91), (92) and (93)

(90)

(91)

(92)

(93)

V. ANALYSIS

Since the proposed MCEPAK protocol is based on ECC,X.1035 standard and D-H algorithm, it inherits most of theirbenefits. In this section, we study and model the adversary,analyze the security of the system mainly in terms of differentattacks, and evaluate the security of the keys. To analyze andevaluate the security of our proposed protocol, we follow theDolev-Yao approach [27]. In the Dolev-Yao model, the adver-sary is capable of recording, deleting, re-playing, re-routing,re-ordering and re-scheduling the messages. All of the mes-sages generated by the honest parties are sent to the adversary,and the honest nodes receive the messages only from theadversary. Also, we analyse the protocol mechanism from thesystem and network overhead point of views.

A. Adversary Models

We consider two models for internal and external adversaries.1) Internal Adversary: In this model, our adversary is one of

the trusted parties that has become malicious.2) Objective: The objectives of the adversary are i) Gaining

access to the system resources such as the appliance or any ofthe controllers, ii) Performing a MITM attack to gain access toany of the keys.3) Initial Capabilities: The adversary has complete knowl-

edge about the topology and the exact address/ID of each party.Furthermore, the adversary knows the detail design of the keyagreement mechanism and has access to the system parametersrequired for the key agreement. Depending on which one of theinvolved parties is the malicious one, the adversary’s knowledgein each case is listed in Table II.

IEEE

Pro

of

Prin

t Ver

sion


4) Capabilities During the Attack: The adversary receivesthe encrypted and unencrypted (plain) data in different stages ofthe keys agreement, or later on during the using of the key. Incase of having control on a controller, the adversary will attemptto perform a MITM attack. She/He can destroy the packets andcause failure in one of the verification phases that yields re-ini-tiation of the key agreement protocol, which is essentially a de-nial of service (DoS) attack. Furthermore in case of a malicious, the adversary can perform DoS attack by initiating the key

agreement protocol continuously.5) Discussion: Referring to the assumptions of theMCEPAK

protocol, controllers are fully trusted parties as parts of the SGdomain, and they are controlled/setup/managed by the grid ad-ministrators. Even a HAN controller, which is usually a SmartMeter that also acts as a gateway, is not under customer control.Therefore, initially they follow the steps of the algorithm anddo not show any misbehaving action. Also, the administratorof the SG monitors them to protect the SG from any maliciouscontroller. So, dealing with malicious controllers is beyond thescope of this paper.However, a malicious can perform a DoS attack easily,

for instance by failing the verification phase. To prevent it, thesystem can define a limit of the key agreement sessions per ap-pliance in each period of time. If after a number of tries, stillthe appliance could not finish the process, it means that eitherthe node is malicious or the initial password between and

does not match. Therefore, the system stops the applianceand cancels its future tries. Having said this, the attack can bedetected at, e.g., level as long as uses the same ID.Initiating the key construction sessions by different IDs is an-other option for to perform DoS attack against the HANcontroller. In this case, can limit the number of open ses-sions in the HAN domain to prevent such an attack.6) External Adversary: In this model, the adversary is not

any of the involved parties, and performs attacks from outsideof the controllers and appliance set.7) Objective: i) Gaining access to the system resources, like

any of the controllers or . ii) Performing a MITM attack togain access to any of the symmetric keys. iii) Performing a DoSattack to overload the system (any of the controllers).8) Initial Capabilities: Similar to the internal model, the

external adversary has complete knowledge about the topologyand the exact address/ID of the parties. The adversary alsoknows the detail design of our mechanisms.9) Capabilities During the Attack: The adversary receives

the encrypted and unencrypted (plain) packets during and afterthe key agreement process.10) Discussion: Since our adversary receives all the packets,

in order to gain access to the system resources, like , she/hecan perform a brute-force attack to find out the pre-shared pass-word between the appliance and the HAN controller. Brute-force attack is a time consuming attack, and the password is usedonly during the first few packet delivery between the two parties( and ). Furthermore, we use a hash function to combinethe password and random numbers to construct the key. There-fore, our model (similar to PAKE protocol) has the forward se-crecy characteristic. Having said this, finding the password doesnot help the adversary to figure out or calculate any of the sym-metric keys. The same situation is applicable to any of the orig-inal keys between the controllers. Indeed, obtaining any of theshared keys between the controllers does not help the adversaryto calculate the constructed symmetric key after the fact. This

Fig. 6. AVISPA results. (a) OFMC. (b) Cl-AtSe.

TABLE IIIOVERHEAD IMPROVEMENT

TABLE IVIMPROVEMENT OF ENCRYPTION/DECRYPTION TIME

is because the packets exchanged by our mechanism do not in-clude all the items required for the key calculation. Besides, theaforementioned discussion shows that an adversary cannot per-form a successful MITM attack.To perform a DoS attack and overload the system (any con-

troller), our adversary should initially run a spoof attack to mas-querade one of the parties as well as performing a brute-force ordictionary attack to steal the shared key between the party andits neighbor. Then, she/he shouldmanage sending the key agree-ment packets to the neighbor to perform the DoS attack. Evenif the adversary is able to manage these attacks, the system canlimit the number of requests from any ID for the key construc-tion and prevents this scenario. Any misbehaviour can be mon-itored by other controllers, where an intrusion detection systemlike [28] would help in this regard.

B. Security Analysis

1) Consensus Key Establishment: Referring to the key con-struction (90), (91), (92), and (93), we need contribution ofother downstream controllers for each controller. For instancein the case of as per (93), we utilize that containsrandom numbers chosen by as well as random num-bers of , (53). Similarly, (92) uses randomvariables as well as (44). Furthermore,

verifies the received shared values all at the same time bychecking . Therefore, if any of the controllers does not co-operate on the key constructions, none of the parties would havean appropriate key.2) Mutual Authentication: The utilization of password

provides a mutual authentication between and . Further-more, since is a part of the calculations that

IEEE

Pro

of

Prin

t Ver

sion


Fig. 7. Main HLPSL Codes.

are used by other controllers for the verification and key forma-tion, the mutual authentication is endorsed on the entire key-set.3) Hierarchical/Conditional Key Formation: needs to

establish a symmetric key shared by in order to establish akey with any of the higher layers controllers. Furthermore, allof the key construction are initiated by and are forwarded to

as a gateway. To be more precise, only the downstream (andnot the upstream) controller’s random numbers are required byeach controller.

4) Replay Attack: Like D-H algorithm, since MCEPAK uti-lizes random numbers and hash functions to establish the keys,it delivers the replay attack resilience.5) Key Privacy & Insider Attack Resilience: Depicted by

(90)–(93), each key is only known by and the correspondingcontroller. For instance, is only known by and ,which supports the key privacy. Other controllers in-betweenonly attend in the key construction; however, they do not gainaccess to any data to be used to decrypt the messages.

IEEE

Pro

of

Prin

t Ver

sion


Fig. 8. HLPSL codes of and . (a) New appliance . (b) Home controller .

6) Off-Line Guessing Attack Resilience: An eavesdroppermay perform an off-line dictionary attack over password byhaving access to the (27) and obtains access to ; never-theless, based on ECC-CDH (Elliptic Curve Cryptography Co-factor Diffie-Hellman) assumption [19], s/he is not able to find. As a result, the adversary does not have complete informa-

tion and data to compute any of the keys.7) Denning-Sacco Attack Resilience: If an eavesdropper

gains access to , still she/he is not ableto obtain value used in the key establishment. Further-more, she/he is not able to guess where

, .8) Compromised Impression Resilience: Referring to our ad-

versarymodels as well as (90)–(93), finding any of the keys doesnot enable an intruder to obtain any other controllers key.9) Ephemeral Key Compromise Impersonation: Even if an

adversary finds any of the passwords, she/he is not able tocalculate since she/he does not have access to the randomnumber . Also, is required by the her/him to obtain( is a controller).10) Unknown Key-Share Attack: assures that the

controllers have the required parameters to calculate the keys.On the other hand, parameters , , assurethe controllers that has the required values. So, if a con-troller is able to perform the key formation, the appliance wouldbe able to do it too, and wise versa.11) MITM Attack: Per the aforementioned discussion on the

adversary models, since all of the packets betweenare encrypted by based temporary keys , MCEPAKenjoys MITM attack resilience. Also, the communications

between the controllers required for key formation are securedby the preliminary keys of the controllers.

C. Formal Validation Using Software Tool

To evaluate validity of the keys, we use Automated Valida-tion of Internet Security Protocols and Application (AVISPA)security analyzer package. AVISPA is a tool for the automaticverification and analysis of Internet security protocols [29], andone of themost trusted evaluation tools in the literature. AVISPAanalyzes the scheme and protocols with respect to different at-tacks by combining automatic security analysis and verificationback-end servers like On-the-Fly Model-Checker (OFMC) andConstraint-Logic-based Attack Searcher (Cl-AtSe). To performthe key validation using AVISPA and evaluate it by the back-endservers, the protocol and mechanisms are required to be codedin the High Level Protocol Specifications Language (HLPSL).More information about the AVISPA, its features and HLPSLlanguage can be found in [29].We apply AVISPA to analyse appropriate shared keys of the

five entities , , , and . Simulation results pre-sented in Fig. 6(a) and (b) show that the symmetric keys con-structed by our mechanism are secure and safe to be used by thesystem entities.The evaluation program and AVISPA related HLPSL codes

for the session, environment and goal sections, as well as eachparty HLPSL related codes are presented in Appendix A.

D. Performance Analysis

1) Low Implementation Cost: Let us consider the followingtwo scenarios:

IEEE

Pro

of

Prin

t Ver

sion


Fig. 9. HLPSL Codes of , and . (a) Building controllers . (b) Neighborhood controller . (c) Central controller .

• : establishes an individual symmetric key byeach controller, following the PAKE or EPAK protocols(refer to Section IV).

• : follows MCEPAK (or SG-MCPAK) protocol.An overall comparison between the two scenarios is presentedby Table III. Based on Fig. 4, performs four iterations toconstruct four symmetric keys between appliance and theupstream controllers. Also, referring to Sections II and III, onepassword between and the controller is required for eachkey agreement. Furthermore, proceeds duringphases and requires five hash functions, while has onlyfour phases and needs only one hash function and one password.In terms of random numbers, in two random numbers perkey are required, and in total eight random numbers are needed.On the other hand, requires only five random numbers.Also, transfers three packets per iteration and in totalneeds packets to be delivered. In contrast,

needs three packets per phase for a total ofpackets.2) Fast Packet Delivery: Packet delivery between andare the same for both scenarios, although MCEPAK pro-

vides a faster packet delivery between and the upper-layercontrollers for regular communications. Let us define as therequired time for the encryption or decryption process at eachparty, which is assumed to be the same. Let us consider the fol-lowing two scenarios:• : System has one symmetric key per layer. If a packetis encrypted by controller to be sent to , shoulddecrypt it by the key between , and then encryptsit again by the key between . Finally, the packetcan be decrypted by using the shared symmetric keybetween .

• : System provides a shared symmetric key between. Therefore, the packet that needs to be sent by

to , needs to be encrypted and decrypted once (by).

Table IV presents the required time in each case by each con-troller, and also presents the time saving (improvement).

Note: An analysis and evaluation on EPAK protocol (cost ofkey agreement) in comparison to the literature is presented atthe end of Section III as well.

VI. CONCLUSION

We have presented the MCEPAK protocol, which enables se-cure communications between a home appliance and differentlayers of the SG control system. The protocol efficiently estab-lishes four multilayer consensus password-authenticated sym-metric keys between an appliance and upper layer controllers inorder to provide a hierarchical authority over an appliance. TheMCEPAK protocol takes advantage of ECC to provide a highsecurity level with a small key size while addressing the poten-tial resource constraints in the devices involved. The protocolcan be easily implemented by adaptation of the current X.1035standard and applying the ECC approach, and it can be extendedto a larger number of layers if required. We have analyzed andshowed that proposed mechanisms reduce the system securityoverhead while providing resilience against most of the well-known attacks. Compared to the X.1035 standard, MCEPAKincurs a lower load for computations of the hash function andrequired passwords. Also, our EPAK protocol presented in thispaper is general in that it can be used and implemented in anyapplication and environment outside of an SG system. We havedeveloped EPAK to facilitate the design of MCEPAK. SinceEPAK is based on ECC, it provides a high security level with asmall key size.

APPENDIXOUR DEVELOPMENT FOR EVALUATION IN AVISPA

Fig. 7 presents our evaluation program and AVISPA relatedHLPSL codes for the session, environment and goal sections.Also, HLPSL codes of the appliance is shown in Fig. 8(a) whileHLPSL codes of the controllers roles are shown in Figs. 8(b)and 9(a)–(c).

IEEE

Pro

of

Prin

t Ver

sion


REFERENCES[1] “Introduction to NISTIR 7628 guidelines for smart grid cyber se-

curity,” National Institute of Standards and Technology (NIST),2010 [Online]. Available: http://www.nist.gov/smartgrid/upload/ni-stir-7628_total.pdf

[2] P. McDaniel and S. McLaughlin, “Security and privacy challenges inthe smart grid,” IEEE Security Privacy, vol. 7, no. 3, pp. 75–77, May/Jun. 2009.

[3] Y. Yan, Y. Qian, H. Sharif, and D. Tipper, “A survey on smart gridcommunication infrastructures: Motivations, requirements and chal-lenges,” IEEE Commun. Surveys Tuts., to be published.

[4] M.M. Fouda, Z. M. Fadlullah, N. Kato, R. Lu, and X. Shen, “Towards alight-weight message authentication mechanism tailored for smart gridcommunications,” in Proc. IFIP SCNC Workshop, Shanghai, China,Apr. 2011.

[5] Q. Li and G. Cao, “Multicast authentication in the smart grid with one-time signature,” IEEE Trans. Smart Grid, vol. 2, no. 4, pp. 686–696,Dec. 2011.

[6] W. Diffie and M. E. Hellman, “New direction in cryptography,” IEEETrans. Inf. Theory, vol. IT-11, pp. 644–654, Nov. 1976.

[7] H. Nicanfar and V. C. M. Leung, “Smart grid multilayer consensuspassword-authenticated key exchange protocol,” in Proc. IEEE SFCSWorkshop, Ottawa, ON, Canada, Jun. 2012.

[8] T. ElGamal, “A public key cryptosystem and signature scheme basedon discrete logarithm,” IEEE Trans. Inf. Theory, vol. IT-31, pp.469–472, Jul. 1985.

[9] S. M. Bellovin and M. Merritt, “Encrypted key exchange: Pass-word-based protocols secure against dictionary attacks,” in Proc.IEEE Comput. Soc. Symp. Res. Security Privacy, Oakland, CA, May1992.

[10] D. H. Seo and P. Sweeney, “Simple authenticated key agreement algo-rithm,” Electron. Lett., vol. 35, no. 13, pp. 1073–1074, Jun. 1999.

[11] H. Yeh and H. Sun, “Simple authenticated key agreement protocol re-sistant to password guessing attacks,” ACM SIGOPS Oper. Syst. Rev.,vol. 36, no. 4, pp. 14–22, Oct. 2002.

[12] W. Juang, S. Chen, and H. Liaw, “Robust and efficient password-au-thenticated key agreement using smart cards,” IEEE Trans. Ind. Elec-tron., vol. 55, no. 6, pp. 2551–2556, Jun. 2008.

[13] X. Ding, C. Ma, and Q. Cheng, “Password authenticated key exchangeprotocol with stronger security,” in Proc. ETCS Workshop, Wuhan,Hubei, China, Mar. 2009.

[14] L. Liu and Z. Cao, “Improvement of one password-based authenticatedkey exchange protocol,” in Proc. ISISE Symp., Wuhan, Hubei, China,Mar. 2009.

[15] G. Yao, H. Wang, and D. Feng, “A group PAKE protocol using dif-ferent passwords,” in Proc. NSWCTC Conf., Wuhan, Hubei, China,Apr. 2009.

[16] Z. Zhang and Q. Zhang, “Verifier-based password authenticated keyexchange protocol via elliptic curve,” in Proc. ICISIT Conf., Beijing,China, Dec. 2010.

[17] IEEE Standard Specifications for Password-Based Public-Key Cryp-tographic Techniques, IEEE Std 1363.2-2008, 2009.

[18] “Password-Authenticated Key Exchange (PAK) Protocol,” Telecom-munication Standardization Sector of International Telecommunica-tion Union (ITU-T), Recommendation X.1035, 2007, .

[19] A. H. Koblitz, N. Koblitzb, and A. Menezes, “Elliptic curve cryptog-raphy: The serpentine course of a paradigm shift,” Elsevier J. NumberTheory, vol. 131, no. 5, pp. 781–814, May 2011.

[20] “Recommendation for pair-wise key establishment schemes usingdiscrete logarithm cryptography (revised),” National Institute ofStandards and Technology (NIST), 2007 [Online]. Available:http://csrc.nist.gov/publications/nistpubs/800-56A/

[21] M. A. Strangio, “Efficient Diffie-Hellmann two-party key agreementprotocols based on elliptic curves,” in Proc. ACM Appl. Sci., Santa Fe,NM, Mar. 2005.

[22] A. P. Muniyandi, R. Ramasamy, and Indrani, “Password based remoteauthentication scheme using ECC for smart card,” in Proc. ICCCS,Orisa, India, Feb. 2011.

[23] H. Boumerzoug, B. A. Bensaber, and I. Biskri, “A keys managementmethod based on an AVL tree and ECC cryptography for wirelesssensor networks,” in Proc. Q2SWinet, Miami Beach, FL, Oct.–Nov.2011.

[24] S. Wang, Z. Cao, M. A. Strangio, and L. Wang, “Cryptanalysis andimprovement of an elliptic curve Diffie-Hellman key agreement pro-tocol,” IEEE Commun. Lett., vol. 12, no. 2, pp. 149–151, Feb. 2008.

[25] E. J. Yooni and K. Y. Yoo, “A new elliptic curve Diffie-Hellman two-party key agreement protocol,” in Proc. ICSSSM Conf., Tokyo, Japan,Jun. 2010.

[26] C. H. Hauser, “Trust research to address uncertainty in security for thesmart grid,” in Proc. IEEE PES ISGT, Washington, DC, Jan. 2012.

[27] D. Dolev and A. Yao, “On the security of public-key protocols,” IEEETrans. Inf. Theory, vol. IT-29, pp. 198–208, 1983.

[28] P. Jokar, H. Nicanfar, and V. C. M. Leung, “Specification-based intru-sion detection for home area networks in smart grids,” in Proc. IEEESmartGridComm, Brussels, Belgium, Oct. 2011.

[29] AVISPA-AutomatedValidation of Internet Security Protocols [Online].Available: http://www.avispa-project.org

Hasen Nicanfar (S’11) received his B.A.Sc.degree in electrical engineering from Sharif Uni-

versity of Technology [CITY / STATE/ COUNTRY?] in 1993, and hisMASc. degree in computer networks from Ry-

erson University [CITY / STATE /COUNTRY?] in 2011. He is workingtoward the Ph.D. degree in the Department ofElectrical and Computer Engineering, the Universityof British Columbia.

From 1993 to 2010, he has worked in different positions such as IT and ERPmanager and consultant, projectmanager, production engineer andmanager, andbusiness and system analyst. Currently, he holds the position of research assis-

tant in WiNMoS Lab [CITY / STATE / COUNTRY?].His research interests are in the areas of the system and network design andmanagement, security and privacy, cryptography, and routing protocol design,for wireless communication and smart grid system.

Victor C. M. Leung (S’75–M’89–SM’97–F’03)received the B.A.Sc. (Hons.) degree in electricalengineering from the University of British Columbia(UBC), Canada, in 1977, and was awarded theAPEBC Gold Medal as the head of the graduatingclass in the Faculty of Applied Science. He attendedgraduate school at UBC on a Natural Sciences andEngineering Research Council Postgraduate Schol-arship and completed the Ph.D. degree in electricalengineering in 1981.From 1981 to 1987, he was a Senior Member of

Technical Staff at MPR Teltech Ltd. In 1988, he was a Lecturer in the Depart-ment of Electronics at the Chinese University of Hong Kong. He returned toUBC as a faculty member in 1989, and currently holds the positions of Pro-fessor and TELUS Mobility Research Chair in Advanced TelecommunicationsEngineering in the Department of Electrical and Computer Engineering. He hasco-authored more than 600 technical papers in international journals and confer-ence proceedings, and several of these papers had been selected for best paperawards. His research interests are in the broad areas of wireless networks andmobile systems.Dr. Leung is a registered professional engineer in the Province of

British Columbia, Canada. He is a Fellow of the Engineering Institute ofCanada, and a Fellow of the Canadian Academy of Engineering. He hasserved/is serving on the editorial boards of the IEEE JOURNAL ON SELECTEDAREAS IN COMMUNICATIONS—WIRELESS COMMUNICATIONS SERIES, IEEETRANSACTIONS ON WIRELESS COMMUNICATIONS, IEEE TRANSACTIONS ON

VEHICULAR TECHNOLOGY, IEEE TRANSACTIONS ON COMPUTERS, IEEEWIRELESS COMMUNICATIONS LETTERS, as well as several other journals. Hehas guest-edited many journal special issues, contributed to the organizationof a large number of international conferences, and served on the technicalprogram committee of numerous international conferences. Dr. Leung is arecipient of the 2011 IEEE Vancouver Section Centennial Award and the 2012UBC Killam Research Prize.

Hasen Nicanfar IEEE ProofWeb Version - UBC ECEvleung/Accepted_Journals/Hasen_TSG_2013.pdfIEEE...

Documents

Transcript of Hasen Nicanfar IEEE ProofWeb Version - UBC ECEvleung/Accepted_Journals/Hasen_TSG_2013.pdfIEEE...