A Key Management Scheme for Secure ... - IEEE Xplore

4746

IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS, VOL. 60, NO. 10, OCTOBER 2013

A Key Management Scheme for Secure Communications of Advanced Metering Infrastructure in Smart Grid Nian Liu, Member, IEEE, Jinshan Chen, Lin Zhu, Jianhua Zhang, Member, IEEE, and Yanling He

Abstract—Advanced metering infrastructure (AMI) is an important component of the smart grid. The cyber security should be considered prior to the AMI system applications. To ensure confidentiality and integrality, a key management scheme (KMS) for a large amount of smart meters (SMs) and devices is required, which is not a properly solved problem until now. Compared with other systems, there are three specific features of AMI that should be carefully considered, including hybrid transmission modes of messages, storage and computation constraints of SMs, and unfixed participators in demand response (DR) projects. In order to deal with security requirements and considering the distinctive features, a novel KMS is proposed. First, the key management framework of an AMI system is constructed based on the key graph. Furthermore, three different key management processes are designed to deal with the hybrid transmission modes, including key management for unicast, broadcast, and multicast modes. Relatively simple cryptographic algorithms are chosen for key generation and refreshing policies due to the storage and computation constraints of SMs. Specific key refreshing policies are designed since the participators in a certain DR project are not fixed. Finally, the security and performance of the KMS are analyzed. According to the results, the proposed scheme is a possible solution for AMI systems. Index Terms—Advanced metering infrastructure (AMI), key management scheme (KMS), smart grid, transmission mode.

I. I NTRODUCTION

A

S A NEW emerging technology for smart grid, advanced metering infrastructure (AMI) [1] is the system and network used to measure, collect, store, analyze, and use energy usage data, which provides a convenient bridge between consumers and electric power utilities. In order to provide the broadest possible platform for delivering a wide range of applications in the future, open network and information techniques have been introduced to the smart grid [2], [3], which increases the probability of cyber security threats [4], [5].

Manuscript received January 10, 2012; revised May 7, 2012 and July 1, 2012; accepted August 2, 2012. Date of publication September 4, 2012; date of current version May 16, 2013. This work was supported in part by the National Natural Science Foundation of China under Grant 51007022 and in part by the Chinese Universities Scientific Fund under Grant 12MS32. N. Liu and J. Zhang are with the School of Electrical and Electronic Engineering, North China Electric Power University, Beijing 102206, China (e-mail: [email protected]; [email protected]). J. Chen is with the Electric Power Research Institute of Fujian Electric Power Company Ltd., Fuzhou 350007, China (e-mail: [email protected]). L. Zhu is with the College of Politics and Public Administration, Tianjin Normal University, Tianjin 300384, China (e-mail: [email protected]). Y. He is with Fujian Shuikou Hydropower Generation Company, Ltd., Fuzhou 350800, China (e-mail: [email protected]). Digital Object Identifier 10.1109/TIE.2012.2216237

In general, the cyber security requirements of AMI include confidentiality, integrality, and availability [6]. Before AMI can be deployed, the confidentiality for customer privacy and customer behavior, as well as message authentication for meter reading, demand response (DR), and load control messages, is the major security requirement to be provided. The confidentiality and integrality can be solved by encryption and authentication protocols, which depend on the security of cryptograph keys. To ensure the security, the key management for large amounts of devices in AMI systems is very important. The key management scheme (KMS) is always composed of a key organizational framework, key generating, refreshing, distribution, storage policies, etc. Recently, there have been several studies related to the key management of AMI systems. An integrated scheme with confidentiality and authentication for secure AMI communications is proposed in [7], which can provide trust services, data privacy, and integrity by mutual authentications. Several typical application protocols are analyzed and compared for AMI customer applications in [8], which use security mechanisms such as Advanced Encryption Standard (AES) encryption and public-key infrastructure authentication. These research results have relations with key management, but the focus is on the encryption and authentication mechanisms for AMI applications, including device authentication, data confidentiality, and message integrity. How to manage the keys for a large number of smart devices in AMI systems is an issue still lacking in complete solution. Supposing that the AMI network is based on the ad hoc wireless sensor network, a key establishment and security algorithm based on public-key cryptography is proposed in [9]. According to the development of smart grid in different countries, the types of AMI networks are various [10], [11]. As a result, the applications of this algorithm are restricted. In [12], the importance of key management has been pointed out, but there is not any specific scheme provided. Furthermore, there have been some KMSs proposed for secure communications of power control systems, such as SCADA systems and wide-area protection systems [13]–[15]. However, these KMSs, along with those used in general IT systems, have difficulties in being directly applied to an AMI system, in that these systems are different in system structures, message characteristics, and requirements. From the existing research results, we can find that the proposed KMSs are mostly for a specific AMI system. The KMS may be not applicable when the application functions, communications, and information technologies are changed.

0278-0046/$31.00 © 2012 IEEE

LIU et al.: KEY MANAGEMENT SCHEME FOR SECURE COMMUNICATIONS OF AMI IN SMART GRID

