BEST PRACTICES AND RESEARCH FOR HANDLING DEMAND RESPONSE SECURITY
ISSUES IN THE SMART GRID
Prakarn Asavachivanthornkul
B.S., King Mongkut's Institute of Technology, Ladkrabang, 2003
PROJECT
Submitted in partial satisfaction of
the requirements for the degree of
MASTER OF SCIENCE
in
COMPUTER SCIENCE
at
CALIFORNIA STATE UNIVERSITY, SACRAMENTO
FALL
2010
BEST PRACTICES AND RESEARCH FOR HANDLING DEMAND RESPONSE SECURITY
ISSUES IN THE SMART GRID
A Project
by
Prakarn Asavachivanthornkul
Approved by:
__________________________________, Committee Chair
Isaac Ghansah, Ph.D.
__________________________________, Second Reader
Scott Gordon, Ph.D.
____________________________
Date
ii
Student: Prakarn Asavachivanthornkul
I certify that this student has met the requirements for format contained in the University format
manual, and that this project is suitable for shelving in the Library and credit is to be awarded for
the project.
__________________________________, Graduate Coordinator
Nikrouz Faroughi, Ph.D.
Department of Computer Science
iii
_____________
Date
Abstract
of
BEST PRACTICES AND RESEARCH FOR HANDLING DEMAND RESPONSE SECURITY
ISSUES IN THE SMART GRID
by
Prakarn Asavachivanthornkul
When electricity demand is peak, utilities and other electric Independent Systems Operators
(ISOs) keep electric generators on-line in order to meet the high demand. In some cases, new
power plants have to be built. This solution increases costs, wastes energy and creates air
pollution. To overcome this, many utilities, government, and others have been developing
Demand Response (DR) programs to manage growth in peak electricity demands, and to provide
more reliable and more economic energy. The primary focus of the Demand Response (DR) is to
provide two-way communications to customers so that the energy-management and control
system (EMCS) at the customer’s sites can take action based on the demands for electricity and
electricity prices. As a result, when the grid supply becomes strained or when the electricity
prices reach a certain point, demand response programs are intended to lower the energy use in
return for reducing total system costs and electric loads on the grid.
DR systems are expected to be eventually utilized in most of California’s residential and
commercial energy customers. The breach in security goals – confidentiality, integrity,
availability and accountability – could adversely affect the system and large number of
customers. The impacts vary from the reliability of the grid itself to the customers’ electric bills
and to the privacy loss of the customers. In some cases, it could affect health and safety of
customers. This project discusses security risks of DR systems, addresses information security
iv
best practices to mitigate those risks and identifies potential Research and Development (R&D)
issues existing in DR systems with the hope of increasing awareness of security issues existing in
DR systems.
The results show that although DR systems have a number of potential security risks and
vulnerabilities that must be addressed, information security best practices can be used to mitigate
some of them. In some situations (e.g., ensuring non-repudiation), where the best practices could
not be directly used, further research will be required to address security issues and appropriate
R&D issues are identified for those unique cases as well.
__________________________________, Committee Chair
Isaac Ghansah, Ph.D.
____________________________
Date
v
ACKNOWLEDGMENTS
I would like to thank Dr. Isaac Ghansah for his direction, assistance and guidance. Dr. Ghansah’s
recommendations and technical advices have been invaluable for this project.
Special thanks should be given to all of my friends who helped me in many ways. Finally, words
alone cannot express the thanks I owe to my family and Puthita Utchavanich, my special friend,
for their encouragements and supports.
vi
TABLE OF CONTENTS
Page
Acknowledgments........................................................................................................................... vi
List of Tables ................................................................................................................................ xiii
List of figures ................................................................................................................................ xiv
Chapter
1. INTRODUCTION ..................................................................................................................... 1
1.1. Background ...................................................................................................................... 1
1.2. Terms and Definitions ...................................................................................................... 5
1.2.1. Security Requirements ......................................................................................... 5
1.2.2. Cyber Security...................................................................................................... 7
1.3. Statement of Problems ..................................................................................................... 7
1.4. Project Overview.............................................................................................................. 8
1.5. Project Objectives .......................................................................................................... 10
1.6. Report Organization ....................................................................................................... 10
2. REVIEW OF DEMAND AND RESPONSE SYSTEMS ....................................................... 13
2.1. Demand Response Systems............................................................................................ 13
2.2. Information transmitted in Demand Response Systems ................................................ 14
2.2.1. Price-Based Information .................................................................................... 15
2.2.2. Event-Based Information ................................................................................... 15
2.2.3. Bidding Information ........................................................................................... 16
2.3. Major Components in Demand Response systems ........................................................ 16
2.3.1. Advanced Metering Infrastructure and Demand Response Systems ................. 16
2.3.2. Home Area Networks, Neighborhood Area Networks and Demand Response
Systems .............................................................................................................. 19
vii
2.3.3. Overview of Zigbee Communication Standard .................................................. 20
2.3.4. Use of Zigbee in HAN for Demand Response Systems ..................................... 20
2.3.5. Demand Response Networks ............................................................................. 21
2.3.6. Open Automated Demand Response.................................................................. 25
2.4. Conclusion ..................................................................................................................... 28
3. SECURITY ISSUES IN DEMAND AND RESPONSE ......................................................... 29
3.1. Security Requirements and Demand Response Systems ............................................... 30
3.1.1. Confidentiality.................................................................................................... 30
3.1.2. Authentication .................................................................................................... 30
3.1.3. Data Integrity ..................................................................................................... 30
3.1.4. Availability......................................................................................................... 31
3.1.5. Accountability .................................................................................................... 31
3.2. Security Issues in Pricing Signals .................................................................................. 31
3.3. Security Issues in Demand Response Events Information ............................................. 32
3.4. Security Issues in Bidding Information.......................................................................... 33
3.5. Security Issues in Demand Response Networks ............................................................ 34
3.5.1. Demand Response Sensor Networks.................................................................. 34
3.5.2. Security Concerns in Demand Response Wireless Sensor Networks ................ 35
3.6. Zigbee Security .............................................................................................................. 36
3.7. Security Concerns in Zigbee .......................................................................................... 39
3.7.1. Key Establishment and Distribution .................................................................. 39
3.7.2. Insufficient Integrity Protection ......................................................................... 40
3.7.3. Nonce Management Problem ............................................................................. 41
3.7.4. Key Management Problem ................................................................................. 42
viii
3.8. Securities Issues in Open Automated Demand Response .............................................. 43
3.9. Automated Demand Response at Residential Sites and Security Issues ........................ 51
3.9.1. Possible Attacks on Programmable Communicating Thermostat ...................... 52
3.10. Conclusion ..................................................................................................................... 53
4. BEST PRACTICES FOR HANDLING SECURITY ISSUES IN DEMAND RESPONSE... 54
4.1. Demand Response Sensor Networks and Security Measures ........................................ 55
4.1.1. Use of Cryptography .......................................................................................... 55
4.1.2. Elliptic-Curve Cryptography .............................................................................. 56
4.1.3. Use of Elliptic-Curve Cryptography in Sensor Networks .................................. 57
4.1.3.1. Authentication..................................................................................... 57
4.1.3.2. Confidentiality .................................................................................... 59
4.1.3.3. Accountability/Non-repudiation ......................................................... 60
4.2. Zigbee and Security Measures ....................................................................................... 60
4.3. Demand Response Best Practices .................................................................................. 61
4.3.1. Data Transmission.............................................................................................. 62
4.3.2. Data Handling Practices ..................................................................................... 62
4.3.3. Key Management ............................................................................................... 62
4.3.3.1. Key Usage........................................................................................... 63
4.3.3.2. Key Period .......................................................................................... 64
4.3.3.3. Algorithm and Key Length ................................................................. 65
4.3.4. Key Management Systems ................................................................................. 67
4.3.4.1. Symmetric Key Management ............................................................. 67
4.3.4.1.1. Key Establishment and Distribution ................................. 68
4.3.4.1.2. Protection of Symmetric Keys in Transit .......................... 71
ix
4.3.5. Access Control and DR communications........................................................... 72
4.4. Open Automated Demand Response Best Practices ...................................................... 73
4.4.1. Security Requirements for OpenADR................................................................ 74
4.4.2. Security Measures for OpenADR ...................................................................... 74
4.4.2.1. TLS 1.0 with server-side certificates .................................................. 75
4.4.2.2. TLS 1.0 with server-side and client-side certificates .......................... 76
4.4.2.3. Web Service Security ......................................................................... 78
4.4.2.3.1. Encryption ......................................................................... 78
4.4.2.3.2. Source Authentication....................................................... 80
4.4.2.3.3. Message Authentication .................................................... 80
4.4.2.3.4. Non-repudiation ................................................................ 81
4.4.2.3.5. Key Pair Management....................................................... 82
4.4.2.3.6. Certificate Management .................................................... 82
4.4.2.3.7. Security Consideration in X.509 Certificate with WSSecurity ............................................................................. 83
4.5. Automated Demand Response at Residential Sites and Security Measures .................. 84
4.5.1. Cryptographic Approaches................................................................................. 85
4.5.2. Key Distribution ................................................................................................. 86
4.5.3. Key Management ............................................................................................... 86
4.6. Conclusion ..................................................................................................................... 87
5. RESEARCH AND DEVELOPMENT ISSUES ...................................................................... 89
5.1. Topics in Authentication and/or Authorization.............................................................. 90
5.1.1. Role-Based Access Control................................................................................ 90
5.1.2. Authentication between DR Service Providers and Smart Devices ................... 92
x
5.1.3. HAN Devices Authentication ............................................................................ 93
5.1.4. Authorization and Authentication between Users and Smart Appliances.......... 94
5.2. Topics in Cryptography and Key Management ............................................................. 96
5.2.1. Public Key Infrastructure ................................................................................... 96
5.2.1.1. Trust Establishment ............................................................................ 99
5.2.1.2. Private Key Protection ........................................................................ 99
5.2.1.3. Certificate Revocation List Availability ........................................... 100
5.2.2. Key Management and Public Key Infrastructure ............................................. 101
5.2.3. Limitation in Devices and Cryptography ......................................................... 102
5.2.4. Key Management for Wireless Sensor Networks ............................................ 103
5.2.5. Accountability/Non-repudiation Issues ............................................................ 105
5.2.5.1. An overview of Contract-Signing Protocols ..................................... 108
5.2.5.2. Roles of TTP ..................................................................................... 109
5.2.5.3. Optimistic Fair Exchange Protocol ................................................... 110
5.2.5.3.1. The Exchange Sub-protocol ............................................ 111
5.2.5.3.2. The Abort Sub-protocol .................................................. 112
5.2.5.3.3. The Resolve Sub-protocol............................................... 114
6.3. Conclusion ................................................................................................................... 117
6. CONCLUSION ..................................................................................................................... 118
6.1. Project Outcomes ......................................................................................................... 119
6.2. Suggestion for Future Work ......................................................................................... 119
Appendix A. TECHNICAL BEST PRACTICES FOR ENFORCING SECURITY GOALS ..... 122
A.1. Use of Cryptographic Tools ......................................................................................... 123
A.1.1. Confidentiality.................................................................................................. 123
xi
A.1.2. Integrity ............................................................................................................ 125
A.1.3. Availability....................................................................................................... 128
A.1.4. Accountability/Non-repudiation....................................................................... 129
A.2. User Authentication ..................................................................................................... 130
A.2.1. Password Authentication .................................................................................. 130
A.2.2. Token Authentication ....................................................................................... 131
A.2.3. Biometric Authentication ................................................................................. 131
A.2.4. Digital Signature .............................................................................................. 132
A.3. Access Control/Authorization ...................................................................................... 132
A.3.1. Discretionary Access Control........................................................................... 133
A.3.1.1. Access Control List........................................................................... 133
A.3.1.2. Capability List .................................................................................. 134
A.3.2. Mandatory Access Control ............................................................................... 134
A.3.3. Role-based Access Control .............................................................................. 135
Glossary ....................................................................................................................................... 136
References .................................................................................................................................... 140
xii
LIST OF TABLES
Page
1. Table 1: List of WAN Technologies with its Application, Strengths and Weaknesses .......... 23
2. Table 2: List of LAN Technologies with its Application, Strengths and Weaknesses ............ 25
3. Table 3: Comprehensive Security Concerns in Zigbee ........................................................... 43
4. Table 4: Possible Attacks and Impacts of Utility/ISO Operator Interfaces ............................. 44
5. Table 5: Possible Attacks and Impacts of DRAS Client Interfaces ........................................ 47
6. Table 6: Possible Attacks and Impacts of Participant Interfaces............................................. 50
xiii
LIST OF FIGURES
Page
1. Figure 1: Overview of Demand Response System .................................................................. 14
2. Figure 2: Advanced Metering Infrastructure and Demand Response ..................................... 18
3. Figure 3: Zigbee-based HAN Enabling Demand Response from Utility AMI Network ........ 20
4. Figure 4: High-level View of Smart Grid Network Architecture ............................................ 22
5. Figure 5: Generic OpenADR Interface Architecture ............................................................... 26
6. Figure 6: DRAS Client Interfaces ........................................................................................... 28
7. Figure 7: Typical Wireless Sensor Networks .......................................................................... 35
8. Figure 8: Zigbee Layer Model................................................................................................. 37
9. Figure 9: Typical Zigbee Network .......................................................................................... 39
10. Figure 10: Security Suites Supported by IEEE 802.15.4 ........................................................ 41
11. Figure 11: Path of Attack in PCT ............................................................................................ 52
12. Figure 12: Simplified Version of ECC-Based SSL Handshake Protocol ................................ 58
13. Figure 13: Recommended Algorithms and Minimum Key Sizes ............................................ 65
14. Figure 14: Comparable Security Strength for the Approved Algorithms ............................... 66
15. Figure 15: Hash Function Security Strengths for Cryptographic Applications ....................... 67
16. Figure 16: Kerberos Operations .............................................................................................. 69
17. Figure 17: TLS Handshake with Client Certificate and MITM Attack ................................... 77
18. Figure 18: Asymmetric Cryptography..................................................................................... 79
xiv
19. Figure 19: Authentication using X.509 Certificate ................................................................. 80
20. Figure 20: Signing and Verification Process of Digital Signature .......................................... 81
21. Figure 21: Requesting and Obtaining a Certificate from CA .................................................. 83
22. Figure 22: Defense Mechanisms for PCT Systems ................................................................. 85
23. Figure 23: Hierarchy of the Key Distribution ......................................................................... 86
24. Figure 24: Signature Generation and Verification .................................................................. 97
25. Figure 25: Use of Digital Signatures for Ensuring Accountability ....................................... 106
26. Figure 26: Exchange Sub-protocol in Optimistic Fair Exchange Protocol ........................... 111
27. Figure 27: Aborted Sub-protocol in Optimistic Fair Exchange Protocol .............................. 114
28. Figure 28: Resolve Sub-protocol in Optimistic Fair Exchange Protocol .............................. 115
29. Figure 29: Public Key Encryption ......................................................................................... 124
30. Figure 30: Message Authentication Code ............................................................................. 126
31. Figure 31: Signature Generation and Verification ................................................................ 127
xv
1
Chapter 1
INTRODUCTION
1.1.
Background
When electricity demand is peak, particularly in summer, utilities, and other electric Independent
Systems Operators keep electric generators on-line in order to meet high demand. In some cases,
series of a new power plant have to be built. This solution wastes energy and increases air
pollution [1]. If the demand is highest in most regions and exceeds available supplies, brownouts
and blackouts can happen. The Economic Impacts of the August 2003 Blackout has shown that
the impacts of blackouts that happened in the Northeast and California during the past few years
caused billions of dollars from loss of businesses and individuals [2]. This has proved that the
traditional electricity grids are not reliable enough.
Demand Response (DR) is “…an action taken to reduce electricity demand in response to price,
monetary incentives, or utility directives so as to maintain reliable electric services or avoid high
electricity prices [3].” During the peak hours, DR programs or tariffs can lower the energy used in
return for decreasing total system costs and electric loads. As a result, the need for building more
power plants and transmission lines, which are non-environmentally friendly, is decreased [1].
The primary focus on Demand Response is to provide electricity consumers with dynamic or
time-based price information or other types of incentive information so that the consumer end-use
electric loads can be shifted or shed in response to the information received in reliable and
economic manners. DR could be implemented in different ways depending on the types of price
information. For example, the Real-Time Pricing (RTP) requires computer-based response, while
2
the fixed time-of-use (ToU) pricing may be manually handled by the customer. In the past few
years, a number of research and development on DR programs have been carried out in order to
manage growth in peak electricity demands and provide more reliable to electricity grids as well
as more economic energy.
Demand Response Research Center (DRRC) operated by Lawrence Berkeley National
Laboratory (LBNL) for the California Energy Commission’s Public Interest Energy Research
Program (PIER) has been putting efforts to develop, demonstrate and deploy activities related to a
framework which can enable Automated Demand Response (AutoDR or ADR). The research
conducted by DRRC plays substantive roles in moving DR to market acceptance. For instance, a
number of field tests conducted in a variety of sites, such as commercial buildings, museums and
high schools, by LBNL through PIER Demand Response Research Center have shown that ADR
can reduce the average building peak electricity demand by 10 to 14 percent [1].
The development of Open Automated Demand Response (OpenADR or Open Auto-DR) has been
carried out in order to provide a web-services-based framework that utilizes Internet-based DR
events and price signals in order to optimize electricity supply and demand, which in turn
improves the reliability of electronic grid and decreases the total cost of overall systems.
OpenADR has been defined as “a set of standard, continuous, open communication signals and
systems provided over the Internet to allow facilities to automate their demand and response with
no human in the loop [4].” In 2008, OpenADR communication specification version 1.0 [5] was
released by LBNL Demand Response Research Center. This specification provides a feasible
framework for developing a low-cost communication infrastructure to facilitate sending and
receiving DR signals from a utility or an Independent System Operator (ISO) to electric
customers and to interact with commercial and industrial control systems based on a DR signal
3
with no human intervention [5]. Many California’s commercialized DR programs have been
developed based on OpenADR and related technologies. As a result, 303 facilities were able to
provide over 55 megawatts (MW) of peak demand reduction, with a percent of peak demand
reduction of 24% [6].
According to California Public Utility Commission (CPUC), there are three regulated investorowned utilities (IOUs) in California that offer DR programs, Pacific Gas and Electric Company
(PG&E), Southern California Edison (SCE) and San Diego Gas and Electric (SDG&E). These
utilities offer DR programs for small, medium and large businesses. A number of study cases of
various businesses have been conducted by these utilities. For instance, a case study on
community medical centers from PG&E has shown that one of the largest hospitals, participating
in the study, could drop more than 500 kW over two to six hour periods on three event days [7].
The benefits of DR vary from consumer’s energy bill savings to energy efficiency and reliability
to the grid. Utilities, ISOs, Regional Transmission Organizations (RTOs) and other organizations
could use DR to manage electrical demand and supply, reduce potential outages, and lower total
system costs instead of having the generators produce more supplies or building more power
generations in order to meet high electrical demands. Having these benefits motivates FERC,
CPUC, CEC and other utilities to conduct a number of assessments, study cases, field tests and
research on DR to demonstrate and improve the abilities of DR. As mentioned earlier, some of
the research has shown that DR can cut costs and provides efficient way to manage and reduce
electric loads in industrial, commercial and residential buildings.
In addition to the efforts to improve DR capabilities, National Institute of Standards and
Technology (NIST) and Smart Grid Interoperability Panel (SGIP) also have responsibilities to
4
coordinate development of a framework including standards and protocols for information
management to achieve interoperability of smart grid devices and systems 1.
Under this
collaboration, there is a working group, called Cyber Security Working Group (CSWG), which is
dealing with cyber security issues in the Smart Grid and developing overall security strategy for
the Smart Grid. NIST has published three volumes of Guidelines for Smart Grid Cyber Security
Strategy and Requirements (NISTIR 7628 vol. 1-3) [8] in Aug 2010. The NISTIR 7628 provides
security strategy, high-level requirements, architectures, privacy issues, etc for addressing cyber
security for Smart Grid systems. Some of the information in this guideline is used in this research
as well.
A lot of research on security issues and countermeasures in DR and relevant components, such as
DR sensor networks, Advanced Metering Infrastructure (AMI) and smart meters, have been
undertaken. In 2006, a research on Network Security Architecture for Demand Response/Sensor
Networks [9] was released by CEC and U.C. Berkeley. It focused on identifying security and
privacy in sensor networks and developing a framework for deployment scenarios – short,
medium and long term deployment – for demand response network architectures. A Security
Specification [10] and a Security Implementation [11] to address AMI security issues have been
recently released by AMI security (AMI-SEC) task force formed by The Open Smart Grid Users
Group2. These reports covered a set of security requirements for AMI and the guide for
establishing a high security assurance level for AMI. The reports addressed some aspects of the
issues related to DR pricing signals. Another report on Cyber Security Issues on Smart Grid
1
2
The NIST Smart Gird Collaboration site: http://collaborate.nist.gov/twikisggrid/bin/view/SmartGrid/WebHome.
The Open Smart Grid Users Group website: http://osgug.ucaiug.org.
5
Systems from National Supervisory Control and Data Acquisition (SCADA) Test Bed (NSTB)
[12] covered a few of the current issues related to AMI and wireless networks. The OpenADR
communication specification version 1.0 [5] by LBNL addresses some of the security
requirements and policies for the communications with Demand Response Automated Server
(DRAS), one of the major components in OpenADR systems. This specification recommended
using communication standards, such as TLS, to address the security requirements for OpenADR,
but vulnerabilities in TLS have been recently found by M. Ray and S. Dispensa [13] in Nov 2009
and it needs to be fixed in order to preserve the security requirements in OpenADR. All of these
reports provide useful information, guidelines and framework for DR systems. However, some
security aspects or issues might have been overlooked and sometimes the recommendation and
security measures might not be addressed.
This project, Best Practices and Research for Handling Demand Response Security Issues in the
Smart Grid, discusses security risks of DR systems, addresses information security best practices
to mitigate those risks and identifies potential Research and Development (R&D) issues relevant
to DR with the hope of increasing awareness of security issues existing in DR systems.
1.2.
1.2.1.
Terms and Definitions
Security Requirements
The terms Security Requirements or Security Goals used in this report refer to the security
aspects as follows:
6

Confidentiality
Confidentiality is to assure that information is not disclosed to unauthorized parties,
entities or processes. This property is to preserve information restrictions on
unauthorized access and disclosure. Encryption and access control are often used to
ensure confidentiality of the information.

Integrity
Integrity is to preserve the authenticity and accuracy of the information. This property
can be divided into two aspects.
Data Integrity is to ensure that data has not been altered in an unauthorized manner
including data in storage, during processing, and while in transit. This includes the
property that data has not been modified, destroyed and substituted in an unauthorized
and undetected manner.
Source Integrity refers to preserving the origin of the data. This property is to ensure
that the source of the data is legitimate and the data is come from the source that it
alleges for. This property sometimes refers to Authentication and is interchangeably
used in this report.

