DAS LAYOUT_Layout 1 7/23/12 3:12 PM Page 30

CYBER SECURITY FOR SMART GRID COMMUNICATIONS

A Key Management Framework for

AMI Networks in Smart Grid
Subir Das, Applied Communication Sciences
Yoshihiro Ohba and Mitsuru Kanda, Toshiba Corporate Research and Development
David Famolari, Day2 Ventures
Sajal K. Das, University of Texas at Arlington

ABSTRACT provider (ESP). The goal of the smart grid is to

create an intelligent and connected infrastructure
The environments in which current electric to maximize efficient use of energy resources
grids operate as well as the requirements for while providing significantly improved security,
the emerging smart grid differ substantially visibility, and operations and management capa-
from those of today’s Internet and telecommu- bility.
nication networks. For example, typical electric The Smart Grid Interoperability Project
or gas meters in the advanced metering infra- (SGIP) [1] together with several standard bodies
structure (AMI) are low-power, low-capability (e.g., IEEE, Internet Engineering Task Force
wireless devices utilizing personal area wireless [IETF]) and government organizations such as
network technology (e.g., IEEE 802.15.4). the National Institute of Standards and Technol-
These devices are low-cost, typically with 4–12 ogy (NIST) are working toward this goal by
kbytes of RAM and 64–256 kbytes of flash defining a number of relevant use cases and
memory, and are often connected to the back- developing a communications framework that
haul via low-bandwidth links. Comparing this to spans several different commercially available
the high-powered, high-capability devices of the technologies, and seeks to knit together both
Internet with gigabytes of RAM and storage, communication and energy networks. This com-
the differences are striking. Security solutions munication framework incorporates wide area
designed for capability-rich Internet devices will networks (WANs) to home area networks
not be suitable for the capability-poor devices (HANs), building area networks (BANs) to
of the smart grid; thus, new requirements are neighborhood area networks (NANs). Advanced
needed that can efficiently operate in resource metering infrastructure (AMI) is an example use
constrained devices. With this operating envi- case network where the end devices are either
ronment in mind, we present a smart grid key connected via the HAN or NAN, and then the
management framework with application to WAN is used to transmit energy usage informa-
AMI networks. Specifically, we describe how tion to the ESP. This system of systems, com-
this key management model can be realized in prising energy and communication networks,
such a resource-constrained environment using thus becomes an information super highway sim-
existing standard protocols and provide prelimi- ilar to today’s Internet where stakeholders in the
nary performance results. community can interact, monitor and manage
the system much more efficiently than what is
INTRODUCTION possible today.
While ESPs are excited with the capabilities
Efficient use and management of energy of communication and information technologies,
resources are becoming increasingly important in they are also concerned about the fact that there
today’s world. As a result, many nations are will be no physical boundary by which the com-
undertaking power grid modernization initiatives ponents of the power grid are connected. For
by adding state-of-the-art communication and example, unlike the traditional grid, advanced
information capabilities to the system. This so- metering systems may be connected to the ESP
called smart grid transformation is enabling new via the public Internet or via private wireless
capabilities into the existing power grid such as networks that are susceptible to attacks and vul-
monitoring, analysis, control, and two-way com- nerable to eavesdropping or spoofing, which can
munication capabilities. The goal is to save ener- eventually damage safety and reliability of the
gy, reduce cost, and increase reliability and grid. It is absolutely necessary to protect the net-
transparency. While many of these features and works and guarantee that information is safe and
capabilities exist today, they were in isolation secure.
and controlled by an individual electric service Although a vast array of security technologies

30 0163-6804/12/$25.00 © 2012 IEEE IEEE Communications Magazine • August 2012

DAS LAYOUT_Layout 1 7/23/12 3:12 PM Page 31

