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
AbstractAdvanced metering infrastructure (AMI) is an im-
portant component of the smart grid. The cyber security should
be considered prior to the AMI system applications. To ensure
condentiality 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 specic features of AMI that
should be carefully considered, including hybrid transmission
modes of messages, storage and computation constraints of SMs,
and unxed 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. Specic key refreshing policies
are designed since the participators in a certain DR project are
not xed. 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 TermsAdvanced metering infrastructure (AMI), key
management scheme (KMS), smart grid, transmission mode.
I. INTRODUCTION
A
S A NEW emerging technology for smart grid, advanced
metering infrastructure (AMI) [1] is the system and net-
work used to measure, collect, store, analyze, and use energy
usage data, which provides a convenient bridge between con-
sumers and electric power utilities. In order to provide the
broadest possible platform for delivering a wide range of appli-
cations 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 Scientic 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: nian_liu@163.com; jhzhang001@163.com).
J. Chen is with the Electric Power Research Institute of Fujian Electric Power
Company Ltd., Fuzhou 350007, China (e-mail: 333a3@163.com).
L. Zhu is with the College of Politics and Public Administration, Tianjin
Normal University, Tianjin 300384, China (e-mail: linzhu16@126.com).
Y. He is with Fujian Shuikou Hydropower Generation Company, Ltd.,
Fuzhou 350800, China (e-mail: heyanling86@126.com).
Digital Object Identier 10.1109/TIE.2012.2216237
In general, the cyber security requirements of AMI include
condentiality, integrality, and availability [6]. Before AMI
can be deployed, the condentiality 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 conden-
tiality and integrality can be solved by encryption and authenti-
cation 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 condentiality and authentication
for secure AMI communications is proposed in [7], which can
provide trust services, data privacy, and integrity by mutual au-
thentications. 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
condentiality, 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 cryp-
tography 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 specic 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 difculties 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 nd that the
proposed KMSs are mostly for a specic 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 4747
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 con-
sideration 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 xed. 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 xed, but we can
design a KMS for the collection of possible functions. In actual
condition, the users can choose part of the KMS for specic
applications. The communications are not xed either, but the
features of messages transmitted in the communication chan-
nels 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. Con-
sidering time requirements of functions, computation, and stor-
age limitations of SMs, specic 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 difculties
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 IVVI present
the key management processes for unicast, broadcast, and mul-
ticast 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 SYSTEM FEATURES AND DIFFICULTIES
FOR A KMS DESIGN
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) SMs;
2) user gateways (UGs);
3) home (local) area networks (HANs);
4) wide-area communications infrastructure;
5) meter data management systems (MDMSs).
Fig. 1. AMI system structure.
1) SMs: Generally, SMs are solid-state programmable de-
vices 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, volt-
age, current, frequency, power factor, etc.), time-based pricing,
consumption data for consumer and utility, net metering, loss or
restoration of power notication, 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
efciency since information feedback has been shown to reduce
consumers usage [17].
2) UGs: The UG, which is always performed in other de-
vices 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 wide-
area communication infrastructure supports continuous inter-
action between the utility, the consumer, and the controllable
electrical load. It must employ open bidirectional communica-
tion 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 ber, 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 notication, publishing of DR projects, subscription
or quit of DR projects, electrical pricing information, and
remote load control.
4748 IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS, VOL. 60, NO. 10, OCTOBER 2013
TABLE I
FEATURES OF AMI MESSAGES
The sender and receiver of these messages can be classied
into two parts. One part is the devices in the user level, in-
cluding 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.,
fromMS 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 xed. 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
xed 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 xed, such as
0:00 of every day or Monday, 0:00, of every week.
C. Difculties and Possible Solutions
A KMS is always composed of a key management frame-
work, 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 difculties of designing the KMS
can be concluded as follows.
1) Hybrid transmission modes are used in the bidirectional
communications, including unicast, broadcast, and mul-
ticast. The KMS should support all these transmission
modes.
To deal with this problem, the key management frame-
work should be exible 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 sys-
tems. 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. Fur-
thermore, as the transmission time of messages is limited,
the number of times of key distribution should be mini-
mized. 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 xed. 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 xed
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.
LIU et al.: KEY MANAGEMENT SCHEME FOR SECURE COMMUNICATIONS OF AMI IN SMART GRID 4749
III. BASIC NOTATIONS AND KEY
MANAGEMENT FRAMEWORK
A. Basic Notations and Denitions
Notations and their denitions 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) u
i
: the ith user in the AMI. u
0
denotes MS; others denote
SXs;
4) k
i
: a user key for u
i
;
5) gk
i
: a group key for the ith DR project;
6) sk
i
: a session key for message transmissions. i = 0 for
broadcast mode; others for unicast mode;
7) gsk
i
: a session key for multicast mode of the ith DR
project;
8) C
i
: an additional value to help generate sk
i
;
9) GC
i
: an additional value to help generate gsk
i
;
10) Count
i
: a counter for u
i
to help generate C
i
;
11) GCount
i
: a counter for u
i
to help generate GC
i
;
12) Data: data of the message;
13) EData: encrypted data of the message;
14) M
i
: metered data of u
i
in the previous day, which is in
binary mode with a xed length;
15) CDate: the measure date of M
i
;
16) Sign
t
: a signature of the encrypted data created in the
sending end;
17) Sign
r
: a signature of the encrypted data created in the
receiving end;
18) project
j
: the jth DR project;
19) request
in
j: request information of joining in the jth DR
project;
20) request
out
j: request information of quitting the jth DR
project;
21) response+: indicating that the distribution by MS suc-
ceeded;
22) response: indicating that the distribution by MS failed;
23) Kgen(1
b
): a secure b-bit key generation algorithm;
24) Random(b): a function to generate a b-bit random num-
ber;
25) E
k
(Data): an encryption function based on symmetric
cryptography algorithm using k as the encryption key;
26) DE
k
(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) HMAC
k
(c): a keyed-hash message authentication func-
tion 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 dened 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 = {u
1
, u
2
, . . . , u
n
} a nite and nonempty set which de-
notes SXs in the AMI system;
K = {k
0
, k
1
, . . . , k
n
,
gk
1
, gk
2
, . . . , gk
m
} a nite and nonempty set of keys in
which {k
1
, k
2
. . . , k
n
} denotes keys
of SXs, {gk
1
, gk
2
, . . . , gk
m
} denotes
group keys of DR projects, and k
0
is
the root key of the key graph;
R a binary relation between U and K,
R
k
U K, called the userkey re-
lation. User u knows key k if and only
if (u, k) is in R.
Moreover, a function is associated with the set, dened as
userset(k) = {u|(u, k) R}.
As an example, the KMF in Fig. 4 can be represented as
follows:
U ={u
1
, u
2
, u
3
}
K ={k
0
, k
1
, k
2
, k
3
} {gk
1
, gk
2
}
R = {(u
1
, k
0
), (u
1
, k
1
), (u
1
, gk
1
),
(u
2
, k
0
), (u
2
, k
2
), (u
1
, gk
2
),
(u
3
, k
0
), (u
3
, k
3
), (u
3
, gk
1
), (u
3
, gk
2
)} .
For users participating in a DR project 1, the set of group
members can be denoted as userset(gk
1
) = {u
1
, u
3
}.
4750 IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS, VOL. 60, NO. 10, OCTOBER 2013
Fig. 5. Process of initialization.
In the KMF, the root key k
0
is used for broadcast mode; the
group keys {gk
1
, gk
2
, . . . , gk
m
} are used for multicast mode in
different DR project groups; the keys {k
1
, k
2
, . . . , k
n
} are used
for unicast mode between MS and each SX.
These keys are foundations for key management; their gen-
eration, distribution, and refreshing mechanisms should be
designed. Furthermore, the session keys are needed in the com-
munication process for message authentication/verication and
encryption/decryption. As a result, the mechanisms to generate,
distribute, and refresh session keys should also be designed
carefully considering the network trafc and computation abil-
ity of SXs.
C. Initialization of the KMS
In order to briey introduce the KMS, u
0
is used to denote
the MS. The keys of KMF and the additional value for generat-
ing session keys are initially generated by u
0
using specic key
servers and then distributed to SXs. Fig. 5 shows the process of
initialization, followed by detailed descriptions.
Step 1) Initial key generation u
0
k
i
=Kgen(1
b
), i = 0, 1, 2, . . . , n
gk
j
=Kgen(1
b
), j = 1, 2, . . . , m
Count
i
=Random(b), i = 0, 1, 2, . . . , n
GCount
j
=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
u
0
{u
1
, u
2
, . . . , u
n
} : k
i
, gk
j
, Count
i
, GCount
j
,
i =0, 1, . . . , n; j = 1, 2, . . . , m.
The user keys {k
1
, k
2
, . . . , k
n
} and related
additional values {Count
1
, Count
2
, . . . , Count
n
}
are distributed to {u
1
, u
2
, . . . , u
n
}, respectively,
through secure channels (e.g., distribute a smart card
for each SX). The root key k
0
and additional value
Count
0
are also distributed to {u
1
, u
2
, . . . , u
n
}.
The keys {gk
1
, gk
2
, . . . , gk
n
} and related additional values
{GCount
1
, GCount
2
, . . . , GCount
m
} 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. KEY MANAGEMENT FOR UNICAST COMMUNICATION
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 condentiality
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
u
0
(or u
i
):
S1.1 C
i
=H(HMAC
k
i
(M
i
CDate)Count
i
)
S1.2 sk
i
= H(k
i
C
i
)
S1.3 EData = E
sk
i
(Data)
S1.4 Sign
t
= HMAC
sk
i
(EData)
A session key should rst be created. In S1.1
and S1.2, the session key sk
i
is generated from the
metering data M
i
, the metering date CDATE, the
value Count
i
, and the user key k
i
. 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
u
0
(u
i
) u
i
(u
0
) : (EDataSign
t
).
The encrypted data with the signature value are
transmitted to the receiver.
Step 3) Session key generation and usage at the receiving
end u
i
(or u
0
):
S3.1 C
i
=H(HMAC
k
i
(M
i
CDate)Count
i
)
S3.2 sk
i
= H(k
i
C
i
)
S3.3 Sign
r
= HMAC
sk
i
(EData)
IF Sign
t
= Sign
r
S3.4 Data = DE
k
i
(EData)
END
LIU et al.: KEY MANAGEMENT SCHEME FOR SECURE COMMUNICATIONS OF AMI IN SMART GRID 4751
TABLE II
KEY REFRESHING POLICIES FOR UNICAST COMMUNICATION
The receiver also can retrieve the materials needed to gener-
ate the session key. The session key sk
i
is generated in S3.1 and
S3.2. With this session key, the signature can be veried and the
data can be decrypted.
B. Key Refreshing Policy
The refreshing policies for keys and related variables are
listed in Table II.
To maintain key freshness, user key k
i
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 sk
i
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 trafc 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 nd 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 sk
i
relies on the user key k
i
and
additional value C
i
. The policy to get the additional value
C
i
is important for both of the communication ends. First,
metering data M
i
are easily obtained by both SMs and MDMS.
Sometimes, metering data remain unchanged since nobody is
at home. Therefore, the metering date CDate of M
i
is used
to provide freshness for the possibility of unchanged metering
data. Second, there is still the possibility of M
i
and CDate
being guessed by the attackers. The function HMAC
k
i
(M
i

CDate) is chosen to provide randomness since the user key k
i
is secret to attackers. Third, as there must be many messages in
each day, Count
i
is used to keep the freshness by Count
i
+ 1
at the beginning of every session.
V. KEY MANAGEMENT FOR BROADCAST COMMUNICATION
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 in-
formation. The session keys should be refreshed before every
broadcast session to provide condentiality and integrity of the
Fig. 7. Process of broadcast communication.
messages. Detailed key management for broadcast communica-
tion contains three steps as follows (see Fig. 7).
1) Session key generation and usage at the sending end. u
0
:
S1.1 C
0
= H(Count
0
)
S1.2 sk
0
= H(k
0
C
0
)
S1.3 EData = E
sk
0
(Data)
S1.4 Sign
t
= HMAC
sk
0
(EData)
A session key should rst be created. In S1.1 and S1.2,
the session key sk
0
is generated from the value Count
0
and the root key k
0
. 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
u
0
{u
1
, u
2
, . . . , u
n
} : (EDataSign
t
).
The encrypted data with the signature value are broad-
cast to the entire receivers.
3) Session key generation and usage at the receiving end
u
i
(i = 1, 2, . . . , n):
S3.1 C
0
= H(Count
0
)
S3.2 sk
0
= H(k
0
C
0
)
S3.3 Sign
r
= HMAC
sk
0
(EData)
IF Sign
t
= Sign
r
S3.4 Data = DE
sk
0
(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, k
0
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 sk
0
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 k
0
and C
0
.
4752 IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS, VOL. 60, NO. 10, OCTOBER 2013
TABLE III
KEY REFRESHING POLICY FOR BROADCAST COMMUNICATION
Fig. 8. Process of multicast communication.
VI. KEY MANAGEMENT FOR MULTICAST COMMUNICATION
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 xed, 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. u
0
:
S1.1 GC
j
= H(GCount
j
)
S1.2 gsk
j
= H(gk
j
GC
j
)
S1.3 EData = E
gsk
j
(Data)
S1.4 Sign
t
= HMAC
gsk
j
(EData)
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.
A session key should rst be created. In S1.1
and S1.2, the session key gsk
j
is generated from
the group key gk
j
and the value GCount
j
. 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.
u
0
{u
i
} : (EDataSign
t
), u
i
userset(gsk
j
).
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. u
i
(u
i
userset(gsk
j
)):
S3.1 GC
j
= H(GCount
j
)
S3.2 gsk
j
= H(sk
j
GC
j
)
S3.3 Sign
r
= HMAC
gsk
j
(EData)
IF Sign
t
= Sign
r
S3.4 Data = DE
gsk
j
(EData)
END
The session key gsk
j
is generated in S3.1 and S3.2. With this
session key, the signature can be veried 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 u
0
. 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.
u
i
(i [1, n]):
LIU et al.: KEY MANAGEMENT SCHEME FOR SECURE COMMUNICATIONS OF AMI IN SMART GRID 4753
S1.1 C
i
=H(HMAC
k
i
(M
i
CDate)Count
i
)
S1.2 sk
i
= H(k
i
C
i
)
S1.3 EData = E
sk
i
(request
in
j or request
out
j)
S1.4 Sign
t
= HMAC
sk
i
(EData)
The request information is encrypted and signed.
Step 2) Request message transmission
u
i
u
0
: (EDataSign
t
).
The request message is transmitted to u
0
.
Step 3) Verify the users request. u
0
:
S3.1 C
i
=H(HMAC
k
i
(M
i
CDate)Count
i
)
S3.2 sk
i
= H(k
i
C
i
)
S3.3 Sign
r
= HMAC
sk
i
(EData)
IF Sign
t
= Sign
r
S3.4 request
in
j or request
out
j =DE
sk
i
(EData)
END
After receiving the request from user u
i
, u
0
should decrypt and verify the request rst and then
check the request whether it is to subscribe or quit
project j. Sometimes, the DR projects are not com-
patible; the user subscribing to a new project means
quitting the current project.
Step 4) Response to the users request. u
0
:
S4.1 C
i
=H(HMAC
k
i
(M
i
CDate)Count
i
)
S4.2 sk
i
= H(k
i
C
i
)
IF the verication of Step3 succeeds
S4.5 EData = E
sk
i
(response+),
OTHERWISE
S4.6 EData = E
sk
i
(response)
END IF
S4.7 Sign
t
= HMAC
sk
i
(EData)u
0
should in-
form the user that the request is success or not.
Step 5) Response message transmission
u
0
u
i
: (EDataSign
t
).
The response message is transmitted to u
i
.
Step 6) The user veries the response. u
i
:
S6.1 C
i
=H(HMAC
k
i
(M
i
CDate)Count
i
)
S6.2 sk
i
= H(k
i
C
i
)
S6.3 Sign
r
= HMAC
sk
i
(EData)
IF Sign
t
= Sign
r
THEN DO
S6.4 Data = DE
sk
i
(EData)
END
The user receives and checks whether the request
to the DR project is successful or not.
Step 7) Generate the newgroup key and additional value. u
0
:
S7.1 GCount