However, until recently, most of the AMI systems were in the pilot phase; there is still some degree of uncertainty in the future. In addition, the construction and development of an AMI system are not consistent in different countries and areas. From the perspective of the application requirements, the functions which need to be deployed are also different. Some applications are very simple, such as metering, measuring, and monitoring; some are relatively complex, and they take more into consideration the applications of DR and load control. Similarly, there are also various communication modes depending on the application requirements and user preference. For the aforementioned reasons, we are trying to propose a more common KMS for AMI systems. To summarize AMI characteristics and trends, we believe that the structure and components of AMI are relatively fixed. In other words, the main object of the key management is the smart meters (SMs), which is constant. Therefore, a key management framework based on key graph is proposed to manage the keys of a large amount of SMs. The functions of AMI are not fixed, but we can design a KMS for the collection of possible functions. In actual condition, the users can choose part of the KMS for specific applications. The communications are not fixed either, but the features of messages transmitted in the communication channels can be decided by the function requirements. In response to this situation, three types of key management processes are designed for unicast, broadcast, and multicast communications depending on function requirements and message types. Considering time requirements of functions, computation, and storage limitations of SMs, specific key regeneration and refreshing policies are designed in each process. The rest of the contents of this paper will be organized as follows. Section II studies the structure and messages of an AMI system and then summarizes the main features relating to key management. According to these features, the difficulties in designing KMS for AMI are analyzed, and corresponding possible solutions are proposed. From Sections III to VI, a novel KMS is proposed. In Section III, the framework and initialization of the KMS are described. Sections IV–VI present the key management processes for unicast, broadcast, and multicast communications, respectively. Furthermore, the security and performance of the KMS will be analyzed in Sections VII and VIII, respectively. Finally, a conclusion will be presented in Section IX.

II. AMI S YSTEM F EATURES AND D IFFICULTIES FOR A KMS D ESIGN A. Structure of AMI System An AMI system does comprise a number of technologies and applications that have been integrated to perform as one (see Fig. 1): 1) 2) 3) 4) 5)

SMs; user gateways (UGs); home (local) area networks (HANs); wide-area communications infrastructure; meter data management systems (MDMSs).

4747

Fig. 1. AMI system structure.

1) SMs: Generally, SMs are solid-state programmable devices that perform a lot of functions, such as bidirectional metering and measuring (not only for electricity consumption but also for real-time electricity load, maximum demand, voltage, current, frequency, power factor, etc.), time-based pricing, consumption data for consumer and utility, net metering, loss or restoration of power notification, power quality monitoring, and remote turn-on or turn-off operations. Moreover, they enable the DR to achieve [16], so as to facilitate greater energy efficiency since information feedback has been shown to reduce consumers’ usage [17]. 2) UGs: The UG, which is always performed in other devices such as SMs or personal computers, implements protocol conversion and communications between two heterogeneous networks, like the in-home network and wide area network. 3) HANs: A HAN is a kind of local area network, which interfaces with SM, UG, distributed energy resources, and local control devices [17], [18]. 4) Wide-Area Communication Infrastructure: The widearea communication infrastructure supports continuous interaction between the utility, the consumer, and the controllable electrical load. It must employ open bidirectional communication standards, yet requiring high security. Various architectures can be employed [19], with one of the most common being local concentrators that collect data from groups of meters and transmit those data to a central server. Various media can be considered to provide part or all of this architecture, such as optical fiber, power line carrier, copper, radio frequency, Internet, and so on. 5) MDMS: An MDMS, with an AMI head end in contact with the user side, is a database of meter data with analytical tools. Through enterprise bus, it interacts with other systems of the electric power utilities, including consumer information system, outage management system, distribution management system, and so on. B. Messages in AMI System Interactive messages are exchanged via AMI communication networks. The messages include meter data, loss or restoration of power notification, publishing of DR projects, subscription or quit of DR projects, electrical pricing information, and remote load control.

4748


TABLE I F EATURES OF AMI M ESSAGES

The sender and receiver of these messages can be classified into two parts. One part is the devices in the user level, including SMs, UGs, and so on. To make the description more concise, these devices will be simply denoted as SXs. Another part is the management side (MS) which realizes the advanced applications of AMI. All the messages can be divided into three classes according to the transmission mode: unicast, broadcast, and multicast. Unicast mode means message transmitted from one point to the other one, e.g., from MS to one SX; broadcast mode means message transmitted from one point to all the other points, e.g., from MS to all SXs; multicast mode means message transmitted from one point to some other points, e.g., from MS to those SXs who join in one same DR project. The sender, receiver, and transmission mode for each message type are listed in Table I. According to the standard of State Grid Corporation of China, the time requirements of different message types are also listed in Table I. These time requirements may be not equal in other countries, but the differences are small for the same development purpose of smart grid. The three transmission modes and relations between MS and SXs are shown in Fig. 2. In the unicast and broadcast modes, the information exchanges between MS and SXs are fixed. In the multicast mode, the situations are more complex. The users of SXs who participate in a DR project can be deemed as a multicast group. However, the members of each group are not fixed as the users may intend to choose other projects according to personal preference and requirements in different times. As we know, users can request to MS for subscription or quit a DR project. However, the update for group members may be not real time. According to the development status, the different countries and areas may have their own approaches to deal with it. Therefore, we assume that users can request for subscription or quit a DR project at any time, but the update time for participators of the projects in MS is fixed, such as 0:00 of every day or Monday, 0:00, of every week. C. Difficulties and Possible Solutions A KMS is always composed of a key management framework, key generating and refreshing policies, key distribution