is currently available to address communication for an example field environment using the AMI
network security, the smart grid environment system. Finally, we conclude the article with GAA uses authenti-
requires unique security capabilities. For exam- future research directions.
cation and key
ple, an electric or gas meter in the advanced
metering system (a so-called smart meter) is a agreement (AKA) for
device with little processing power, and typically
RELATED WORK
mutual authentica-
only 4–12 kbytes of RAM and 64–256 kbytes of Key management has been an area of consider-
flash memory. These low-cost devices may also able attention, particularly in browser-based web tion. While this archi-
make use of personal area wireless network applications. Most notably, initiatives such as tecture allows the
technology such as Zigbee, and often are con- OAuth [2], OpenID [3], SAML [4], and others
cellular operators to
nected to the backhaul via low bandwidth links. have emerged to provide single sign-on (SSO)
The link characteristics can also vary depending capabilities. OAuth is a popular SSO enabler bootstrap other ser-
upon the activity state of the meter. For instance, and provides mechanisms for end users to autho- vices the client wants
smart meters may periodically wake up and sync rize third-party access to networked resources
with the network to save power rather than without requiring static credentials to be shared to use, it does not
always being active. Additional device require- with third parties. Another popular SSO tech- allow authentication
ments include: nology is OpenID, which has gained consider-
mechanisms other
• The support of multihop networks using able momentum with commercial web services.
mesh topology (e.g., to extend backhaul It is employed by several prominent web service than AKA
reach back) providers such as Google, Yahoo!, AOL, and credentials.
• The support of multiple link layer technolo- Facebook, among others. OpenID is an open,
gies decentralized access control mechanism that
Given the low-bandwidth nature of the commu- allows users to sign-on to several different ser-
nication links and the comparatively low capabil- vices with a single digital identity. It requires
ity of the smart meters themselves, these regular logon to the subscriber’s service provider
requirements demand that protocol overhead to access services provided by each service
and performance be optimized. provider. However, security concerns regarding
Advanced meters can also be used for other vulnerabilities associated with OpenID have
purposes besides simple metering data. Ameri- begun to surface. In [5], the authors address per-
can National Standards Institute (ANSI) C12.22 ceived limitations, such as symmetric cryptogra-
allows advanced meter peering via relay or con- phy, length of time the authentication status is
centrators. Other applications, such as Con- stored in relay providers and OpenID providers,
strained Application Protocol (CoAP), an and vulnerabilities to man-in-the-middle attacks.
emerging IETF standard , should be able to run Secure Assertion Markup Language (SAML)
simultaneously on a single meter. While these is yet another technique to provide authentica-
are very attractive features and make the tion and authorization data between secure
advanced meter economically more viable, they domains such as enterprise networks. SAML is
add additional challenges to security; for exam- defined in XML and uses federated identity
ple, each application needs to be authenticated management techniques to ease authentication
and also needs to preserve the integrity of sys- and authorization tasks across domains under
tem data (e.g., billing system). While some ven- the same federation. In [6], the authors identify
dors may provide end-to-end application several security flaws with respect to confiden-
encryption capabilities in a proprietary way, the tiality, bilateral authentication, integrity, and
adoption of this non-standard solution is very user tracking that could lead to potential vulner-
minimal. able implementations of SAML.
Therefore, in recent years, several efforts None of above mechanisms provides a fully
have started addressing the smart grid security unified key management framework that could
issues. Each of them identified that the smart enable multiple communication layers and pro-
grid introduces a different set of security require- tocols to work across layers without having dedi-
ments, thus necessitating new techniques and cated key management at each layer or protocol.
protocols for this environment. To meet these While other approaches exist, such as adding
emerging requirements, we propose a unified network access authentication within Kerberos
key management framework with two models by attempting to integrate with Extensible
appropriate for smart grid and then show how Authentication Protocol (EAP) [7], these tech-
the framework can be realized using existing niques require modified EAP methods in order
protocols. Our work is motivated by two guiding to interwork with Kerberos.
principles: A commonly used mechanism in cellular net-
• Avoid multilayer authentication works is called generic authentication architec-
• Adapt to a multilayer and multiprotocol ture (GAA), which is a Third Generation
environment Partnership Project (3GPP) solution for authen-
Our approach is a simple unified key manage- tication and key agreement between clients and
ment framework that addresses certain smart services. There are two ways by which GAA can
grid security requirements with direct applica- be used: i) based on a shared secret between the
tion to AMI networks. client and the server (a.k.a., Generic Bootstrap-
The rest of the article is organized as follows. ping Architecture (GBA)), and ii) based on pub-
We present related work, and describe our pro- lic-private key pair and digital certificates. GAA
posed models and framework. We show how uses Authentication and Key Agreement (AKA)
these models can be realized by using existing for mutual authentication. While this architec-
protocols and extensions. We provide a test plan ture allows the cellular operators to bootstrap
description with initial implementation results other services that the client wants to use, it