Availability
Availability is to ensure that the information is available in a timely and reliable
manner. This includes no denial of an authorized access to entities, processes, devices
and information.
7

Accountability
Accountability is to ensure that the subject is accountable for its action. This includes
the property that an action by an entity is traced uniquely to that entity. Nonrepudiation – preventing an entity from denying involvement in a particular action
related to the data – is covered in this property as well.
1.2.2.
Cyber Security
According to NISTIR 7628, Cyber Security “focuses on the protection required to ensure
confidentiality, integrity and availability of the electronic information communication systems
[14].” In the smart grid systems, it involves the balance of both power and IT communication
system to maintain reliability to the Smart Grid. It includes preventing, detecting and responding
to attacks in order to minimize the number of successfully attacks.
1.3.
Statement of Problems
DR systems are expected to be eventually utilized in most of California’s residential and
commercial energy customers. The breach in security goals could adversely affect large scale of a
smart grid system and large number of customers. The impacts are varied from the reliability of
the grid itself to the impacts on customers’ electric bills and to the invasion of the privacy of
customer’s information. For example, unauthorized modification of price signals could affect
customers financially. Manipulation of DR signals not only affects electric bills but also causes
annoyance to customers. In some situations, it could affect health and safety of customers as well.
For example, an attacker may turn on heating units during an extremely hot day in the summer.
Moreover, the information from the smart devices responded by customers, and/or the
8
information collected by utilities could result in the exposure of energy consumption uses and
patterns of customers, resulting in privacy loss.
Therefore, the security concerns of customer information and proper countermeasures in order to
protect against different kinds of attacks must be identified. Appropriate data handling practices
and cryptographic mechanisms must be addressed in order to provide the security and privacy to
customer information. In some cases, the information security best practices provided in this
research to handle DR security issues may not be directly applied to the DR systems. Those
specific situations are identified as Research and Development (R&D) issues.
1.4.
Project Overview
Demand Response (DR) systems for managing energy usage in homes and buildings are one of
the critical areas in the Smart Grid. Utilities have deployed Advanced Metering Infrastructure
(AMI) in order to provide two-way communications between homes or buildings and the utilities
via smart meters. The electric meters or some other devices residing in homes and buildings could
be used as a gateway between buildings and the utilities. This gateway is used to provide real
time communication link between electric, gas, water meters, and other digital devices in homes.
This has led to architecting Home Area Networks (HANs) that connect thermostats, load switches
and lightening devices. All these smart devices connected in the HAN can be set to operate
during low and high cost energy periods. Introduction of HAN along with advanced wireless
home networking has enabled use of home monitoring devices and home automation. Wireless
communication standard, such as Zigbee and Wi-Fi, can be used in home automation for
controlling demand response events. The load shedding or shifting is carried out when DR events
9
and price signals arrive at the smart meter or home gateway. DR strategies which are preprogrammed in smart devices will take action in response to the signals received.
However, once these components are deployed in the Smart Grid, they are vulnerable to a number
of attacks. Information transferred in DR systems, such as price signals, could be modified in an
unauthorized manner. Devices could be manipulated to perform some malicious activities. An
attacker may be able to turn on/off air conditioning units in homes remotely. Customers’
information could be eavesdropped resulting in privacy loss. Besides, some communication
standards, such as Zigbee and Wi-Fi, have certain vulnerabilities which can lead to many kinds of
attacks, such as eavesdropping, replay and Man-in-the-Middle (MITM) attacks. Therefore, a
number of security issues have to be determined and solved before DR systems are deployed in a
large scale. Security measures and best practices must be specified for handling those security
issues as well.
This project explores DR systems and related components, such as AMI and HAN. It discusses
relevant communication protocols and network architectures, such as Zigbee, with respect to
security. In additions, it focuses on identifying security issues in the information transmitted in
DR systems, such as price and DR events information, DR networks, such as Wireless Sensor
Networks (WSNs) and HAN, and other components as well as OpenADR. The security measures
and best practices in information security for handling those issues in DR systems are provided.
In some cases, the measures and practices recommended may not be directly applicable. DR
specific Research and Development (R&D) issues are provided as well.
10
1.5.
Project Objectives
The overall objectives of the project are as follows:

Identify potential security issues in the context of DR, including information
transmitted in the system, Wireless Sensor Networks (WSNs), communication
protocols, and OpenADR, with respect to the security goals.

Investigate which information security best practices can be applied to DR systems in
order to mitigate actions that violate security goals. This includes the use of
cryptography and other security mechanisms to handle those issues as well.

Explore possible R&D issues that should be addressed in the DR systems since some
of the best practices may not be able to use directly or may require further research to
address those security issues.
1.6.
Report Organization
This report is organized as follows:

Chapter 1: Introduction

Chapter 2: Review of Demand and Response Systems
This chapter gives an overview of how DR systems work. It gives brief details of the
information transmitted in DR systems, and related components, such as AMI and
HAN, in order to see how this information flows in the systems from utilities through
these components and load reduction at customers’ sites is carried out. Next, it looks
into HAN and the use of Zigbee communication protocol in HAN to see how home
11
automation can shift or shed electric loads. DR networks and communication
protocols that could be used are also described. Finally, it also provides information
about OpenADR and its interfaces in order to see how automated DR is carried out.

Chapter 3: Security Issues in Demand and Response Systems
This chapter first specifies the overall security requirements in DR systems. It also
looks into the security issues in information transmitted in DR systems. Next, it
discusses about the security issues in DR networks, where the use of Wireless Sensor
Network (WSN) and HAN is described. Since Zigbee is the most common protocol
used in HANs, the security mechanisms offered by Zigbee are discussed and security
concerns in Zigbee are identified. Next, OpenADR and security issues focusing on
the information transmitted between its interfaces are identified with the impacts if
the security goals are compromised. Finally, automated DR at residential sites is
discussed with respect to the security.

Chapter 4: Best Practices for Handling Security Issues in Demand Response Systems
This chapter provides security measures and best practices used to mitigate the risks
and security issues specified in Chapter 3. It first provides security mechanisms for
ensuring confidentiality, authentication and accountability in DR sensor networks. It
also suggests the security measures for Zigbee protocol. Next, the best practices for
data transmission, data handling, key management and access control for DR are
provided. The best practices for OpenADR for handling security requirements are
also provided. Finally, it discusses the security measures and Key Management
12
practices for automated demand at residential sites. (Note that some of the technical
best practices discussed in this chapter are referred to in Appendix A.)

Chapter 5: Research and Development Issues
This chapter identifies potential R&D topics with respect to DR systems. The R&D
Topics discussed in this chapter are organized into the topics in Authentication and
Authorization, Cryptography and Key Management, and other topics.

Chapter 6: Conclusion

Appendix A: Technical Best Practices for Enforcing Security Goals
This section provides technical best practices to ensure confidentiality, integrity,
availability and accountability in information systems. These best practices include
the Use of Cryptographic tools, User Authentication techniques and Access
Control/Authorization. Application of these best practices to DR systems are
mentioned where necessary in this report as well.
13
Chapter 2
REVIEW OF DEMAND AND RESPONSE SYSTEMS
DR can reduce energy consumption during peak time or based on events of which the energy
prices are high, such as congestion, supply-demand balance and/or market conditions that raise
the energy supply costs. When the grid supply becomes strained or when the electric prices reach
a certain point, demand response programs lower the energy use in return for decreasing total
system costs and electricity supplies on the grid. Consequently, it maximizes usage of the energy
and brings reliability to the grid.
This chapter intends to give an overview of DR systems and the information transmitted in DR
systems, such as real-time pricing and time-of-use pricing. It also provides brief details of major
components related to DR, such as Advanced Metering Infrastructure (AMI), Home Area
Networks (HANs) and Neighborhood Area Networks (NANs) in the context of DR. Finally, it
provides an overview of OpenADR as well.
2.1.
Demand Response Systems
A utility is responsible for monitoring the power consumption and transmitting DR commands to
Energy Management and Control Systems (EMCS) at the customers’ sites. The EMCS then
adjusts the electricity loads in response to the commands received based on the pre-programmed
DR strategies. The utility receives energy usage information from the meters at customers’ sites
and informs customers, via SMS, email or paging, if they would like to adjust their power
consumption. Customers are also able to decide to reduce power manually. During the DR events,
14
a utility could trigger automatic controls in order to turn off air-conditioning or heating units,
lower the lighting levels and control water pumps. Figure 1 shows the overview of DR systems.
Figure 1: Overview of Demand Response System [15]
All of these activities utilize a number of computerized technologies, such as the Internet, Local
Area Networks (LANs), Wireless Sensor Networks (WSNs) and Wi-Fi, and also different kinds
of devices, such as EMCS, smart meters and sensor devices, to manage and control energy usage
in an efficient manner.
2.2.
Information transmitted in Demand Response Systems
The primary focus on Demand Response is to provide electricity consumers with dynamic or
time-based price information or other types of incentive information so that the consumer end-use
electric loads can be shifted or shed in response to the information received in reliable and
economic manners. DR could be implemented in different ways depending on the types of price
information. For example, the Real-Time Pricing (RTP) requires computer-based response, while
the fixed time-of-use pricing may be manually handled by the customer. This section provides
details of major types of information that could be transmitted in DR systems.
15
2.2.1.
Price-Based Information
The pricing signal consists of Real-Time Pricing (RTP), Critical-Peak Pricing (CPP), and Timeof-Use pricing (ToU).
Real-time price is the electricity prices that fluctuate during different time periods over the course
of the day. This dynamic pricing allows customers (industrial, commercial and residential) to
shift or shed electricity usage in order to minimize electricity and operating costs for their
business. This price signal will show the current price for power and an automation system, such
as smart clients or meters, will determine what actions need to be taken based on the pricing
signal it received.
Critical-peak price is a dynamic electricity price which is usually increased, probably three to ten
times as much as a standard rate, during periods of high energy use, called CPP events. This
information allows electricity consumers to reduce electricity usage during the on-peak hours or
shift usage to off-peak hours.
Time-of-use price is the electricity prices that are not real-time. This pricing information is
defined ahead of time, usually for 24 hour day, and fixed in the certain time periods based on
seasons. For example, weekday afternoon in the summer the price is usually on-peak (higher than
a standard rate) and weekend night during the winter the price is usually off-peak (lower than a
standard rate).
2.2.2.
Event-Based Information
DR strategies are pre-programmed in Energy Management Control System (EMCS) at the
customers’ sites. The strategies are carried out when the DR events and pricing signals arrives.
16
The main purpose of the DR strategies is to control the electric loads at the end users according to
the electric demands in return for decreasing electric usage at end points and providing reliability
to the grid.
2.2.3.
Bidding Information
DR supports several bidding-based programs, such as Capacity Bidding Program (CBP) and
Demand Bidding Program (DBP), which are offered through a utility, such as PG&E. Customers,
who participate in these bidding programs, can submit a bid for load reduction for a purposed
level of curtailment or against the energy generation resource. In return, the customer will get
incentive payment, if the bid is cleared and he reduces the energy consumption according to the
bid. The details of how each bidding program like CBP or DBP works are not in the scope of this
document.
2.3.
Major Components in Demand Response systems
DR systems consist of several infrastructure and networking technologies in order to carry DRrelated signals from utility to homes. This section gives a brief overview of those components and
describes why they are necessary for DR systems. We first look into AMI, which is a major part
in DR systems. HAN and NAN is explained in the context of DR, including Zigbee, which is a
communication standard used in HAN and NAN.
2.3.1.
Advanced Metering Infrastructure and Demand Response Systems
Advanced Metering refers to “Advanced metering is a metering system that records customer
consumption [and possibly other parameters] hourly or more frequently and that provides for
daily or more frequent transmittal of measurements over a communication network to a central
17
collection point [3].” Advanced Metering Infrastructure (AMI) is composed of advanced devices
at the customer site, such as electricity meters, gas meters, and water meters, communication
networks between the customer and utilities, and data reception and management systems, such
as meter data management. AMI allows utilities to balance demand and supply for electricity and
be able to monitor and control electricity loads which allow the grids to be run more reliably and
efficiently.
The basic functions of AMI involve reading and recording electric consumption of the customer
based on pre-defined schedules, including short-term intervals and/or on-demand, and then
storing and forwarding that usage information through the communication networks, which may
either be wireless communication, such as Radio Frequency (RF) or wired communication, such
as power line communication or broadband over power line (BPL) or perhaps the combination of
the two.
AMI is significant as a DR enabling technology because of the ability to provide usage data based
on hourly intervals, which is needed for time-based pricing information. The time-based pricing
information, such as Real-Time Pricing (RTP), enables the ability to reduce and shift electric
loads dynamically over certain period.
The AMI networks allow utilities to collect and distribute usage and other related information to
customers, suppliers and other service providers. By providing information to customers, the
system assists a change in energy usage in response to time-based pricing signals or incentives
information which bring about reliability of the grid. The overview picture of AMI and DR are
shown in Figure 2 below.
18
Figure 2: Advanced Metering Infrastructure and Demand Response [16]
AMI systems are viewed as consisting of the following components:

Smart Meter – The smart meter is the source of metrological data as well as other
energy-related information. These smart meters can provide interval data for customer
loads as well as distributed generation.

Customer Gateway – The customer gateway acts as an interface between the AMI
network and customer systems and appliances within the customer facilities, such as a
Home Area Network (HAN) or Building Management System (BMS). It may or may
not co-locate with the smart meter.

AMI Communications Network – This network provides a path for information to
flow from the meter to the AMI head end.
19

AMI Head End – This system manages the information exchanges between external
systems, such as the Meter Data Management (MDM) system and the AMI network.
2.3.2.
Home Area Networks, Neighborhood Area Networks and Demand Response Systems
Smart Grid provides two-way communications between homeowners’ premises and utility
companies’ back-end IT infrastructure. This is done by deploying Advanced Metering
Infrastructure (AMI) systems that combine Home Area Networks (HANs) and Neighborhood
Area Networks (NANs). A HAN typically connects home devices together whereas a NAN
connects HAN Gateways for the Utility Network.
Home Area Networks connect thermostats, load switches, lightening devices and other smart
home devices in homes or buildings. All these smart devices connected to HAN can be set to
operate during low cost energy periods. The introduction of HAN along with advanced wireless
home networking has enabled use of home monitoring devices and home automation. Zigbee
wireless communication can be used in home automation for controlling demand response events.
Figure 3 demonstrates high-level view of Zigbee-based HAN which facilitates DR signals from/to
the utility’s AMI network.
The key enabling technology for energy management products in the home are protocols such as
Zigbee and Z-Wave, ultra low-power IEEE 802.15.4-based wireless networking standard that has
emerged as the key to robust, reliable and secure HAN deployments. Although there are several
other potential HAN Protocols, Zigbee is the only one being discussed in detail in this report,
since it is the most popular open standard for HANs.
20
Figure 3: Zigbee-based HAN Enabling Demand Response from Utility AMI Network [17]
2.3.3.
Overview of Zigbee Communication Standard
Zigbee is a low-power wireless networking standard which is built on top of IEEE 802.15.4
standard. It is designed specifically for wireless control and monitoring network and can be used
to implement HAN devices and appliances in order to provide automation system in the home.
Zigbee enables devices to self assemble into wireless mesh network – from smart meters to
devices in home.
2.3.4.
Use of Zigbee in HAN for Demand Response Systems
The use of Zigbee in HAN enables electric consumer and utilities manage energy consumption
effectively. For example, during the period of peak electrical demand, AMI system and HAN
would work together and shed the load based on the price signal or DR events received by the
utility in order to manage the high-load devices, such as changing the thermostat setting of the
HVAC system in participating homes.
21
As shown in Figure 3, the electric meter serves as the gateway, called Energy Service Portal
(ESP), between Zigbee-based HAN and Neighborhood Area Network (NAN) or the utility. The
ESP communicates with a variety of Zigbee-based devices, including Programmable
Communicating Thermostat (PCT), In-home display, Energy Management Consoles, etc. The
devices in HAN can receive pricing signals from the AMI network. Load control events which
are typically created by the utility can be displayed in the in-home display and allow the utility to
schedule turning off high-load applications, such as air conditioners and pool pumps, of the
homeowners to manage energy and provide the reliability of the grid. Homeowners still can
choose to opt-in or opt-out the events received based on the energy price during the peak demand.
After the utility sends DR events to the ESP, the events will be forwarded to the devices which
are responsible for the signals. For example, load control device, which is responsible for
shedding or shifting electric loads in the house, will receive the load control events and re-act
based on the received events.
2.3.5.
Demand Response Networks
Before we look at DR networks, let us introduce a high-level view of the Smart Grid network
architecture. (See Figure 4)
22
Figure 4: High-level View of Smart Grid Network Architecture [18]
The Utility Control Center is connected with the generator and distribution substation through
Wide Area Network (WAN). The AMI consists of different kinds of networks, such as NAN and
HAN. The utility network is connected to homes, buildings and industries via NAN. Inside
homes, Local Area Network (LAN), such as HAN, can be used to connect smart meters and other
smart devices together. A smart meter serves as a gateway for communication between HAN and
NAN or the utility. In the context of DR, we focus on the networks inside the AMI network,
particularly NAN and HAN, where sensor networks can be applied. The detail of sensor networks
will be discussed later in Chapter 3.
Diverse communication protocols could be utilized in DR systems. For example, Zigbee and WiFi can be used for wireless communications between s smart devices or smart sensors in HAN or
a customer’s site. WiMax can be used for wireless data transmission in WAN. However, these
23
protocols have strength and weakness, which should be considered. Table 1 and 2 below shows
areas of application, strengths and weaknesses of communication protocols used in WAN and
Local Area Network (LAN) and could be used in DR systems respectively. These tables are
derived from Consumer Portal Telecommunications Assessment and Specification [19]. Even
though, there are a number of technologies that could be used in DR systems, only Zigbee will be
discussed in details with respect to security later in Chapter 3.
Table 1: List of WAN Technologies with its Application, Strengths and Weaknesses
WAN Technologies
Areas of Application
Strengths
ADSL (Asymmetric
Wide-area access
Digital Subscriber
between utility and
most of the
bandwidth with
Line)
customers’ sites
areas through
distance
- Available to
Weaknesses
- Decreasing
telephone lines
- Consistent
bandwidth
Cable Modem
Access between utility
and customers’ sites
- Available to
most households
- High bandwidth
- Inconsistent
bandwidth
depending on
number of users
and time of day
24
WAN Technologies
Areas of Application
Strengths
WiMAX (IEEE
Connection between
802.16)
customers’ portals and
costly
deployment of
utility
deployment of
WiMAX is in
wired
the beginning
infrastructure
phase which is
- Does not require
Weaknesses
- Market
uncertain if it
will meet the
range targets
BPL (Broadband
over Power Line)
Two kinds of BPL
- Access between
utility and
customers’ sites
(Access BPL)
- Access within
- Existing wired
- Not suitable for
infrastructure
every
available to
applications
nearly every
depending on
home
current existing
on power line3
customers’ sites
(In-home or Inbuilding BPL)
3
For example, in the case of power lost, data transmitted could be lost as well. This concern applies to
many distributed communications systems. However, it is possible to be implemented in Automatic Meter
Reading (AMR) and DR because the customers’ portal could buffer the data until the power restored [19]
25
Table 2: List of LAN Technologies with its Application, Strengths and Weaknesses
LAN Technologies
Areas of Application
Wired Ethernet
Providing connection
(IEEE 802.3)
for devices at
Strengths
- Low cost
- Hugh market
Weaknesses
- Only for LAN
technologies
customers’ sites to a
WAN and other
networks
WiFi (IEEE 802.11x)
Connection of devices
- High
Availability
- Easy to deploy
- Additional
within a customer’s
security
site
mechanisms
required
Zigbee (IEEE
Connection of sensors
802.15.4)
and other devices in
HAN
- Low power
requirement
- Design for use
- Limited range
- Relatively low
data rate, but it
User interfaces at
in Industrial and
would be
customer sites
home
sufficient for the
automation
devices used in
Meter reading
- Scalable
HAN.
(Allowing many
devices to share
a network)
2.3.6.
Open Automated Demand Response
Open Automated Demand Response (OpenADR) is “a set of standard, continuous, open
communication signals and systems provided over the Internet to allow facilities to automate their
demand and response with no human in the loop [4].” Internet-based electricity pricing and DR
signals are used with pre-programmed control strategies to optimize energy use of a site or
26
building with no manual intervention. OpenADR is used to exchange information between a
utility or Independent System Operator (ISO) and the end-point users or customer systems.
OpenADR architecture depicted in Figure 5 consists of a Demand Response Automation Server
(DRAS) and a DRAS Client. A server provides signals corresponding to DR events to notify
customers and a client at the customer’s site listens to the signals and automates signals to preprogrammed control systems.
Figure 5: Generic OpenADR Interface Architecture [4]
Information flow in the OpenADR architecture is in five steps, as follows:
1.
The utility or ISO defines DR event and price signals that are sent to DRAS.
2.
DR event and price services published on a DRAS.
27
3.
DRAS clients, that can be a client and logic with integrated relay (CLIR) for a legacy
control system or web service software for a sophisticated control system, request
event information from the DRAS every minute.
4.
Pre-programmed DR strategies determine action based on event and price.
5.
EMCS carries out load shed based on DR events and strategies.
The DRAS is an infrastructure component in Automated Demand Response programs which are
based on a client-server infrastructure. The automation server distributes and receives information
among its entities, such as utilities and ISOs. The purpose of the DRAS is to automate dynamic
pricing and reliable related messages and information received from utilities or ISOs to optimize
the consumption of electricity during peak hours. The DRAS is an integrator between a
Utility/ISO and DR participants. The major roles of DRAS are to notify the participants regarding
real-time prices (RTP), DR events and DR related messages including dynamic pricing. Figure 6
below shows details of DRAS and its interface to utility and participant sites including the
internet interface.
The DRAS interface could be given through Web Service Description Language (WSDL) and
eXtensible mark-up language (XML) schema could be used for data models and entities. The
DRAS interface functions are divided into three groups as follows:

Utility and ISO Operator Interfaces

Participant Operator interfaces