Fig. 2. Relations and transmission modes between MS and SXs. (a) Relations between MS and SXs. (b) Broadcast mode for all the SXs. (c) Multicast mode for SXs participating in the DR project 1. (d) Unicast mode between MS and each SX.

policies, storage methods, and so on. According to the structure and messages of AMI, the difficulties of designing the KMS can be concluded as follows. 1) Hybrid transmission modes are used in the bidirectional communications, including unicast, broadcast, and multicast. The KMS should support all these transmission modes. To deal with this problem, the key management framework should be flexible enough to support these three different transmission modes. For each mode, the key generating, refreshing, and distribution policies will be designed, respectively. 2) The SXs are always implemented based on embedded systems. Their computation and storage abilities are limited, which cannot be equaled to a normal computer or server. In addition, the messages require time-limited transmissions. The limited computation ability of SXs mostly affects the design of key generation and refreshing algorithms. Relatively simple algorithms such as hash symmetric cryptographic algorithms could be primarily used. Furthermore, as the transmission time of messages is limited, the number of times of key distribution should be minimized. Similarly, the keys and other related data needed to be stored in SXs should also be minimized. 3) Users participating in DR projects are not fixed. They can choose the projects in different times according to personal preference and requirements. Users participating in the same DR project can form a group, and the users are group members. The group will not be fixed due to the aforementioned reasons. As a consequence, we should focus on the forward security and backward security for multicast mode. New users who participate in the DR project should be included in a group, and the new keys and additional data should be distributed to all the group members for secure communications. On the other hand, users who quit the DR project cannot receive the messages, and the keys and additional data shared in the group should be renewed.


4749

III. BASIC N OTATIONS AND K EY M ANAGEMENT F RAMEWORK A. Basic Notations and Definitions Notations and their definitions that are used in the KMS will be listed as follows: 1) n: the number of SXs; 2) m: the number of DR projects; 3) ui : the ith user in the AMI. u0 denotes MS; others denote SXs; 4) ki : a user key for ui ; 5) gki : a group key for the ith DR project; 6) ski : a session key for message transmissions. i = 0 for broadcast mode; others for unicast mode; 7) gski : a session key for multicast mode of the ith DR project; 8) Ci : an additional value to help generate ski ; 9) GCi : an additional value to help generate gski ; 10) Counti : a counter for ui to help generate Ci ; 11) GCounti : a counter for ui to help generate GCi ; 12) Data: data of the message; 13) EData: encrypted data of the message; 14) Mi : metered data of ui in the previous day, which is in binary mode with a fixed length; 15) CDate: the measure date of Mi ; 16) Signt : a signature of the encrypted data created in the sending end; 17) Signr : a signature of the encrypted data created in the receiving end; 18) projectj : the jth DR project; 19) requestin j: request information of joining in the jth DR project; 20) requestout j: request information of quitting the jth DR project; 21) response+: indicating that the distribution by MS succeeded; 22) response−: indicating that the distribution by MS failed; 23) Kgen(1b ): a secure b-bit key generation algorithm; 24) Random(b): a function to generate a b-bit random number; 25) Ek (Data): an encryption function based on symmetric cryptography algorithm using k as the encryption key; 26) DEk (EData): a decryption function based on symmetric cryptography algorithm using k as the decryption key; 27) k ⊕ c: an exclusive OR operation between k and c; 28) kc: a concatenation between k and c; 29) H(k): a hash function; 30) HMACk (c): a keyed-hash message authentication function using k as the key. B. Framework of the KMS To support all the three different transmission modes of the messages, the key management framework of an AMI system is constructed based on the key graph [20]. As shown in Fig. 3, the KMF can be defined as follows: KMF = (U, K, R)

Fig. 3. Key management framework based on key graph.

Fig. 4. Instance of the key management framework.

where U = {u1 , u2 , . . . , un }

a finite and nonempty set which denotes SXs in the AMI system;

K = {k0 , k1 , . . . , kn , gk1 , gk2 , . . . , gkm }

a finite and nonempty set of keys in which {k1 , k2 . . . , kn } denotes keys of SXs, {gk1 , gk2 , . . . , gkm } denotes group keys of DR projects, and k0 is the root key of the key graph; R a binary relation between U and K, Rk ⊂ U × K, called the user–key relation. User u knows key k if and only if (u, k) is in R. Moreover, a function is associated with the set, defined as userset(k) = {u|(u, k) ∈ R}. As an example, the KMF in Fig. 4 can be represented as follows: U = {u1 , u2 , u3 } K = {k0 , k1 , k2 , k3 } ∪ {gk1 , gk2 } R = {(u1 , k0 ), (u1 , k1 ), (u1 , gk1 ), (u2 , k0 ), (u2 , k2 ), (u1 , gk2 ), (u3 , k0 ), (u3 , k3 ), (u3 , gk1 ), (u3 , gk2 )} . For users participating in a DR project 1, the set of group members can be denoted as userset(gk1 ) = {u1 , u3 }.