IEEE Communications Magazine • August 2012 31

DAS LAYOUT_Layout 1 7/23/12 3:12 PM Page 32

on either network access authentication or appli-

UKMF
cation-level authentication. For example, the ini-
tial peer entity authentication can be based on
application-level authentication if the access net-
Application-layer Protocol Protocol Protocol Protocol Protocol work where a device initially attaches is an open
access network.

BENEFIT OF THE PROPOSED FRAMEWORK

We provide a brief theoretical analysis to show
Link-layer Protocol Protocol Protocol Protocol Protocol
the benefit of our proposed approach in terms of
the code size and number of messages required
for authentication and key establishment on a
(a) given node.
Let n denote the number of target protocols
UKMF for which authentication and key establishment
are needed. Let m (≤ n) denote the number of
distinct key management protocols used by n
Application-layer Protocol Protocol Protocol Protocol Protocol target protocols. Let k (m ≤ k ≤ n) denote the
number of protocol bundles where a protocol
bundle is defined as a set of target protocols that
DKMF DKMF DKMF DKMF DKMF share the same UKMF or a distinct target proto-
col that uses DKMF. Let Pj denote the key man-
Link-layer Protocol Protocol Protocol Protocol Protocol agement protocol used for a protocol bundle j.
Let Ci denote the code size of key management
(b) protocol i (≤ m). Let CCrypto denote the code size
of the cryptographic module shared by all key
Figure 1. Conceptual model of unified key management: a) fully unified management protocols. Let C UKMF denote the
model; b) partially unified model. code size of UKMF. Let Ni denote the number
of messages required for key management proto-
col i to complete authentication and key estab-
does not allow authentication mechanisms other lishment.
than AKA credentials. The total code size C of the key management
protocols implemented on the node can be rep-
resented as
PROPOSED FRAMEWORK
C = (Σ i=1Ci) + CCrypto + ek<nCUKMF,
m
Our key management mechanism defines a uni-
fied key management function (UKMF) across where ek<n =1 if k < n and ek<n = 0 otherwise,
and Σ i=1Ci = Σ j=1CPj.
m k
multiple protocols within the same communica-
tion layer or across different communication lay-
ers. Figure 1 shows a conceptual model of the Assuming C UKMF << C i for all i, the total
proposed framework. Although it only refers to code size depends on m. Now if a fully unified
application-layer and link-layer protocols, this UKMF model is employed, m = 1, and there-
concept is generally applicable to any protocol fore the most reduced code size is expected. The
requiring a cryptographic operation at any com- benefit of DKMF is also obvious as long as m <
munication layer. Ideally, there should be only n.
one UKMF across all protocols with ciphering The total number of messages N for n proto-
mechanisms. This is referred to as the fully uni- cols comprising k protocol bundles to complete
fied model, as depicted in Fig. 1a. authentication and key establishment on the
node can also be represented as N = Σ j=1NPj. It
k
On the other hand, depending on deployment
requirements and other design constraints, some is clear from the expression that the total num-
protocols may use a dedicated key management ber of messages is minimized when a fully uni-
function (DKMF) while others may use a fied UKMF model is employed, where k = 1
UKMF. This model is referred to as the partially and N = NP1 = N1. It is important to note that
unified model. Figure 1b shows a typical instance the above equations for C and N are generally
of a partially unified model where only applica- applicable to any node with a fully unified
tion-layer protocols use a UKMF and link-layer UKMF model, with a partially unified UKMF
protocols use DKMF. In partially unified model, model, and with a DKMF-only model.
the mapping between a protocol and a UKMF
or DKMF can be arbitrary. In both fully and EAP-BASED UNIFIED KEY MANAGEMENT
partially unified models, a protocol that uses a Although the conceptual model described above
UKMF may also have a DKMF where the latter is general enough to apply to any key manage-
may be managed by the UKMF. For example, ment framework that supports bootstrap cipher-
some application protocols may be DKMF based ing of multiple protocols, in this article, we focus
on its own application-specific key management on the use of the EAP key management frame-
protocol, while the UKMF may generate a sym- work [8] because it is being used for existing
metric key to be used by the application-specific access technologies such as Ethernet, Wi-Fi, and
key management protocol to bind the UKMF WiMAX networks. EAP was originally designed
with the DKMF. as a network access authentication protocol for
In both models, the initial peer entity authen- Point-to-Point Protocol (PPP) and has been
tication between a pair of UKMFs can be based adopted by multiple data link layer protocols