j
= Random(b)
S7.2 gk

j
= Kgen(1
b
)
TABLE IV
KEY REFRESHING POLICY OF THE FIXED DR PROJECT GROUP
If some users join or quit the DR project, the
group key and additional value should be regener-
ated before the update time.
Step 8) Prepare to distribute the new group key and addi-
tional value to all the members of DR project j. u
0
:
S8.1 C
i
=H(HMAC
k
i
(M
i
CDate)Count
i
)
S8.2 sk
i
= H(k
i
C
i
)
S8.3 EData = E
sk
i
(GCount

j
, gk

j
)
S8.4 Sign
t
= HMAC
sk
i
(EData)
Step 9) Distribution of the new group key and additional
value to all the members of DR project j
u
0
{u
i
} : (EDataSign
t
), u
i
userset(gsk
j
).
Step 10) Session key generation and usage at the receiving
ends. u
i
(u
i
userset(gsk
j
)):
S10.1 C
i
=H(HMAC
k
i
(M
i
CDate)Count
i
)
S10.2 sk
i
= H(k
i
C
i
)
S10.3 Sign
r
= HMAC
sk
i
(EData)
IF Sign
t
= Sign
r
S10.4 GCount

j
, gk

j
= DE
sk
i
(EData)
END
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 gk
j
, GCount
j
GC
j
, gsk
j
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, gk
j
and GCount
j
should be regenerated by u
0
and then
distributed to all the users participating in the project. The
details are listed in Table V.
4754 IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS, VOL. 60, NO. 10, OCTOBER 2013
TABLE V
KEY REFRESHING POLICY WHEN NEW USERS
ARE ADDED IN THE DR PROJECT GROUP
VII. SECURITY ANALYSIS
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 rst,
with a secure session key. Only if it passes the authentica-
tion, 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. PERFORMANCE ANALYSIS
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 VI
KEYS AND RELATED DATA STORED IN THE MS AND SXs
TABLE VII
CALCULATION METHODS OF STORAGE COST
TABLE VIII
STORAGE COST ACCORDING TO NUMBER OF DR PROJECTS AND SXs
In actual applications, the key used in symmetric cryptogra-
phy 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 stor-
age for keys and the related data. The storage cost is not a prob-
lem. 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 nd 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.
LIU et al.: KEY MANAGEMENT SCHEME FOR SECURE COMMUNICATIONS OF AMI IN SMART GRID 4755
TABLE IX
CALCULATION METHODS OF COMPUTATION COST
TABLE X
TIME COST OF COMPUTATION IN EACH SX
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:
1) C
R
: time cost of a random-number generation;
2) C
Kgen
: time cost of b-bit key generation algorithm;
3) C
H
: time cost of executing a HASH operation;
4) C
HMAC
: time cost of executing an HMAC operation;
5) C
XOR
: time cost of an exclusive OR operation;
6) N
P
: the number of DR projects which have users joining
or quitting (N
P
m);
7) N
G
: the total number of users in the DR projects which
have users joining or quitting (N
G
n).
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 1050 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 calcu-
lated. 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/s1 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
nd 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 N
P
and N
G
, and the results are calculated and listed in
TABLE XI
TIME COST OF COMPUTATION IN MS
(UNICAST AND BROADCAST MODES)
TABLE XII
TIME COST OF COMPUTATION IN MS (MULTICAST MODE)
TABLE XIII
TIME COST OF DISTRIBUTION
Table XII. The time cost increases with the value of N
G
.
However, even if N
G
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 N
G
C
T
,
where C
T
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 situ-
ation of AMI systems, the communication rate in the MS
is not less than 155 Mb/s (the SDH network based on
optical bers 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 nd that the time cost of distribution
will not affect the refreshing of keys and the distribution of the
network trafc in AMI systems.
IX. CONCLUSION
To solve the key management problems of AMI systems, a
novel KMS has been proposed. From the security and perfor-
mance 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 difcult task to be implemented in SMs
or UGs; 3) the distribution of the keys and related data will not
affect the normal network trafc in an AMI system; and 4) the
KMS can deal with normal security problems; the forward and
backward security can also be ensured.
4756 IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS, VOL. 60, NO. 10, OCTOBER 2013
REFERENCES
[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. 21042108, Nov./Dec. 2009.
[2] V. C. Gngr, D. Sahin, T. Kocak, S. Ergt, C. Buccella, C. Cecati, and
G. P. Hancke, Smart grid technologies: Communication technologies
and standards, IEEE Trans Ind. Informat., vol. 7, no. 4, pp. 529539,
Nov. 2011.
[3] G. Zhabelova and V. Vyatkin, Multiagent smart grid automa-
tion architecture based on IEC 61850/61499 intelligent logical
nodes, IEEE Trans. Ind. Electron., vol. 59, no. 5, pp. 23512362,
May 2012.
[4] A. Hahn and M. Govindarasu, Cyber attack exposure evaluation frame-
work 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. 15011507, Jul. 2010.
[6] F. M. Cleveland, Cyber security issues for advanced metering
infrastructure (AMI), in Proc. IEEE Power Energy Soc. Gen.
MeetingConvers. Del. Elect. Energy 21st Century, Pittsburgh, PA,
Jul. 2008, pp. 15.
[7] Y. Ye, Q. Yi, and S. Hamid, A secure and reliable in-network collab-
orative communication scheme for advanced metering infrastructure in
smart grid, in Proc. IEEE WCNC, Cancun, Mexico, Mar. 2831, 2011,
pp. 909914.
[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. 2628, 2011, pp. 114119.
[9] J. Kim, S. Ahn, and Y. Kim, Sensor network-based AMI network secu-
rity, in Proc. IEEE PES Transmiss. Distrib. Conf. Expo.: Smart Solutions
Changing World, New Orleans, LA, Apr. 1922, 2010, pp. 15.
[10] Z. M. Fadlullah, M. M. Fouda, N. Kato, A. Takeuchi, N. Iwasaki,
and Y. Nozaki, Toward intelligent machine-to-machine communica-
tions in smart grid, IEEE Commun. Mag., vol. 49, no. 4, pp. 6065,
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. 12181228,
Apr. 2011.
[12] R. Shein, Security measures for advanced metering infrastructure
components, in Proc. APPEEC, Chengdu, China, Mar. 2831, 2010,
pp. 13.
[13] D. Robert, B. Colin, D. Ed, and M. G. N. Juan, SKMAA key manage-
ment architecture for SCADA systems, in Proc. 4th Austral. Inf. Security
Workshop, 2006, vol. 54, pp. 183192.
[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. 11541163, Jul. 2009.
[15] N. Liu, J. Zhang, and W. Liu, Toward key management for communica-
tions of wide area primary and backup protection, IEEE Trans. Power
Del., vol. 25, no. 3, pp. 20302032, Jul. 2010.
[16] H. Sle 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. 102109, 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. 44874494, 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. 14031410, Aug. 2010.
[19] H. Gharavi and B. Hu, Multigate communication network for smart
grid, Proc. IEEE, vol. 99, no. 6, pp. 10281045, 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. 1630,
Feb. 2000.
Nian Liu (S06M11) received the B.S. and
M.S. degrees in electric engineering from Xiangtan
University, Xiangtan, China, in 2003 and 2006, re-
spectively, and the Ph.D. degree in electrical engi-
neering 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 in-
clude 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 manage-
ment and energy saving.
Jianhua Zhang (M04) was born in Beijing, China,
in 1952. He received the M.S. degree in electrical
engineering from North China Electric Power Uni-
versity, Beijing, in 1984.
He was a Visiting Scholar with Queens 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 Transmis-
sion 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.