4750


Fig. 5. Process of initialization.

In the KMF, the root key k0 is used for broadcast mode; the group keys {gk1 , gk2 , . . . , gkm } are used for multicast mode in different DR project groups; the keys {k1 , k2 , . . . , kn } are used for unicast mode between MS and each SX. These keys are foundations for key management; their generation, distribution, and refreshing mechanisms should be designed. Furthermore, the session keys are needed in the communication process for message authentication/verification and encryption/decryption. As a result, the mechanisms to generate, distribute, and refresh session keys should also be designed carefully considering the network traffic and computation ability of SXs. C. Initialization of the KMS In order to briefly introduce the KMS, u0 is used to denote the MS. The keys of KMF and the additional value for generating session keys are initially generated by u0 using specific key servers and then distributed to SXs. Fig. 5 shows the process of initialization, followed by detailed descriptions. Step 1) Initial key generation u0 ki = Kgen(1b ),

i = 0, 1, 2, . . . , n

gkj = Kgen(1b ),

j = 1, 2, . . . , m

Counti = Random(b),

i = 0, 1, 2, . . . , n

GCountj = Random(b),

j = 1, 2, . . . , m.

The initial b-bit keys for each SX and each DR project group are generated. Step 2) Initial keys and additional value distribution u0 → {u1 , u2 , . . . , un } : ki , gkj , Counti , GCountj , i = 0, 1, . . . , n;

j = 1, 2, . . . , m.

The user keys {k1 , k2 , . . . , kn } and related additional values {Count1 , Count2 , . . . , Countn } are distributed to {u1 , u2 , . . . , un }, respectively, through secure channels (e.g., distribute a smart card for each SX). The root key k0 and additional value Count0 are also distributed to {u1 , u2 , . . . , un }. The keys {gk1 , gk2 , . . . , gkn } and related additional values {GCount1 , GCount2 , . . . , GCountm } are distributed to SXs depending on the users’ choice of participation in DR projects.

Fig. 6. Process of unicast communication. (a) From MS to SX. (b) From SX to MS.

IV. K EY M ANAGEMENT FOR U NICAST C OMMUNICATION A. Key Management Process of the Unicast Communication According to the analysis of messages in AMI systems, the unicast transmission mode includes three types of messages: meter data, subscription or quit of DR projects, and remote load control. The messages can be bidirectional: from MS to SX or SX to MS. In the communication process, the confidentiality and integrity of the messages should be provided. For this purpose, the session key should be refreshed at every session. The details of the key management for unicast communication process can be divided into three steps (see Fig. 6). Step 1) Session key generation and usage at the sending end u0 (or ui ): S1.1 Ci = H(HMACki (Mi ⊕CDate)⊕Counti ) S1.2 ski = H(ki ⊕ Ci ) S1.3 EData = Eski (Data) S1.4 Signt = HMACski (EData) A session key should first be created. In S1.1 and S1.2, the session key ski is generated from the metering data Mi , the metering date CDATE, the value Counti , and the user key ki . With this session key, the information that is going to be transmitted is encrypted and signed in S1.3 and S1.4. Step 2) Transmission of the message u0 (ui ) → ui (u0 ) : (EDataSignt ). The encrypted data with the signature value are transmitted to the receiver. Step 3) Session key generation and usage at the receiving end ui (or u0 ): S3.1 Ci = H(HMACki (Mi ⊕CDate)⊕Counti ) S3.2 ski = H(ki ⊕ Ci ) S3.3 Signr = HMACski (EData) IF Signt = Signr S3.4 Data = DEki (EData) END


4751

TABLE II K EY R EFRESHING P OLICIES FOR U NICAST C OMMUNICATION

The receiver also can retrieve the materials needed to generate the session key. The session key ski is generated in S3.1 and S3.2. With this session key, the signature can be verified and the data can be decrypted.

Fig. 7. Process of broadcast communication.

messages. Detailed key management for broadcast communication contains three steps as follows (see Fig. 7).

B. Key Refreshing Policy The refreshing policies for keys and related variables are listed in Table II. To maintain key freshness, user key ki should be refreshed in a certain period, such as one day, one week, and so on. Using a HASH function as the key refreshing algorithm will not only avoid key distribution cost of network but also provide independence between the new keys and old keys. To ensure the information security, session keys ski should be refreshed before every session. If the session keys are refreshed in MS and then distributed to SXs, it may lead to a lot of network traffic cost due to the huge number of SXs. However, if they can be respectively refreshed in both MS and SX according to a given agreed strategy, this problem will be avoided. The most important of the agreed strategy is that some data used for key refreshing can be easily retrieved by each side. In our work, we find that the daily metering data of an electricity user can be retrieved by the SX and MS since the metering is a basic function in AMI systems. As a result, a novel session key refreshing policy is designed based on metering data. Refreshing of session key ski relies on the user key ki and additional value Ci . The policy to get the additional value Ci is important for both of the communication ends. First, metering data Mi are easily obtained by both SMs and MDMS. Sometimes, metering data remain unchanged since nobody is at home. Therefore, the metering date CDate of Mi is used to provide freshness for the possibility of unchanged metering data. Second, there is still the possibility of Mi and CDate being guessed by the attackers. The function HMACki (Mi ⊕ CDate) is chosen to provide randomness since the user key ki is secret to attackers. Third, as there must be many messages in each day, Counti is used to keep the freshness by Counti + 1 at the beginning of every session. V. K EY M ANAGEMENT FOR B ROADCAST C OMMUNICATION A. Key Management Process of the Broadcast Communication Two types of messages are transmitted in broadcast mode, including publishing of DR projects and electrical pricing information. The session keys should be refreshed before every broadcast session to provide confidentiality and integrity of the