32 IEEE Communications Magazine • August 2012

DAS LAYOUT_Layout 1 7/23/12 3:12 PM Page 33

including IEEE 802.3, IEEE 802.11, and IEEE

802.16 as well as IP and higher layer protocols, End host
such as Protocol for Carrying Authentication for
Network Access (PANA) [9] and Internet Key
Exchange version 2 (IKEv2) [10]. PANA is cur- UKMF
rently included in ZigBee Smart Energy Profile
2.0 [11]. An authentication algorithm supported
by EAP is called an EAP method. EAP supports EAP
Application 1 Application 2
a number of methods including symmetric and peer
asymmetric key based.
Figure 2 shows an example of EAP-based
unified key management architecture. In this fig- Application 2 Application 2
ure, two applications are managed by UKMF, function X function Y
and application 2 has two functions that use dif- EAP peer
ferent sets of key material. It is assumed that lower layer
communications between the UKMF and other
elements in the end host are realized through
local application programming interfaces (APIs),
whereas communications between the UKMF Network
(Each network element may be implemented on
and other elements in the network are realized physically separated devices.)
through either local APIs or protocols depend-
ing on whether communicating entities are
UKMF
implemented in the same device or not.
The main task of the UKMF in an EAP-based
unified key management is to receive EAP key-
ing material from an EAP peer or authentication EAP
Application 1 Application 2 authenticator/
server depending on whether it resides in an server
end-host or a network. The UKMF also derives
and distributes key material to its key consumers
(i.e., an element of application 1, an element of Application 2 Application 2
application 2 function X, an element of applica- function X function Y
tion 2 function Y, and EAP peer and authentica-
EAP authenticator
tor lower layers) and triggers EAP lower layer
re-authentication when a rekey of EAP keying
material is needed
The master session key (MSK) and extensible Figure 2. Example of EAP-based unified key management architecture.
MSK (EMSK) are the EAP keying material
exported to the EAP peer and authenticator
lower layers. Since MSKs are used to protect the its parent key instead of EMSK and a unique
EAP peer and authenticator lower layers, and label for the function within the application as
the endpoints of a protocol that uses an UKMF outlined in Fig. 2. Additional parameters such
may not be the same as those of EAP, we pro- as a key identifier and the identifier of the end
pose to use EMSKs for generating keys especial- host may be contained in the optional data for
ly for AMI applications such as ANSI C12.22 both USRK and its child keys. The lifetime of
and CoAP. any key derived from EAP keying material is
The EAP key management framework pro- bounded by the lifetime of the EAP keying
hibits EMSKs from being exported outside the material. A derived key may be cached in its
EAP server. To accommodate this constraint, key consumer as long as its lifetime remains
the UKMF in the network is expected to reside unexpired.
in the same node as the EAP server. The key It is important to note that some applications
hierarchy under EMSK is defined in [12] based may have multiple functions for which communi-
on a usage-specific root key (USRK) as follows: cations are carried out between different ele-
ments for different functions in the same
USRK = KDF(EMSK, key label | “\0” | application. For example, the ANSI C12.22
optional data | length). metering application defines both a registration
function, in which a chain of C12.22 relays are
In the EAP-based unified key management responsible for registering an end host, and a
mechanism, we use the USRK for bootstrapping resolve function, in which the first hop C12.22
the application-layer ciphering key. Cryptograph- relay from the end host is responsible for resolv-
ic independence among different application- ing the transport address of a communicating
layer ciphering keys derived from the same peer of the end host. For such an application, a
EMSK is guaranteed by: distinct key is generated for and distributed to
• Assigning a unique USRK label for each each network element involved in a specific
application and for an application that has function of the application and communicates
multiple functions with the end host as illustrated in Fig. 2.
• Defining a child key of the application-spe-
cific USRK for each function of the appli-
cation
DETAILED DESIGN
In this case, each child key is derived using This section describes a detailed design of the
the same USRK derivation algorithm, but using proposed key management mechanism.

IEEE Communications Magazine • August 2012 33