DRAS Client Interfaces
28
Figure 6: DRAS Client Interfaces [5]
2.4.
Conclusion
This chapter provided an overview of how DR systems work and how information is transmitted
in the systems through various communication networks to EMCS at customers’ sites in order to
shed or shift electric loads. Time-based pricing information, DR events information and bidding
information were described briefly to see how electric loads can be decreased or increased based
on this information. Major components, such as AMI, NAN, HAN were described in the context
of DR. The Zigbee communication standard was explained along with HAN so as to see how
home automation can carry out load reduction. The strengths and weaknesses of communication
protocols along with the usage are briefly described. Finally, an open standard for automated
demand response, OpenADR architecture, and how it works were explained in this chapter.
29
Chapter 3
SECURITY ISSUES IN DEMAND AND RESPONSE
Demand response is a way to manage electricity consumption in response to supply conditions.
The primary function of the Demand Response (DR) is to provide the customers with price
information so that customers or energy-management and control system (EMCS) at the
customer’s sites can respond based on the demands for electricity and electricity prices
appropriately. The price information could be real-time based, tariff-based or some combination.
Since the pricing information could be transmitted electronically or fixed for long period and
could be accessed by the participants of the DR programs, the customer’s security and privacy
should be addressed. Also, the integrity of the pricing signal is critical because if it can be
manipulated, it could lead to financial impacts on the organization or customers. Thus, most of
the DR functions in the smart grid, such as load shedding/reduction, time-of-use (ToU) pricing,
dynamic pricing, etc. require integrity, availability and/or confidentiality to maintain the
reliability of the grid and prevent adversaries to manipulate the information in the system. The
manipulation of DR signals not only affects electric bills but also causes annoyance to customers
and reduces customers’ confidence. Hence, it is crucial to identify potential security concerns,
threats and vulnerabilities and provide defense mechanisms to protect against those issues. This
chapter is to identify those potential security issues based on the DR technologies addressed in
the previous chapter and the best practices for handling security goals for the issues identified in
this chapter will be discussed in Chapter 4.
30
Security issues are explained below by first looking at the security requirements relevant to DR
systems. Next, the information transferred in DR is adressed with respect to security. DR
networks and security issues are discussed, including security issues in Wireless Sensor Networks
(WSNs), Zigbee. Finally, security issues related to OpenADR and DR at residential sites are
specified.
3.1.
3.1.1.
Security Requirements and Demand Response Systems
Confidentiality
The information sent between each entity, such as control usage of the meter, pricing and
metering usage and billing information, needs to be confidential and protected from unauthorized
access to the information, such as eavesdropping attacks, since it can lead to the invasion of
customer privacy and the leaking of the information to an adversary.
3.1.2.
Authentication
The components in DR system, such as HAN-based devices, Energy Management and Control
Systems (EMCS), DR services provider and metering, must be authenticated in order to
communicate with each other. If they fail to authenticate with the DR control services, they must
not be able to connect or respond to the DR event signals in order to protect from an unauthorized
device to communicate with the DR systems, such as hijacking of the meter connection.
3.1.3.
Data Integrity
Unauthorized manipulation of DR information, control signals for the EMCS to manage devices
and control usage of the meter or smart meter by inducing an inappropriate response, such as
turning on/off electrical devices at customers’ sites or shutting down DR operation, could directly
31
decrease power reliability and efficiency of the grid and cause financial impacts as well as
annoyance on customers. Also, manipulating the pricing signal could adversely impacts the
customer and market sections financially.
3.1.4.
Availability
Pricing and electricity usage information need to be confidential, accurate and available all the
time; otherwise, it would affect DR control behavior since the grid may not be able to response
based on the signals and take a wrong action, leading to financial impacts on customers and
markets. Real-time load use information transmitted between DR services provider and customer
EMS needs to be available in the timely manner since it can affect the behavior of the grid.
Legacy devices at end user and low bandwidth of communication channels may result in the loss
of availability.
3.1.5.
Accountability
Failure to hold account of the actions taken by communicating parties because of the invalid
meter, EMS, or DR services provider information would result in the dispute between parties and
decrease customer confidence.
3.2.
Security Issues in Pricing Signals
The pricing signal consists of dynamic/real-time and fixed-time pricing. Real-time pricing
requires computer-based response, while the fixed time-of-use pricing may be either manually
handled by the customer or automatically handled by the smart device based upon the time
periods and the prices.
32
Since the real-time pricing information could be daily transmitted via the Internet, it has more
security concerns than that of the fixed pricing. The integrity of the price information is of the
most concern. The real-time price could be modified by an attacker in such a way that it affects
the organization or customers financially. The modification of the price signals could affect the
reliability of the grid. For example, if an attacker modifies the actual price information to be
lower than the normal price, the building automation system may shift the electric loads and the
blackouts may occur. The automation system at customers’ point must be able to authenticate that
the price signals it received is actually come from the utility and not modified by an unauthorized
entity. Moreover, confidentiality should be an issue. Eavesdropping on this information,
especially the response information that customers make according to the power price, could
reveal the electrical usage patterns and invade the privacy of the customer. The customer also
may deny receiving price signal or refuse to hold for his action in the response to the price signal.
Thus, mechanism for providing non-repudiation needs to be identified. Also, when it comes to
real-time based services, the availability of the price information in timely manner could be issue
as well.
The fixed time-of-use pricing is less concerned about the confidentiality and integrity of
information, since the information is fixed for a certain period of time and is not regularly sent
electronically. Thus, the meter reading and the accuracy of data should be only two concerns for
ToU pricing.
3.3.
Security Issues in Demand Response Events Information
If DR events information is manipulated by an attacker by controlling the electricity usage, such
as turning on/off the air condition or heating units at end users, this could affect both the utility
33
and participants in DR program financially. Moreover, if an attacker turns on all air conditioning
or heating units in a large commercial area, the excessive loads in the grid could occur, leading to
blackouts and large financial impacts. In some case, the manipulation of DR events may affect
health and safety of customers. For example, an attacker may turn on heating units during an
extremely hot day in the summer. This type of attacks can be carried out by Man-in-the-middle
(MITM) attacks.
An attacker may attempt to prevent EMCS at customers’ sites from receiving the DR event
signals from the utility gateway so that the EMCS cannot shed or shift electric loads. This type of
attacks can be carried out by Denial of Service attacks.
The DR events information must be protected from any kind of unauthorized modification and
the clients or EMCS must be able to authenticate that the DR signals are come from the legitimate
source.
3.4.
Security Issues in Bidding Information
The bidding process begins with the request for a bid from electricity generator, which could be
sent in the form of an email, SMS, or by webpage. The customer submits request a bid to the
generator. If the bid is accepted, the notification message will be sent to the customer via email,
SMS or webpage.
However, an attacker can also make a request for a bid or send notification messages by spoofing
emails or SMS messages to the customer himself. Also, an attacker could manipulate the load
reduction per time block information sent by the customer, causing false behavior of bidding
program and financial impacts on bidding participants. For example, an attack pretends to be a
34
customer and issues bidding message instead. Eavesdropping on the load reduction per time block
information sent by customers could disclose the energy usage of the customer as well.
3.5.
Security Issues in Demand Response Networks
DR systems largely depend on wireless sensor networks which can be used in HAN and NAN to
carry out load reduction and DR events. The details of how DR and HAN operate in are already
discussed in the previous chapter. This section is to give overview of sensors and sensors network
from a small unit like sensors to a collection of sensors and advanced sensors like building
gateway nodes. It also analyzes security concerns in DR sensors networks in the context of DR.
3.5.1.
Demand Response Sensor Networks
The DR sensor network consists of the followings:

Sensor clusters or sensor network is a collection of sensors and actuators at either a
residence, commercial or industrial building that has the ability to monitor and respond
to physical or natural conditions. The communication of each sensor node is based on
wireless communications and can be used to receive DR and price signals and send
relevant information, such as energy usage or sensor status. However, it has a limited
set of computational tasks, including local data aggregation and encoding.

Cluster gateway or sink node acts as a proxy for each sensor cluster to link with other
clusters. For example, a small area may have a cluster gateway node to connect with
another gateway node.

Building gate way node for home or building control subsystem. A building may
consists of one or more building gateway node act as sensors and enterprise
35
monitoring & control subsystems. The building gateway node can connect with
scalable LAN/WAN includes:
o
Wired network such as DSL, Cable, Leased line or Passive Optical Networks
(PONs)
o
Wireless network such as cellular network (2, 2.5, 3, 4G) operating in licensed
frequency bands IEEE 802.11x networks as well as Mesh networks.
The sensor data gathered by each sensor node is sent through a sink either to local sensor node or
actuators or to gateway connected to other networks, such as the Internet or Wi-Fi. Figure 7
demonstrates typical view of wireless sensor networks.
Figure 7: Typical Wireless Sensor Networks [20]
3.5.2.
Security Concerns in Demand Response Wireless Sensor Networks
Sensors have the capabilities of observing information, such as temperature, lighting and
humidity and forwarding a response based on the information received to EMCS. For example, in
the area that has comfort temperature, air conditioning units may be turned down. Pricing signals
can be specified based on sensor data a utility receives as well. However, an attacker may inject
some sensor data or disrupt sensor reading which can cause false sensor reading and an
36
inappropriate response to EMCS. Also, some malicious command aiming for controlling
electrical devices in homes or buildings, such as turning on heating units during the summer,
could be inserted into the sensor nodes. This can affect billings and/or health concerns of the
customers. The limitation of sensor nodes, such as slow CPUs, short battery life and small
memories, should be a concern as well. Two major types of attacks on sensor networks can be
categorized as follows:

Physical attacks: A sensor node can be physically captured or stolen or destroyed due
to its small size compared to traditional network devices. Sensor nodes may contain
secret information, including cryptographic keys. If an attacker successfully captures a
node, he or she may be able to obtain secret information or re-program and use it for
malicious purposes.

Network/Link Layer attacks: The attacks in this type mostly aim for injection and
deletion of packets. Even though, some countermeasures, such as using timestamps or
including a verifiable authenticator in to the packet (the details of those
countermeasures will be discussed later in Chapter 4), can mitigate the attacks, but an
attacker may try to drain power of sensor nodes instead. This can happen due to the
resource limitations of the devices.
3.6.
Zigbee Security
Zigbee provide two extra security layers which are built on top of IEEE 802.15.4 standard, where
the security features are provided. The layers are network and application security layers. Figure
8 below shows the Zigbee security layers.
37
Figure 8: Zigbee Layer Model [21]
Zigbee is based on 128-bit Advance Encryption Standard (AES) algorithm and the Counter Mode
with Cipher Block Chaining Message Authentication Code protocol (CCMP). The 128-bit key,
which is recommended by NIST [23], is considered relatively strong for AES algorithm. Zigbee
supports security services, such as access control and frame integrity in order to provide
authorization and data integrity. Also, it defends against replay attacks by comparing the
sequential freshness value with the last known value and rejecting the data frame that has been
replayed (or has the freshness value that has not been updated). Zigbee offers defend mechanisms
as follows [23]:

Freshness: Zigbee devices maintain counters for incoming and outgoing packets. This
freshness counter can be used to protect against replay attacks.

Message Integrity: Message Integrity Check (MIC) can be used to protect against
modification of the message in transit. Zigbee offers 0, 32, 64 or 128 bits for MIC with
the tradeoff in message overhead.

Authentication: Zigbee is based on symmetric schemes, and hence the authentication is
achieved because only the sender and receiver know the shared key. Only the same
38
shared key can encrypt and decrypt messages successfully. A network key, which is
shared among all the nodes in the network, is used to provide network level
authentication. A link key, which is shared between a pair of devices, is user to
provide device level authentication.

Encryption: Zigbee is based on 128-bit AES encryption. The encryption messages can
be done by using a network key for broadcasting messages to the network, or using a
link key for sending messages between a pair of devices.
Zigbee uses the concept of Trust Center, which allows devices to join a network and distribute
keys (see Figure 9). A Zigbee coordinator serves as a Trust Center which is mainly responsible
for authenticating the new device that request for joining the network and distributing and
maintaining network keys. The cryptographic keys in Zigbee can be categorized into three groups
as follows:

Master Key is a long-term key used to establish symmetric keys (Link keys) between
two Zigbee-enabled devices. The master keys are pre-installed in the devices by
manufacturers in each device or are sent over-the-air to the devices.

Link Key is unique session key between each pair of devices. The link keys are used to
encrypt and decrypt information transmitted between two devices in the HAN. Link
keys are managed by the application layer.

Network Key is a unique 128-bit key which is shared among all the nodes in the
network. The network keys can be regenerated by the trust center or coordinator at
different period of intervals. The network key is used by each node in order to join the
network and can be used for broadcast communication in the network. When the trust
39
center changes the network key, the old network is used to encrypt the new one and it
is distributed throughout the network.
Each pair of node can have both link key and network key. Link and network keys can be updated
periodically. Figure 9 below shows the overview of Zigbee network and the use of Zigbee
cryptographic keys.
Figure 9: Typical Zigbee Network [24]
3.7.
Security Concerns in Zigbee
This section discusses some of the potential security issues in Zigbee standards
3.7.1.
Key Establishment and Distribution
The most concern in the Zigbee-based HAN network is the process of setting up a new device in
the network and how the keys are established at both sides of the devices. When the new device is
newly connected to the Zigbee network, the key must be established between the new device and
its pair node. The key distribution for each pair of nodes in Zigbee standard can be done by three
methods as follows:
40

Provisioning or Commissioning is to use out-of-bound mechanism, such as preinstallation key or over-the-air key, to place the key into devices. The pre-install
methods are not optimal because of the limitation of the ability to write the key in flash
memory of the devices when the key needs to be changed or re-established. Also, the
key is sent over-the-air in plaintext, which is susceptible to one-time eavesdropping
attack. One way to help this issue is to ensure that devices are in close proximity.

Key Transport is to have trust center distribute the keys to the devices. This method
requires sending the key itself to the devices. The transportation of the key relies on
the satisfactory security practice of the vendors. An attacker may be able to intercept
the key, if the security mechanism for transporting the key is not secure enough to
protect the key.

Key Agreement is to have trust center and devices negotiate the keys without transport
the key itself. According to R. Cragie [25], Key Agreement is the most secure method
for key establishment between devices in the network. The key agreement is based on
Symmetric Key Key Establishment (SKKE) which uses the master keys for
distributing the shared secret key. However, the master key itself has the issue of the
key distribution as well, since it has to be pre-installed or sent over-the-air.
3.7.2.
Insufficient Integrity Protection
Zigbee supports eight security suites as shown in Figure 10 below.
41
Figure 10: Security Suites Supported by IEEE 802.15.4 [26]
The specification requires that the implantation must support at least AES-CCM-64 and Null
modes. The others are optional. The table shows that AES-CTR mode uses counter-mode
encryption without a MAC. Consequently, it is possible that the encryption is applied, but no
integrity protection on a frame, which could lead an adversary to forge or modify a message
transmitted in the network. Also, AES-CTR mode is vulnerable to DoS attacks. This is because
there is no integrity protection mechanism in this mode. It is recommended that AES-CTR mode
should never be used [26].
3.7.3.
Nonce Management Problem [27]
In Zigbee, the security suites and keying information are stored in an Access Control List (ACL).
Zigbee supports up to 255 ACLs. Each ACL entry contains at least the following security
information: destination address, security suite, and security material. The security material
consists of at least a cryptographic key for the security suite and the nonce state. A Nonce state
consists of Initialized Vector (IV) and frame counter. The nonce state serves as an identifier for
each packet and has to be preserved across different packet since it is used to protect against
replay attacks. However, only the frame counter is variable; thus, the nonce state is derived from
the frame counter.
42
When the sender sends a message, he or she chooses the appropriate ACL entry based on the
destination address. However, the same key may be used in two or more different ACL entries.
The problem arises if the sender happens to re-use a nonce because two or more different
messages are encrypted using same key and same nonce and since Zigbee supports AES-CCM
mode which is based on a stream cipher encryption, it is possible that an attacker can discover the
XOR of the plaintexts by computing the two ciphertexts using XOR [26]. This can be taken place
because the nonce is initialized or updated independently.
Another scenarios is when a power failure occurs causing the lost of ACL states. It is not clear if
when the power is back-up, nonce states will be reset to known value or not. If so, a nonce will be
reused in the same ACL without key being updated [26].
3.7.4.
Key Management Problem
Zigbee does not support group keying since each ACL entry can only be associated with a single
destination address. The problem arises because there is no simple way to implement group
keying using Zigbee [26]. This may end up having application developers using multiple ACL
entries sharing the same key and the possibility that reusing the same nonce with the same key
becomes large. As discussed earlier, having two or more messages encrypted with the same key
and nonce could compromise security.
43
The list below summarizes Zigbee security concerns and impacts on security requirements.
Table 3: Comprehensive Security Concerns in Zigbee
Zigbee Security Concerns
Impacts Level
Key establishment problem
- Key provisioning sends over-the-air
- Key transports rely on vendors to implement security
mechanism
- Key agreement is the most secure for key distribution, but has
Confidentiality (H)
Integrity (H)
an issue of a master key could be sent over-the-air in
plaintext
Lack of message integrity protection in AES-CTR mode
Message Integrity (H)
Confidentiality (M)
3.8.
Denial of services attacks on AES-CTR
Availability (H)
Allow the use of same key in different ACL entries
Confidentiality (M)
Reuse of nonce occurs in the case of power failure
Confidentiality (M)
Securities Issues in Open Automated Demand Response
Since the OpenADR system is based on the Internet communication, the information transmitted
in each DRAS interface must be protected and prevented from any kinds of data manipulation,
such as changing pricing information and DR events. The DRAS and DRAS clients need to be
authenticated in order to communicate with each other. Also, access control to each entity in the
OpenADR system is needed in order to protect from unauthorized access to the system. If the
security goals are breached, potentially adverse impacts could occur, such as the excessive loads
in the grid leading to blackouts and the large financial impacts on both the utility and participants
in DR program. This section focuses on the security concerns on the information transmitted
44
between the interfaces between utility/ISO, DRAS and DRAS client. Table 4, 5 and 6 describes
the purposes and types of information transmitted in OpenADR, possible attacks and impacts that
could happen if each security goal is compromised. The information transmitted in the OpenADR
is categorized into three groups based on the DRAS interfaces, Utility/ISO interfaces, DRAS
client interfaces and Participant interfaces (See Figure 6).
Table 4: Possible Attacks and Impacts of Utility/ISO Operator Interfaces
Utility/ISO Operator Interfaces
Purpose
Information Transmitted
To initiate,
Program type, date & time
publish or
of the event, date & time
update DR
issued, geographic
event
location, customer list
information in
(account numbers) and
DRAS
load shed event
information.
Possible Attacks and Impacts
Confidentiality (L):
Eavesdropping on this formation is not of
concern since the information may not be
sent regularly. The information needs to
be protected from unauthorized access.
Integrity (H):
Attacker modifies configuration data in
the DRAS, such as DR program data,
customer list and shed event information,
affecting the DR program behavior.
Attacker issues false or malicious DR
events in DRAS, causing blackouts and
instability of the grid. Also, this may lead
to the financial impacts on customers.
Availability (L):
Failure in communication between utility
and DRAS
45
Utility/ISO Operator Interfaces
Purpose
Information Transmitted
To initiate bid
Program type, date & time
request in
of the event, date & time
DRAS
issued, geographic
location, customer list
Possible Attacks and Impacts
Confidentiality (H):
Eavesdropping on this formation could
result in the leaking of bidding and also
pricing information to the attacker.
(account numbers), request
for a bid (RFB) issue date
Integrity (H):
& time, RFB close time,
Unauthorized manipulation on this
price offered for load
information could affect the bidding
reduction per time block.
program behavior.
Attacker issues false bidding information,
causing the false behavior of the bidding
program and the financial impacts on
customer.
Availability (L):
Failure in communication between utility
and DRAS.
46
Utility/ISO Operator Interfaces
Purpose
Information Transmitted
To set accepted
Participant list (account
bids in DRAS
numbers), accept or reject,
load reduction bids per
time block (for
Possible Attacks and Impacts
Confidentiality (H):
Eavesdropping on this formation could
lead to the invasion of participant’s
privacy.
verification)
Integrity (H):
Attacker modifies participant list or load
reduction per time block, accepted or
rejected bid, causing instability of the grid
and having financial impacts on
participants.
Attacker issues accepted/rejected bids to
DRAS clients which may make an
inappropriate response, such as increase
the loads, according to the false accepted
or rejected bids received.
Availability (L):
Failure in communication between utility
and DRAS
47
Table 5: Possible Attacks and Impacts of DRAS Client Interfaces
DRAS Client Interfaces
Purpose
Information transmitted
To send shed or
Utility event information
event
for smart DRAS clients,
information to
such as date & time of the
trigger the
event, date & time issued
event client to
mode and pending signals.
shed or shift
loads at
Mode and pending signals
for simple clients.
participant
sites, facilities
or aggregator
sites
Possible Attacks and Impacts
Confidentiality (H):
Attacker intercepts information sent
between DRAS and DRAS client to gain
knowledge of DR events, pricing
information, customer information.
Loss of confidentiality on this information
can lead to the exposure of customer data,
Event pending signals for
unauthorized modification of information,
simple clients.
manipulation of information, malicious
attacks, etc. causing the instability of grid
and financial impacts on customers.
Integrity (H):
Attacker issues false/malicious DR
events.
Attacker may be able to turn on air
conditioning or heater units in a large
commercial building which can cause
excessive loads to the gird and blackouts
may take place, resulting in the instability
of the grid and financial impacts on
customers.
Attacker may be able to shut down all air
conditioning units which can cause
annoyance and health concerns to some
48
DRAS Client Interfaces
Purpose
Information transmitted
Possible Attacks and Impacts
customers.
Attacker issues false time
synchronization, causing events to occur
sooner or later than they normally would
have.
The signals need to be authenticated that
they actually came from the DRAS.
Inability to authenticate DRAS, DRAS
client and UIS can lead to a number of
attacks, such as authentication sniffing,
denial of service (DoS), man-in-themiddle attack, etc.
Attacker captures an authentic signal,
prevents the required reduction in load
forcing utilities to take other measures
such as buying energy at higher costs, and
blackouts could occur.
Availability (H):
Attacker prevents the reduction of the
load by disabling DRAS clients from
receiving the incoming DR signals using
denial of service attacks.
Attacker floods the DRAS
communications channel with non-DR
related Internet traffic.
49
DRAS Client Interfaces
Purpose
Information transmitted
Possible Attacks and Impacts
Failure in communication between DRAS
and DRAS clients.
Accountability (M):
Participant denies receiving DR events.
Participant denies receiving bidding
information.
To send request
This information comes in
for bid to
the form of an email,
participant or
phone call or page.
facility
Integrity (L):
An adversary may manually send an
email, make a phone call or submit a page
to the participant or facility manager so
manager or
that the manager may respond to the
aggregator
adversary instead of to DRAS or the
manager may take a wrong action in
response to the bid request.
To notify the
This information comes in
acceptance or
the form of an email,
rejection
phone call or page.
notification to
the participant
or facility
manager or
aggregator
Integrity (L):
An adversary may manually send an
email, make a phone call or submit a page
to the participant or facility manager so
that the manager may respond to the
adversary instead of to DRAS or the
manager may take a wrong action in
response to the notification.
50
Table 6: Possible Attacks and Impacts of Participant Interfaces
Participant Interface
Purpose
Information transmitted
To set, adjust or
Load reduction per time
cancel standing
block (price and load
bids in the
amount)
DRAS.
Possible Attacks and Impacts
Confidentiality (M):
Attacker intercepts load reduction
information sent from participant to the
DRAS in order to gain knowledge of this
information, causing the leak in the
electricity usage of the customer.
Integrity (H):
Attacker submits bids for participants,
causing the financial impacts on
participants.
Availability (L):
Failure in communication between DRAS
and DRAS client.
To send the
Program identifier,
system load
facility or participant
status
identifier, date & time of
information to
the event (shed or shift),
DRAS from
shed data in kW/kWh,
DRAS clients.
load reduction end uses
Unauthorized manipulation on this
(HVAC, lighting, etc.),
information could make DRAS not be
event type (Day-Ahead or
able to record the actual response of the
Day-Of)
DRAS client to the DR events received.
Confidentiality (H):
Eavesdropping on this formation could
invade the customer privacy.
Integrity (H):
The DRAS may make an inappropriate
response to the DR program according to
51
Participant Interface
Purpose
Information transmitted
Possible Attacks and Impacts
the false system load status. This could
lead to the unreliability of the grid.
Availability (L):
Failure in communication between DRAS
and DRAS client.
3.9.
Automated Demand Response at Residential Sites and Security Issues
Demand response events arrive at the residential site from the utility to adjust the electricity price.
During peak hours the price of the electricity rises; through demand response the customers can
adjust their residential temperature on the basis of the demand response event received. During
normal conditions the broadcast messages consisting of price signals are sent to residential
whereas during emergency control signals are issued. The Programmable Communicating
Thermostat (PCT) would be used in order to reduce the electric power at the residential site.
Broadcast messages which will be sent out to the thermostat which causes the thermostat to
update the power consumption. The PCT will be provided to the residential customers by the
IOU’s. The PCT will communicate with the utility through a meter. The connection is done
through a wide area network. The PCT allows the customer to set the temperature for heating as
well as cooling. Security issues such as confidentiality, integrity, availability and, non-repudiation
come into effect for the PCT during the flow of events from the utility to the residential site.
Integrity plays a crucial role in PCT. An attacker can cause annoyance, affect health and safety,
grid instability by carrying out blackout, increase cost for the customer as some form of threats.
The summary of attack patterns in PCT is shown in Figure 11.
52
3.9.1.
Possible Attacks on Programmable Communicating Thermostat