1) Session key generation and usage at the sending end. u0 : S1.1 C0 = H(Count0 ) S1.2 sk0 = H(k0 ⊕ C0 ) S1.3 EData = Esk0 (Data) S1.4 Signt = HMACsk0 (EData) A session key should first be created. In S1.1 and S1.2, the session key sk0 is generated from the value Count0 and the root key k0 . With this session key, the information that is going to be transmitted is encrypted and signed in S1.3 and S1.4. 2) Transmission of the message u0 → {u1 , u2 , . . . , un } : (EDataSignt ). The encrypted data with the signature value are broadcast to the entire receivers. 3) Session key generation and usage at the receiving end ui (i = 1, 2, . . . , n): S3.1 C0 = H(Count0 ) S3.2 sk0 = H(k0 ⊕ C0 ) S3.3 Signr = HMACsk0 (EData) IF Signt = Signr S3.4 Data = DEsk0 (EData) END The receivers generate the session key and then verify and decrypt the information. B. Key Refreshing Policy The key refreshing policy for broadcast communication, as is listed in Table III, is similar to that for unicast communication. To ensure key freshness, k0 should be refreshed periodically, such as one day or one month. Using a HASH function would provide a good performance of key independence between new keys and old keys. The session key sk0 for broadcast communication should be refreshed before every session. In addition, the randomness and independence of session keys would be well ensured by the adoption of a HASH function and the refreshing of k0 and C0 .

4752


TABLE III K EY R EFRESHING P OLICY FOR B ROADCAST C OMMUNICATION

Fig. 9. Key regeneration and refreshing when the new users subscribe or quit the DR project. (a) Users request to subscribe or quit the DR project. (b) Regenerate and distribute the new group key and additional value.

Fig. 8. Process of multicast communication.

VI. K EY M ANAGEMENT FOR M ULTICAST C OMMUNICATION A. Analysis of the Requirements In all types of AMI messages, electrical pricing information and remote load control may be transmitted in multicast mode. As the users who subscribe to a DR project are not fixed, the group members who will receive the multicast messages should be updated in a certain period (such as one day and one week) depending on the actual situation of electric power utilities. Therefore, the key management for multicast communication is separated into two parts. One is similar to the broadcast communication. The session key of multicast communication also should be generated before every new session. In another one, considering that the users may join or quit a DR project, the group key and additional value should be regenerated and refreshed with the support of unicast communication. B. Session Key Generation and Usage in a DR Project Group The session key generation and use in a DR project group are similar to that of broadcast communication. The main difference is the range of receivers. The process is shown in Fig. 8. Step 1) Session key generation and usage at the sending end. u0 : S1.1 GCj = H(GCountj ) S1.2 gskj = H(gkj ⊕ GCj ) S1.3 EData = Egskj (Data) S1.4 Signt = HMACgskj (EData)

A session key should first be created. In S1.1 and S1.2, the session key gskj is generated from the group key gkj and the value GCountj . With this session key, the information that is going to be transmitted is encrypted and signed in S1.3 and S1.4. Step 2) Transmission of the messages. u0 → {ui } : (EDataSignt ),

ui ∈ userset(gskj ).

The encrypted data with the signature value are multicast to the receivers of DR project j. Step 3) Session key generation and usage at the receiving ends. ui (ui ∈ userset(gskj )): S3.1 GCj = H(GCountj ) S3.2 gskj = H(skj ⊕ GCj ) S3.3 Signr = HMACgskj (EData) IF Signt = Signr S3.4 Data = DEgskj (EData) END The session key gskj is generated in S3.1 and S3.2. With this session key, the signature can be verified and the data can be decrypted. C. Key Regeneration and Refreshing When the Users Request to Join or Quit a DR Project When a user decides to join or quit a DR project, the user needs to request to u0 . After acknowledgement, the group key will be updated. The overall process is shown in Fig. 8. This subprocess is realized using unicast messages. The details include seven steps (see Fig. 9). Step 1) User requests to subscribe or quit DR project j. ui (i ∈ [1, n]):


S1.1 Ci = H(HMACki (Mi ⊕CDate)⊕Counti ) S1.2 ski = H(ki ⊕ Ci ) S1.3 EData = Eski (requestin j or requestout j) S1.4 Signt = HMACski (EData)

4753

TABLE IV K EY R EFRESHING P OLICY OF THE F IXED DR P ROJECT G ROUP