DAS LAYOUT_Layout 1 7/23/12 3:12 PM Page 34

KEY MANAGEMENT ALTERNATIVES between ANSI C12.22 hosts and ANSI 12.22
Rekeying EMSK will master relays where the host is a PaC and the
Many different link-layer technologies may be master relay is a PANA authentication agent
replace all keys used for connecting smart meters to the AMI (PAA).
derived from it. network including Ethernet, PLC, ZigBee, Wi- Both of the above architectural alternatives
Therefore, from an Fi, and third/fourth generation (3G/4G). There- may require an extension of EAP to support
fore, considerations are needed for how the application-level authentication to bootstrap
optimization point of EAP-based unified key management scheme can application-layer ciphering since the current
view, it is desirable work with multiple link-layer technologies that applicability of EAP is for network access
may manage link-layer-specific keys in different authentication. Such extensions of EAP applica-
to design a system ways. There are two alternative methods. bility are possible without necessarily requiring a
such that the fre- First architectural alternative: EAP is used modification of EAP itself. The next subsections
quency of EMSK for both network access authentication and boot- describe additional considerations needed to
strapping application-layer ciphering. In this extend EAP applicability to fit our unified key
rekeying can be case, EAP may be carried out either at the link- management mechanism.
reduced as much as layer using a link-layer specific EAP transport,
or at the network layer using PANA. When CONFIGURATION
possible. There are using link-layer key management with PANA, The EAP-based UKMF requires end hosts to
three independent there is two cases to consider. configure information in order to bootstrap
solutions to address •In the first case, link-layer ciphering may be application-layer ciphering. Specifically, the fol-
disabled or enabled independent of PANA use. lowing information needs to be configured:
the rekey issue. In this case, cryptographic or non-cryptographic • The transport identifier of an EAP authen-
access control is provided at the IP layer or ticator that supports bootstrapping applica-
above. An example cryptographic access control tion-layer ciphering
at the IP layer is IPsec. An example of non-cryp- • A set of identifiers of applications that sup-
tographic access control at the IP layer is Source port bootstrapping application-layer cipher-
Address Validation Improvements (SAVI). In ing from EAP
this case, link-layer ciphering may be enabled • For each application that supports boot-
using a link-layer specific authentication and key strapping application-layer ciphering from
agreement mechanism that may not support EAP, the identifier(s) of the application
EAP, such as Universal Mobile Telecommunica- endpoint(s) in the network
tions System (UMTS) AKA. This case belongs As part of our future work, we plan to identi-
to the partially unified model in that UKMF is a fy candidate solutions that enable such informa-
part of key management for application-layer tion to be dynamically configured.
ciphering and optionally for IP layer ciphering,
but not part of a key management for link-layer REKEYING APPLICATION-LAYER
ciphering. CIPHERING KEYS
•In the second case, link-layer ciphering is
bootstrapped using PANA in which a link-layer In the EAP-based unified key management
master key is securely established between two mechanism, without an additional rekey mecha-
endpoints of the link using the PANA security nism, rekeying application-layer ciphering keys
association. The link-layer master key is used by derived from EMSK is carried out via EAP re-
the secure association protocol to establish link- authentication. Rekeying EMSK will replace all
layer ciphering keys. The link-layer master key keys derived from it. Therefore, from an opti-
may be an individual key or a group key depend- mization point of view, it is desirable to design a
ing on the trust model of the link layer. When system such that the frequency of EMSK rekey-
the link-layer master key is an individual key, the ing can be reduced as much as possible. There
key is used solely between the endpoints of a are three independent solutions to address the
particular link. An example of such an individual rekey issue.
key is PEMK (PaC [PANA client]-EP [enforce- The first solution is to use EAP extensions
ment Point] master key). When a group key is for EAP re-authentication protocol (ERP) for
used, all nodes that possess the same group key EAP re-authentication. Since ERP operates
are considered as trusted. A typical link-layer without rekeying EMSK, this solution can avoid
technology that uses a group key is ZigBee. The EMSK rekeying even when the fully unified
group key needs to be securely delivered to each model is used and employs EAP re-authentica-
node once it successfully authenticates to the tion for network access.
network. PANA may be used for protecting the The second solution is to use the second key
group key delivery. This case belongs to the fully management alternative (i.e., using EAP carried
unified model. by PANA for bootstrapping application-layer
Second architectural alternative: EAP is used ciphering only). This solution can avoid EMSK
for bootstrapping application-layer ciphering rekey when an end host changes its network
only. PANA is used as the EAP transport for point of attachment since EAP is not used for
application-level authentication. Note that network access, and PANA has its own mobility
IKEv2 is another EAP transport over UDP. management mechanism to deal with the end
Access control at the link layer or network layer host’s IP address change.
may be performed independent of this EAP for The third solution is to generate multiple sets
bootstrapping application-layer ciphering. This of application-layer ciphering keys (instead of a
architecture belongs to the partially unified single set of application-layer ciphering keys) for
model. An example use case of this model is for each function of a given application and change
bootstrapping ANSI C12.22 ciphering keys the effective set of application-layer ciphering