An attacker may attempt to shut down the A/C, prevent the load reduction, and
manipulate the scheduling of events received.

An attacker tries to tamper with the incoming signals or PCT system. The attacker
carries out the attacks by carrying out masquerading and man in the middle attack by
shutting or turning down the A/C units in order to cause the grid instability.

An attacker blocks the incoming broadcast signal by carrying out denial of service
attack. Replay attacks can be carried out in order to manipulate the incoming demand
response signal.

An attacker could manipulate the system by disabling the PCT antenna or changing the
PCT local time.
Figure 11: Path of Attack in PCT [28]
53
3.10. Conclusion
This chapter covered security requirements for DR systems, and a number of security issues in
the context of DR. Information transferred in DR systems, such as price signals including RTP,
ToU and CPP, was discussed with respect to security. DR sensor networks, which can be used in
HAN and NAN, were described in details. The security issues related to the DR sensor networks,
including two major types of attacks – physical and network/link layer attacks – were discussed.
Zigbee protocol is commonly used in HAN for controlling and monitoring network and for
providing certain security in home automation, but there are still issues in Zigbee, which have to
be considered. Potential security concerns in Zigbee, such as key establishment and distribution,
lack of message integrity protection in AES-CTR mode, nonce management problem, etc. were
also discussed in details. OpenADR, which is based on the Internet communication, were
described in security context. Possible attacks and impacts that could happen if security is
compromised on each DRAS interfaces, utility/ISO, DRAS and DRAS client are identified.
Finally, Automated DR at residential sites, which use PCT to reduce the electric power depending
on the control signals received, and possible attacks were discussed as well. The next chapter will
discuss about controls and countermeasures using information security best practices in order to
mitigate those risks.
54
Chapter 4
BEST PRACTICES FOR HANDLING SECURITY ISSUES IN DEMAND RESPONSE
Demand Response systems are expected to be eventually utilized in most residential and
commercial energy consumers. The security and privacy of customer information must be the
highest priority. Proper data handling practices must be carried out in order to protect the security
and privacy of customer information. Cryptographic tools, key management practices and access
control must be used to ensure security goals.
The breach in security goals – confidentiality, integrity, availability, accountability – could
adversely affect large scale of a smart grid system and large number of customers. The impacts
are varied from the reliability of the grid itself to the financial impacts on utilities and customers
as well as the invasion of the privacy of customer information. Consequently, it is important that
security concerns and countermeasures are considered at the early stage.
This chapter proposes security measures to defend against possible attacks based on the security
concerns specified in Chapter 3. It provides best practices for handling security issues related to
the DR and OpenADR. Moreover, some of the technical best practices for ensuring security goals
in the Appendix A, which may not be specific to DR systems and can be used for various IT
systems, are referred throughout this chapter, when it is appropriate. There may be some situation
where the best practices suggested in this chapter may not be used directly since the complexity
of the systems. R&D issues are required to be addressed. The R&D issues will be discussed in the
next chapter.
55
4.1.
Demand Response Sensor Networks and Security Measures
As stated in Chapter 3, wireless sensor networks can be used for locating, monitoring power
usage and physical or natural conditions. The DR signals, including price signals and DR events
signals, can be transmitted via sensor nodes. A number of attacks, such as physical attacks,
unauthorized modification, and denial of service attacks, could be carried out and cause adversely
impacts on the systems.
In order to provide security goals, advanced cryptographic tools must be applied, but complex
computations may shorten the battery life and may be slow due to the limited CPUs and
memories. The limitation in battery life of the sensor nodes exposes another attack that tries to
drain power of sensor nodes by sending a number of messages to them and forcing sensor devices
authenticate and verify those messages which result in battery run out. Thus, the sensor nodes
must not perform much computation on the collected data in order to prolong the battery life
while preserving security goals. Physical attacks to a sensor node could make an attacker obtain
the keying information embedded inside as well.
In this section, we suggest a security measures that can be used to protect against attacks on DR
sensor networks.
4.1.1.
Use of Cryptography
If an adversary can capture one or more packets and analyze traffic, he may inject false messages
or modify the contents. The system must have the ability to prove that a message comes from the
source that it claims and the message has not modified in an unauthorized manner. Many
cryptographic approaches could be used to provide particular security goals.
56
One of them is to use symmetric key (shared key) approaches and separate shared keys for each
pair of nodes. The node can only communicate with its pair because it requires the same key to
encrypt and decrypt the message. Thus, both receiver and sender node can authenticate each other
because they have the same shared key. If one of the nodes is compromised, an attacker cannot
impersonate the other pair nodes since each pair of nodes requires one shared secret key. To
implement this approach, the key has to be distributed ahead of time. Kerberos can be used for
the key management and distribution. Data confidentiality is achieved by encrypting the message
with the shared key. However, this approach may not support non-repudiation properly. It also
has high communication and implementation costs. Moreover, the battery life for this approach
should be of concern since it can be shorter than it is expected to be. This leads to more attractive
approach which can be used for sensor-class nodes.
4.1.2.
Elliptic-Curve Cryptography
Sensor nodes have resource limitations, and hence some of the today’s Internet cryptographic
schemes may not be appropriate due to smaller memory and lower computational CPU. Besides,
the battery life becomes shorter, if the computation is more complex. The emerging of EllipticCurve Cryptography (ECC) help overcome those issues.
ECC offers the same capabilities of cryptographic schemes used in the Internet communications,
such as Digital Signature Algorithm (DSA) and Diffie-Hellman (DH) algorithm, but with the
smaller key size. According to RSA Laboratories [29], Rivest, Shamir & Adleman Public Key
cryptography (RSA) with 1024-bit key provide equivalent security level to ECC with 160-bit key.
However, RSA laboratories recommend using RSA with 2048-bit key which is equivalent to ECC
with 224-bit key to protect data beyond the year 2010 [30]. ECC also offers Elliptic-Curve Digital
57
Signature algorithm (ECDSA) and Elliptic-Curve Diffie-Hellman (ECDH) key exchange which
makes it possible to provide mutual authentication, key exchange and ECC-based digital
signature for Wireless Sensor Networks (WSN).
4.1.3.
Use of Elliptic-Curve Cryptography in Sensor Networks
4.1.3.1. Authentication
Each sensor node must be able to detect that a message comes from an alleged source and the
message has not been modified in an unauthorized manner. Mutual authentication approach can
be used to provide such detection. Each sensor node can have its own public and private key pair.
According to A. S. Wander, N. Gura, H. Eberle, V. Gupta, S. Chang and C. Shantz [31], an
abbreviated X.509 certificate can be imitated by having a unique node identity along with a
public key and a signature. Hence, the ECC-based Secure Socket Layer protocol (SSL) can be
implemented. Also, since ECC is based on Public Key Cryptography, the only phase that affects
when applying ECC to SSL is the handshake phase. Figure 12 demonstrates the exchange of
message between the client and the server during the SSL handshake with mutual authentication
for both RSA-based and the ECC-based SSL. The notations [RSA, ECC] in the figure denote the
size of the message in bytes for each algorithm. The notation C means the client and S means the
server.
58
Figure 12: Simplified Version of ECC-Based SSL Handshake Protocol [31]
The programmatic details of the message exchange during the ECC-based SSL handshake
protocol is not in the scope of this chapter. The steps of the simplified version of ECC-based SSL
handshake involve:

The client sends a 32-byte randomly generated number or data to the server.

The server replies back with the random data received from the first step along with
the server’s certificate. The server’s certificate contains server’s ECDH public key
signed by Certificate Authority (CA) using ECDSA signature. If the client successfully
authenticates the server, the client uses its own ECDH private key and the server
public key to perform an ECDH operation to gain the premaster secret. (Note that for
RSA-based algorithm, the message size is 294 bytes while it is only 118 bytes for
ECC-based algorithm)

The client sends its own certificate to the server. Also, the server performs an ECDH
operation using its own private key and the client public key.
59

The derivation of the master key and session key is unchanged from the RSA-based
SSL handshake.
To implement this approach, a base station, which acts as a control center or Certificate Authority
(CA), is needed for collecting each node’s public key certificate. This mutual authentication
approach can authenticate whenever a new node is set up in a sensor cluster or network. In other
word, the public keys of all the nodes are needed to be authenticated. Thus, if an attacker tries to
set up his own sensor node to intercept the data sent in the sensor networks, he will need to have a
certificate, which is usually protected from an unauthorized access to the data in the certificate
storage. However, this approach requires each node to keep its pair node’s certificates on its
memory; therefore, the size of the certificate should be of concern4. Also, the message
authentication can be achieved by using digital signature. The use of digital signature can
substantially reduce the impacts from Man-in-the-middle (MITM) attacks. The further detail of
ECC Cipher Suits for TLS is specified in RFC 44925.
4.1.3.2. Confidentiality
Once the mutual authentication and key exchange between each pair of nodes are established, the
shared key can be used to communicate with its pair node. If one of the pair nodes is
compromised, the information sent between the other pairs of the node is not revealed since each
pair of nodes have different shared key obtained during the key exchange phase. Also, the shared
key should be re-established periodically in order to reduce the risk of an attacker gaining
4
According to the research on A. S. Wander, N. Gura, H. Eberle, V. Gupta, S. Chang and C. Shantz [30], a
traditional X.509 RSA-1024 certificate is on the order of 700 bytes long, the simplified certificate is only
262 bytes long and an ECC-160 certificate can be reduced from approximately 530 bytes to 86 bytes.
5
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) are available at:
http://tools.ietf.org/html/rfc4492.
60
knowledge of the key. However, this means the sensor node needs to keep its pair node’s shared
key in its memory. This also can be an issue, since the memory size is limited. (Note that,
according to RFC 4492, ECC with 160-bit key requires 282 bytes of data memory)
4.1.3.3. Accountability/Non-repudiation
Accountability can be provided by using the digital signature technique. The details of how to
ensure accountability and the issues of non-repudiation/accountability are discussed in Chapter 5.
4.2.
Zigbee and Security Measures
Zigbee protocol is based on symmetric keys; the communication is secured by using shared key.
However, the shared secret-key scheme has the issues in that if the key is compromised, all
communications between the devices that use the same shared key will be no longer secure. Also,
the key distribution is also expensive since Zigbee uses mesh-networking which means any
device has to store the secret keys of all of its pair nodes in order to have multiple potential paths
to route to their destination. Thus, symmetric algorithms cannot scale to a large system with
hundreds of devices.
Besides, although Zigbee supports security services and provide mechanism to defend against
certain attacks, such as eavesdropping and replay attacks, there is still the framework for
exploiting IEEE 802.15.4 and Zigbee, called KillerBee. KillerBee framework is published by J.
Wright [32], Senior Security Analysis at InGuardian Website in October 2009. It can be used to
analyze Zigbee security; and could be used for Zigbee exploitation as well. KillerBee can be used
for sniffing and injecting packets as well as decoding and manipulating network packets. The
result [32] has shown some successful attacks using KillerBee to obtain the key and carry out
61
replay attacks. If an attacker can inject the false message into the HAN network, the response of
the device to the DR events or pricing information may be false. This can have financial and/or
health-related impacts on homeowners. It also can lead to grid failure. Thus, using Zigbee alone
may not be enough to provide security for Demand Response in HANs.
The solution to these is to consider Elliptic-Curve Cryptography (ECC) as a public key scheme
for Zigbee. ECC offers Elliptic-Curve Diffie-Hellman (ECDH) key exchange which could be
used for the key agreement method. According to NIST Recommendation for Key Management
(Part 1) [33], ECC with 160-bit key provides equivalent encryption as strong as AES algorithm
with 128-bit key. Also, authentication and non-repudiation can be provided by ECC as discussed
in previous section.
4.3.
Demand Response Best Practices
To carry out load shed or load shift in buildings or residential areas, pricing and control signals
have to be sent via the Utility Gateway over a network, such as the Internet. When day-ahead and
near real-time information arrive to an EMCS through the energy meter or gateway, the
electricity demand will be moderated based on the signals received. A Home Area Network
(HAN) will be used to distribute energy management information to all HAN devices in the
building or home. All of the components used in DR programs, such as smart meters, HAN with
DR capabilities, have potential vulnerabilities. Once they are deployed on a network, a number of
attacks could be performed on those components. For example, an attacker may inject a malicious
command into the system, collect personal information of users, or modify message contents.
This section discusses best practices for DR systems in order to provide security for protecting
against potential security issues and vulnerabilities specified in Chapter 3.
62
4.3.1.
Data Transmission
To ensure integrity of the message, mutual authentication should be used between devices in
HAN and NAN. DR and price signals and other information in the DR systems also need to be
encrypted in order to provide data confidentiality. The appropriate communication protocols for
secure communication, such as Transport Layer Security (TLS) protocol, Internet Protocol
Security (IPSec), Wireless Fidelity (Wi-Fi) associated with IEEE 802.11i for a wireless local area
network (WLAN) and IEEE 802.15.4 using Zigbee with elliptic curve cryptography (ECC) for
sensor networks in HAN and NAN, can be used to protect network traffic.
4.3.2.
Data Handling Practices
Information is sometimes sent between utilities and third party contractors, who may perform
some kinds of collection of private data. Reusing and disclosing personal data by either utilities or
third party could affect the privacy of customer information. Therefore, the information must be
controlled in secure manners such that only necessary information of the customer is provided to
any data collection entity and only authorized entities can access and use customer information.
Also, the utility must obtain individual’s permission prior to using personal information or
disclosing private data to a third party. The length of time that a utility may retain customers’
energy usage information must be specified.
4.3.3.
Key Management
Key management mostly depends on the technologies and cryptographic schemes used. For
example, the key management and distribution in Zigbee discussed earlier are relied on an
asymmetric approach and a trust center. In asymmetric approaches, X.509 public key certificate,
63
which will be discussed in the OpenADR best practices later, could be used to prevent the
disclosure of the keys to public. This section provides best practices and recommendations for
key management derived from the NIST SP800-57, Recommendation for Key Management (Part
1) [33], and NISTIR 7628, Guidelines for Smart Grid Cyber Security (vol. 1) [14], and the
document [34] from Cryptography and Key Management Group (CKM) under NIST SGIP
CSWG.
4.3.3.1. Key Usage
Cryptographic keys can be used for different purposes, such as authentication, encryption, digital
signatures, or random number generation. However, if one single key is used for two different
cryptographic processes, it may increase the risk of key compromising. Also, if the key is
compromised, the impacts may across the processes that use the same key. It is recommended
that a single key should be used for only one purpose [33]. The reasons for this are as follows:

Using the same key for different cryptographic purposes may increase the risks of key
compromising.

If the key is compromised, the impact may across the processes that use the same key.
This principle limits the impacts in the case of key compromised.
In some case, using the same key for different purposes may not be appropriate. For example, in
asymmetric schemes, a private key may be used for both transportation of the shared-secret key
and signing of digital signature. In practice, each cryptographic key should have an expiration to
indicate whether the key is still in effect or not. In this case, a private key may be needed to retain
in the system after it is expired for the key transport of the corresponding public key. However,
the same private key for digital signatures should be destroyed after the key period ends to reduce
64
the chance of key compromising. Thus, it is not suitable for this situation to use a single key for
the purposes of key transport and digital signature. It is a best practice to use different key pairs
for encryption and digital signature because the signatures are used for longer-term authentication
and message integrity, but the encryptions are done by using a shorter-term key pair.
4.3.3.2. Key Period
It is important to specify the longevity requirements for a specific key purpose. In asymmetric
schemes, the life span of a public and private key for each key pair may be different. A private
key for signing a digital signature may have the same cryptoperiod as the associated public key. If
the private key is no longer needed, so the public key. On the other hand, the key pair for
encryption and decryption of the message may have different life span. The private key, which is
used for decryption, may need to retain after the public key is destroyed as long as there is a need
to decrypt the messages that have been encrypted with the associated public key.
In the case of symmetric key, a shared secret key is used by both an originator and recipient for
message encryption and computation of a MAC. If the originator usage period, the period of time
during which cryptographic protection may be applied to data [33], is ended, the shared key
should not be used for providing protection. In contrast, the recipient usage period may be
extended for later uses. For instance, the information protected by the originator key has been
kept in a secure storage and may need to be decrypted and be authenticated at a later point in
time.
65
4.3.3.3. Algorithm and Key Length
NIST SP800-57 recommends the cryptographic algorithms and key lengths to be used to obtain
the required security level. The algorithm and key size selection should be conformed the NIST
recommendation. Figure 13 below is the list of appropriate algorithms and key sizes for
protection of data during the given time periods. Note that the value of L is the size of public key,
while N is the size of private key for Finite Field Cryptography (FFC) algorithms, such as Digital
Signature Algorithm (DSA) for digital signatures and Diffie-Hellman (DH) for key agreement.
The value of k is considered as the key size for Integer Factorization Cryptography (IFC)
algorithms, such as RSA. The value of f is considered as the key size for Elliptic-Curve
Cryptography (ECC).
Figure 13: Recommended Algorithms and Minimum Key Sizes [33]
To consider using this table for appropriate key size associated with the algorithm, “if the security
life of the information extends beyond one time period specified in the table into the next time
period (the later time period), the algorithms and key sizes for the later time shall be used [33].”
66
For instance, if information is initially signed in 2009 and needs to remain security for a
maximum of ten years, a 2048-bit RSA key is recommended to be used in this case to provide the
appropriate protection until 2019 since 2019 is in the period of 2011 to 2030. Also, if the
signature is required, it must be generated using a hash algorithm with comparable or greater
strength (with the equivalent or greater bits of security), such as SHA-224 or SHA-256. The lists
of comparable algorithm strengths are shown in Figure 14 below. Note that 2TDEA stands for
two-key Triple Data Encryption Algorithm and 3TDEA stands for three-key Triple Data
Encryption Algorithm. Figure 15 shows the hash size with comparable strength for digital
signatures, HMAC, key derivation function and random number generation.
Figure 14: Comparable Security Strength for the Approved Algorithms [33]
67
Figure 15: Hash Function Security Strengths for Cryptographic Applications [33]
4.3.4.
Key Management Systems
Generally, there are two different approaches for key management systems depending on the
cryptographic schemes used – Public Key Infrastructure (PKI) and Symmetric Key Management.
The key management topic is very broad and complex. Some of the issues, which are still
required for further research, will be discussed later in the R&D chapter. PKI and the use of
X.509 certificates will be discussed later in the best practices for OpenADR. This section
describes about issues and solutions in symmetric key management systems.
4.3.4.1. Symmetric Key Management
Symmetric approaches require all end points in the system to use the same key. Each party
communicates with each other by using a symmetric key, often called a secret key or a shared
key, for both encryption and decryption. In a symmetric cipher system, shared keys usually have
68
a shorter life span compare to public/private key pairs in an asymmetric cipher system and are
typically session based. The reason for this is that using a shared key to transfer data is faster than
using a public/private key pair; hence, it is suitable for processing large amount of data. However,
with a large data sample, the risks of being analyzed and key compromising are increased. Thus,
the keys are needed to be re-established or re-distributed more often. Moreover, there are
challenges in the break-once-run-everywhere issue since all communicating party must share the
identical key. If the key is compromised, all communication using that key will be no longer
secure. Therefore, there are primary concerns in key management for symmetric cryptography
systems including key establishment and distribution, and the protection of the symmetric key.
4.3.4.1.1.
Key Establishment and Distribution
In a symmetric system, a shared key can be generated locally on the end devices or remotely.
However, millions of devices will be eventually deployed in smart grid systems in order to utilize
DR. By having those devices generate the keys themselves; it would be difficult to manage the
generation and distribution of the keys. Also, because of the limitations in devices, such as lowpower processor, memory constraints and slow computation, key generation algorithms may not
be always possible to apply to those devices. Remote key generation would be more appropriate,
but key distribution and trust risks are of concerns. In this remote scenario, the shared key is
generated and distributed externally by a trust Key Distribution Center (KDC). Nonetheless,
before the shared key is distributed to each participating entity, any entity needs to be
authenticated whether it is legitimate. One of the common protocols used for KDC is called
Kerberos Authentication Protocol.
69
Kerberos protocol is a client-server model designed for the purposes of authentication and key
distribution for symmetric cryptography. It allows communicating parties to authenticate their
identity to another in secure manner. In Kerberos, the KDC, which is a trusted third party,
maintains a database of secret key of each entity on the network in such a way that only the
associated entity and the KDC know the shared-secret key. A client needs to be authenticated to
the Authentication Server (AS) using a long-term shared secret, such as password, in order to
receive a Ticket Granting Ticket (TGT) from AS. The ticket is used to prove the identity of the
client to the Application Server (AP), of which the services are provided. The communication
between each entity is secure by using a session key generated by the KDC. The details of the
operations of Kerberos protocol are illustrated in Figure 16 below. Note that each client needs to
have a shared secret key between itself and KDC. We use KA-B to denote the shared secret key
between the machine A and B.
Figure 16: Kerberos Operations [35]
70
The operations and messages are described below