The request information is encrypted and signed. Step 2) Request message transmission ui → u0 : (EDataSignt ). The request message is transmitted to u0 . Step 3) Verify the user’s request. u0 : S3.1 Ci = H(HMACki (Mi ⊕CDate)⊕Counti ) S3.2 ski = H(ki ⊕ Ci ) S3.3 Signr = HMACski (EData) IF Signt = Signr S3.4 requestin j or requestout j = DEski (EData) END After receiving the request from user ui , u0 should decrypt and verify the request first and then check the request whether it is to subscribe or quit project j. Sometimes, the DR projects are not compatible; the user subscribing to a new project means quitting the current project. Step 4) Response to the user’s request. u0 : S4.1 Ci = H(HMACki (Mi ⊕CDate)⊕Counti ) S4.2 ski = H(ki ⊕ Ci ) IF the verification of Step3 succeeds S4.5 EData = Eski (response+), OTHERWISE S4.6 EData = Eski (response−) END IF S4.7 Signt = HMACski (EData)u0 should inform the user that the request is success or not. Step 5) Response message transmission

If some users join or quit the DR project, the group key and additional value should be regenerated before the update time. Step 8) Prepare to distribute the new group key and additional value to all the members of DR project j. u0 : S8.1 Ci = H(HMACki (Mi ⊕CDate)⊕Counti ) S8.2 ski = H(ki ⊕ Ci ) S8.3 EData = Eski (GCountj , gkj ) S8.4 Signt = HMACski (EData) Step 9) Distribution of the new group key and additional value to all the members of DR project j u0 → {ui } : (EDataSignt ),

ui ∈ userset(gskj ).

Step 10) Session key generation and usage at the receiving ends. ui (ui ∈ userset(gskj )): S10.1 Ci = H(HMACki (Mi ⊕CDate)⊕Counti ) S10.2 ski = H(ki ⊕ Ci ) S10.3 Signr = HMACski (EData) IF Signt = Signr S10.4 GCountj , gkj = DEski (EData) END

u0 → ui : (EDataSignt ). The response message is transmitted to ui . Step 6) The user verifies the response. ui : S6.1 Ci = H(HMACki (Mi ⊕CDate)⊕Counti ) S6.2 ski = H(ki ⊕ Ci ) S6.3 Signr = HMACski (EData) IF Signt = Signr THEN DO S6.4 Data = DEski (EData) END The user receives and checks whether the request to the DR project is successful or not. Step 7) Generate the new group key and additional value. u0: S7.1 GCountj = Random(b) S7.2 gkj = Kgen(1b )

D. Key Refreshing Policy According to the aforementioned key management process, the key refreshing policy also can be introduced separately by whether users of the DR project change or not. 1) The users in a DR project do not change. The refreshing of gkj , GCountj GCj , gskj is similar to that of broadcast communication. The details are listed in Table IV.

2) Users join or quit a DR project. When users subscribe or quit the DR project, gkj and GCountj should be regenerated by u0 and then distributed to all the users participating in the project. The details are listed in Table V.

4754


TABLE V K EY R EFRESHING P OLICY W HEN N EW U SERS A RE A DDED IN THE DR P ROJECT G ROUP

TABLE VI K EYS AND R ELATED DATA S TORED IN THE MS AND SXs

VII. S ECURITY A NALYSIS A. Key Generation A user key and a group key are both generated by using a b-bit secure random key generation function. A session key is created based on a user key or group key and mixed with additional value using a HASH function. The user key is secure. The additional value, which is created using a random number through a HASH function, is random and independent. Therefore, the session key will also be secure. B. Key Freshness In the KMS, the user key can be autorefreshed in a certain period. Refreshing of group keys depends on whether there are users joining or quitting the DR project. If there is any user who wants to join or quit the DR project, the group key should be refreshed at the update time. On refreshing methods, both of the user and session keys use HASH functions. The difference is that the session key also uses a random additional value or metering data with metering date to refresh it. As a result, the new keys are independent of old keys. C. Authentication and Integrity Session keys are held only by the two communication ends. The receiver will verify the signature of encrypted data first, with a secure session key. Only if it passes the authentication, the receiver would decrypt the message. Otherwise, the message will be discarded. The authentication and integrity of information transmission can then be ensured. D. Forward and Backward Security As the users can choose to join or quit the group of the DR project, the forward and backward security of the group should be considered. In our scheme, if there are any users who choose to join or quit the group, all the group keys and additional values will be regenerated and refreshed and then distributed to the members of the new group. VIII. P ERFORMANCE A NALYSIS A. Storage Cost For application of the KMS, related data should be stored, including various keys, counters, and additional values. The data which should be stored in MS and SXs are summarized in Table VI. Based on Table VI, the calculation methods of the storage cost of the communication ends are listed in Table VII.

TABLE VII C ALCULATION M ETHODS OF S TORAGE C OST

TABLE VIII S TORAGE C OST ACCORDING TO N UMBER OF DR P ROJECTS AND SXs

In actual applications, the key used in symmetric cryptography algorithms usually has a length of 128 or 256 b (such as AES and IDEA). In this paper, we choose a 128-b-long key, with the same length of a counter and an additional value. For MS, special key management servers can be used as storage for keys and the related data. The storage cost is not a problem. In contrast, the storage ability of SXs is limited. Therefore, the maximal possible storage cost of each SX according to SX number and DR project numbers should be evaluated. Based on Table VII, the results are listed in Table VIII. From the result, we can find that the storage cost in each SX will not increase with the number of SXs in the AMI system. The storage cost in each SX is only increased with the number of DR projects. In a normal situation, we assume that the number of DR projects is not more than 15, and the related maximum storage cost of each SX is 1.088 KB. This result is acceptable.