34 IEEE Communications Magazine • August 2012

DAS LAYOUT_Layout 1 7/23/12 3:12 PM Page 35

Power line

DR signal
In-home
display

Wide PV,
area Communication link Smart battery
DRMS MDMS Home
network meter server
Home
appliances
Utilities office
Home
Metering data

Figure 3. Basic components of an AMI system.

keys when a rekey is needed. For example, ANSI

C12.22 defines an array of ciphering keys where WAN NAN
key-id, or the array index, is carried in each
security-enabled message, and changing keys is Smart
done by changing the key-id value. The size of meter
the key array may be determined based on the Wide
MDMS area Concentrator Smart
characteristics of the application (e.g., the array network meter
size for an application may be set such that it is
proportional to the average rekey frequency of Smart
the application). meter

ANSI CI2.22 ANSI CI2.22 ANSI CI2.22 ANSI CI2.22 ANSI

TEST PLAN master relay relay CI2.22
host
This section describes a practical deployment
plan of the EAP-based unified key management Authentication AAA (radius, diameter) PANA
PAA PaC
mechanism. server

BASIC AMI SYSTEM ARCHITECTURE

Figure 4. Architecture and functional mapping.
Figure 3 shows the basic components of an AMI
system. The smart meter installed in the con-
sumer’s house pushes the metering data to the
meter data management system (MDMS) in the the NAN between the concentrator and the
utility’s office, or the MDMS pulls the metering smart meter.
data from the smart meter. The smart meter The concentrator acts as an ANSI C12.22
could also receive demand response (DR) sig- Relay and PANA PAA, and the smart meter
nals from the MDMS or from the demand acts as an ANSI C12.22 Host and PANA PaC.
response management system (DRMS) via the The authentication and key establishment
MDMS. In addition, the smart meter may com- procedures are described below:
municate with an in-home display to show the 1 The smart meter starts PANA negotiation
consumer’s energy usage and the home server to with the concentrator at bootstrapping.
coordinate the energy usage in the home. PANA is used for EAP transport.
The smart meter will communicate with the 2 The concentrator relays the EAP messages
MDMS via a public wide area network (WAN), between the smart meter and the MDMS.
which may be the Internet for the exchange of An authentication, authorization, and
DR signals and metering data. We are consider- accounting (AAA) protocol such as
ing the possibility of ANSI C12.22 as an applica- RADIUS or Diameter is used for EAP
tion protocol between the MDMS and the smart transport between the concentrator and the
meter. ANSI C12.22 provides security mecha- MDMS.
nisms but it lacks a mechanism for dynamic key 3 The smart meter is permitted to connect the
management (rekeying). In addition, the net- ANSI C12.22 network, and the ANSI
work access authentication is required in the C12.22 ciphering key is shared by the smart
NAN. In order to fulfill these requirements, our meter, the concentrator, and the MDMS
unified key management mechanism can be after EAP authentication succeeds. The key
applied as shown in Fig. 4, based on the first is generated from EAP EMSK.
architectural alternative mentioned earlier. Since 4 When rekey of the ANSI C12.22 ciphering
a large number of smart meters may be attached key is needed, EAP re-authentication will
to one NAN, the data concentrator is installed be carried out as part of PANA re-authen-
to collect the metering data. In this case, PANA tication before expiration of the ANSI
is used for the network access authentication for C12.22 ciphering key.

IEEE Communications Magazine • August 2012 35