AS_REQ is the request for client authentication to AS (See Appendix A for various
user authentication techniques).

AS_REP is the reply message from AS. It contains TGT and the session key. TGT is
encrypted using the secret key of the TGS. The session key is encrypted using the
shared secret key between the client and KDC (KC-KDC). Once the client receives the
AS_REP message, it decrypts the session key using KC-KDC. Assume the session key
obtained from the AS is denoted by KC-AS.

TGS_REQ is the request for a service ticket to the Ticket Granting Server (TGS). This
message contains the TGT from the previous message and an authenticator generated
by the client. The authenticator is encrypted using the session key (KC-AS) obtained
from the previous message.

TGS_REP is the reply from the TGS. The message includes the requested service
ticket and a service session key. The requested service ticket is encrypted with the
secret key of the service. The service session key is generated by the TGS and is
encrypted with the session key (KC-AS) obtained from the AS, so the client can obtain
the service session key by decrypting it with the KC-AS.
Assume the service session
key is denoted by KC-AP.

AP_REQ is the request for accessing a service provided by the Application Server.
The message contains the service ticket obtained from the TGS and an authenticator is
generated by the client, but encrypted with the service session key (KC-AP) obtained
from the TGS.
71

AP_REP is the reply from the Application Server to prove that it is the service server
that the client is requesting. This packet is only necessary, when the mutual
authentication is required. After the Application Server is authenticated, the session
key KC-AP is used for securing the communication between the client and the
Application Server.
Kerberos provides mutual authentication between a client and server, and protect the
communication from certain kinds of attacks, such as eavesdropping and replay attacks. It also
minimizes the trust risks by having the client authenticate with the AS before receiving the
tickets. However, in actual practice, there are still issues need to be solved. First, if the KDC is
not available, no client can log into the system. This single point of failure could be mitigated by
having multiple Kerberos servers. Also, it may require additional mechanisms to handle the time
synchronization issues among its components since the tickets contain available period to indicate
how long the tickets are still valid. Network Time Protocol could be used to keep the host clock
synchronized. Moreover, because of the centralized authentication, if the KDC is compromised,
an attacker could impersonate any client.
4.3.4.1.2.
Protection of Symmetric Keys in Transit
As stated earlier, symmetric approaches have the issues of break-once-run-everywhere. Thus, not
only the communication needs to be protected, but the key itself is required to be protected as
well. In practice, there may be some situation that a shared secret key needed to transported to
another entity, which may increase the exposure of the key. To reduce the risk, a long-term key
could be used to establish a session or temporary shared key between the communicating pair.
After the shared key is established, both communicating parties use this key to encrypt and
72
decrypt messages. One of the common techniques is to use a combination of both asymmetric and
symmetric keys. The public key can be used as a long-term key to encrypt the session key and
distribute the encrypted session key to the other ends.
4.3.5.
Access Control and DR communications
This section is intended to provide the use of different access control policies for different point
of communication in DR systems. The discussion of access control policies is provided in the
Appendix A.
The access control policies are tailored to the requirements of networking and communication. In
the smart grid systems, different types of networks, such as Enterprise Bus, Wide Area Network
(WAN), Field Area Network, etc could be implemented. These networks may be implemented
using public networks, such as Internet, and non-public network. The communication may go
through both public and non-public networks. The communication from public networks should
be able to access least resources or services than that of private networks. For instance, Field Area
Network that could be used to connect the energy services interface and the meter in the customer
domain, must have the access control which specifies what accesses are allowed and which
operations can be performed. If the access control is not specified properly, an attacker may gain
access to the meter remotely, and cause malicious impacts on the customer domain.
Also, each entity in the smart grid systems, such as Advance Meter Infrastructure (AMI), Home
Area Network (HAN) or Neighborhood Area Network, is required to have appropriate access
control policies in order to restrict the incoming and outgoing connection to the devices within
the network. The policy must be specified in such a way that which communication from/to
which entity should be allowed. For example, the connection from public network should be
73
limited to access the resource in the AMI system while the connection from HAN to NAN could
be allowed in a secure manner. ACL could be used in this environment in order to accept or deny
the access from/to different networks.
Moreover, since there will be different kinds of personnel and device who can access and utilize
resources in smart grid systems and perform different operations on those resources, the access
control policies should be specified in the level of applications or devices. For example, utility
operator may be able to perform configuration of the meter remotely, while the customer should
be able to only view the price information from the meter. RBAC could be used in this situation
by specifying the roles by determining the responsibilities as parts of the system. Thus, different
entries, such as a home user or utility operator, who are assigned to different roles, will not be
able to perform operations other than its own role.
The main purposes of access control are to ensure that the resource is only allowed for an
intended user or device and that the user or device is identified. Limiting the permissions of the
subjects such that the subject should be given only necessary privileges to complete its tasks will
help reduce the impact of unauthorized access and modification to the resource of the system.
4.4.
Open Automated Demand Response Best Practices
This section uses the security concerns addressed in chapter 3 to derive security requirements and
to provide some of the best practices based on the security requirements specified in OpenADR
specification [5].
74
4.4.1.
Security Requirements for OpenADR
The following set of general security requirements is derived from the security concerns specified
in Chapter 3 and OpenADR specification:

All of the information transmitted in the OpenADR system must be protected from
unauthorized access, inspection and modification from unintended users.

Information transmitted either to or from the Demand Response Automated Server
(DRAS) must maintain confidentiality and integrity from third parties.

The DRAS must provide accountability for the following transactions

Prices received by participants

DR events received by participants

Bids submitted by participants

The DRAS must maintain confidentiality of participants, utilities and ISOs.

The proper access control to the information stored on the DRAS must be provided so
that only authorized users can modify it.
4.4.2.
Security Measures for OpenADR
The OpenADR communication is based on the Internet and Web Services technologies. Secure
communication protocols, such as Transport Layer Security Protocol (TLS), can be used to secure
network traffic. According to the OpenADR Communications Specification [5], the official TLS
specification as published by the Internet Engineering Task Force (IETF) has been proposed as
follows:
75

1024-bit Rivest, Samir & Adleman Public Key cryptography (RSA) for key exchange

3DES (Data Encryption Standard) and AES128 (Advance Encryption Standard) for
data encryption

SHA1 (Secure Hash Algorithm) for Message Integrity Code (MIC)

Hashed MAC (HMAC) for Message Authentication Code.
According to this TLS specification, it is relatively safe and provides high-level integrity.
However, TLS itself also has some vulnerability which will be described below. This section
analyses those three approaches with respect to security issues mentioned above 6. The DRAS
interfaces security can be implemented by three approaches as follows:

TLS 1.0 with server-side certificates

TLS 1.0 with server-side and client-side certificates

Web Service Security (WS-Security)
4.4.2.1. TLS 1.0 with server-side certificates
This is most commonly employed in secure web servers. The server-side certificate is used for
one-way authentication that allows clients to know that the web server which is responding to the
request is the required one. The major flaw of this method is that the client is not authenticated
which is subject to a number of serious Man-in-the-middle (MITM) attacks.
6
Note that at the time this report was being created, TLS version 1.1 and 1.2 has been released and RSA
Laboratories has recommended it to use RSA with 2048-bit key in order to protect data beyond the year
2010 [29].
76
4.4.2.2. TLS 1.0 with server-side and client-side certificates
This approach is similar to the first one, but requires a client to provide its certificate for
authentication. Even though, this mutual authentication provides the sense that client must be
authenticated before communicating with the HTTPS servers, but the cost to implement this
approach is extremely high since every clients’ certificates need to be issued and maintained. In
addition, there is a problem with TLS standard itself which is subject to MITM attacks related to
renegotiation. TLS allows both server and client to request renegotiation, a new handshake that
establishes new cryptographic perimeters, of the TLS session at any time. The problem is in order
to obtain and validate the client certificate, the HTTPS server need to renegotiate the TLS
channel. During the authentication, there is a loss of continuity, called “the authentication gap”,
which occurs because there is no cryptographic binding between the old connection and the
newly established one. The authentication gap bug in the TLS protocol allows an attacker to carry
out a number of MITM attacks and inject data into the authenticated SSL communications. This
demonstrates that the existing systems which are currently implemented using client certificates
authentication are vulnerable. Figure 17 demonstrates the process of how an attacker can exploit
the defect in TLS.
77
Figure 17: TLS Handshake with Client Certificate and MITM Attack [13]
The SSL/TLS renegotiation is vulnerable to a form of MITM attack, and hence to implement
OpenADR all the SSL libraries need to be updated with the most recent patches. This
vulnerability applies to SSL version 3.0, and all current versions of TLS (version 1.0, 1.1, and
1.2). Also, all the software which implements SSL communication is required to be updated with
the latest vendor patches. The short-term fix of this problem is to not allow or disable client-side
certificates. However, this approach is intended to be used for more secure channel (which
78
requires both server-side and client-side certificates). Thus, unless this vulnerability is fixed, this
approach should not be used because the intended “more” security will not be realized.
IETF has defined a specification of a TLS extension which ties the re-negotiation to the TLS
connection they are being operated which in turn fix this vulnerability. The details of the TLS
extension could be found at RFC57467. The status of vendor patches and updates on this
SSL/TLS authentication gap could be found at PhoneFactor8.
4.4.2.3. Web Service Security
Web Service Security (WS-Security) is a specification for secure Web Services. It provides
approach of how to enforce confidentiality and integrity on Web Services messaging. This
standard includes the specification details of how to use Security Assertion Markup Language
(SAML), Kerberos and Public Key Infrastructure (PKI) certificate format X.509. This section
discusses how to enforce the security goals by using some of the cryptographic tools based on
PKI and X.509 certificate format with WS-Security specification.
4.4.2.3.1.
Encryption
PKI supports both the encryption and signing. The use of encryption can be done by using the
public key (Asymmetric Cryptography) from the X.509 certificate issued by the CA in order to
provide data confidentiality. Figure 18 below shows the use of public key encryption.
7
Internet Engineering Task Force (IETF), Request for Comments(RFC) 5746 , “Transport Layer Security
(TLS) Renegotiation Indication Extension” is available at: http://www.rfc-editor.org/rfc/rfc5746.txt.
8
Status of Patches for SSL/TLS Authentication Gap is available: http://www.phonefactor.com/sslgap/ssltls-authentication-patches.
79
Figure 18: Asymmetric Cryptography [37]
However, in the OpenADR system, the information can be real-time based, such as Real-time
pricing signal. Using public key encryption could be slow due to the size of ciphertext. Another
approach is the combination of both symmetric and asymmetric cryptographies. The public key
can be used as a long-term key and symmetric key can be used as a short-term or one-time key.
The public key is used to establish a temporary shared secret key between the communication
pairs by encrypting the shared key and negotiate with the client. After the shared key is
established, both communication pairs use this key to encrypt and decrypt messages.
There are some security issues in providing data confidentiality that need to be addressed.

Given the same plaintext, the ciphertext should never be repeated. Randomness can be
used to attach with the message, so that the encrypted message will never be repeated.

Ciphertext should never be used by an eavesdropper to replay the message. Time
stamping can be used to validate that the message is a replay.

Encrypted message should never differ in length.
80
4.4.2.3.2.
Source Authentication
To implement authentication with X.509 certificate, Certificate Authority (CA) and Certificate
Store are needed. The certificate store is the place where all the X.509 certificates are stored. The
X.509 certificates issued by the trusted CA are used to verify that the identity of both the server
and client are valid. The certificate includes the credentials, such as the identity and public key,
and the signature part which is produced by signing the message with the private key of the CA.
When the server received the message, it will use client’s public key obtained from the X.509
certificate to validate the signature. The server ensures that the message came from the claimed
source and that the X.509 certificate has not expired.
Figure 19: Authentication using X.509 Certificate [37]
4.4.2.3.3.
Message Authentication
Encryption does not necessarily provide protection from unauthorized modification of the
message. Thus, message authentication is needed to provide data integrity. The most commonly
used technique is to use Digital Signature Algorithm (DSA) in conjunction with RSA algorithm.
Signature is generated by using the sender’s private key and an appropriate Secure Hash Standard
81
(SHS) which should comply with Digital Signature Standard (DSS), FIPS PUB 1869, from the
National Institute of Standards and Technology (NIST). The verification process is done by using
the corresponding public key of the sender and the same hash function. The receiver of the
message can ensure that the message came from the source that it claims and the message is not
tempered with by anyone because the only corresponding public key and the same hash function
can verify the signature part and only the user that possesses the private key can digitally sign the
message. Figure 20 demonstrates the process of signing and verification using Digital Signature.
Figure 20: Signing and Verification Process of Digital Signature [38]
4.4.2.3.4.
Non-repudiation
Non-repudiation can be provided by using the digital signature technique. Typically, the private
key is only known by the owner and restricted from public. Thus, using the corresponding public
key can ensure that the sender is the only one who signed the message.
9
Digital Signature Standard is available at http://www.itl.nist.gov/fipspubs/fip186.htm
82
4.4.2.3.5.
Key Pair Management
The key management is one of the critical parts of OpenADR. A best practice is to use different
key pairs for encryption and digital signature since the signatures are used for longer-term
authentication and message integrity, but the encryptions are done by using a shorter-term key
pair. Also, the key distribution, revocation and key backup processes tend to be different based on
what the keys are used for. For example, if the encrypted message is store on hard disk, the
archived version of the private key may be needed to decrypt the encrypted message.
Nevertheless, the key pair for digital signature may not need to be changed. Also, to protect a
public and private key pair, the secure place to store the private key is needed and it should be
restricted such that only an authorized party can access it. Typically, the private key should not be
accessed by or sent to any other party including the CA. The public key is needed to be protected
from unauthorized modification as well. The public keys from X.509 certificates are signed by
the trusted CA which can provide such the protection.
4.4.2.3.6.
Certificate Management
Certificate management depends on the type of CAs which can be an internal or external
organization. For the external CAs, X.509 certificates can be simply obtained by submitting a
certificate signing request (CSR). The public/private key pairs will be generated only for use with
the requested certificate. For the internal CAs, the certificate management varies depending on to
the organization. However, CSR can be used for obtaining the certificates as well. Figure 21
shows the process of a client requesting and issuing an X.509 certificate from a CA that processes
CSR and the process of a CA issuing an X.509 certificate.
83
Figure 21: Requesting and Obtaining a Certificate from CA [37]
If the integrity of the certificate has been compromised, the CA has to revoke X.509 certificates.
The certificate revocation list (CRL) is typically available to the public, so that any recipients of a
signed message can verify that the certificate has not been revoked.
4.4.2.3.7.
Security Consideration in X.509 Certificate with WS-Security
In OpenADR systems, security concerns are focused on confidentiality and both source and data
integrity. X.509 certificates can be used as a binary security tokens with the WS-Security
specification defined in the OASIS standard for SOAP message security [39] in order to provide
confidentiality and integrity of the message. In WS-Security, message integrity can be provided
by using XML signature in conjunction with X.509 certificates. Also, to keep SOAP (Simple
Object Access Protocol) message confidential, XML encryption also can be used in conjunction
with X.509 certificates. Even though, using X.509 certificate can reduce the risks of MITM
84
attacks, the designer should be aware that using digital signature alone may not be sufficient to
secure SOAP messages. A replay attack could be carried out, if there is no mechanism to detect it.
Time stamp, sequence number or expiration date can be included into the signature part of the
message or of the SOAP header for some SOAP extension. The use of WS-Security in
conjunction with X.509 certificates provides a great deal of flexibility and high-level of
confidentiality and integrity, but it tends to have some impacts on the system performance, such
as speed and complex computation.
4.5.
Automated Demand Response at Residential Sites and Security Measures
The demand response for residential customers is carried out by using a Programmable
Communicating Thermostat (PCT). PCT Communication takes place through a broadcast
wireless network, such as sub carrier FM, which allows large number of PCTs to receive the
information in a single broadcast transmission. When the DRAS receives the demand response
signals from the utility, it will provide the signals to a network operating center (NOC), which is
responsible for the broadcast of the signals to PCTs. Broadcast messages, consisting of the price
signal, will be sent out to the thermostat in order to update the power consumption at the
residential sites. The broadcast messages could be manipulated by an adversary in such a way that
they can affect the energy usage in residential areas. For example, an attacker may attempt to turn
on all air-conditioning units in the residential site resulting in excessive loads to the grid, and
blackouts may occur. Also, an attacker could send false message which is not issued from the
broadcast network, causing incorrect response from the PCT and incorrect energy price is set. To
defend against the security concerns discussed in Chapter 3, the layer of defense has been
addressed as shown in Figure 22 below.
85
Figure 22: Defense Mechanisms for PCT Systems [28]
Layers of Defense
ATTACK
MECHANISM
BUSINESS
LOGIC
Compromise Head-End
No Remote Load Increase
KEYS &
CRYPTO
DETECTION
ENVIRONMENT
Asymmetric
Keys
IDS
Incentives
Key Splitting
Frequent Time
Update
Safety Limits
Falsify / Forge Data
Random Recovery Delays
Crypto
Algorithm
Locally Change PCT
Time
Logical Gaming
Detection
Radio Stations
Initial Setback Recovery
Limit
Key
Distribution
Tamper Detection
Key
Management
Audit Logs
Key
Administration
System
Recommendations
Disable Antenna
FCC
Override Local Time Set
Jam Broadcast Signal
Legislation
Simultaneous Addressing
Limits
External Factors /
Influence
This section focuses on the use of cryptographic approaches to provide defensive mechanisms
against the security concerns since they are considered as the main defense against attacks. The
further details of business logic, detection and environment layers are in the Reference Design for
PCT [28].
4.5.1.
Cryptographic Approaches
E. W. Gunther [28] has recommended using Elliptic Curve Cryptography (ECC), which is based
on the asymmetric approaches and consumes low energy. The use of ECC for authentication and
confidentiality is already discussed earlier in this report.
86
4.5.2.
Key Distribution
The challenge in the case of PCT is the key distribution issues. When the PCT devices are
manufactured, the unique random number must be place into each PCT. This number will be used
in the installation process as well as the transmission of cryptographic key information to the
device. The key materials could be embedded into the device. This may lead to the issue of key
handling and storage since if the PCT is stolen, the knowledge of the key information might be
leaked. One solution to this is to separate critical information like a key such that there must not
be any single entity possessing enough information by itself to reconstruct the secret. In the PCT
system, the random number could be placed into the thermostat along with an out-of-band
communication channel. The out-of-band channel could be a phone number or activation code
which the installer of the PCT could obtain it confidentially in order to activate or install the PCT
into a residential site.
4.5.3.
Key Management
Key management for PCT system utilizes a three-tiered hierarchy of keys as shown in Figure 23.
Figure 23: Hierarchy of the Key Distribution [28]
87
The benefit of the hierarchy is that when the primary key is compromised at some point, the
backup key can be used instead. The backup key will never be used and keep in secure storage, if
the primary one is not compromised. In this hierarchy, there are two entities which are system
owner and system operator.
System Owner is the highest level of authority for overseeing and control of the entire PCT
system. Any Information transferred from the System Owner to the PCT must go to the System
Operator. The system owner possesses two separate public/private key pairs, one primary and one
back up keys. The primary keys will be used when the system owner authenticates the public key
of the system operator and also when the system owner sends system-wide messages, such as
emergency messages.
System Operator is the responsible for sending messages to PCTs. A public/private key pair will
be used for all PCT communication from system operator to PCTs. In some case, the system
operator may possess more than one key pair based on the different operating regions, or service
territories.
4.6.
Conclusion
This chapter discussed information security best practices to enforce security requirements for
DR systems. In DR sensor networks, ECC could be an attractive approach for providing
confidentiality, mutual authentication, and accountability. In addition, the use of Zigbee alone
may not be sufficient enough to ensure security. One of the solutions is to consider ECC as a
public key scheme for Zigbee. This chapter also provided the best practices, such as data handling
and data transmission practices, and recommendation for key management derived from NIST
SP800-57 (Part1) [33], NISTIR 7628 (vol. 1) [8]. Symmetric Key Management, such as key
88
distribution using Kerberos and symmetric key protection, are explained. OpenADR best
practices derived from the OpenADR communication specification, which recommended using
TLS for secure communications, were discussed. In addition, Asymmetric Key Management
using X.509 certificates were discuessed in the context of OpenADR. Cryptographic approach
and key management and distribution for PCT in Automated DR at residential sites were also
addressed in this chapter as well.
89
Chapter 5
RESEARCH AND DEVELOPMENT ISSUES
The security measures and best practices specified in the previous chapter help mitigate actions
that violate confidentiality, integrity, and availability of the information flow in the DR systems.
However, there are still areas where those solutions may not be adequate and may require further
research. This chapter provides potential Research and Development (R&D) issues specific to the
security measures and best practices discussed in this research. Each R&D topic is provided with
the explanation of the issues and, if applicable, details of possible solutions, followed by possible
research outcomes.
The potential research topics are organized as follows:

Topics in Authentication and Authorization
This covers potential research issues regarding authentication and/or authorization
issues including topics in Role-Based Access Control, Authentication between DR
Service Providers and Smart Devices, HAN Device Authentication, Authorization and
Authentication between Users and Smart Appliances and/or HAN-Based Monitors.