TABLE IX C ALCULATION M ETHODS OF C OMPUTATION C OST

4755

TABLE XI T IME C OST OF C OMPUTATION IN MS (U NICAST AND B ROADCAST M ODES )

TABLE XII T IME C OST OF C OMPUTATION IN MS (M ULTICAST M ODE )

TABLE X T IME C OST OF C OMPUTATION IN E ACH SX

TABLE XIII T IME C OST OF D ISTRIBUTION

B. Time Cost of Computation As the transmission of messages is time limited, the time cost of the maximum computation tasks at a certain time needs to be analyzed. According to the processes of the key management, the calculation method of computation cost in all the three transmission modes is listed in Table IX: CR : time cost of a random-number generation; CKgen : time cost of b-bit key generation algorithm; CH : time cost of executing a HASH operation; CHMAC : time cost of executing an HMAC operation; CXOR : time cost of an exclusive OR operation; NP : the number of DR projects which have users joining or quitting (NP ≤ m); 7) NG : the total number of users in the DR projects which have users joining or quitting (NG ≤ n).

1) 2) 3) 4) 5) 6)

1) Time Cost of Computation in Each SX: The SX is always implemented by embedded systems. Embedded cipher chips are used for cryptography computation. The operation rate for symmetric cryptography algorithms, hash functions, and HMAC is about 10–50 Mb/s. The rate of a XOR operation is too small to be taken into consideration. The time cost of computation in each SX can then be calculated. The results are listed in Table X. From the results, the time cost of computation in each SX is very small for SXs which will not affect the transmission of different messages. 2) Time Cost of Computation in MS: The PCI cryptographic coprocessor can be used to do the computation in MS. The operation rate for symmetric cryptography algorithms, hash functions, and HMAC is about 50 Mb/s–1 Gb/s, and the rate of random-number generation is about 1 Gb/s. The rate of a XOR operation can be ignored. The time cost of computation in unicast and broadcast modes is calculated and listed in Table XI. From the results, we can find that the time cost is very small and almost has no effect on the transmission of different messages. The time cost in multicast mode should consider the value of NP and NG , and the results are calculated and listed in

Table XII. The time cost increases with the value of NG . However, even if NG is set to 10 000, the time cost will not affect the transmission of messages. C. Time Cost of Distribution According to the analysis of the key management process, the time cost of distribution in a refreshing time is NG × CT , where CT is the distribution time cost of a package including the key and the related data. The package size of key and related data distribution is usually no more than 384 b. According to the actual situation of AMI systems, the communication rate in the MS is not less than 155 Mb/s (the SDH network based on optical fibers is always used as the main communication channel between users and MS; the transmission rate is 155 Mb/s, 622 Mb/s, and more), and then, the distribution cost can be calculated in Table XIII. From the result, we can find that the time cost of distribution will not affect the refreshing of keys and the distribution of the network traffic in AMI systems. IX. C ONCLUSION To solve the key management problems of AMI systems, a novel KMS has been proposed. From the security and performance analysis, the conclusion includes the following: 1) The design of KMS is closely integrated with the three different transmission modes, which supports the unicast, broadcast, and multicast modes; 2) the storage and computation of keys and related data are not a difficult task to be implemented in SMs or UGs; 3) the distribution of the keys and related data will not affect the normal network traffic in an AMI system; and 4) the KMS can deal with normal security problems; the forward and backward security can also be ensured.

4756