DAS LAYOUT_Layout 1 7/23/12 3:12 PM Page 36

ANSI C12.22 application will be needed, which

Object code size
We have established Module name may contribute to a much larger code footprint.
(in kbytes)
For example, if a C12.22 application uses a sepa-
that information dis- rate authentication mechanism other than EAP
covery for bootstrap Cryptographic module 50.0 or uses other EAP methods, it results in a signif-
application ciphering icant increase in the code size and additional
EAP module (EAP-PSK) 13.1 messaging overhead.
is an important and
PANA client module 52.4
as yet missing piece CONCLUSIONS AND FUTURE WORK
to realizing the uni- UKMF module 1.7 In this article, we propose a unified key manage-
fied key manage- ment mechanism (UKMF) that can generate
Total 117.2 ciphering keys for multiple protocols of multiple
ment framework
communication layers from a single peer entity
vision. This area Table 1. Object code size compiled on x86 CPU. authentication procedure. The unified key man-
requires additional agement mechanism is suitable for smart grid
use cases, especially for smart metering, where
investigation and is We also consider a model in which MDMS smart meters are assumed to be low-cost wire-
part of our future and smart meters directly communicate without less devices for which repeated peer entity
work. a concentrator. This model is referred to as a authentication attempts for each protocol can be
non-concentrator model, which is typically used contributed to increased system overhead. Our
for a NAN with a small number of smart meters. proposed mechanism is flexible in that peer enti-
We adopt the second architectural alternative ty authentication can be treated as either net-
(described earlier) to this model. Figure 4 shows work access authentication or application-level
the architectural mapping of the non-concentra- authentication. We present the details on an
tor model as well. The MDMS acts as an ANSI EAP-based unified key management mechanism
C12.22 master relay, PANA PAA, and authenti- and show that it is important to consider re-key
cation server. The smart meter acts as an ANSI efficiency of the ciphering keys bootstrapped
C12.22 host and PANA PaC. from EMSK.
The authentication and key establishment We also discuss our test environment where
procedures of this model are outlined below: the proposed unified key management mecha-
1 The smart meter starts PANA negotiation nism is integrated with an ANSI C12.22 based
with the MDMS at bootstrapping. PANA is smart metering application, and where PANA is
used for EAP transport. used for both network access authentication and
2 The smart meter shares the ANSI C12.22 application-level authentication. We present pre-
ciphering key with the MDMS after EAP liminary implementation results achieved using a
authentication is succeeded. The key is gen- commercial microprocessor, typical to those
erated from EAP EMSK. deployed in smart meters and using a general
3 When re-key of ANSI C12.22 ciphering key purpose computer. We plan to do additional
is needed, EAP re-authentication will be optimization on our code size and compare with
carried out as part of PANA re-authentica- other code sizes as well.
tion before expiration of the ANSI C12.22 We have established that information discov-
ciphering key. ery for bootstrap application ciphering is an
We have started implementation of the pro- important and as yet missing piece to realizing
posed unified key management mechanism in the unified key management framework vision.
our test environment as described above. We This area requires additional investigation and is
implemented EAP and PANA on an embedded part of our future work. Also included in future
device with Toshiba microprocessor TLCS-900. work are the security enhancements that may be
The footprint of our PANA and EAP implemen- needed to support new demands of the smart
tation is less than 30 kbytes, which indicates that grid, particularly those impacts associated with
EAP and the EAP lower-layer part of the pro- increasing adoption of electrical vehicles.
posed unified key management mechanism can
satisfy the requirements described earlier. Cur-
rently we are in the process of integrating the
REFERENCES
embedded system with the rest of the architec- [1] Smart Grid Interoperability Project,
http://www.nist.gov/smartgrid.
ture and expect to have some additional results [2] E. Hammer-Lahav, The OAuth 1.0 Protocol, 2010,
in near future. http://tools.ietf.org/html/rfc5849.
In addition to the above, we also implement- [3] OpenID Authentication 2.0 – Final Technical Specifica-
ed several modules in a general-purpose com- tion. http://openid.net/specs/openid-authentication-
2_0.html.
puter. Table 1 shows the object code size for [4] P. Harding, L. Johansson, and N. Klingenstein, “Dynamic
each module. The code was compiled by gcc ver- Security Assertion Markup Language: Simplifying Single
sion 4.5.2 on an x86 CPU running Linux (Ubun- Sign-On,” IEEE Security & Privacy, 2008.
tu 11.02). [5] H.-K. Oh and S.-H. Jin, “The Security Limitations of SSO
in OpenID,” ICACT, 2008.
As shown in Table 1, it is evident that only an [6] T. Gross, “Security Analysis of the SAML Single Sign-On
additional code size of 1.7 kbytes (i.e., 1.5 per- Browser/Artifact Profile,” Computer Security Applica-
cent of the total code size) of the UKMF mod- tions Conf., 2003.
ule is needed for supporting dynamic key [7] B. Aboba et al., “Extensible Authentication Protocol
(EAP),” http://www.ietf.org/rfc/rfc3748.txt, 2004
provisioning for ANSI C12.22 application. With- [8] B. Aboba, D. Simon, and P. Eronen, “Extensible Authen-
out UKMF, an additional module for authenti- tication Protocol (EAP) Key Management Framework,”
cation and key establishment dedicated to the http://www.ietf.org/rfc/rfc5247.txt, 2008.