Topics in Cryptography and Key Management
This research area covers potential research issues with respect to Cryptography and
Key Management. This area includes the topics in Public Key Infrastructure (PKI) and
Key Management and PKI Issues, Limitation in Devices and Cryptography, Key
90
Management in Wireless Sensor Networks, and Non-Repudiation/Accountability
Issues.
5.1.
5.1.1.
Topics in Authentication and/or Authorization
Role-Based Access Control
As discussed in the Appendix A, Discretionary Access Control (DAC) policy could be
implemented in some part of the DR systems, but it has major issues that the policies may not be
controlled by a central authority since the owner of the object can change or give the access rights
to others. Also, there is a need for extra security mechanisms to prevent from unauthorized
copying when an access rule is given to someone else by the owner. On the other hand,
Mandatory Access Control (MAC) may be more appropriate for multi-level secure military
organizations. Role-based Access Control (RBAC) could be one of the effective means to control
the accesses to the system in more central and secure manner, especially in an enterprise system
like the Smart Grid. In RBAC the access decisions are made by roles or responsibilities that the
users or subjects have in the organization. Access rights are categorized by role name and the
attempt to perform an operation that is not associated with the given role will be denied. Thus, it
can encapsulate the job functions one needs into one role. The modification to that role can be
made without affecting other roles. This makes it easier for an administrator or security authority
to control and manage the access policies.
However, the complexity when implementing RBAC in the smart grid systems is that role
engineer becomes very difficult since the DR will contain a large number of entities, including
users and devices, of which the responsibilities are various. For example, auditors should have the
ability to read and verify states of the devices including remote attestation, but must not be able to
91
configure the devices. Administrators can add, modify and remove users and their access rights in
the systems and so on. Defining roles of all the entities in the system would become very difficult
since some operations may be generally performed by most of the users and users belonging to
different roles may have some common operations. It is rare to have all the operations needed to
perform a job function can be neatly encapsulated into the same role definition without
duplicating with other definitions.
One of the challenges of implementing RBAC is to find the balance between stronger security
and easier administration. Most likely, the higher the security is, the more granular the roles
become. Hence, one user may be assigned to multiple roles. In this kind of situation, the
administration tasks become more complex and inefficient. To deal with this issue, role hierarchy
could be implemented. A role hierarchy is used to simplify role definitions by combining roles. In
other word, one role may contain other roles. For example, the role called “Security Manager”
may contain the roles of “Auditor” and “Security Officer”. Thus, an administrator does not need
to repeatedly list all the operations that are required for the Security Manager role. Role
hierarchies are usually complied with the structure of the organization. The uses of role
hierarchies help reduce the complexity of the administration tasks and simplify the number of
roles assigned to the entities.
Another challenge is to define the policy in order to preserve the principle of Least Privilege – a
subject or entity in the system must be given the privileges that are necessary for its task, but no
more. It is often that operations grouped into a particular role may be unnecessary for that role
because of a variety of attributes and constraints of the job function. To describe access rules and
policies, this principle must be considered. Thus, identifying what appropriate roles for the
92
participants are and what functions should be performed on different Smart Grid environments by
those roles is very crucial.
Research in this area should help specify clearly what types of roles users (eg. Auditors,
protection engineers, security officers, etc) partake in the system and what operations should be
permitted for the roles specified on various components of the smart grid systems. Additionally
support for both hierarchical and non-hierarchical roles, emergency bypass of normal role
assignment will be needed in keeping with high priority goal of availability.
5.1.2.
Authentication between DR Service Providers and Smart Devices
DR signals and control commands could be sent directly from DR Service providers to smart
appliances, HAN devices or Energy Management Control System (EMCS) this applies to
situations where the signal sent without going through HAN gateways in order to control energy
usage by shifting or shedding electrical loads at participant’s sites or control the devices.
However, an attacker could also send false signals or inject any malicious commands to those
devices. If an attacker successfully injects false commands into the system, it could have a
tremendous impact on the stability of the grid and energy consumers’ billings. Authentication of
DR signals sent between DR services providers and other smart appliances is crucial. The system
must provide a mechanism to authenticate to ensure that the commands are sent from alleged
sources to intended devices properly. If a command is sent in an unauthorized manner the
command should be rejected and the devices must not respond to it. Also, the response from the
devices should be sent to indicate that the commands received are successfully carried out.
Cryptographic techniques, such as digital signature, could provide such a protection. However,
devices such as meters, sensors, and other HAN devices, have resource constraints including
93
limited memory, storage, and battery life as well as bandwidth. These limitations should be
considered when utilizing mechanisms to provide authentication as well.
The research in this area is to provide specific solutions to those issues addressed above.
However, there may be situations where the cryptography may not be utilized adequately, since
there will be many different kinds of devices deployed in the DR system. The research should
also identify these limitations and/or provide best practices or means to handle those issues as
well.
5.1.3.
HAN Devices Authentication
A smart meter and other device could be used as a gateway in order to receive and demand
response to DR signals from/to utilities and DR services providers. HAN devices will response to
the DR signals received according to DR strategies which could be pre-programmed in the
devices. However, it is possible for an attacker to forge a DR command and inject it into HAN.
Also, an attacker may be able to join his own device to the network in order to intercept the traffic
or perform malicious attacks. It is crucial that authentication mechanisms must be provided in
such a way that when a device receives a command, it must be able to ensure that the command is
come from the legitimate source and is delivered to the correct device. When the authentication
fails, the device should not respond to the signal and/or should be able to report back to the DR
head-end. Cryptographic schemes, such as digital signature or message authentication code, could
be used to provide such a protection.
Research in this area is needed to provide specific methods for such authentication. However, it is
necessary to consider the techniques that can be implemented in different kinds of devices since
HAN devices could be gas meters, water meters, lighting controls, in-home monitors, thermostat,
94
etc. Each of the devices may have some limitations, such as resource limitations or inability to
store data permanently, and only cryptographic tools may not be sufficient enough to ensure the
authentication between those devices. Also, since to some extent, HAN devices could be obtained
and installed by consumers, the authentication process should be operated on autonomous basis to
simplify things for the consumer.
5.1.4.
Authorization and Authentication between Users and Smart Appliances
User authentication is important in DR systems, since users could be maintenance personnel, IT
personnel or home users. Thus, the way to authenticate users should be friendly enough for home
users who may not possess technical skills, but it is still required to be strong enough to protect
from several kinds of attacks. Password authentication is one of the possible techniques that could
be implemented. Currently many smart meters are using this technique to authenticate
maintenance personnel. Also, since access to smart devices can be local or remote through AMI
or HAN gateway, an attacker may attempt to gain access to the devices as well. Therefore, the
system should provide mechanisms to defend the system from password attacks, such as
dictionary and brute force attacks, and also limit the attempts to perform those attacks to the
system.
Other user authentication techniques, such as token and biometric authentication, could be used
as well (See Appendix A for the details of user authentication). However, those techniques still
have some issues, which are already discussed in Appendix A. For example, a smart card could
be used for authentication, but it can be stolen. The Two-factor authentication, such as use of both
a token and password for authentication, may be used in this case to provide greater security. In
addition, HAN-based devices may have the issues of resource constraints, such as limitation in
95
memories and spaces or low computational power. Complex authentication may not be
appropriate. Thus, the choice of authentication techniques and the balance between security and
user friendliness could be one of the research in this area.
Once a user is successfully authenticated and gains access to the system, authorization techniques
must be applied. Authorization refers to the act of granting a user or device proper rights to access
some particular resource of the system. The issue is that different users could have different
functions to perform on the devices. For example, a home user should not have permission to
change or reset some important configuration values like energy price and monthly usage in the
meter. To provide authorization, access control mechanisms are necessary. Access control
mechanisms, such as Role-based Access Control (RBAC), must be described and utilized in order
to ensure such that the users can only perform the tasks they are allowed. Details of the issues in
RBAC are described in the next topic. Thus, authentication and authorization should be able to
ensure that only authorized users can perform certain functions on specific devices.
The research in this area is to identify the potential issues of password attacks that could be
manipulated by an adversary and provide defense mechanisms to those issues in HAN-based
devices. Also, it should identify an appropriate set of roles and determine how these roles can
perform particular tasks on particular devices. Finally, it should describe access control policies
and provide the techniques to implement those policies in the DR systems as well.
96
5.2.
Topics in Cryptography and Key Management
5.2.1.
Public Key Infrastructure
Asymmetric or public key cryptography can be used to implement security goals, such as
confidentiality, integrity and non-repudiation. However, to successfully provide these goals, there
is the need to ensure that a given public key is from the alleged source and can be trusted. Since
the public key is usually made available to the public, it could be published by an adversary as
well as the legitimate user. This trust issue has led to the use of Public Key Infrastructure (PKI)
and public key certificates.
PKI is a system that is widely used for the establishment and distribution of digital certificates
that bind a users’ identity and its public key together in order to ensure that the specific public
key belongs to the specific identity. The main purposes of PKI are to manage public keys and
enable the uses of public key cryptography and digital certificates through the use of Certificate
Authorities (CAs) and Registration Authorities (RAs) in insecure environment, such as Internet.
Two major components of PKI are as follows:

Certificate Authority (CA)
A CA is “an authority trusted by one or more users to create and assign public key
certificates [40].” The CA is sometimes called a trusted third party which is
responsible for providing various key management services and publishing a public
key bound to a given user. This is done by having the CA create a message containing
the entity’s public key and identity and digitally signing the message with its private
key. This message is called a digital certificate. The detail of digital signature is
described in the next section. CA can be an internal or external organization or a
97
trusted third party who can certify the public key associated with the name and identity
of the owner.

Registration Authority (RA)
In general, RA is an optional component that is used to perform administrative tasks
which CA normally performs. A RA is responsible for verifying an entity’s certificate
request and determining whether an entity is qualified to have a certificate or not.
Digital certificates simply utilize the concept of a digital signature. Figure 24 shows the process
of signature generation and verification.
Figure 24: Signature Generation and Verification [41]
Digital Signature is analogous to a hand-written signature. However, it is very difficult for it to be
counterfeited because it can combine the name and identity of the signer. The signature part is
generated by using a secure hash function, such as a message digest algorithm, and the sender’s
private key. The sender encrypts the hash of the original message using his private key. When the
98
message is received, the recipient verifies that the message has not been altered in transit using
the public key of the sender and the same hash function. The source of the message is
authenticated, because only the corresponding public key can verify the signature. Thus, digital
signature can provide both source and data integrity.
Typically, a digital certificate contains a public key, certificate information regarding the public
key and digital signature of the CA. The certificate information can be the name and identity of
the public key or subject data, the algorithm used and date range which is used to verify if the
certificate is valid. The signature part of the certificate is derived from a public key and the
credential of the public key owner; it is digitally signed with the CA’s private key. The recipient
of the certificate uses CA’s public key to verity the certificate. Thus, the use of a certificate
ensures that the public key in the certificate belongs to the owner or subject of the certificate.
Thus the use of PKI allows for the implementation of digital certificates which are used for
ensuring that the public key is certified and comes from the source that it claims. After the public
key is considered as the trusted, public key encryption, digital signature techniques, and so on,
can be performed.
However, implementing PKI is not an easy task. Careful planning and proper design are critical.
Thus, there are some research areas, which have to be explored before implementing a PKI, as
follows [42]:

Trust Establishment

Private Key Protection

Certificate Revocation List (CRL) Availability
99
5.2.1.1. Trust Establishment
PKI largely relies on trust. To fully utilize PKI, the CA and RA must be trusted and must verify
that the identity of the entity requests for a digital certificate is trustworthy. The requesters must
be authenticated that they are what they claim to be. The issue is that appropriate and strong
verification process must be provided, since CA and RA could be external and internal and could
be individually implemented depending on the organization. In addition to the trustworthy
verification procedure, the issue of trusting the actual CA needs to be considered as well as the
security policy of the CA to ensure that the CA has an appropriate infrastructure and trusted
personnel. Even though for years, vendors with infrastructure services have been providing
certificate services, there is an issue regarding the cost of the certificates. Also, the ways to utilize
certificates from those vendors may not be appropriate when applying those methods to some
devices in the smart gird systems since there may be some resource constraints of the devices.
Another issue is how to handle in the case where the user’s private key has been stolen or lost
with or without the notice of the holder of the key and he or she has reported it in order for the
certificate to be revoked. A common method in this case is to place the key on a CRL. There are
research issues regarding using CRLs for meters which needs to be addressed. There are more
details on this in later sections.
5.2.1.2. Private Key Protection
Compromise of a private key will lead to the breaches in security goals, such as loss of
confidentiality, integrity, and non-repudiation, since an adversary can use the private key to
decrypt the message or digitally sign the message while pretending to be the actual owner of the
key. Not only do the private keys of the users of PKI need to be protected, but the private keys of
100
CAs need to be protected as well. Compromising the CA’s private key would allow an attacker to
create numerous illegitimate digital certificates and use those certificates for the malicious
purposes. Thus, there must be a mechanism to investigate or detect that the private key has been
compromised as quickly as possible; otherwise, vast amounts of adverse consequences could take
place. To minimize the risk, generally, both the owners of the key, which could be a variety of
devices, such as meters and personal computers, or persons, and the authorized issues of the keys
must be protected using defensive measures such as Intrusion Detection System (IDS), Antivirus
software, etc. Also, secure storage devices must be utilized. Nonetheless, since in the smart gird
systems, a wide variety of devices and machines will be utilized, different technologies or means
to store the secret information may have to be considered. More importantly, since those devices
would operate with nearly no human interference, there should be the mechanism of how to
report to the CA that a device or the key has been tampered with. Thus, there are a number of
research issues that should be considered in this area.
5.2.1.3. Certificate Revocation List Availability
Every so often certificates can no longer be considered trustworthy for various reasons including
expired certificates, lost or compromised private keys, and the loss of devices that contain
certificate information. A CRL is a list containing the serial numbers and revocation dates of all
the digital certificates that have been revoked and no longer valid, and maintained by an issuing
authority. The CRL is typically available to the public, so that any recipients of a signed message
can verify that the certificate received has not been revoked and it is still valid. The issue is that
CRL is the only way the CA can invalidate the certificates. Thus, CRL needs to be updated in
timely manner. Also, it needs online validation, which may consume bandwidth of the networks.
101
As a result, an adversary may try to attack the availability of the CRL, such as using Denial of
Service (DoS) attacks, if the CRL is not available, no operation that depends on the acceptance of
the CRL will be carried out. Also, there is the risk that the CRL becomes unavailable due to the
machine containing the CRL is infected or compromised, for example; an attacker may be able to
use an invalid certificate to trick others for malicious purposes. To minimize the risks associated
with the CRL availability, the issuing authority must maintain secure architectures and strong
defense mechanisms in order to avoid those security violations and fail-over plans in order to
provide secondary architecture whenever the primary one has failed. Thus, there is a need for a
research in this area so as to provide solutions to those issues specified above.
5.2.2.
Key Management and Public Key Infrastructure
There may be some situations in the DR where PKI is not appropriate since some devices such as
smart meters would not be able to connect to key servers and Certificate Authority (CA). Those
devices may contain both short-term symmetric and long-term asymmetric keys. Also, the DR
systems will eventually involve millions of devices. Hence, key distribution is one of the potential
issues in DR systems. The resource limitations of devices also pose some problems with respect
to the size of keys and certificates. For example, if the size of certificate is too large, the
validation process may be slow and battery life of the device may be shorter than expected.
Moreover, the key should be re-negotiated from time to time in order to protect itself and reduce
the risk of key being broken. To implement security mechanisms, appropriate key lengths and
algorithms should conform to the recommendations from NIST, FIPS, RSA laboratories and other
standards. For example, NIST SP800-57 (Part 1) [33] recommends using minimum 2048-bit key
for RSA algorithm to protect data beyond 2010. In the case of symmetric algorithms, NIST
102
SP800-57 (Part 1) [33] recommends using at least three keys for triple DES or at least 128-bit key
for AES algorithm. However, legacy devices or systems could be used in the Smart Grid systems
and may use smaller key size which the designer should include some extra mechanisms, such as
time stamping and other techniques, to provide reasonable security level instead of depending on
only cryptographic schemes used.
The research in this area is to provide best practices for key management in the Smart Grid, in
which key sizes, key lifecycles for each key type and cipher used must be specified. Also,
mechanisms to handle the security issues of resource limitations in legacy devices should be
specified as well as the methods to deal with key distribution and certificate management in
different kinds of environment, where PKI could be applied in the system. There are more Key
management issues. In cases where symmetric shared keys are used there is a different key
management problem from public key systems. The problems are: Will the key be installed in
devices at the factory? Will keys be installed by users? What if the keys are changed or need to be
changed due to loss, theft, etc.
5.2.3.
Limitation in Devices and Cryptography
DR systems will be utilizing various kinds of hardware devices, such as sensors, meters, etc.
Those devices may have some resource limitations, such as battery life, bandwidth, CPU and
memory. For example, in sensor network, Elliptic-Curve Cryptography (ECC) could be an
attractive approach for providing security in Wireless Sensor Networks (WSN), since it utilizes
smaller key size and less energy than the cryptographic schemes used in the Internet
communications, while providing equivalent security level as other algorithms. However, there is
still ongoing research on how much memory a sensor will need in order to keep the secret
103
information, such as keys and certificates, and also how much energy a sensor will consume for
the computation of encryption and decryption using different key sizes. Also, resource limitations
introduce new kinds of attack which tries to drain battery life and memory resources. Thus, it is
necessary to address those limitations and choose the appropriate mechanism in order to ensure
security goals as well as overcome those limitations. The outcomes of the research in this area
should provide the specific solutions or best practices to those issues addressed above on a
specific device.
5.2.4.
Key Management for Wireless Sensor Networks
Wireless Sensor Networks are expected to be widely utilized in the Smart Grid, especially in
Home Area Networks (HANs) and Neighborhood Area Networks (NANs). Sensors can be used
to monitor physical properties, such as temperature, lighting and humidity, and convert the
observed information into electrical signals which will be forwarded to EMCS or other devices.
Once EMCS receives the sensor signals, it will determine the signals and shed or shift electric
loads in homes or buildings. Therefore, to ensure security, sensor nodes must be able to
authenticate each other and verify that the signals received have not been tampered with by
anyone. Regardless of what schemes will be implemented, keys and secret information must be
used in order to ensure security goals. However, sensor nodes have resource limitations, such as
slow CPUs, short battery life and small amounts of memory. Thus, the secret information that
could be embedded in the sensor nodes is limited due to small memories. Also, keys could be
distributed over-the-air, thus there must be mechanisms to protect the keys as well. One of the
communication protocols that could be used in wireless sensor networks is Zigbee protocol. One
of the most concerns in the Zigbee-based HAN network is the process of setting up a new device
104
in the network because an attacker could connect his device in the Zigbee as well. Another issue
is how the keys are established at both sides of the devices. When the new device is newly
connected to the Zigbee network, the key must be established between the new device and its
pair. The key distribution for each pair of nodes in Zigbee standard can be done by three methods
as follows (See chapter 4 for details):

Provisioning or Commissioning is to use out-of-bound mechanism, such as preinstallation key or over-the-air key, to place the key into devices. The key is sent overthe-air in plaintext, which is susceptible to one-time eavesdropping attack.

Key Transport is to have a trust center distribute the keys to the devices. This method
requires sending the key itself to the devices. The transportation of the key relies on
the satisfactory security practice of the vendors. Thus, an attacker may be able to
intercept the key, if the security mechanism for transporting the key is not secure
enough to protect the key.