R EFERENCES [1] H. Sui, H. Wang, M.-S. Lu, and W.-J. Lee, “An AMI system for the deregulated electricity markets,” IEEE Trans. Ind. Appl., vol. 45, no. 6, pp. 2104–2108, Nov./Dec. 2009. [2] V. C. Güngör, D. Sahin, T. Kocak, S. Ergüt, C. Buccella, C. Cecati, and G. P. Hancke, “Smart grid technologies: Communication technologies and standards,” IEEE Trans Ind. Informat., vol. 7, no. 4, pp. 529–539, Nov. 2011. [3] G. Zhabelova and V. Vyatkin, “Multiagent smart grid automation architecture based on IEC 61850/61499 intelligent logical nodes,” IEEE Trans. Ind. Electron., vol. 59, no. 5, pp. 2351–2362, May 2012. [4] A. Hahn and M. Govindarasu, “Cyber attack exposure evaluation framework for the smart grid,” IEEE Trans. Smart Grid, vol. 2, no. 4, pp. 835– 843, Dec. 2011. [5] G. N. Ericsson, “Cyber security and power system communication— Essential parts of a smart grid infrastructure,” IEEE Trans. Power Del., vol. 25, no. 3, pp. 1501–1507, Jul. 2010. [6] F. M. Cleveland, “Cyber security issues for advanced metering infrastructure (AMI),” in Proc. IEEE Power Energy Soc. Gen. Meeting—Convers. Del. Elect. Energy 21st Century, Pittsburgh, PA, Jul. 2008, pp. 1–5. [7] Y. Ye, Q. Yi, and S. Hamid, “A secure and reliable in-network collaborative communication scheme for advanced metering infrastructure in smart grid,” in Proc. IEEE WCNC, Cancun, Mexico, Mar. 28–31, 2011, pp. 909–914. [8] J. Wang and V. C. M. Leung, “A survey of technical requirements and consumer application standards for IP-based smart grid AMI network,” in Proc. ICOIN, Barcelona, Spain, Jan. 26–28, 2011, pp. 114–119. [9] J. Kim, S. Ahn, and Y. Kim, “Sensor network-based AMI network security,” in Proc. IEEE PES Transmiss. Distrib. Conf. Expo.: Smart Solutions Changing World, New Orleans, LA, Apr. 19–22, 2010, pp. 1–5. [10] Z. M. Fadlullah, M. M. Fouda, N. Kato, A. Takeuchi, N. Iwasaki, and Y. Nozaki, “Toward intelligent machine-to-machine communications in smart grid,” IEEE Commun. Mag., vol. 49, no. 4, pp. 60–65, Apr. 2011. [11] T. Sauter and M. Lobashov, “End-to-end communication architecture for smart grids,” IEEE Trans. Ind. Electron., vol. 58, no. 4, pp. 1218–1228, Apr. 2011. [12] R. Shein, “Security measures for advanced metering infrastructure components,” in Proc. APPEEC, Chengdu, China, Mar. 28–31, 2010, pp. 1–3. [13] D. Robert, B. Colin, D. Ed, and M. G. N. Juan, “SKMA—A key management architecture for SCADA systems,” in Proc. 4th Austral. Inf. Security Workshop, 2006, vol. 54, pp. 183–192. [14] D. Choi, H. Kim, D. Won, and S. Kim, “Advanced key-management architecture for secure SCADA communications,” IEEE Trans. Power Del., vol. 24, no. 3, pp. 1154–1163, Jul. 2009. [15] N. Liu, J. Zhang, and W. Liu, “Toward key management for communications of wide area primary and backup protection,” IEEE Trans. Power Del., vol. 25, no. 3, pp. 2030–2032, Jul. 2010. [16] H. Sæle and O. S. Grande, “Demand response from household customers: Experiences from a pilot study in Norway,” IEEE Trans. Smart Grid, vol. 2, no. 1, pp. 102–109, Mar. 2011. [17] F. Benzi, N. Anglani, E. Bassi, and L. Frosini, “Electricity smart meters interfacing the households,” IEEE Trans. Ind. Electron., vol. 58, no. 10, pp. 4487–4494, Oct. 2011. [18] D.-M. Han and J.-H. Lim, “Smart home energy management system using IEEE 802.15.4 and ZigBee,” IEEE Trans. Consum. Electron., vol. 56, no. 3, pp. 1403–1410, Aug. 2010. [19] H. Gharavi and B. Hu, “Multigate communication network for smart grid,” Proc. IEEE, vol. 99, no. 6, pp. 1028–1045, Jun. 2011. [20] C. K. Wong, M. Gouda, and S. Lam, “Secure group communication using key graphs,” IEEE/ACM Trans. Netw., vol. 8, no. 1, pp. 16–30, Feb. 2000.

Nian Liu (S’06–M’11) received the B.S. and M.S. degrees in electric engineering from Xiangtan University, Xiangtan, China, in 2003 and 2006, respectively, and the Ph.D. degree in electrical engineering from North China Electric Power University, Beijing, China, in 2009. He is currently a Lecturer with the School of Electrical and Electronic Engineering, North China Electric Power University. His research interests include smart grid, cyber security, and power system optimization.

Jinshan Chen received the B.S. and M.S. degrees in the major of communication engineering and communication and information system from North China Electric Power University, Beijing, China, in 2009 and 2012, respectively. He is currently with the Power Grid Technology Center, Electric Power Research Institute of Fujian Electric Power Company Ltd., Fuzhou, China. His research interests are communication technology and cyber security of electric power system.

Lin Zhu received the B.S. degree from Beijing Language and Culture University, Beijing, China, in 2007. She is currently working toward the M.S. degree at Tianjin Normal University, Tianjin, China. Her research interests are demand side management and energy saving.

Jianhua Zhang (M’04) was born in Beijing, China, in 1952. He received the M.S. degree in electrical engineering from North China Electric Power University, Beijing, in 1984. He was a Visiting Scholar with Queen’s University Belfast, Belfast, U.K., from 1991 to 1992 and was a Multimedia Engineer of electric power training with CORYS T.E.S.S., France, from 1997 to 1998. He is currently a Professor and Head of the Transmission and Distribution Research Institute, North China Electric Power University. He is also the Consultant Expert of National “973” Planning of the Ministry of Science and Technology. His research interests are in power system security assessment, operation and planning, and microgrid. Prof. Zhang is a Fellow of the Institution of Engineering and Technology, U.K., and a member of several technical committees.

Yanling He received the B.S. and M.S. degrees in the major of materials science and engineering from Shandong University, Jinan, China, in 2009 and 2012, respectively. She is currently with Fujian Shuikou Hydropower Generation Company, Ltd., Fuzhou, China.