36 IEEE Communications Magazine • August 2012

DAS LAYOUT_Layout 1 7/23/12 3:12 PM Page 37

[9] Y. Ohba, Ed., “Protocol for Carrying Authentication for MITSURU KANDA ([email protected]) is a senior
Network Access (PANA),” http://www.ietf.org/rfc/ research scientist in Toshiba Corporate Research & Devel-
rfc5191.txt, 2008. opment Center. He received B.E. and M.E. degrees in
[10] C. Kaufman, “Internet Key Exchange (IKEv2) Protocol,” information sciences from Tohoku University in 1997 and
http://www.ietf.org/rfc/rfc5996.txt, 2005. 1999. His research interests are IPv6 and security. He is
[11] ZigBee Alliance, “ZigBee Smart Energy Profile™ 2.0 an author of the Linux IPv6/IPsec stack and a member of
Technical Requirements Document,” 2010. the racoon2 project (an open source IKE implementa-
[12] J. Salowey, “Specification for the Derivation of Root tion).
Keys from an Extended Master Session Key (EMSK),”
http://www.ietf.org/rfc/rfc5295.txt, 2008. DAVID FAMOLARI ([email protected]) is a vice presi-
dent at Rutberg & Company, a technology-focused
BIOGRAPHIES investment bank specializing in the mobile and wireless
sector. He serves as a venture advisor to Paladin Capital
S UBIR D AS [M] ([email protected]) is a director and Group, is a founding partner at Day2 Ventures, a co-
senior scientist in the mobile networking department of founder of GoodCompany Ventures, and sits on the
Applied Communication Sciences, New Jersey. His current Technology Advisory Board at Ben Franklin Technology
research interests include mobile networking, network Partners. Previously, he spent more than 12 years in
security and mobility, AMI networks, IP multimedia subsys- advanced R&D at Telcordia Technologies. He earned an
tem, and ad hoc networks. He is very active in several stan- M.B.A. from the Wharton School at the University of
dards and holds leadership positions in IEEE 802. He is a Pennsylvania, and M.S. and B.S. degrees in electrical
recipient of an IEEE Region 1 award and a member of the engineering from Rutgers University.
IEEE Communications Society.
S AJ A L K . D A S ( d a s @ u t a . e d u ) i s a U n i v e r s i t y D i s t i n -
Y OSHIHIRO O HBA ([email protected]) is a chief guished Scholar Professor of Computer Science and
research scientist in Toshiba Corporate R&D Center. He Engineering at the University of Texas at Arlington,
received B.E., M.E., and Ph.D. in information and computer where he is also the director of the Center for Research
sciences from Osaka University in 1989, 1991, and 1994, in Wireless Mobility and Networking. His current
respectively. He is an active member in IEEE 802 and IETF research interests include mobile and pervasive com-
for standardizing security and mobility protocols. He is a puting, wireless sensor networks, energy and sustain-
main contributor to RFC 5191 (PANA-Protocol for Carrying ability, smart environments and cyber-physical systems,
Authentication for Network Access). He received the IEEE security and privacy, social networks, applied graph
Region 1 Technology Innovation Award in 2008. theory, and game theory.

IEEE Communications Magazine • August 2012 37