Key Agreement is to have a trust center and devices negotiate the keys without
transporting the key itself. Key Agreement is the most secure method for key
establishment between devices in the network [25]. The key agreement is based on
Symmetric Key Key Establishment (SKKE) which uses the master keys for
distributing the shared secret key. However, the master key itself has the issue of the
key distribution, since it has to be pre-installed or sent over-the-air.
Even though, Zigbee provides mechanisms for key establishment and key distribution, it still has
some of the security issues specified above. Thus, to implement wireless sensor networks in
Smart Grid systems, those issues need to be solved beforehand.
105
The research in this area should provide specific techniques or practices to protect the keys and
also provide proper key management schemes that could be utilized in wireless sensor networks.
5.2.5.
Accountability/Non-repudiation Issues
Non-repudiation refers to preventing an entity from denying involvement in a particular action
related to the data. Non-repudiation is crucial in DR systems since there may be a risk that a
customer can deny receiving the information or sending the response to the system. For example,
a customer may deny that he or she was involved in the sending of the message to shift the
electric loads and if there is no proof, he or she may successfully refuse to pay for the electricity
bill. Thus, the mechanisms for verifying to see if the senders of the message are who they say
they are and if the system already sent the information to the user and/or the user already received
the information are necessary. The system must provide the means to ensure that the participants
are accountable for their actions. In other words, the false denial by customers and/or utilities
from having been involved in a communication must be prevented. Failure to provide
accountability/non-repudiation may result in a dispute between a user and the system provider
and it also decrease the customers’ confidence.
Digital signature technique can be used to provide accountability. Typically, a private key is only
known by the owner and restricted from public. When a user receives the information which is
digitally signed using DSA (digital signature algorithm), only the corresponding public key can
ensure that the sender is the only one who signed the message. This could prevent the sender from
successfully denying that he or she sent the information.
On the other hand, to prevent the receiver from denying receipt of the information, the response
message which has to be signed by using the private key of the receiver is needed. The response
106
messages should include all the contents of the information received, plus the identity of the
receiver, along with the signature part. The signature part is generated by using the private key of
the receiver, the identity of the receiver and a secure hash function. Because the response
message is digitally signed with the private key of the receiver, only the corresponding public key
can ensure that the receiver is the only one who could have signed the message. This can ensure
that the receiver is held accountable for receiving the information.
Figure 25 shows the use of digital signatures for ensuring accountability. The notation KPrivA is
the private key of the entity A and KPubA is the public key of the entity A.
Figure 25: Use of Digital Signatures for Ensuring Accountability
2) KPubA{KPrivA {h(ma, A)}} = h(ma, A)’
1) ME1 = ma, A, KPrivA {h(ma, A)}
h(ma, A)’ = h(ma, A)
EMCS (BOB)
UTILITY (ALICE)
3) ME2 = ME1, mb, B, KPrivB {h(ME1, mb, B)}
4) KPubB{KPrivB {h(ME1, mb, B)}} = h(ME1, mb, B)’
h(ME1, mb, B)’ = h(ME1, mb, B)
The steps are explained as follows:
1.
The utility sends the message ME1 to Bob. The ma could be a command or price
including some DR-related information. A is the identity of Alice or Utility. The
signature part of the message ME1 is generated by applying a hash function to (ma and
A) and signing it with the KPrivA.
107
2.
When Bob receives the message, he then uses the public key of Alice to decrypt the
signature part of ME1. Bob applies the same hash function to ma and A of the first part
of the message ME1 and compares it with the result from the decryption. If they are
the same, the message ME1 has not been altered in transit. Also, since Bob can decrypt
the signature part successfully by using Alice’s public key, this ensure that Alice is the
only who has signed the message. Thus, both source and data integrity of message
ME1 is provided. Thus, this prevents the sender, Alice, from denying that she did not
send the message to Bob.
3.
The response message ME2 sent from Bob to Alice should include all the contents of
the information received, plus the identity of the receiver, along with the signature
part. The signature part is created by using the KPrivB to encrypt the hash value of the
first half of the message.
4.
Similar to step 2, Alice uses Bob’s public key KPubB to decrypt and verify the
signature. This step ensures that Bob has received the message ME1 from Alice and he
is the one who has signed the message. Alice can use message ME1 from Bob to verify
that Bob has really received it and has not modified it. Hence, this can ensure that Bob
is held accountable for receiving the message from Alice.
To implement these in DR system, there must be some secure storage to keep the digital
signatures of both sender and receiver. When a dispute takes place, the digital signatures stored in
the storage can be used to verify accountability. The issue is that the key period or longevity of
the public keys corresponding to the digital signatures stored in the secure storage must be
specified. Key management practices for an asymmetric scheme must be considered.
108
Another important issue is that, if the response message from Bob is lost in transit due to the
network problem, communication loss, Alice will not get the response message. Moreover, if the
EMCS has already taken some actions in response to the command received, the dispute between
Alice and Bob could happen since Bob can say he did not receive the message from Alice and
there is no mean for Alice to prove whether Bob received the message or not.
Contract-Signing Protocols (CSP) could be adapted as one of the possible solutions to this
problem for ensuring non-repudiation. An overview of contract signing protocols that could be
used in DR systems is discussed below.
5.2.5.1. An overview of Contract-Signing Protocols
CSP allows two or more parties to exchange their signatures fairly, meaning that no party
receives the contract unless all of them are in agreement. CSP is fundamentally used in the
environment of electronic commerce. In traditional practices, a contract between two or more
parties is signed face-to-face simultaneously, and a copy of the contract is exchanged among the
parties. All parties make sure that they are signing the same contract and the identities of others
are not masquerading, and no interception from an outsider is allowed. However, in the electronic
signing, two parties may not see each other, the signing process may not be under observation of
the others, and also an adversary could be one of parties in the network. Besides, a
communicating party may claim that he or she did not sign the contract, after the agreement
between two or more parties was set up. This is analogous to the traditional practices when the
signature in a paper contract is repudiated by the signer, claiming that it is a fraud.
One of the major properties that make contract-signing protocols overcome distrust is fairness,
which implies that at the end of the protocol, both parties get non-repudiation evidences, such as
109
valid digital signatures on a contract, and the receiver gets the message; otherwise, no parties get
anything. Non-repudiation in contract-signing protocol implies that once the signing protocol is
completed, a contract cannot be broken since it provides evidences that both the sender and
receiver have agreed on the signing of the contract.
There are several contract-signing protocols, some including Trusted Third Party (TTP) and some
without it. However, because DR systems will eventually involve with millions of devices and
users, it would be inappropriate for allowing those devices to deal with the electric signing
individually since if there is a conflict from any kinds of error, such as communication loss or any
kinds of attack, there may be a risk that the agreement cannot be settled or retrieved by all parties,
and also it is almost impossible to provide fairness without utilizing TTP [43]. Hence, one of the
common solutions for fair exchange is to use TTP. This section does not intend to provide all the
details of contract-signing protocols, but it provides an overview of a possible contract-signing
protocol that could be used in DR systems.
5.2.5.2. Roles of TTP
TTP serves as a third person who is trusted by both parties and it approves the contract after all
the signing is over. The roles of TTP are analogous to a role of a post office that is trusted by both
the sender and receiver of the mail. A post office receives a registered mail from the sender and
gets the notice or receipt from the receiver before delivering the registered mail. Usually, all the
communications between both parties will go through the TTP; hence, one of the major
drawbacks of using TTP is that TTP can become a bottleneck. The optimistic contract-signing
protocol could be used to solve this problem. The basic idea behind the optimistic protocols is
110
that TTP is not involved in any communication unless there is a conflict during the execution of
the protocol.
As stated earlier, one of the major properties that must be required for implementing CSP is the
fairness. Below is an overview of Optimistic Fair Exchange Protocol (OFEP), which could be
applied in DR systems in order to provide non-repudiation.
5.2.5.3. Optimistic Fair Exchange Protocol
OFEP proposed by N. Asokan, V. Shoup, and M. Waidner [44] can be adapted for an Internetbased contract-signing environment. The basic ideas of OFEP are the following.
Assume that there are two parties, Alice and Bob, who are exchanging a contract. Alice is the
originator of the contract. M is a contract body and all parties are mutually authenticated, e.g. via
the use of PKI (see detail in Chapter 4), hence, it can be assumed that both parties know each
other’s public verification key. In other words, Alice knows KpubB, which is the public key of Bob
and Bob knows KpubA, which is the public key of Alice. The identity of the TTP is T. H(x) is a
secure hash function (see details in Appendix A) and RX is a random number generated by X. An
m denotes the message sent between Alice and Bob. The steps are as follows (See Figure 26):
111
5.2.5.3.1.
The Exchange Sub-protocol
Figure 26: Exchange Sub-protocol in Optimistic Fair Exchange Protocol
1(a): m1 = SigA{KpubA, KpubB, T, M, H(RA)}
1(b): m2 = SigB{m1, H(RB)}
2(a): m3 = RA
2(b): m4 = RB
ALICE
2(c): {m1, RA, m2, RB}
BOB
2(c): {m1, RA, m2, RB}
The exchange steps are as follows:
1.
Both parties exchange messages indicating that they are going to sign the contract.
a)
Alice sends m1 = SigA{KpubA, KpubB, T, M, H(RA)} to initiate the exchange.
b)
Bob receives the message m1 and uses Alice’s public key to verify the message.
At the receiving of the message, Bob can verify the contract M. If Bob agree
with the contract, he then replies Alice with his commitment message m2 =
SigB{m1, H(RB)}. (Note that the message exchange may be foiled by replay
attacks, in which a dishonest party may try to send the same message several
times. Timestamp and/or Nonce10 can be inserted into the messages in order to
protect against replay attacks).
2.
If both parties are honest, and the messages are received on time, both of them obtain
the same contract during the completion of the exchange of the message.
10
A number used only once
112
a)
Alice receives the commitment message from Bob, and uses the public key of
Bob to verify that the contract has not been modified. Then, Alice sends a
random number RA, called a contract authenticator, to Bob. This RA can be
analogous to the actual signature of Alice.
b)
Bob applies the secure hash function to RA and verifies it with the H(RA)
received at the earlier step. Then, Bob send his contract authenticator RB to
Alice. Alice then verifies it with the H(RB) obtained during the earlier step as
well. This RB can be analogous to the actual signature of Bob.
c)
At the end of the exchange of the contract authenticators, both Alice and Bob
obtain the same contract in the form of {m1, RA, m2, RB}. This can be analogous
to the situation where the contract is signed by both Alice and Bob using their
signatures, RA and RB respectively.
5.2.5.3.2.
The Abort Sub-protocol
When an originator of the contract wishes to cancel the exchange, he or she may issue an abort
request to TTP. This allows an honest originator to time out the exchange after a response from
the communicating party is not received within a reasonable period. To cancel the exchange, the
originator of the contract, Alice, can issue a message to abort an exchange to TTP. It should be
noted that the originator could be an honest or a dishonest party as well. This protocol is designed
for preventing one party from receiving only the abort token (the message signed by TTP
indicating that the exchange has been aborted denoted by SigT{abort, m1} in Figure 27), while the
other have a valid contract. In this case, Alice receives the abort token, while Bob has a valid
contract. However, it does not prevent a dishonest originator from possessing an abort token after
113
the signing of the contract [45]. In other words, Alice may attempt to get both the abort token and
the contract. As a result, the abort token should not be used as a proof that the message has been
canceled [45].
Although an honest originator can issue an abort request, but if the TTP has been already
resolved by some other party who know both m1 and m2, TTP will not grant the abort request
(See Step 2 in Figure 27). Instead, the TTP will send the replacement contract to the originator.
This is because a resolve request must contain both m1 and m2. This implies that Bob has already
received the message m1 from Alice and is willing to sign the contract by sending the
commitment message m2 to Alice, but Alice has not yet received the message m2 within a
reasonable period. Thus, Alice still can get the replacement message, if Bob is willing to sign the
contract with her. However, if Bob does not agree with the contract, he can ignore all the
messages from Alice instead.
The steps are illustrated in the Figure 27. (Note that the format of the abort is not clear from the
protocol description [45])
114
Figure 27: Aborted Sub-protocol in Optimistic Fair Exchange Protocol
Trusted Third Party
(TTP)
ALICE
1) SigA{abort, m1}
2)
If no resolve is requested then
Tà A: SigT{abort, m1}
Else
Tà A: SigT{m1, m2}
The aborted sub-protocol is as follows:
1.
Alice sends SigA{abort, m1} to TTP.
2.
If the TTP has not previously been requested for any resolve by Bob, TTP sends
SigT{abort, m1} to Alice in order to indicate the m1 has been aborted. Otherwise, TTP
sends SigT{m1, m2} to both Alice and Bob. The request for aborted can be sent by
only Alice, since the message m1 is signed by using the private key of Alice. If Bob
does not agree with the contract, he can ignore all the messages from Alice instead.
5.2.5.3.3.
The Resolve Sub-protocol
If something goes wrong during the exchange protocol, both parties can send resolve message to
the TTP in order to issue a replacement of the contract. In order to request a resolve, both parties
must possess both m1 and m2. In this case, Bob can send a resolve request after receiving the
message m1 from Alice, and Alice can request for a replacement message at any time after
receiving the commitment message m2 from Bob. Figure 28 shows the steps of the resolve subprotocol.
115
Figure 28: Resolve Sub-protocol in Optimistic Fair Exchange Protocol
Trusted Third Party
(TTP)
ALICE
1) SigA{m1, m2}
BOB
1) SigB{m1, m2}
2)
If abort is requested then
Tà A,B: SigT{abort, ma1}
Else
Tà A,B: SigT{m1, m2}
The resolve sub-protocol is as follows:
1. The resolve message can be sent by either party, since it needs both m1 and m2 to be
signed. The resolve message is in the form of SigA{m1, m2} or SigB{m1, m2}.
2. If the message m1 has been already aborted, TTP will reply with the abort token, ma1;
otherwise, the replacement contract is sent to either party. The replacement contract
will be signed by TTP and it is in the form of SigT{m1, m2}.
As stated earlier, after the execution of the protocol, both parties either obtain a valid contract or
nothing. The exchange of contract authenticators and the role of TTP that can issue the
replacement message to both parties prove that both of the parties are committed to sign a
contract.
Even though OFEP can be used to provide non-repudiation, there is another issue of using TTP
that if TTP is compromised, it can issue a false contract. Additionally, there may be the chance
that the contract is inconsistent. Assume that an adversary pretends to be Bob, or Bob is a
dishonest party, after the step 2(a) of the exchange sub-protocol (see Figure 26), if Bob
116
intentionally does not send back his contract authenticator, RB, (step 2(b)), Alice will not get the
actual Bob’s signature, RB. Also, since Bob already possessed Alice’s signature, Bob can use any
arbitrary contract and use RA as Alice’s signature for the false contract. This enables a dishonest
party to produce an inconsistent version of the contract [46]. Moreover, another issue with this
protocol is replay attacks [46]. If an adversary can intercept the message m1 in the step 1(a) and
the Alice’s authenticator, RA in the step 2(a), he or she can use those to do a replay attack; even if,
the attacker does not know any details about the contract. As a result, the attacker could cause
another party to commit the old contract with him or her. Thus, to utilize this protocol, the
additional defense mechanisms for these issues must be provided. In addition, since the contractsigning protocols relies on the use of asymmetric schemes, the key management and PKI issues,
which are already discussed earlier in this chapter, should be considered as well.
Furthermore, there may be some components in DR systems, such as Zigbee-based HAN home
automation, which could utilize only a symmetric approach that is known to be insufficient to
provide non-repudiation. Therefore, there should be a mechanism for handling non-repudiation
where secure communications with proofs of involvement of customers are necessary, especially
where financial transaction is involved.
The research in this area is to provide mechanisms for handling non-repudiation requirements in
DR systems. The practices using digital signatures for asymmetric approaches recommended in
this report could be one of the solutions. Contract-signing protocols could be adapted as one of
the possible solutions to non-repudiation requirements, but there are issues that need to be solved,
such as the problem of an inconsistent contract and replay attacks, prior to utilizing it. Moreover,
there are certain issues, which need to be considered, such as key management practices and PKI
117
issues. Also, the mechanism for ensuring non-repudiation in symmetric schemes should be
provided in the situation where only symmetric keys are used.
6.3.
Conclusion
The information security best practices suggested in Chapter 4 could help ensure security goals in
some certain, but there may some situations that further research are required. Each R&D topic is
provided with the explanation of the issues and, if applicable, details of possible solutions,
followed by possible research outcomes. The R&D issues addressed in this chapter are derived
from the best practices and recommendation from Chapter 4.
This chapter identified a number of R&D issues, mostly potential research topics in Cryptography
and Key management since they are crucial for enforcing security goals. Some of the topics are
specific to DR systems, such Authentication between DR Service Providers and Smart Devices,
and HAN Devices Authentication, while some of the topics seem to be general, but they are also
important and must be addressed for enforcing security in DR systems, such as RBAC and
Limitation in Devices and Cryptography.
118
Chapter 6
CONCLUSION
This research provided the background information, and discusses security issues, best practices,
and R&D issues in DR systems. It described about background information of DR systems and
related components and how information is transmitted in a DR system carries out load shedding
or shifting through various components, such as AMI, HAN and EMCS at electric consumers’
sites. These components were briefly described in the context of DR in order to see how they
cooperate with each other. Zigbee communication standard is explained along with HAN so as to
see how home automation can carry out load reduction. Wireless Sensor Networks, which is one
of the major topics in DR, was explained with respect to DR. This research also covered
OpenADR and Automated DR at residential sites. A number of security issues and risks in DR
systems and relevant components were identified, such as security issues in pricing signals,
security concerns in DR sensor networks and Zigbee protocol, security issues in OpenADR, etc.
The security measures and best practices for addressing these issues were discussed, such as the
use of ECC in sensor networks, data handling practices and key management practices, etc. More
importantly, this report identified a number of R&D issues in case there is still the need for
further research, such as non-repudiation issues, RBAC and limitation in devices and
cryptography. These issues are required to be addressed in order to enforce the security
requirements in DR systems.
119
6.1.
Project Outcomes
As is indicated in the report, a number of potential security risks and vulnerabilities in DR were
discussed. These include confidentiality, integrity and availability of information transmitted in
DR systems and security concerns in DR sensor networks, Zigbee and OpenADR systems. The
security requirements for each of the issues may be different. For example, fixed time-of-use
pricing is less concerned about the confidentiality and integrity of information, since the
information is fixed for a certain period of time and is not regularly sent electronically.
In addition, because DR systems consist of several components, the security measures and
information security best practices used on those components can be applied to mitigate the risks
and concerns specified. In some cases, the security mechanisms and best practices, such as the
use of X.509 certificates in DRAS, could be applied directly. However, there may be some
situations, where the best practices cannot be used directly or further research is required for
addressing security issues, such as accountability/non-repudiation issues. The R&D issues were
discussed and identified in the context of DR for those unique cases as well.
6.2.
Suggestion for Future Work
This project addressed security issues, best practices and R&D issues in DR systems at a very
low-level implementation focusing on how to ensure security requirements in the information
transmitted in DR systems and networks. However, there are still other related components that
are not covered in this report, such as Demand Response (DR) and Distributed Energy Resources
(DER) integration at residential sites, which will require management of devices, such as natural
wind turbines and roof top solar in order to provide two-way communications network in real-
120
time base between utility’s network operation center (NOC) and the elements in DER. These
could pose other threats and vulnerabilities regarding the integration. Also, this report covered
only some aspects of privacy of customer’s information regarding how privacy loss could occur
based on the information sent in DR systems and how data handling and transmission practices
could prevent it, but there are still a number of issues that are not covered in this report, including
the legal and regulation aspects, guidelines or framework for handling privacy in DR and/or
privacy issues in smart meters, etc. These topics may require further research as well.
121
APPENDICES
122
APPENDIX A
Technical Best Practices for Enforcing Security Goals
This section discusses technical best practices that can be used to enforce confidentiality,
integrity, accountability, and availability policies. Information transferred in the DR systems
could be manipulated by an attacker to affect grid reliability or cause large financial impacts to
both utilities and energy consumers. For example, if an attack could successfully modify price
information or meter information, customers’ energy bills could be affected. Also, a customer
could deny receiving some information which will result in a dispute between participants of the
system or decrease in customer’s confidence. Information must be protected from attacks such as
eavesdropping, Man-in-the-Middle (MITM) attacks, and unauthorized access or modification of
information. To do so, cryptographic schemes, such as Symmetric and Asymmetric algorithms,
can be used to provide security goals – Confidentiality, Integrity, Availability and Accountability.
Several authentication techniques can be used to verify the identities of the users in the system.
Access control policies can also be used to provide authorization or specify privilege for users.
The best practices discussed in this section can be applied for securing information systems.
These best practices include the Use of Cryptographic tools, the means for User Authentication
and Access Control/Authorization. Application of these best practices to DR systems are
mentioned where necessary in this document as well.
123
A.1.
Use of Cryptographic Tools
A.1.1. Confidentiality
If an attacker can gain some customer information, such as energy usage or other personal
information, the privacy of the customers will be invaded. Also, some critical information like
Demand Response strategies should not be accessed or known by an adversary, since he/she can
manipulate the information to extend some knowledge of the system and use that information to
attack the system.
To provide confidentiality of the information, encryption techniques can be used. One of them is
to use symmetric or shared key method. The information can be encrypted and decrypted by
using shared secret key which is usually known by both sender and receiver. Thus, even if an
attacker intercepts the information transmitted between the components in the system, the
plaintext will not be discovered without the knowledge of the secret key. However, this approach
has major flaws. One of them is that, in practice, the shared key may be distributed to more than
two entities and hence it increases the chance for leaking of the key. Also, if the key is
compromised, all the communication channels using that key will be no longer secure.
Moreover, the key distribution is extremely expensive and difficult to manage because every
entity in the system must have shared keys to communicate with others.
Another approach is to use public key encryption to provide confidentiality of the information.
This technique requires each entity has a pair of keys – Public and Private Keys. Public key
usually is known by public, but private key is known by only its owner and will not be disclosed
to anyone. Only the key pair can be successfully used to encrypt and decrypt the message. Even
though these keys go in pairs, it is extremely difficult to derive one from the other. To encrypt the
124
plaintext, the sender will use the public key of the recipient. Hence, the receiver will use his own
private key to decrypt the ciphertext. The Figure 29 below describes how to provide encryption
and decryption using public key.
Figure 29: Public Key Encryption [37]
The public key encryption provides higher security level than secret key encryption because the
private key will not be distributed to others and the only one who can decrypt the message is the
owner of the private key. On the other hand, the computation of the asymmetric approach is more
complex than that of the symmetric approach since the key size and ciphertext are much larger, so
the performance of the system may be slower than using symmetric cryptography.
Additionally, in some system, the information can be real-time based, which means that the
performance of the system must be of concern. Thus using asymmetric approach may not be
appropriate in that case. Another approach is to combine the use of symmetric and asymmetric
cryptography. The public key can be used as a long-term key, while the shared key is used as
125
temporary (or session) key. Before the communication takes place, both sender and receiver can
exchange the session key by using the other end side’s public key to encrypt the shared key. After
the shared key is established, both sender and receiver use the shared key to encrypt and decrypt
data for the communication. When the communication is ended, the shared key may be re-used or
established again. This way the communication will not be delayed because of the size of the
message and be secured since the session key will be used as a short-term key or one-time key.
A.1.2. Integrity
The term integrity can be used to refer to both source integrity (authentication) and data integrity
(message integrity). If an identity of a source is not verified, an attacker can inject a false message
into the system or the message can be come from a fraudulent source. Also, if the information
sent in the system is modified, the system must be able to detect that a modification has been
made. The impacts of the breach in this security goal vary from the grid itself to customers’
billings. Man-in-the-Middle (MITM) attacks or other forms of unauthorized modification attack
can be carried out, if the system fails to provide defensive mechanisms against those kinds of
attacks.
In the symmetric approach, identities of both the sender and receiver are authenticated because
only the sender and receiver know the shared key. Therefore, in some cases, the use of the shared
key technique also provides source integrity. Message authentication can be provided using
Message Authentication Code (MAC). MAC is authentication tag which is generated by applying
MAC algorithm together with shared secret key and the message. MAC can be computed and
verified by using the same key. Thus, the receiver uses the same shared key of the sender to
verify if the message is modified or not. MAC algorithm can be done using Hash function. Figure
126
30 demonstrates the use of MAC for message authentication. The notation K in the figure referred
to shared key between the sender and receiver.
Figure 30: Message Authentication Code [47]
Thus, when the receiver can verify if the message has been modified by using the same MAC
algorithm and shared key to compute MAC from the receiving message and compare it with the
MAC part of the receiving message. If they are equivalent, the receiver can be sure that the
message has not been modified.
Another way to provide integrity is to use asymmetric approach. In public key scheme, Digital
Signature Algorithm (DSA) can be used to provide authentication and message integrity. Digital
Signature is analogous to hand-written signature. However, it is very difficult to be counterfeited
because it can combine the name and identity of the signer. The signature part is generated by
using Secure Hash Function and the sender’s private key. The sender encrypts the hash of the
127
original message using his private key. When the message is received, the recipient verifies that
the message has not been altered in transit using public key of the sender and the same hash
function. The source of the message is authenticated, because only the corresponding public key
can verify the signature. Thus, Digital Signature provides both source and data integrity. Figure
30 shows the process of signature generation and verification.
Figure 31: Signature Generation and Verification [41]
One issue with the use of public key cryptography is that the public key must be certified. That is,
one has to prove that it belongs to the intended user and is not a forged. For example, an
adversary uses a public key with the name and identity of the intended recipient instead and uses
this bogus key to communicate with the system. Digital Certificate can be used to ensure that the
public key is authenticated and come from the source that it claims.
128
Typically, Digital Certificate contains a public key, the certificate information regarding the
public key and the digital signature of a Certificate Authority (CA). The certificate information
can be the name and identity of the public key or subject data, the algorithm used and date range
which is considered valid of the certificate. The signature part of the certificate is derived from a
public key and the credential of the public key owner and digitally signed with CA’s private key.
The recipient of the certificate uses CA’s public key to verity the certificate. CA can be an
internal or external organization or a trusted third party who can certify the public key associated
with the name and identity of the owner. Thus, the use of certificate ensures that the public key in
the certificate belongs to the owner or subject of the certificate. The use of digital certificates in
the DR is a problem that will be discussed further in the next chapter.
A.1.3. Availability
Availability of data is to have data available in a timely manner. In the Smart Grid system, some
information, such as Real-Time Pricing (RTP) information and Demand Response events, is
required to be accurate and available all the time. However, an attacker can perform Denial of
Service attacks (DoS) which usually affect the availability of the system. Mutual authentication
techniques could be used to reduce the number of DoS attacks since both client and server must
authenticate each other before the communication takes place. However, an attacker still can
flood the network with large amount of packets in order to exhaust the bandwidth limits, resulting
in loss of availability. Therefore, cryptographic approaches alone are not enough to defend
against DoS attacks. Other security measures, such as using Intrusion Detection System (IDS)
and Firewall with Access Control list, applying secure software development methodology, using
129
secure communication protocols, should be applied. Legacy devices at end user and low
bandwidth of communication channels may result in the loss of availability as well.
A.1.4. Accountability/Non-repudiation
When a user receives some information, such as price information, and performs some response
based on the energy price received, there may be a risk that the user can deny receiving the
information. Thus, the mechanisms for checking to see if the system already sent the information
to the user and/or the user already received the information are necessary. The system must
provide the means to ensure that the user is accountable for his or her action. The failure to
provide accountability may result in a dispute between a user and the system provider and it also
decrease the customer’s confidence.
Digital signature technique can be used to provide accountability. Typically, a private key is only
known by the owner and restricted from public. When a user receives the information which is
digitally signed using DSA (digital signature algorithm), only the corresponding public key can
ensure that the sender is the only one who signed the message. This could prevent the sender from
successfully denying that he or she sent the information.
On the other hand, to prevent the receiver from denying receipt of the information, the response
message which has to be signed by using the private key of the receiver is needed. The response
messages should include all the contents of the information received, plus the identity of the
receiver, along with the signature part. The signature part is generated by using the private key of
the receiver, the identity of the receiver and the secure hash function. Because the response
message is digitally signed with the private key of the receiver, only the corresponding public key
130
can ensure that the receiver is the only one who can sign the message. This can ensure that the
receiver is held accountable for receiving the information.
To implement this technique in Smart Grid system, there must be some secure storage to keep the
digital signatures of both sender and receiver. When a dispute takes place, the digital signatures
stored in the storage can be used to verify accountability.
A.2.
User Authentication
Before a user can gain access to any resources, such as files, processes, or data, of the system, the
identity of the user must be successfully verified and the user must have the right to access those
resources. The process of verification of the user’s identity is called user authentication. After the
user is authenticated, access control mechanisms can be used to check to see if the user is allowed
to access the required resource. The detail of access control will be discussed later in this section.
Authentication can achieve in many ways, such as using password, biometric and public key
cryptography, thus choosing the appropriate method is one of the crucial decisions in designing a
system. This section is intended to provide commonly use authentication techniques.
A.2.1. Password Authentication
Passwords are the most widely used method for user authentication. In general, a user provides
the identity and types some word, phrase or password he knows. The system compares the saved
password with the received password for authenticating the user. Even though, this method is
simple and easy to be implemented, there are vulnerabilities, which need to be addressed.
131

Password may be easy to guess, if the system does not provide security policies for
creating user passwords, such as policies against using short passwords or common
passwords that are easy to guess.

Password must be protected using encryption techniques and stored in secure storage.

Countermeasures for password attacks, such as password sniffing and password
guessing, must be provided in order to reduce the risk of discovering password by an
attacker.
A.2.2. Token Authentication
Token authentication attempts to use something that a user has, such as smart cards, magnetic
stripe cards, memory card, cell phones, security tokens, etc., to authenticate with the system. This
technique alone may not be secure enough for the system since the token can be stolen and used
by an adversary. However, it can be combined with the password or PIN, which provides
significantly greater security than using password alone. The use of token and PIN is called twofactor authentication.
A.2.3. Biometric Authentication
Biometric Authentication is the verification of an individual based on unique, physical
characteristics, such as fingerprint, retina, iris patterns, voiceprint and signature. Biometric
authentication provides higher level of security than password authentication, but it is technically
complex and expensive compared to password authentication. However, the major advantage of
using biometric is that it is not easily stolen or lost. However, to apply biometric method, types of
biometrics have to be considered since they have advantages and disadvantages over the others.
132
For example, voice patterns can be easily faked by using a recorder, but it can provide a way to
identity the subject without the subject’s knowledge. Fingerprints may be unique and easy to
implement, but the subject’s finger needs to be clean, so it may not appropriate to apply to
industrial applications.
A.2.4. Digital Signature
There may be some case where it is not necessary to authenticate the communicating parties. For
example, when downloading music or software patch from the Internet, the server does not need
to identify who is downloading, but may have to ensure the users that the data is genuine and is
not tempered with by malicious software like virus or spyware.
A.3.
Access Control/Authorization
Authorization refers to the act of granting a user or device proper right to access some particular
resource of the system. Authorization fundamentally relies on authentication; thus, the process of
authorization must take place after a user, device or subject is already authenticated. To provide
authorization, access control mechanisms are necessary. For this reason, the two terms,
authorization and access control, are sometime used interchangeably. Access control is used to
limit authenticated user to gain an access to a particular resource, and prevent unauthorized use of
a resource, such as viewing and modifying a resource, including use of resource in an
unauthorized manner. Three most commonly used access control policies are Discretionary
Access Control (DAC), Mandatory Access Control (MAC) and Role-based Access Control
(RBAC).
133
A.3.1. Discretionary Access Control
DAC is based on the identity of the subject, which can be a user, process or component, and on
the access rules. The access rules to an object used to determine whether the subjects are allowed
to perform are specified by the owner of the object or anyone who is authorized to control the
access to the object. Access decisions are based on the credentials that the subject presented at the
time it is correctly identified, such as username/password, biometrics, and cryptographic tokens.
Typically, in DAC model, a subject may have an access right which allows enabling another
subject to access to the same resource at the subject’s discretion.
DAC is likely to be very flexible and simple, but there are two main issues that need to be
considered in order to implement DAC policy. First, information of the object could be copied by
the subject that is granted by the owner of that object. For example, Bob may grant Ann read
access to some file, but if there is no mechanism to prevent Ann from copying the content of the
file, she may be able to copy and use that information in an unauthorized manner. Second, the
access rights to an object are controlled by the owner of the object, rather than controlled by the
system authority who manages the system security policies.
Two most commonly used mechanisms for implementing DAC policy, which could be used in
DR systems, are Access Control List (ACL) and Capability List (CL).
A.3.1.1.
Access Control List
ACL is a list of permissions associated with an object that is used to specify which subjects, users
or systems are allowed to access that particular object as well as which operations the subject can
perform on that particular object. Each entry in ACL is called Access Control Entry (ACE) which
is usually composed of an identity of the subject and set of the permissions being granted or
134
denied for that object. In the ACL-based environment, it is simple to determine which users that
are allowed to access to this particular object. However, it is difficult to determine all the access
rights for a particular user. Thus, in some environment with the large number of users, where the
change in access control policies could be occurred constantly, implementing ACL may not be
appropriate. ACL could be created and stored in devices. If an access to a particular device is
attempted by some users or devices which are not in the list, the access must be denied. By
checking access rights for each object the user has, ACL can be used to protect against an
unintended operation performed by legitimate users or devices as well.
A.3.1.2.
Capability List
A capability can be viewed as a token, a key or a ticket of an object associated with the
permission to access that object. A capability can be analogous to a movie ticket which a
customer must have in order to access into the movie theater or a key that is needed to enter the
house. In capability-based system, a subject, which is requesting an access to a particular object,
must possess a capability for that object in order to gain access to the object. A capability could
be delegated to anyone else by the owner of the object, which is analogous to the movie ticket or
the key which could be given to another. Thus, capabilities are critical to the system security, so
when the capability is given to the subject, it must not be tempered by that subject.
A.3.2. Mandatory Access Control
MAC is an access policy used in multiple-level systems that require highly sensitive data, such as
classified military or government information. MAC ensures the enforcement of security policies
by assigning labels on the information and comparing it to the level of sensitivity a subject has. A
subject can only access to the data on which it has a label. For example, a user whose label is the
135
“Secret” classification should not be able to read a file of which the label is the “Top Secret”
classification. The owner of the object cannot change the access rights to that object; thus, the
access decisions are made by a central authority of the system, not by an individual owner.
A.3.3. Role-based Access Control
RBAC is based on the roles or responsibilities that a subject or a user has within the organization
and on rules which determine what access rights are permitted for the subject in a given role.
Access rights are grouped by role name and the operations on which an individual user can
perform are based on the associated role. Typically, the process of defining roles is based on
security policies derived from analyzing fundamental goals and structures of the organization.
In RBAC, users are granted membership by determining their responsibilities into roles. When a
new user account is created to the system, it has to be assigned into a proper role. Therefore,
assigning user membership into roles can be easily established as a job assignment. An old
operation associated with a particular role can be deleted and a new operation can be established
easily without affecting other roles. A user with a given role will not be able to perform any
operation other than the operations which are not assigned into that role. Therefore, the use of
role to control accesses can be very effective since roles can be modified without updating the
access rights for each of the users in the system. However, sometime, several operations in one
role could be overlapped with others, so the principal of the least privilege – a subject or entity in
the system must be given the privileges that are necessary for its task, but no more – must be
applied such that the user should be given no more than the privileges that are necessary to
complete his or her tasks.
136
GLOSSARY
3DES
Triple Data Encryption Standard
2TDEA
Two-Key Triple Data Encryption Algorithm
3TDEA
Three-Key Triple Data Encryption Algorithm
ACL
Access Control List
ADR or AutoDR
Automated Demand Response
AES
Advanced Encryption Standard
AMI
Advanced Metering Infrastructure
AP
Application Server
API
Application Program Interface
AS
Authentication Server
CEC
California’s Energy Commission
CPP
Critical-Peak Pricing
CPUC
California Public Utility Commission
CSP
Contract-Signing Protocol
DAC
Discretionary Access Control
DEA
Data Encryption Algorithm
DES
Data Encryption Standard
DoS
Denial of Service Attack
137
DRAS
Demand Response Automation Server
DR
Demand Response
DRRC
Demand Response Research Center
DSA
Digital Signature Algorithm
ECC
Elliptic-Curve Cryptography
ECCDH
Elliptic-Curve Diffie-Hellman
ECDSA
Elliptic-Curve Digital Signature algorithm
EMCS
Energy Management and Control Systems
EMS
Energy Management System
FFC
Finite Field Cryptography
HAN
Home Area Network
HMAC
Hashed Message Authentication Code
HTTPS
Hyper Text Transfer Protocol Secure
IETF
Internet Engineering Task Force
IFC
Integer Factorization Cryptography
ISO
Independent System Operator
IV
Initialized Vector
LANs
Local Area Networks
KDC
Key Distribution Center
138
LBNL
Lawrence Berkeley National Laboratory
MAC
Mandatory Access Control
MAC
Message Authentication Code
MIC
Message Integrity Code
MDM
Meter Data Management
MITM
Man-In-The-Middle
NAN
Neighborhood Area Network
NIST
National Institute of Standards and Technology
OpenADR
Open Automated Demand Response
PCT
Programmable Communicating Thermostat
PG&E
Pacific Gas and Electric Company
PIER
Public Interest Energy Research Program
PKI
Public Key Infrastructure
RBAC
Role-Based Access Control
R&D
Research and Development
RTO
Regional Transmission Organization
RTP
Real-Time Pricing
RSA
Rivest, Shamir & Adleman Public Key cryptography
SAML
Security Assertion Markup Language
139
SCE
Southern California Edison
SDG&E
San Diego Gas and Electric
SGIP
Smart Grid Interoperability Panel
SHA
Secure Hash Algorithm
SSL
Secure Socket Layer
TCP/IP
Transmission Control Protocol/Internet Protocol
TGS
Ticket Granting Server
TGT
Ticket Granting Ticket
ToU
Time-of-Use Pricing
TLS
Transport Layer Security
WAN
Wide Area Network
WiMAX
Worldwide Interoperability for Microwave Access
WLAN
Wireless Local Area Network
WSDL
Web Service Description Language
WSN
Wireless Sensor Network
WS-Security
Web Services Security
XML
eXtensible Mark-up Language
140
REFERENCES
[1] California Energy Commission’s Public Interest Energy Research Program, PIER Buildings
Program (2008, Dec 03), “Automated Demand Response Cuts Commercial Building Energy
Use and Peak Demand, Technical Brief,” [Online]. Available:
http://www.esource.com/esource/getpub/public/pdf/cec/CEC-TB-31_AutoDR.pdf.
[2] Electric Consumer Research Council (Feb 09, 2004), “The Economic Impacts of the August
2003 Blackout,” [Online]. Available:
http://www.elcon.org/Documents/EconomicImpactsOfAugust2003Blackout.pdf
[3] Federal Energy Regulatory Commission (FERC) (2007, Sept), “Assessment of Demand
Response and Advanced Metering 2007,” [Online]. Available:
http://www.ferc.gov/legal/staff-reports/09-07-demand-response.pdf.
[4] S. Kiliccote, M. A. Piette, J. H. Dudley; Lawrence Berkeley National Laboratory (LBNL), E.
Koch and D. Hennage; Akuacom (2009, July), “Open Automated Demand Response for
Small Commercial Buildings,” [Online]. Available: http://drrc.lbl.gov/pubs/lbnl-2195e.pdf.
[5] M.A. Piette, G. Ghatikar, S. Kiliccote, E. Koch, D. Hennage, P. Palensky, and C. McParland
(2009, April), “Open Automated Demand Response Communications Specification (Version
1.0),” [Online]. Available: http://openadr.lbl.gov/pdf/cec-500-2009-063.pdf.
[6] S. Kiliccote, M. A. Piette, J. L. Mathieu, and K. M. Parrish (2010, Aug), “Findings from
Seven Years of Field Performance Data for Automated Demand Response in Commercial
Buildings,” [Online]. Available: http://drrc.lbl.gov/pubs/lbnl-3921e.pdf.
[7] PG&E (2007), “Community Medical Centers Demand Response (DR),” [Online]. Available:
http://www.pge.com/includes/docs/pdfs/mybusiness/energysavingsrebates/demandresponse/cs
/HealthCare_CommunityMedicalCenters_DR_CaseStudy.pdf.
[8] The Smart Grid Interoperability – Cyber Security Working Group (2010, Aug), “Smart Grid
Cyber Security Strategy and Requirements,” NISTIR 7628, [Online]. Available:
http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7628.
[9] Public Interest Energy Research Group and P.S. Subrahamanyam, D. Wagner, E. Jones, U.
Shankar and J. Lerner (2006, June), “Network Security Architecture for Demand
Response/Sensor Networks,” [Online]. Available:
http://www.law.berkeley.edu/files/demand_response_CEC.pdf.
[10] AMI-SEC-ASAP (2008, Dec), “AMI System Security Requirements,” V1.01.
141
[11] AMI-SEC-ASAP (2009, Feb 19), “AMI Security Implementation Guide,” V0.4.
[12] National SCADA Test Bed (2009, Apr), “Study of Attributes of Smart Grid Systems –
Current Cyber Security Issues,” [Online]. Available:
http://www.inl.gov/scada/publications/d/securing_the_smart_grid_current_issues.pdf.
[13] M. Ray, S. Dispensa, PhoneFactor Inc. (2009, Nov 4), “Renegotiation TLS version 1.1,”
[Online]. Available: http://extendedsubset.com/?p=8.
[14] The Smart Grid Interoperability – Cyber Security Working Group (2010, Aug), “Guidelines
for Smart Grid Cyber Security: Vol. 1, Smart Grid Cyber Security Strategy, Architecture,
and High-Level Requirements,” NISTIR 7628 (Vol. 1), [Online]. Available:
http://csrc.nist.gov/publications/nistir/ir7628/nistir-7628_vol1.pdf.
[15] Kevin Lauckner; HoneyWell, (2009, Jul), “Honeywell Smart Grid Perspective,” [Online].
Available:
http://www.demandresponsetownmeeting.com/presentations/ppt/2009/Kevin%20Laucker,%
20Honeywell_SESSION%20D,%207.14.09.ppt.
[16] Illinois Security Lab, (2009, Mar 10), “AMI Security,” [Online]. Available:
http://seclab.uiuc.edu/web/component/content/article/37-education/81-ami-security.html.
[17] S. Ashton; Ember Corp. (2008, Nov 01), “Designing Smart Energy Devices,” [Online].
Available: http://www.sensorsmag.com/networking-communications/standardsprotocols/designing-smart-energy-devices-1526.
[18] M. Palaniswami; University of Melbourne, “Smart Grid,” [Online]. Available:
http://www.ict-ccast.eu/workshops/2nd/Panel%20-%20ISSNIP%20%20Marimuthu%20Palaniswami.pdf.
[19] Electric Power Research Institute (2006), “IntelliGridSM Consumer Portal
Telecommunications Assessment and Specification, Technical Report,” Palo Alto, CA.
[20] OECD (2009, Dec). “Smart Sensor Networks: Technologies and Applications for Green
Growth,” [Online]. Available: http://www.oecd.org/dataoecd/39/62/44379113.pdf.
[21] K. Masica; Lawrence Livermore National Laboratory (2007, Apr), “Recommended Practices
Guide For Securing ZigBee Wireless Networks in Process Control System Environments
(Draft),” [Online]. Available:
http://csrp.inl.gov/Documents/Securing%20ZigBee%20Wireless%20Networks%20in%20Pr
ocess%20Control%20System%20Environments.pdf.
142
[22] Federal Information Processing Standards Publication 197 (2001, Nov), “Advance
Encryption Standard (AES),” [Online]. Available:
http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf.
[23] H. Labiod, H. Afifi, C. D. Santis; Springer (2007), “Wi-Fi, Bluetooth, Zigbee and WiMax”.
[24] D. Gascón (2009, Feb 05), “Security in 802.15.4 and Zigbee Networks”, [Online]. Available:
http://www.sensor-networks.org/index.php?page=0903503549.
[25] R. Cragie (2008, Dec), “Public Key Cryptographic in Zigbee Network”, [Online]. Available:
http://www.elektroniknet.de/fileadmin/user_upload/pdf/euzdc2008/Cragie_Jennic.pdf.
[26] N. Sastry and D. Wagner, “Security Considerations for IEEE 802.15.4 Networks,” [Online].
Available:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.68.6564&rep=rep1&type=pdf.
[27] G. Aggelou (2008), “Wireless Mesh Networking” p.412-414.
[28] E. W. Gunther (2007, Mar), “Reference Design for Programmable Communicating
Thermostats Compliant with Title 24-2008,” [Online]. Available:
http://drrc.lbl.gov/pct/docs/ReferenceDesignTitle24PC_rev15.doc.
[29] M.J.B. Robshaw, Y. L. Yin (1997, June), “Overview of Elliptic Curve Cryptosystems,” RSA
Laboratories Technical Note [Online]. Available:
http://www.rsa.com/rsalabs/node.asp?id=2013.
[30] B. Kaliski (2003, May), “TWIRL and RSA Key Size,” RSA Laboratories Technical Note
[Online]. Available: http://www.rsa.com/rsalabs/node.asp?id=2004.
[31] A. S. Wander; University of California at Santa Cruz, N. Gura, H. Eberle, V. Gupta, S.
Chang and C. Shantz; Sun Microsystems Laboratories (2005, Mar), “Energy Analysis of
Public-Key Cryptography for Wireless Sensor Networks,” [Online]. Available:
http://research.sun.com/projects/crypto/wandera_energyanalysis.pdf.
[32] J. Wright; InGuardian (2009, Oct), “An attack framework designed to explore vulnerabilities
in ZigBee and wireless sensor networks,” [Online]. Available:
http://inguardians.com/pubs/toorcon11-wright.pdf.
143
[33] E. Barker, W. Barker, W. Burr, W. Polk, and M. Smid; National Institution of Standard and
Technologies (NIST), (2007, Mar 08), “Recommendation for Key Management – Part 1:
General (revised),” SP800-57 (Part 1), [Online]. Available:
http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf
[34] D. Thanos, D. Biggs and T. Metke; NIST SGIP CSWG Cryptography & Key Management
Group (2010, Mar 25), “Smart Grid Cryptography and Key Management,” [Online].
Available: http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/CSCTGCrypto.
[35] F. Ricciardi (2006, Nov 26), “The Kerberos Protocol and Its Implementation,” [Online].
Available: http://www.zeroshell.net/eng/kerberos/Kerberos-operation/
[36] E. Rescorla; RTFM, Inc., M. Ray, S. Dispensa; PhoneFactor, N. Oskov; Microsoft (2010,
Feb), “Transport Layer Security (TLS) Renegotiation Indication Extension,” Internet
Engineering Task Force (IETF), Request for Comments(RFC) 5746, [Online]. Available:
http://www.rfc-editor.org/rfc/rfc5746.txt.
[37] Microsoft Developer Network (MSDN) library, Microsoft Corporation (2009), “Web Service
Security Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements
(WSE) 3.0,” [Online]. Available: http://msdn.microsoft.com/en-us/library/aa480545.aspx.
[38] Wikipedia (2009, Nov), “Digital Signature”, [Online]. Available:
http://en.wikipedia.org/wiki/Digital_signature.
[39] A. Nadalin, IBM Corporatation; C. Kaler, Microsoft Corporation; P. Hallam-Baker,
VeriSign Inc.; R. Monzillo, Sun Microsystems Inc. (2004, Mar), “Web Services Security:
SOAP Message Security 1.0 (WS-Security 2004) OASIS Standard 200401”, [Online].
Available: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security1.0.pdf.
[40] A. Arsenault; Diversinet, S. Turner; IECA, PKIX Working Group (2002, Jul), “Internet
X.509 Public Key Infrastructure: Roadmap,” [Online]. Available:
http://tools.ietf.org/html/draft-ietf-pkix-roadmap-09.
[41] National Institute of Standard and Technology (NIST) (2009, Jun), “Digital Signature
Standard (FIPS 186-3),” [Online]. Available: http://csrc.nist.gov/publications/fips/fips1863/fips_186-3.pdf.
[42] E. Stavrou (2005, Jan), “PKI: Looking at the Risks,” [Online]. Available:
http://www.devshed.com/c/a/Security/PKI-Looking-at-the-Risks/.
144
[43] H. Pagnia and F. C. Gärtner; Darmstadt University of Technology (1999, Mar), “On the
Impossibility of Fair Exchange without a Trusted Third Party, Technical Report”.
[44] N. Asokan, V. Shoup, and M. Waidner (2000), “Optimistic fair exchange of digital
signatures, IEEE Journal on Selected Areas in Communications,” pages 593–610.
[45] N. Asokan, V. Shoup, and M. Waidner (1998), “Asynchronous protocols for optimistic fair
exchange,” In Proc. IEEE Symposium on Research in Security and Privacy, pages 86–99.
[46] V. Shmatikov, J. C. Mitchell (2000), “Analysis of a Fair Exchange Protocol,” [Online].
Available: http://www.isoc.org/isoc/conferences/ndss/2000/proceedings/001.pdf.
[47] W. Stalling, L. Brown (2008), “Computer Security Principles and Practice: Chapter 2 –
Cryptographic Tools,” First Edition, [Online]. Available:
http://people.eecs.ku.edu/~saiedian/Teaching/Fa09/710/Lectures/ch02.pdf.