SECURITY AND PRIVACY IN DEMAND RESPONSE SYSTEMS IN SMART GRID
Mithila Paranjpe
B.E., Gujarat University, 2007
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
SECURITY AND PRIVACY IN DEMAND RESPONSE SYSTEMS IN SMART GRID
A Project
by
Mithila Paranjpe
Approved by:
__________________________________, Committee Chair
Isaac Ghansah, Ph.D.
__________________________________, Second Reader
Scott Gordon, Ph.D.
____________________________
Date
ii
Student: Mithila Paranjpe
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
SECURITY AND PRIVACY IN DEMAND RESPONSE SYSTEMS IN SMART GRID
by
Mithila Paranjpe
Demand response programs are used in smart grid to improve stability of the electric grid and to
reduce consumption of electricity and costs during peak times. One of the key aspects in demand
response programs is for utilities to provide secure information to customers. Various threats and
attacks could hinder the propagation of crucial information related to price, electricity usage,
device and customer information. Privacy of utility, customer and other demand response entities
could be at risk due to the vulnerabilities. This project analyzes security issues, best practices, and
research issues in demand response program. It illustrates various security issues and possible
best practices for the demand response program. It covers proper data handling practices for
maintaining
confidentiality,
integrity,
availability,
and
accountability.
Some
of
the
countermeasures are inadequate for Smart Grid architecture and hence require more research.
Some of the research issues are discussed. In conclusion, this project helped evaluate security
privacy issues and possible best practices for energy efficient solutions associated with demand
response system.
_______________________, Committee Chair
Isaac Ghansah, Ph.D.
_______________________
Date
iv
DEDICATION
This project is dedicated to my beloved mother Bela Vichare for her never-ending sacrifice, love
and support.
v
ACKNOWLEDGMENTS
I would like to extend my gratitude to my project advisor Dr. Isaac Ghansah, Professor, Computer
Science and Engineering for guiding me throughout this project and helping me in completing
this project successfully. I am also thankful to Dr. Scott Gordon, Professor, Computer Science
and Engineering, for reviewing my report. I am grateful to Dr. Nikrouz Faroughi, Graduate
Coordinator, Department of Computer Science, for reviewing my report and providing valuable
feedbacks. In addition, I would like to thank The Department of Computer Science at California
State University for extending this opportunity for me to pursue this program and guiding me all
the way to become a successful student.
Lastly, I would like to thank my mother Bela Vichare for providing me the moral support and
encouragement throughout my life.
vi
TABLE OF CONTENTS
Page
Acknowledgments…………………………………………………….………………………. vi
List of Tables………………………………………………………………………………….. x
List of Figures………………………………………………………………………………… xi
List of Abbreviations………………………………………………………………………….xiii
Chapter
1. INTRODUCTION ……………..…………………………………………………………. 1
1.1 Introduction to Demand Response Programs………..…………………..…………..... 3
1.2 Demand Response Signals and Polices.……………..……………………..………..... 4
1.3 Demand Response Events…………………………………………………………….. 8
1.4 Open Automated Demand Response Communications Infrastructure ...………....….. 9
1.5 Privacy in Demand Response……………………………………………..…….….... 12
1.6 Related work for Demand Response…………………………………...………....…. 13
1.7 Goal of the project…………………………….…………………………...……....… 15
2. SECURITY ISSUES IN DEMAND RESPONSE……………………………….…….….. 16
2.1 Overview………………………………………………………………….……....…. 16
2.2 Security Concerns in Demand Response……………………………….....……....… 17
2.3 Technological issues in Smart Devices……………………………......……….....… 26
2.4 Generic Event-Based Program (GEBP) in OpenADR……………….……………... 33
2.5 Security Issues in Generic DR event………………………………………..………. 35
2.6 Security Concerns in OpenADR Interfaces………………………………….......….. 39
2.7 Threats in OpenADR…………………………………………………….………….. 43
vii
2.8 Potential vulnerabilities in OpenADR………………………………………………. 45
3. BEST PRACTICES FOR DEALING WITH DEMAND RESPONSE RISKS…………... 49
3.1 Overview…………………………………………………………………….….…… 49
3.2 Secure Information Flow…………………………………………………...…..……. 50
3.3 Secure Data Handling Practices….……………...………………………………....... 50
3.4 Access control………………………………………………………………….……. 51
3.5 Account Management…………………………………………………………..…… 51
3.6 Identifier Management………………………………………………………..……... 52
3.7 Cryptographic mechanisms for demand response…………………..………….……. 53
3.8 Mutual authentication and Message Authentication………………………….….….. 63
3.9 Key management……………………………………………………………….......... 65
3.10 Open Automated Demand Response (OpenADR) Security Measures……….……. 66
3.10.1 Security Requirements…………………………………...…………………....... 66
3.10.2 Security Measures…………………………………………...…………….……. 67
4. PRIVACY ISSUES AND ITS RELATED BEST PRACTICES IN DEMAND
RESPONSE……………………………………………………….…….………… 76
4.1 Overview………………………….……………………………………..…....... 76
4.1.1 Identity Theft………………….…………………………………………….. 76
4.1.2 Determine Personal Behavior Patterns……………….……………………….. 77
4.1.3 Determine Specific Appliances Used………………….…………………….... 77
4.1.4 Issues in data collection and availability ……………….…………………....... 78
4.1.5 Issues in smart meter………………………………….……………………... 78
4.1.6 Issues in data storage and processing…………………….…………………... 79
viii
4.1.7 Issues in Commissioning, Registration, and Enrollment of HAN devices………… 80
4.1.8 Issues with Third Party…………………………………………………………….. 81
4.2 Consumer to Utility Privacy Impact Assessment ……………………………………… 81
4.3 Identification of Legal and regulatory framework of demand response………………...83
4.4 Privacy principals in Demand Response……………………………………………….. 84
4.5 General Accepted Privacy Principles (GAPP)………………………………………….. 85
4.6 Privacy Recommendations in Demand Response……………………..……………….. 86
5. RESEARCH ISSUES IN DEMAND RESPONSE………………………………………... 88
5.1 Overview………………………………………………………………….……………. 88
5.2 Authentication and Authorization for Demand Response Devices…….………………. 88
5.3 Key Management for Demand Response Devices………………….………………….. 89
5.4 Role based access control (RBAC) ……………………………………………………. 90
5.5 Security issues in Log information…………………………….……………………….. 91
5.6 Traffic Analysis……………………………………………….………………………... 92
5.7 Privacy issues in Data Storage………………………………………….……………..... 93
5.8 Privacy issues in ownership of customer data………………………………….............. 94
6. CONCLUSION…………………………………………………………………….…...….. 95
6.1 Summary……………………………………………………………………………….. 95
6.2 Strength and weakness………………………………………………………………..... 96
6.3 Future Work……………………………………………………………………………. 97
Bibliography…….................................................................................................................... 98
ix
LIST OF TABLES
Page
1.
Table 1 Simplified example of ACL in AutoDR ……………………………… 21
2.
Table 2 Capability list in AutoDR……………………………………………... 22
3.
Table 3 Demand Response Generic DR event …………………………………. 36
4.
Table 4 Information sent between Utility to DRAS…………………………… 40
5.
Table 5 Information sent from DRAS to Participant, Facility or Aggregator..... 41
6.
Table 6 Information sent from DRAS clients to DRAS…………...…………... 42
x
LIST OF FIGURES
Page
1.
Figure 1 Demand Response program for energy reduction …..………………….……. 2
2.
Figure 2 Communication between aggregator, bidding web portal and customer site.…7
3.
Figure 3 Generic Open Automated Demand Response Interface Architecture…..…... 10
4.
Figure 4 DRAS Interfaces…………..………………………………………….…..…. 12
5.
Figure 5 Demand Response Interaction in Smart Grid……………………………..… 16
6.
Figure 6 Relationship between Third Party, Resource Owner and Resource
Custodian………………………………………………………………………….…... 24
7.
Figure 7 Information flow in DR program with Third Party…………………….…… 25
8.
Figure 8 Demand response in residential and commercial area………………….…… 27
9.
Figure 9 Energy management software from Energy Lens…………………………… 32
10.
Figure 10 Automated Generic Event-Based Program (GEBP) Use Case …….…….... 36
11.
Figure 11 Possible path of attacks on the Demand Response system……….………... 43
12.
Figure 12 Example of providing identity and authenticating a user………………….. 53
13.
Figure 13 Symmetric Key Encryption ……………………………………….………. 55
14.
Figure 14 MAC for message authentication………………………………………….. 55
15
Figure 15 Asymmetric Cryptography ………………………………………….…….. 57
16.
Figure 16 Use of Digital Signature for data integrity ………………………….…….. 59
17.
Figure 17 The requesting and obtaining process for X.509 certificate…………..…... 60
18.
Figure 18 Certificate validation with CRL…………………………………………… 62
19.
Figure 19 Certificate Validation with Online Certificate Status Protocol (OCSP)…... 63
20.
Figure 20 Basic TLS handshake..……………………………………………….…..... 70
21.
Figure 21 TLS handshake with client certificate and MITM attack.………………… 71
xi
22.
Figure 22 Message flow in Web Service……………………………………….….… 73
23.
Figure 23 Authentication using X.509 certificate……………………….......... 75
xii
LIST OF ABBREVIATIONS
AMI
Advanced Metering Infrastructure
AutoDR
Automated Demand Response
CBP
Capacity Bidding Program
CLIR
Client Logic and Integrated Relay
CRL
Certificate Revocation List
CPP
Critical Peak Pricing
DR
Demand Response
DRRC
Demand Response Research Center
DRAS
Demand Response Automation Server
DR-CBP
Demand Response Capacity Bidding Program
EMCS
Energy Management and Control System
FTP
File Transfer Protocol
IP
Internet Protocol
LBNL
Lawrence Berkeley National Laboratory
OpenADR
Open Automated Demand Response
PCT
Programmable Thermostat
PKI
Public Key Infrastructure
PGE
Pacific Gas and Electric
RTP
Real Time Pricing
SDGE
San Diego Gas And Electric
SOAP
Simple Object Access Protocol
TCP
Transmission Control Protocol
xiii
TOU
Time of Use
WSL
Web Service Description Language
WWW
World Wide Web
XML
eXtensible Markup Language
xiv
1
Chapter 1
INTRODUCTION
It has been predicted that the demand for electricity is expected to grow by 30% in the coming
years along with the rise in electricity prices to 50% [1] due to population growth and
industrialization. Other issues include instability in the grid such as the blackouts and controlling
greenhouse gas emissions during electric generation leading to global warming concerns. This
has led to modernization of electricity to provide energy efficient programs, use of renewal
sources of energy, reduced energy cost and secure electricity provision. Thus, Smart Grid has
been proposed to improve the consumption of electricity among utilities and customers.
The transformation of the current grid to the Smart grid will benefit the generation, transfer and
consumption of electricity. An effective mechanism is required to enable these benefits for
facilitating customers to reduce electricity consumption during peak hours when electricity prices
are high. Electricity prices generally depend upon market economy and fuel prices. Demand
Response (DR) programs for smart grid can be used to improve the stability of grid and reduce
the consumption and costs of electricity during peak times. DR is a mechanism in smart grid that
is required to provide a manageable way to consume electricity corresponding to market prices,
utility or ISO’s directives. DR programs will include interfaces to carry out a two-way
communication between the grid and the customer, decision-supporting tools to monitor the
energy usage and user-friendly appliances at the customer site to respond to the incoming DR
signals from the utility. DR mechanism can be used for residential, large commercial as well as
small commercial buildings. It uses control systems to shed loads at the customer site by sending
signals. Load shedding is carried out on the basis of utility directives or increase in market prices
which allows the customer to reduce the electricity consumption during peak hours of usage of
electricity. However, DR can also be used to increase the demand of electricity according to the
2
consumption. For example, DR program can be implemented to reduce the electricity usage when
the prices of electricity are higher during the afternoon or increase the demand of electricity at
night when prices are low. If signals associated with the increased price and electric usage are
sent back and forth between customer and utility in real time, then this can effectively reduce the
consumption. Figure 1, indicates the use of demand response program at the customer site for
reducing the electric consumption.
Figure 1: Demand Response program for energy reduction [2]
The DR signals are required to be propagated in real time or ahead in time through different
communicating interfaces, as a result of which the grid will be more vulnerable to various threats
and attacks leading to exposure and manipulation of crucial information pertaining to electricity
usage, and customer information. Privacy of utility, customer and other DR entities could be at
3
threat due to these vulnerabilities. This report will mainly focus on the security and privacy issues
and the corresponding solutions.
1. 1 Introduction to Demand Response Programs
The primary focus of the DR is to provide the customer with specific set of actions such as
dynamic pricing or a bidding program. The Demand Response program include strategies such as
reducing electric loads by dimming electric lights when not used, changing thermostat
temperature, turning off/on electrical appliances etc. These activities are generated when pricing
information is sent to the customers or the energy-management and control system (EMCS) at the
customer’s site to respond to the pricing signals. Hence, the customer may decrease demand (or
shed load) during higher electricity price or increase demand (or shift load) during lower
electricity price. The pricing information could be real-time based, tariff-based or some other
combination. DR could be implemented in many different ways based on the type of pricing
signals. The real-time pricing (RTP) requires computer-based response, while the fixed time-ofuse pricing may be manually handled by the customer based upon the time periods and the
pricing. The pricing information is transmitted to the customer on the basis customer’s private
information such as Name, Address, Event Identification, and Event Type. Since the pricing
information could be transmitted electronically or fixed for long period and could be accessed by
the participants of the DR program, it is crucial that the integrity of the pricing signal is
maintained as it could lead to financial impacts on the organization as well as the customers.
Manipulation of the DR signals could also affect the reliability of the grid and privacy of the
customer.
4
1.2 Demand Response Signals and Policies
Customers are informed to shed load through demand response signals sent by the utility. Signals
associated with Real time price, Time-of-use price, critical peak pricing and bidding program are
sent back and forth from the utility to the customer. The pricing signals consists of real-time
pricing (RTP) and time-of-use pricing (ToU). The real-time pricing requires computer-based
response, while the fixed time-of-use pricing may be either manually handled by the customer or
automatically by smart device based upon the DR event. This section provides the basic
understanding of each of these signals with respect to the smart grid application.
1.2.1 Real Time price
It is the pricing information determined based on electrical usage and charges and the signal is
sent to customer during different periods on the basis of wholesale market prices. Smart devices
residing at the resident site measure the electricity usage at a regular interval of 15, 30 to 60
minutes. This electric usage information is then sent to the DR services provider. The pricing
signal is supplied to the customer in a day or hour ahead based on market prices. A statistical
model generated by the utility or the EMCS predicts the real time prices. The real time prices will
be determined based on the geographical location, the service date, and the time of the day in
order to stabilize the electricity usage. For example, the price determined from 1 to 2 pm on
August 30th will be different from the price from 2 to 3pm on the same day. Also, the price from
1 to 2 pm on August 31st will be different from the August 30th price from 1 to 2 pm. Thus,
customers will alter or reduce the usage during most expensive periods to minimize the electricity
consumption and costs.
5
1.2.2 Time-of-use price
This is also known as static time pricing. The pricing information is predetermined ahead of time
or fixed in certain periods based on seasons. The electricity consumption is checked every hour
and prices are generated according to different periods in a day. For example, on a particular day,
the time-of-use price for the summer season would be 5.62cents per KWH from 10 to11 AM.
However, on the same day, price from 10 AM to Noon would be 10.62 cents per KWH. The rates
for peak and off peak energy usage tend to be same which are determined on the annual basis for
each season. Thus, the market price will be the same for every hot summer afternoon if the
demand is at peak as compared to that of the mild summer afternoon when the demand is much
lower.
1.2.3 Critical-Peak Pricing
The Critical Peak Pricing is a DR program which is initiated by the utility and the event is
generally triggered by temperature or by utility under conditions such as special emergency alerts,
forecasted higher market prices or for testing and evaluating purposes. The pricing levels are
predetermined for the peak periods, which cannot be adjusted to the market prices.
1.2.4 Demand Response Bidding Signals
An incentive is paid to the customer to reduce the electric load according to the voluntary bid
based on the load reduction events in this automated DR program. Customers intending to
participate will be provided with defined time before submitting the bids. The utility will review
the submitted bids from the customers. The utility accepts all the bids from the customers until a
specific megawatt limit is met. Day-Ahead bid is the bidding program provides incentives to the
6
customers on hourly basis. The other type of bidding program is the Day-Of-Program in which
the utility sends an alert to the customers to provide a bid on the same day. Thus, customers have
one hour after the Day-Of event to submit the bid. If the customer has already accepted the bid,
the customer can increase the bid for the hours pertaining to Day-Ahead and the Day-of Event
program or submit new bids. Communication between several entities of Demand response such
as utility, EMCS, and customer takes place. Administrative information among the utility and
EMCS such as event ID, program name, customer ID, geographical location, event timing,
opening time of bid, and closing time of bid are required to be propagated among the DR program
entities. Security issues associated with access control, network, platform as well as privacy take
place, which need to be foreseen. In general, customers whose energy usage is inappropriate
during peak times will benefit from the real time pricing scheme.
1.2.5 Capacity Bidding Program Signals
The Capacity Bidding Program (CBP) provides customer with monthly incentive by
predetermined energy usage in KWH. Customers register themselves with a third party to join the
program. If a customer is signed up for another demand response program, then he will not be
allowed to join the CBP [3]. Customer makes monthly nominations for load reduction and
receives capacity payments based on the nominations. Customer provides nomination before
event begins for the respective month. Customer can also carry out the bidding program with a
third party, to take charge of tasks such as acknowledgement of delivery of the event, payment
penalties and receipt of payments. The DR-CBP involves interaction among utilities, EMCS,
third party and the customer. The bidding information is provided in the information system of
the utility as well as that of the third party. Thus, strong access control and secure mechanisms
7
are required. Figure 2 shows the working of CBP automation. A third party provides an online
bidding web portal to collect the bids, display status of day-of and day-ahead program and issue
DR event notification to CBP customers. Aggregator bids through an online bidding web
interface handled by utility five business days before the event starts. Bidding web portal sends
day ahead and day-of signals notifications to Web Services server of utility which are further
broadcasted to aggregator. Aggregator then forwards it to the customer to shift or shed the electric
load.
Figure 2: Communication between aggregator, bidding web portal and customer site [4]
Interactions among third party web portal, third party aggregators, server and customer site are
carried out through secure TLS/SSL communications. Secure measures and access controls are
issued by utility and approval from customer is required before the third party takes part in the
CBP.
8
1.3 Demand Response Events
Demand response signals which propagate within the smart grid are sent to the control systems
situated at the residential site. DR strategies are pre-programmed in the Energy Management
Control System (EMCS) at the residential site. Once the DR signal arrives, the pre-programmed
actions are carried out. For example, lights kept switched on accidently in the backyard can be
dimmed/switched off during the daytime through DR strategies. This plays an effective role in
reducing the electric consumption and customer bill. The DR strategies can implement an action
to reduce the air-conditioning, refrigeration and heating on the basis of the DR event received.
However, the DR events that propagate through wireless communication such as sensor networks,
Zigbee and WiFi at the residential site are vulnerable to attacks. Wired networks such as Ethernet,
DSL used at residential site for smart devices like display devices and load control devices are
also vulnerable to tampering. An attacker can manipulate the DR event by turning on all the
electrical appliances in a particular area of the city. This can create excessive load on the grid and
thus affecting the stability of the grid. Large amount of energy could be wasted leading to
financial loss to the utility as well as the customer. Tampering smart appliances at the residential
site such as smart meter, thermostat or health monitoring devices can have serious impact to the
customer. An attacker can disable services of utility or EMCS, which can cause a hindrance to
propagation of the control signals. Thus, the flow of events should be protected from
manipulation and the entity receiving the events should be authorized and authenticated. Effective
data handling practices are required to protect the integrity, authorization, secrecy, and
confidentiality.
9
1.4 Open Automated Demand Response Communications Infrastructure
Until now Demand Response mechanism was carried out manually by utility personnel through
email, phone calls, pager notification for execution of DR strategies. The DR strategies were
implemented through manually switching off the electrical appliances or an event initiated by a
person through a control system. Thus, an effective means was required to carry out the DR
programs with minimal human intervention. Open Automated Demand Response is data model
developed by Demand Response Research Center (DRRC) which specifies communications data
model for sending and receiving the demand response signals. It provides automation of DR
strategies through standardized and signaling communications for updating the electric usage at
customer location. It provides remote access to the entities of the DR program. It provides
robustness, reliability, and cost effective methods for the DR signals [5]. Figure 3 indicates the
generic Open Automated Demand Response. OpenADR architecture consists of a Demand
Response Automation Server (DRAS) and a DRAS Client. The Demand Response Automation
Server transfers signals corresponding to DR events to notify customers to update energy usage
and DRAS client which resides at the client location listens the incoming signals and sends
automated signals to pre-programmed control systems.
10
Figure 3: Generic Open Automated Demand Response Interface Architecture [6]
The OpenADR architecture has five steps as follows [6]:
1. The utility or ISO issues DR event and price signals and sends it to the DRAS. The DR
event is created based on the market prices.
2. DR event and price services are made available on a DRAS.
3. DRAS clients listen to the incoming DR events at regular intervals. The DRAS client can
be Client Logic and Integrated Relay (CLIR) or Web Service.
4. Pre-programmed DR strategies such as reducing the temperature of heater, turning on/off
the electrical appliances, dimming of lights etc can be implemented based incoming DR
event.
5. EMCS carries out load shed based on DR events and strategies.
11
1.4.1 Demand Response Automation Server (DRAS)
The DRAS is based on a client-server infrastructure is a crucial component in carrying out
automated DR programs. The automation server distributes and receives information among its
entities such as utilities, ISOs, and facility site. The purpose of the DRAS is to automate dynamic
pricing and reliable 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. A secure and reliable
communication is required among the interfaces as well as proper access control mechanisms
among the personnel’s associated with the utility and its sub-systems such as EMCS, maintenance
operator for the customer site smart devices and third party organizations.
Figure 4 describes DRAS interface functions divided into three groups
1. Utility and ISO Operator Interfaces
2. Participant Operator interfaces
3. DRAS Client Interfaces
12
Figure 4: DRAS Interfaces [5]
The interface can be implemented through WSDL or SOAP. XML can be used for the data model
and the entities. The OpenADR specification is used to carry out interoperability between the
utility and the customers.
1.5 Privacy in Demand Response
The Demand response programs are associated with transferring the pricing signals, energy
usage, customer private information, and meter usage. The information such as temperature and
energy usage are monitored, collected and analyzed by utility and EMCS. The transmission of
information generally takes places through internet or through broadcasting. Large amount of
data will be collected and analyzed from the smart devices such as smart meters, thermostats, and
wireless sensors residing at the residential site and exposure to this critical information can create
concern among the customers as well as the providers. Security threats can lead to exposure of
13
information and thus leading to privacy concern for the customer as well as the utility. Utilities
and third-party for demand response providers need to follow standard privacy policies and
standard defense mechanisms for protecting the privacy of personal information.
1.6 Related work for Demand Response
Demand response carried out so far by Pacific Gas and Electric (PG&E) and San Diego Gas and
Electric (SDG&E) have been manual or semi-automated. However, a more flexible, robust and
reliable approach for the smart grid was required for reduction of electric consumption. The
Demand Response Research Center (DRRC) led by Lawrence Berkeley National Laboratory has
carried out considerable amount of work for the demand response programs; this organization is
dedicated to proposing technologies, policies, strategies and standards for the demand response
programs. The research center is working over Open Automated Demand Response to facilitate
secure communication between utility and customer using electric and price DR signals [6].
DRRC has carried out a field test by using XML-based Web Service Oriented Architecture
(SOA) in a large commercial building. The field test has proven that OpenADR is a reliable
resource that ensures stable and economical operation of DR pricing and control signals in the
smart grid. OpenADR will also allow integration Distributed Energy Resources, Plug-in-electric
vehicle as well as other Home Area network devices. Currently PG&E is carrying out peak
pricing program performed by Lawrence Berkeley National Laboratory (LBNL) through
Automated Demand Response (Auto-DR) by using XML-based communications with Energy
Information Systems and Energy Management and Control Systems (EMCS). LBNL has
conducted a research to demonstrate automation of load shedding in 27 sites and reducing the
demand by 10% through OpenADR [6]. The HoneyWell OpenADR is currently providing 80MW
of demand response and will support customers with the critical peak pricing information [7]. In
14
order to allow the customers to pre-program the temperature settings as well update the room
temperature with the incoming automated DR signals, companies such as HoneyWell,
Consolidated Edison Company and EnergyStar have come up with graphical user interface
programmable thermostats to set the temperature manually as well as through internet for the
corresponding DR programs. Honeywell provides a two-way communication through
programmable thermostat and in home gateway to carry out real time load shedding through DR
signals. To carry out secure and energy efficient communication among the smart appliances in
DR program, Zigbee Alliance developed a wireless communication specification for home
automation. Smart grid will lead to widespread management initiatives, installation of smart
devices, interaction among several smart grid entities and third party agencies. This rises privacy
concern for the customers and energy providers for information getting into the wrong hands.
Research by National Institute of Standards and Technology (NIST) and the office of Information
and Privacy Commissioner, Ontario (IPC) found out privacy issues, laws and principals for the
smart grid [8]. They also worked to find best practices associated with the in-home devices and
pertaining wireless networks. The National Institute of Standards and Technology and the U.S.
Federal Communications Commission have adopted some the concepts defined in Privacy by
design [8] issued by IPC.
Demand response also requires bottom up practices to identify the future concerns for the demand
response smart grid. NIST’s Cyber Security Coordination Task Group (CSCTG) looks forward to
carrying out potential research and development for issues related to interfaces, protocols,
software and hardware applications, and secures mechanism.
15
1.7 Goal of the project
The goal of this project was to carry out a research on the security and privacy issues and its
pertaining solutions in Demand Response programs as well as analyzing several aspects
associated with entities of the Demand Response systems in Smart Grid. This report is structured
as follows; Chapter 2 deals with security issues related to demand response program. It illustrates
several impacts of threats and attacks on interfaces, protocols, private information and
information flow among entities involved with DR programs. Chapter 3 pertains to the best
practices associated with the security and privacy issues. It provides an approach for cost and
energy effective measures for solutions associated with security and privacy concerns. It covers
proper data handling practices for enforcing security goals of confidentiality, integrity,
availability, and accountability. Some of the security solutions considered for demand response
are currently considered to be inadequate for a critical infrastructure such as Smart Grid. These
solutions are recognized as research topics that are discussed in Chapter 4. Chapter 5 deals with
strength, weakness and future work for the demand response program in smart grid.
16
Chapter 2
SECURITY ISSUES IN DEMAND RESPONSE
2.1 Overview
The Demand Response programs consist of strategies for increasing or decreasing electric loads,
electric usage information, and changing temperature. Communication channels used could be
wireless communication through sensor network, Zigbee in home area network, wired
communication through Ethernet or plain old telephone service (POTS). The DR programs
interact with several components of the Smart Grid for the information flow consisting of
sensitive information such as personal identities, activities, location information, financial
information, user profiles, and connections among the smart grid entities. The interaction takes
place through interface which needs to be secured by providing confidentiality, authentication,
non-repudiation, integrity, availability and accountability. DR Entities such as utility, EMCS,
DRAS, participant manager as well as the smart devices associated with demand response
program can be vulnerable to security threats. Figure 5 indicates interaction among the Smart
Grid entities for the demand response programs.
Figure 5: Demand Response Interaction in Smart Grid [9]
17
2.2 Security Concerns in Demand Response
2.2.1 Confidentiality
The transfer of information related to electric usage, metering usage, and customer information,
needs to be confidential and secured from unauthorized access from an adversary. In wired and
wireless communication, a leak of signal consisting of DR program information can lead to
unauthorized access and non-detectable use of techniques to obtain the information. Wired
communication can also be attacked through physical access to the Local Area Network (LAN)
device. Eavesdropping, data manipulation, and denial of service attacks can lead to exposure of
customer private information and administrative information related to utility and its sub-systems.
For example, an attacker could use network-scanning tools to study the transfer of DR events
from the broadcaster or sensor networks to the smart devices at the residential site and obtain
customer information such as device ID, geographical location, and energy usage. This way the
attacker will be able to analyze the lifestyle of the resident and utilize this information for
malicious activities such as home invasion.
2.2.2 Authentication
Authentication ensures the validity of the claimed entities of the DR program and provides
assurance that the entity is not attempting to masquerade or carry out unauthorized replay of DR
message. The components of the DR system, such as Smart Devices, Energy Management
System (EMS), DR services provider, smart meter and third party organizations must be
authenticated to communicate with each other. Authorized entities of the DR system should be
authenticated on the basis of access control. It is also necessary to authenticate the source sending
the DR signal to the corresponding entity in the DR program. A failed authentication can lead an
18
adversary to modify or gain access to the DR control services for unauthorized access to the DR
devices. For example, a failed authentication of the utility or third party personnel can modify the
DR event and result in incorrect updating of the energy usage at the resident site. At the
residential site, failure to achieve authentication of the smart meter can send incorrect energy
usage which in turn can affect the billing of the customer.
2.2.3 Integrity
Unauthorized manipulations of information can be related to electric usage, customer
information, DR control signals, and billing information. Access to each of this information can
allow an attacker to turn on/off the electrical devices or manipulate the load, which could affect
the stability and reliability of the grid. Manipulating the pricing information and customer
information could adversely affect the privacy and financial aspects of the customer and utility.
An insider attack by personnel’s within the utility and its sub-systems or the third party
organization can also carry out manipulation for DR registration program, control signals sent to
the corresponding DR entities such as EMCS, smart devices and third party maintenance
operators. An outsider attacker can carry out combination of several attacks such as
eavesdropping and scanning the network to determine the flow of DR information and then
further carry out data manipulation attack by changing the contents of the DR signals.
2.2.4 Availability
Availability of information and devices taking part in the DR program are required to fulfill their
respective purpose. Customer, pricing and electric information propagated among the DR entities
need to maintain integrity, confidentiality and availability at all times. Real time load information
transmitted between DR entities such as DR services provider, customer EMS and smart devices
19
needs to be available. Unavailability of information among DR entities could affect the grid
stability and financial aspects for customers and utility. Failure to achieve timely DR information
in the grid can lead to incorrect load control mechanisms. For example, if DR event to turn the
AC off is not available to the EMCS during peak hours, then it will not be able to carry out the
pre-programmed DR strategies for customer site for load management. Load control devices will
not be able to carry out appropriate action if information is unavailable at resident site. Attacks
linked to Denial-of-Service attack can lead the DRAS, broadcaster, communicating networks
such as sensor network, Zigbee or smart devices to hinder the DR program. For example, an
attacker can flood the communication channels or crash the services of DRAS, broadcaster or
other networking devices in order to discontinue the information flow to its destination or access
to the devices/service.
2.2.5 Accountability
Accountability acknowledges the responsibility of the actions and traces the actions taken for a
successful DR program. One can trace the DR event after it passes through the communication
channel, so that if an attack takes place, its causes can be determined and hold entity accountable
and responsible for attack. Failure to achieve it can lead to disagreement between the parties
through incorrect information associated with the meter, EMS or DR services provider. For
example, when DR signals propagate from utility to resident site, there must be a way to confirm
whether resident received DR events information and updated the energy usage based on DR
events received. In other case, the resident may deny receiving DR event information. A failed
trust can lead to a dissatisfied customer; however, through accountability it can be regained.
Information associated with accountability is stored within the storage system which requires
effective access control. Accountability is not only a concern for the customers, but also a
20
concern among the utility and its sub-systems. For example, an attacker’s modification of the DR
event sent from DRAS to EMCS can lead to disagreement which can be resolved through
accountability by utilizing auditing through audit logs.
2.2.6 Access Control
Access control polices should be determined for authorized personnel to limit access of critical
information through authentication, authorization and accountability to determine who can log
into the system and which users are accessing the resources. Several entities in demand response
collect and transfer DR information to respective sub-entities. DR personnel carries out
registration, configuration, execution, and maintenance of DR program based on access rights
assigned to them. The utility should carry out tasks such as managing, reviewing, activating,
updating, disabling and deleting accounts of DR personnel’s from time to time to track proper
access controls.
2.2.6.1 Access Control Polices
Access control polices determine who can access the resources, under what circumstances the
access should be granted, and how the access should by managed. Mandatory access control
(MAC) policy provides users with access rights to resources. The decision of the policy is made
by a central authority of the organization, not by individual owner of resource, and the owner
cannot change access rights. It can be used for highly sensitive administrative information of
utility, DRAS and participant site. A central authority makes access decisions for operators at
utility, DRAS and facility site. Operators cannot modify or assign these access decisions.
Encryption based access control can also be used to validate and authorize a user, where receiver
decrypts the encrypted DR information through private key. However, entire DR information is
vulnerable to threats if the private key is lost during transaction. Roles can also be assigned by
21
utility through Role Based Access Control to restrict access to resources from unauthorized users.
Access rights are grouped by role name, and the use of resources is restricted to authorized
individuals. User roles can be revoked easily, new roles can be created based on job assignments
and old roles can be deleted as organizational operations change and evolve. Roles are assigned to
participant operator, utility operator, third party aggregators, third party installers and
maintenance operators based on their job functions. Utility administrator can also enforce
separation of duty along with RBAC mechanism to DR personnel’s. For example, in DR a utility
operator will have access rights to add DR event in the information system of utility and DRAS
but will not be able update DR event received from DRAS in the information system.
2.2.6.2 Access Control Mechanism
Access control mechanisms such as capability access control and access control lists provide
security attribute for users and resources for the access control policies discussed in section
2.2.6.1. User attributes consists of user identifiers, groups, and roles assigned to users and
resource attribute consists of sensitivity labels, types, or access control lists. Access control
mechanisms such as access control list (ACL) provide with defined privileges for granting or
denying access for a specified user or groups of users to prevent inappropriate access. ACL
provides information of resource or group owner and associated access rights such as read, add,
delete and update DR information. Table 1, shows an example of access control list in AutoDR
Object
Subject
File_DR event info: Read
Program notifier
File_DR event in DRAS:Read
DRAS event notifier
File_OperatorReport of DRAS :Read
Utility Operator
Table 1: Simplified example of ACL for AutoDR
22
Other form of access control mechanism is capability list. A capability list consists of owner
information and specifies operations associated with resource that the user can access. Table 2,
show example of capability list in AutoDR.
Subject
Capability
Object: Operations
Utility Operator
Program notifier
DRAS event notifier
Process_Set up DR event
File_OperatorReport of DRAS :read
File_DR event info: read
Process_initiateDR event in DRAS
File_DR event DRAS:
Process_Execute DR event at customer
read
site
Table 2: Capability list for AutoDR
Failure to achieve access control mechanism can lead to insider threat within the organization.
For example, a utility operator can provide incorrect DR event information associated with
geographical location and customer information thus affecting the billing information and privacy
of the customer. Access control is also required for the remote access such as wireless network
and mobile devices. A DR event propagated among the smart devices through wireless
communication require remote access methods. The remote access methods such as
authentication among the smart devices and the utility are required to take place.
2.2.7 Data Transfer
The demand response event which is transferred back and forth from the utility and its subsystems to the customer needs to be secured from manipulation or unauthorized access. The
devices and entities should send secured acknowledgements. Failure to achieve secure
mechanisms for DR event transfer can allow an attacker to carry out numerous attacks. An
attacker can eavesdrop to scan transmission of packets over the network through tools such as
protocol analyzer and gain unauthorized access to carry out malicious activities such as
modifying DR event, collecting information related to source and destination, message replay or
23
fake DR event injection. An adversary acting as man-in-middle can change the DR information,
network configuration, add or remove intercepted message to cause communication and DR
services disturbance. Modification of DR information such as incorrect geographical location,
energy usage and smart device information can affect the electric bill of the consumer. For
example, TLS communication used in OpenADR is vulnerable to man-in-middle attacks. An
attacker can scan the transmission of DR packets between DRAS and participant site and inject a
false DR message to switch on AC during peak hours and thus affecting customer bill.
2.2.8 Third Party Data Access
Third party will take part in DR program in the form of vendors, installers, maintenance operators
for smart devices and handling DR information for billing purposes. Figure 6, indicates
relationship between third party, resource owner (resident owner) and resource custodian (utility)
for the third party data access. Residential customer interacts with the utility to select a service
from the third party and grants permission to the third party by notifying utility to share its
information. Utility interacts with third party to indicate service requested by the resource owner
and provides resource owner’s information to the third party.
24
Figure 6: Relationship between Third Party, Resource Owner and Resource Custodian [10]
The Figure 7, below indicates the information flow in DR program with third party. Resource
Owner is a residential electric utility customer who grants access to electricity usage information
to third party. The third party is a value-added service provider to offer services such as energy
consumption analysis, monitoring and managing the electricity usage. The transmission and
distribution service provider (TDSP) provides electricity service to the customer and handles any
HAN based communications. A retail electric provider (REP) manages functions such as billing
through utility’s perspective. In some scenarios, the third party could also play the role of REP for
billing purposes by accessing customer’s electricity usage data. The Resource Custodian is a
customer portal operated as an independent entity. However, in some cases the customer portal is
collectively run by the TDSP’s. The customer portal accesses the customer's electricity usage data
and shares this data with third parties based on customer's permission. Thus, the customer portal
provides the customer to manage and share data with third-party. A customer can modify
permissions granted to third party, by providing the list of permissions to the utility. The utility
25
further sends the modified permissions to third party to update in its system. The communication
takes place through shared resource key [10]. However, if the shared key is lost during
transaction, then it can lead to several attacks. Public key cryptography could be used initially to
validate the source and exchange the shared resource key. After which this shared key can be
used to exchange the information among customer, utility and third party.
Figure 7: Information flow in DR program with Third Party [10]
2.2.8.1 Security concerns
Information accessed from customer site such as energy usage needs to be handled through
proper secure and access control mechanism. The resident is not in direct control of the
information provided to the third party. It needs to interact with the utility to identify what and
when the information is provided to third party. Real time electricity information obtained from
smart meter could reveal daily schedule of the customers such as frequency when they are away
26
from house, which devices are used, what type of alarm system is used or determine the presence
of medical equipment. Thus, personal information should be provided to third party by utility that
is enough to provide the service. Failure to achieve proper access control mechanism or audit
mechanism can lead the third party to share the customer information to other unauthorized
organizations or misuse it for their own purposes.
2.3 Technological issues in Smart Devices
The demand response program serves as a measure to control electricity as well as influence the
reduction in electricity demand. The management of demand relies highly on energy efficient
devices and good operating practice of electricity. To carry out the DR strategies it is crucial to
determine the large energy consuming devices such as air conditioner, heater, and pool pump
residing at the customer’s place as well the number of hours these devices operate. The Figure 8
indicates several smart devices such as display devices, smart meter, load control devices and
programmable thermostat used in residential as well as commercial sector to manage the energy
usage. This section determines the essential smart devices used for the DR program and their
respective issues.
27
Figure 8: Demand response in residential and commercial area [11]
2.3.1 Smart Meters
Smart meter provide two-way communication between the meter at resident site and utility. Smart
meters gather hourly real time electric usage information from in-home devices such as smart
thermostat and provide it back to utility through wireless communication. PG&E uses radio
frequency (RF) network to send smart meter data to a nearest network access point. Each access
point collects data, encrypts, routes it via relay devices and sends to the utility. The system uses
mesh technology, which allows smart meters and sensor devices to securely route smart meter
data through relay devices. Smart meters will be communicating upstream with utility and
downstream with home area network through wireless communication. An attacker can switch off
smart meters remotely by manipulating DR message to discontinue load management at resident
28
site. The DR event to shut off high wattage electrical appliances would not be executed since the
smart meter is switched off at resident site. If this attack is carried out on large scale to numerous
meters in the city it can cause blackout and high energy cost. Deployment, monitoring and
maintenance of smart meters by the utility and third party personnel’s can pose a threat to privacy
of the customer if proper access control mechanisms are not met. An attacker can intercept
signals received from HAN and electric usage information sent from smart meter to utility. An
attacker can replicate device within the HAN, leading smart meter to detect wrong reading. In
general, smart meter data is used for customer billing purposes; manipulation of smart meter data
can affect confidentiality and integrity of data; affecting financial aspects of utility and customer.
This can also affect meter reading which is provided through two-way wireless communication
between smart meter and home energy management software applications or energy management
display devices. According to Pike Research [12], utility network, including Neighborhood Area
Network (NAN) and HAN domain encrypt the smart meter data within their domains. The smart
meter decrypts the received data from one domain and encrypts data to send it to another domain,
however, data remaining on the smart meter for a short period will be unencrypted which could
be lead smart meter to be comprised. An attacker can eavesdrop by attaching a rouge device to
intercept transfer of information to other devices causing concerns in customer privacy.
2.3.2 Load Management Devices
In automated DR, utility sends DR event to resident site via EMCS or aggregator to balance
supply of electricity for load management by updating or controlling the electricity. Utility preprograms and controls the devices during peak hours to switch off/on the appliance. Aggregator
can be third party or utility owned to shift/shed load at the resident site. Customers can appoint
third party aggregator for DR program. Aggregator should collect smart device data and customer
29
personal information after customer’s approval. Aggregator sends the DR event to EMCS or
directly to smart devices at resident side. Once the DR event reaches at load management
devices, they switch on/off high wattage electrical appliances. The load management device is
placed near electrical appliances such as air/heat/water unit which generally consume more
electricity during peak hours. Aggregator/EMCS sends feedback to the utility regarding load
reduction information such as shed/shift data in KWH, DR event type, DR event ID and resident
site ID. Effective load management carried out by utility provides a reliable and blackout free
grid. Security and privacy mechanism should be considered before designing these control
devices. This section discusses the issues in load management devices through load control
devices, smart thermostat and energy information display.
2.3.2.1 Load Control Devices
Load Control Devices control the power consumption for high voltage load devices such as air
conditioner, heater/water units and pool pumps. Load controlling can be carried out through oneway or two-way communication. In one-way communication, the utility program operator sends
the load control signals to the customer site. Usually, one way communication is used for sending
high price levels without the need for home devices to respond back to the program operator.
Real time two-way communication between utility and load control devices can be carried out via
TCP/IP [13]. Two-way communication can enable the transmission of information back to the
program operator about whether remote switching has been successful, current status of the load
and data from load measurement device (smart meter). This facilitates the program operator to
receive specific information about the quantity and timing of any load reduction achieved. The
load control devices consist of a relay switch to accept the sensitive DR information from the
utility. Utility or third party will install and maintain load control devices at customer site. Failure
30
to achieve proper access control mechanism for installation and maintenance of the load control
modules can hinder the load control. An attacker can carry out interception of incoming DR
signals, denial of service attacks by flooding the load control device, injection of false DR signals
or tampering the device. These attacks can have a significant impact on the customer bill as well
as the reliability of the grid. For example, an attacker can turn on all the air conditioner units
causing sudden increase in the load or flood device with large amount of load control signals. An
attacker could also replicate the device in order to carry out masquerading. The device is required
to consist of cryptographic keys for authentication purposes; failure to protect these keys can
allow an attacker to tamper the device.
2.3.2.2 Energy Information Displays/Web Portal devices
Real time energy usage information can also be provided to customer to track consumption of
energy through a graphical user interface. Companies such as Google PowerMeter, Agilewaves,
Tendrill, Energy Tracking, and Energy Lens allow consumers to view their energy usage through
LCD display, website or desktop software within a specific interval of time. Energy usage
information can be viewed in the form of charts and tables related to daily and monthly usage.
These applications also carry out consumption comparison and predict energy usage based on
historical usage. However, these display devices are vulnerable to tampering, manipulation of
data as well access to confidential and private information. The customer will not be able to view
or estimate the usage if the display device is tampered. The customer will not be able to gain a
clear idea of when to turn off the electrical appliances during peak hours. Manipulation of smart
meter data can lead to incorrect information on the display device. Failure to achieve
authentication between the smart meter and the display device can allow an attacker to view
energy usage information. An adversary can intercept and monitor the wireless communication
31
between the smart meter and the display devices. An attacker may inject some false smart data or
disrupt smart meter reading which could cause false reading on the display devices. It is crucial to
determine that the display devices do not provide information to the manufacturers of these
devices. Only an authorized and authenticated customer, failure to do so can affect the privacy of
the customer, should view the data.
2.3.2.3 Smart Thermostats
Utility broadcasts the DR signals to customer site to update the temperature. Smart Thermostat
residing at the resident site accepts these broadcasted DR signals and updates the temperature
accordingly. Programmable Thermostat (PCT) will be provided by the utility, which will be
compatible with the DR communication system. The Utility will carry out one-way default
communications sending pricing information to the PCT. The pricing information is sent on the
basis of customer information such as name, address, PCT device ID and DR event ID to the
PCT. PCT uses pre-programmed temperature setting based on specific price rules and adjusts the
room’s temperature according to DR event. PCT will communicate at regular intervals with other
in-home devices such as outlets, meters through Zigbee communication to manage and control
the load of electrical appliances. Graphical user interface of smart thermostat will provide
information such as pending DR signals, current electric price, load control events and list of
electrical appliances turned on/off to customer. Thus, the customer will be able to monitor electric
usage and manage energy loads. The need for wireless and wired communication has led to issues
associated with confidentiality, authentication, integrity and non-repudiation during the transfer
of DR information among utility, smart devices and EMCS. An attacker can tamper with the
device or jam the communication; thus preventing the device to perform its operations. Traffic
analysis can be carried out even if the message is encrypted during communication between
32
utility, in-home devices and smart meter interacting with the thermostat to gain knowledge
regarding energy usage. An attacker can flood the thermostat or manipulate the DR signals.
Insider threat from utility or third party can gain energy usage information and turn off/on devices
through installation and maintenance. Replay attacks can modify the incoming DR signals. Thus,
it is necessary to determine proper data handling practices.
2.3.4 Energy Management Systems
The Energy Management Systems (EMS) consists of tools which are operated by the utility
personnel to monitor, control, and update load at the resident site. The EMS collects and provides
an interface to view real time information by EMCS. The EMS monitors the meters and tracks the
status of the electrical appliance consuming large amount of electricity in real time. The EMS
consists of a software tool used for analyzing and monitoring energy consumption in the form of
charts, tables, and figures by EMCS and facility managers. This allows carrying out effective data
analysis such as when and how was the energy wasted and saved. Figure 9 indicates energy
management software from energy lens depicting the energy usage and wastage on monthly and
daily basis.
Figure 9: Energy management software from Energy Lens [14]
33
Security issues intersect with the utility personnel’s, EMCS and communication network. A
building/facility manager monitoring the energy usage through EMS applications could gather
data and provide it to other third party for fraudulent use. An attacker can intercept the wireless
messages between the EMCS, smart meter, and EMS application. A failed authentication and
authorization to the EMS can allow an intruder to gain confidential information. An attacker
tampering with the smart meter and other in-home devices would be able to increase or reduce the
load; resulting the EMS to gain false information.
2.4 Generic Event-Based Program (GEBP) in OpenADR
The Automated DR carries out demand response management for customer specific location,
energy usage requirements, and energy consumption based on market electric prices. The
OpenADR carries out automation of DR program through three interfaces among utility, DRAS,
and the participant site to send and receive DR signals. Figure 3, demonstrates the three interfaces
of OpenADR. The interface can be implemented through WSDL or SOAP and XML will be used
to exchange DR information among the DR entities. The OpenADR specification is used to carry
out interoperability between the utility and the customers. The DRAS receives the signals from
the utility/ISO and sends it to the appropriate participant to control the energy usage. This section
discusses the use cases of OpenADR and security issues in a generic DR event. The DRAS can be
deployed based on the following [5].

If the DRAS is owned by a third party and operator interfaces are developed by some
other third party, then separate interfaces are required to carry out communication
between the utility and DRAS and from DRAS to the customer site.

If the DRAS and the operator interfaces are developed and deployed by the utility/ISO,
then only one interface is required which is DRAS client interface.
34

If the DRAS is deployed by a third party which also develops the operator interfaces,
then a utility/ISO and DRAS Client interface are required, but the participant operator
interface is not required as the DRAS and the operator interface itself are owned by the
third party.
2.4.1 The OpenADR Use Case Roles
2.4.1.1 Utility Roles
It consists of a program operator, program notifier and a program settlement. Out of these three,
the program operator is a human personnel administrated by utility/ISO. It sends the DR program
signals related to pricing signals. Program notifier and the program settlement can be a subsystem or a human operator [5]. The notifier sends DR signals to the participants through
automation server, whereas the program settlement measures the usage of electricity at resident
site and provides it to the information system of the utility.
2.4.1.2 DRAS Roles
It consists of sub-system known as DRAS Event notifier and Program notifier. The notifier sends
DR event initiated by utility to the participant site based on customer information provided during
registration of DR program. DR event sent to participant site consists of information such as date
and time of the event, date and time of issued event, geographic location and pending DR signals.
2.4.1.3 DRAS Client Roles
It consists of Event Client, Feedback Client and DRAS operator. The event client receives the DR
signals from the automation server (DRAS) and notifies the facility regarding the DR event. It
35
passes on the signal to other client sub-systems at the participant site in order to shed loads. The
DRAS Feedback Client sends feedback information such as shed data, DR program ID,event type
(day ahead or day-of) and load reduction end uses (heating, lighting and air conditioning) to
DRAS. It sets the load status in the DRAS such as customer usage information, and shed info.
2.4.1.4 Participant Roles
Participant site manages the electric usage for the customers who request the DR program. It
consists of the human operator which plays the role of Facility Manager/ Aggregator Manager/
Network Manager, who is responsible for managing the DR program.
2.5 Security Issues in Generic DR event
Figure 10 below describes the use case for Generic Event-Based Program for three AutoDR
scenarios: Program Configuration, Program Execution, and Program Maintenance. Table 3,
shows the components such as Utility, DRAS, participant site, DRAS client and customer
engaged in receiving and delivering the DR events. Security issues such as confidentiality,
authentication, integrity and availability associated with the three scenarios of the generic event
based program are described below.
36
Figure 10: Automated Generic Event-Based Program (GEBP) Use Case [5]
Scenarios
Security Concerns
GEBP Configuration
Confidentiality:
 Unauthorized access of program operator to UIS
and DRAS can result in setting up wrong
information for the GEBP program in the UIS
and DRAS, signing up incorrect participants of
the GEBP program into the UIS and entering
invalid information to DRAS which is further
accessible to the participant manager. Only
authorized operators should have the rights to
access and configure GEBP program in UIS and
DRAS.s
 Unauthorized access of participant manager to
the DRAS and DRAS client can result in
37

GEBP Execution
incorrect information in program schedule
constraints (e.g. time, duration), type of
information (e.g. prices, levels) as part of DR
event, program event information for signal
mapping, account number for settlement,
participant identification and password, and grid
location. This could affect the privacy of the
customer, efficiency of the grid, and affect the
financial aspects of the grid.
Unauthorized access of participant manager can
affect the DRAS client connection with DRAS
which can lead to flow of incorrect DR program
parameters.
Integrity:
 The utility program operator may configure
incorrect GEBP information or program, such as
participant identification and program event
information in the DRAS incorrectly.
 The participant manager may set up the
participant’s site EMCS to respond to DR events
and shed or shift loads inappropriately.
Availability:
 Incorrect configuration information in the DRAS
and DRAS client related to DR program
parameters, DRAS client connection information
such as DRAS IP address by the operator can
lead to failure in communication.
 An attacker can flood the communication
channel and the DRAS by carrying out flood
attacks causing the DRAS to suspend its
services.
Confidentiality:
 The adversaries could gain knowledge of the
event information sent between the DRAS event
notifier and DRAS client and manipulate it in
several ways, such as load shedding or shifting
and information collecting. This information
includes date and time of the event, participant’s
account numbers, mode and pending signals.
 The adversaries could gain knowledge of
feedback information (shed information, facility
usage information) sent between the DRAS
feedback client at the participant site to the
DRAS.
38
Integrity:
 The GEBP DR event information from event
notifier sent from the DRAS to the DRAS client
could be manipulated by adversaries. The
adversary could make use of this information,
such as date and time of the event, mode, and
pending signal in order to shed or shift the
electric loads at the participant site at wills. This
can affect the billing of the electric participants
and could cause instability of the grid.
 Attackers can manipulate the confirmation of DR
message sent by DRAS client to DRAS. The
confirmation message can be sent by the
adversaries instead of by the participant site so
DRAS will not be able to know if the client
actually receives the DR event information and a
wrong action may be taken. This can affect the
efficiency of the grid and also the billing of the
electric participants.
 The system load status, such as shed data in
kW/kWh, near real time load, load reduction
(HVAC, lighting), etc. sent from the DRAS
feedback client to the DRAS could be
manipulated by the adversaries. It can be
mimicked and sent by the adversaries so that the
DRAS will not be able to record the response to
the DR event at the participant site. As a
consequence, the DRAS may not respond or may
make an inappropriate response according to the
false current load status at the participant site.
This can affect the efficiency of the grid and also
the electricity use of the end users.
Availability:
 The event notifier in the DRAS may not notify
the DRAS client in timely manner. As a result,
the DRAS client may not be able to determine
the current event and take the wrong action that
may affect the grid.
 The feedback client in the DRAS client may not
notify the DRAS in timely manner. The DRAS
may not be able to know the current system load
status and take the wrong action that may affect
the grid.
Accountability:
 There must be the way to prove whether DRAS
client actually received DR events information
39
GEBP Maintenance
and shed or shift loads based on the DR events
received. The participant may deny receiving DR
event information.
Confidentiality:
 Unauthorized access control of the utility
program operator could modify, add, delete
facilities and events and to access logs and
operation reports which might affect the
efficiency of grid.
 Confidential information such as communication
status and logs of DRAS and DRAS client could
be viewed by unauthorized access of participant
manager.
Integrity:
 (see GEBP Configuration Scenarios)
Availability:
 The utility program operator cannot get the
operation reports and check status information
from DRAS at any time due to the failure of the
system due to any kinds of error condition and
specific exceptions, such as out of disk, network
failure.
 The participant manager cannot opt out of GEBP
program at any time.
Table 3: Demand Response Generic DR event
2.6 Security Concerns in OpenADR Interfaces
This section focuses on the security concerns based on the information sent between the entities
of the OpenADR such as utility, DRAS, participant site and the residential site. Each table below
describes parties interacting for sending and receiving the DR signals and the overall security
issues that can hinder the propagation of the signals in the OpenADR system. The information
transmitted in the OpenADR is categorized into three groups such as information sent between
Utility to DRAS, Information sent between DRAS to participant, facility or aggregator sites and
Information sent from DRAS clients to DRAS. Since the OpenADR system is based on the
Internet communication, the information transmitted in each DRAS interface must be protected
40
and prevented from any kind of data manipulation such as changing price information and DR
events. The DRAS and DRAS clients need to be authenticated in order to communicate with each
other. In addition, access control to each entity in the OpenADR system is needed to protect from
unauthorized access to the system. If the security goals are breached; adverse impacts could take
place such as the excessive load in the grid leading to blackouts, large financial impacts on both
the utility and participants in DR program and privacy of the utility and customers. Tables 4, 5
and 6 indicate the transfer of DR information and their overall impacts.
Information sent between Utility to DRAS
Event
The
Utility
Program Operator
configures
the
DR
program,
initiates the event
or updates event
information
in
UIS and DRAS
Information transmitted
Program type, date & time of the
event, date and time issued,
geographic location, customer
list (account numbers).
Utility Program
Operator initiates
bid the request in
DRAS
Program type, date and time of
the event, date & time issued,
geographic location, customer
list (account numbers), request
for a bid (RFB) issue date and
time, RFB close time, price
Overall Impacts
Confidentiality (M):
Eavesdropping on this formation is
not
concerned
since
the
information may not regularly
send. However, the information
needs to be protected.
Integrity (M):
Unauthorized manipulation on this
information could affect the DR
program behavior. For example, an
attacker can change the DR
program’s geographic location and
thus affecting a wrong customer
site.
Availability (L):
Failure in communication between
utility and DRAS because of
interception of data or inhibit the
use of any OpenADR component
by an unauthorized. Incorrect
information of event by the
Demand
Response
Program
personnel.
Confidentiality (H):
Eavesdropping on this formation
could result in the leak of bidding
information. The information
needs to be protected.
Integrity (H):
41
offered for load reduction per Unauthorized manipulation on this
time block.
information could affect the
bidding program behavior.
Availability (L):
Failure in communication between
utility and DRAS because of
interception of bidding data by an
unauthorized entity or incorrect
information of event provided by
the Demand Response Program
personnel.
Participant
list
(account Confidentiality (H):
numbers), accept or reject Eavesdropping on this formation
information.
could invade the privacy of the
participant.
Integrity (H):
Unauthorized manipulation on this
information could affect the DR
program behavior, such as
modification of account numbers,
accept or reject bids and customer
list for the DR program.
Availability (L):
Failure in communication between
utility and DRAS because of
interception of data or inhibit the
use of any OpenADR component
by an unauthorized. Incorrect
information of event by the
Demand
Response
Program
personnel.
The
Utility
Program Notifier
gets the updated
DR
event
information from
the
UIS
and
initiates the event
in DRAS.
Table 4: Information sent between Utility to DRAS
Information sent from DRAS to Participant, Facility or Aggregator sites
Event
Demand
response event
information
sent to the
DRAS client at
the participant
site to modify
the energy


Information transmitted
DR event information such as
date and time of the event,
date and time issued mode
and pending signals is sent to
the DRAS client
As well as pending signal for
DRAS client
Overall Impacts
Confidentiality (H):
Eavesdropping can cause invasion
of customer privacy.
Integrity (H):
Unauthorized manipulation on this
information could have financial
impacts on customers and affect the
stability of the grid.
42
usage in the DR
program
Information
sent to the
notifier
consisting of
acceptance or
rejection
notification to
the participant
or facility
manager or
aggregator
This information is provided
through email, phone call or page.
The source needs to be
authenticated and authorized before
sending the signals.
Availability (L):
Failure in communication between
DRAS and participant sites.
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.
Table 5: Information sent from DRAS to Participant, Facility or Aggregator sites
Information sent from DRAS clients to DRAS
Event
DRAS
client
located at the
participant site
sends the load
status
information to
DRAS
Information transmitted
Program identifier, facility or
participant identifier, date and
time of the event (shed or shift),
shed data in kW/kWh, load
reduction end uses (HVAC,
lighting.), event type (Day-Ahead
or Day-of)
Overall Impacts
Confidentiality (H):
Eavesdropping on this formation
could invade the customer privacy.
Integrity (H):
Unauthorized manipulation on this
information could make DRAS not
be able to record the actual
response to the DR events received
of the DRAS client. The DRAS
may make an inappropriate
response to the DR program
corresponding to the false system
load status.
Availability (L):
Failure in communication between
DRAS and DRAS client.
Table 6: Information sent from DRAS clients to DRAS
43
2.7 Threats in OpenADR
A threat is a deliberate unauthorized attempt to access, modify, and cause the service to be
unavailable. DR events propagate through the smart grid through a communication channel. The
smart devices interact with each other as well as the utility through network. Whenever, the
network comes into place there is chance that there are different risks. The threat can be in terms
of a virus, worm or poor network architecture. An attacker can attempt to gain access to resources
through unprotected communication channels. Threats can be caused through external penetration
or internal penetration. The internal penetration is generally through insider personnel with
unauthorized access or improper access control. The external penetration is carried out through an
outsider by tampering a device or penetration through network. This section focuses on possible
attacks in the OpenADR system. Figure 11, below indicates the possible threats which can tamper
with the DR system.
Figure 11: Possible path of attacks on the Demand Response system [15]
44
2.7.1 Reconnaissance attacks
Hacker tries to gain information related to network, its topology, devices within the network and
software used in the devices. There are two types of reconnaissance attacks known as scanning
and eavesdropping. Scanning attacks allow an attacker to scan the entire network and ping to
every IP address in network to find the services such as SMTP, Telnet, FTP, and WWW running
on machines by using port scanning functionality. Eavesdropping attack allows the hacker to
examine the transmission of the packets by using a protocol analyzer tool. An attacker can
capture packets consisting of sensitive information such as password, session tokens and
confidential information sent between the two entities. An attacker can examine the transmission
of information between the two demand response entities to gain knowledge pertaining to energy
usage, device information, customer location and other DR events. Attacker could also examine
information flow from the broadcaster, sensor networks to the smart devices at the residential site.
This can affect the confidentiality and the availability of the DR program. The attacker can carry
out traffic analysis to determine the sequence of DR program and inject malicious code or device.
2.7.2 Access Attacks
The attacker gains access to the network and its resources such as email server and web servers
through password guessing, protocol analyzer and social engineering. These attacks can lead to
man-in-the-middle attack and replay attack. Access attacks such as masquerading, session
hijacking and repudiation can affect integrity, confidentiality and availability. The attacker can
gain unauthorized access and modify the DR configuration information, which can lead to
improper connection with DR entities such as DRAS, participant site and devices at customer
site. Manipulation of DR events can affect the financial aspect, power usage and the monitoring
and controlling information. The hacker manipulates the DR events by breaking DRAS. The
45
opponent can shut down operations of the DRAS to block the flow of information to entities of
demand response. Broadcaster, smart devices such as smart meter, control devices and sensor
network can be disabled by gaining unauthorized access.
2.7.3 Denial of Service Attack (Dos)
The hacker attempts to deny legitimate traffic and user access to a particular resource, or, at the
very least, reduce the quality of service for a resource. The attacker can flood the disk space of
DRAS by sending large messages, trojan horse, virus or worm and thus harming the system. The
DOS attack can be carried out through E-mail bomb, Chargen, CPU hogging, Rerouting attacks
and Smurf attacks. The DOS attack highly affects the availability of services of DRAS, DRAS
client or broadcaster by overloading large volumes of attack traffic.
2.8 Potential vulnerabilities in OpenADR
Threats to OpenADR can affect hardware, software applications, DR information as well network
involved in DR programs. These threats exploit the vulnerabilities in OpenADR to gain benefits
and critical information for destroying the electric grid or creating challenging situations such as
blackout. Several possible attacks on application, transport, network and physical layer can hinder
the demand response program. For instance, an attacker may manipulate the DR control actions
and turn on all air conditioning units causing unexpected and excessive load in the grid which
may lead to black outs and grid instability. At the network or transport layer the attacker causes
denial of service by flooding the head-end IP network with acknowledgements or by intercepting
wireless messages. It is crucial to discuss and analyze the impacts of the potential vulnerabilities
that result in adverse impacts on the operation of the grid via the OpenADR. This section focuses
on the potential vulnerabilities to exploit the OpenADR.
46
2.8.1 People, Policy and Procedure
Proper training associated with policies, security training and awareness program should be
provided to operators involved in the demand response programs. Failure to achieve adequate
security policy and procedure can have a high impact on the security infrastructure of the
OpenADR program. Without sufficient training, the staff cannot be expected to maintain proper
security procedures. This might impact the security of the grid as well as privacy of customer
since an adversary can gain internal knowledge such as passwords, confidential information of
customers and bring malicious programs or hardware to disrupt the system. Utility personnel
could view or misuse the registration information of the customer for the DR program and post
the information to other unauthorized users. Inadequate security and privacy policy can lead to
exposure and risks of employee or customer information, pricing information and energy
information. Insufficient management associated with configuration and modification of the DR
programs, home devices maintenance, hardware, and software of devices and documentation
could affect the DR programs. Insufficient identity validation and background checks can lead
disgruntled insiders, such as the facility manager, or program operators to leak sensitive
information to adversaries. Dishonest insiders such as the facility manager who manages a DRAS
client may not abide by the DR events to shed loads, refuse to comply with the bid obligations or
utilize an energy pricing policy. Failure to provide authorized access can allow an insider attacker
to manipulate the configuration, execution, and maintenance procedures of the DR program. For
example, a program operator may sign up unknown participants to access the DRAS thus
increasing risk of vulnerability. Disgruntled insiders could bring viruses or other malicious
programs into the system through email attachments or expose sensitive DR information to other
unauthorized parties. Sophisticated intrusion detection system, encryption mechanisms and access
control policies should be used to reduce insider attacks. Access control policies based on role
47
and mandatory access control can be used to authorize access to resources. Separation of duties
along with access control mechanism will allow more than one employee to perform certain DR
operations (section 2.2.6). For example, if a single DR employee is responsible for creating,
transferring, modifying, updating, storing and making backups storage can hinder the DR
program. Audit functions can be used to track resource access, network access and user actions.
Inadequate disaster recovery plan pertaining to cyber security issues can lead major grid failure.
For instance, if a failure occurs in DRAS, a notification through email, voice or pager should be
sent to utility or facility manager in AutoDR mechanism.
2.8.2 Platform Vulnerabilities
Poor software practices such as coding errors, software engineering methods in OpenADR,
failure to follow OpenADR specification, poor debugging practices associated with
authentication, authorization and other cryptographic mechanisms can lead to Denial of service
attack(Dos), by-pass authentication, exposure and manipulation of private information.
Inappropriate access control mechanisms for authorization can lead an adversary gaining
privilege to carry out malicious activities to disrupt the DR program. Inadequate password
management such as hard coded passwords in applications and devices associated with DR
program, weak cryptographic technique and poor error handling mechanisms may lead an
opponent to gain unauthorized access in system. Sensitive DR information should be protected
during transmission as well as storage from being exposed or modified. Along with DR
information, information associated with the cryptographic keys, administrative passwords,
security tokens, documents associated with access controls and privacy violation should also be
protected.
48
2.8.3 Network vulnerabilities
Inadequate integrity check can lead to confidentiality and integrity issues for DR control
information, energy usage, and customer private information. DR data should be checked before
it is sent over the network or processed by the devices. Receiving devices that do not comply with
the rules of the protocol or standard should not act according to the DR event. Poorly installed
equipment at the utility or resident site could also leak information. Inappropriate protocol
selection can hinder the information management through exposure of cryptographic keys.
Failure to detect the network traffic or entities responsible to block the communication channel
can lead to man-in-middle attacks as well as denial of service. The network architecture does not
clearly provide security zones used at different network layers [9]. A weak authentication process
of source and keys can lead to unauthorized modification of information and malicious attacks
such as session hijacking, authentication sniffing, DoS, man-in-the-middle attack, etc A clear text
protocol can lead to man in middle attack and session hijacking. Unauthorized access to DRAS
and DRAS client or physical devices can lead a number of hardware attacks such as such as
malicious configurations, micro controller dumping, meter hijacking, etc
49
Chapter 3
BEST PRACTICES FOR DEALING WITH DEMAND RESPONSE RISKS
3.1Overview
Development in communicating technologies such as Internet and Telecommunications has lead
to a new frontier of electricity provision. Smart Grid enables effective energy savings by linking
several entities of grid through enhanced technology. This has lead to a two-way communication
among DR programs to meet the requirements for reducing electricity demand. Demand
Response facilitates to carry out back and forth communication of pricing, customer, energy
usage and financial information by passing it among several entities of smart grid such as utility,
EMCS, aggregator and customer sites. The success of demand response programs is achieved
through timely and reliable communication. The Advanced Metering Infrastructure (AMI) system
provides day-ahead and near real-time information to an Energy Management Control System
(EMCS) to moderate electricity demand based on DR signals received. A Home Area Network
(HAN) distributes energy management information to all HAN devices in building or home.
Several modes of attacks upon IT communications ranging from attackers gaining physical access
or remote access can take place. Security roles are required to limit the access to several entities
of the DR programs. An attacker may be able to obtain confidential information and increase or
decrease the load by modifying the message. Failure to provide confidentiality, integrity,
authentication and privacy for DR information can cause severe malfunctions in financial sector
of the grid, customer’s private information and grid reliability. It is necessary to leverage existing
security policies and standards for communications in the DR program. This chapter provides
potential best practices for related security issues in DR program.
50
3.2 Secure Information Flow
Information related to prices, customer private information, and energy usages are transmitted
among several channels and entities of demand response program. It is crucial that the
transmission of the data takes place in a secure manner. Communications between Demand
Response components must be strongly authenticated. To ensure integrity of the message, mutual
and message authentication should be used between these DR entities. Data confidentiality can be
provided through encryption. Secure communication through appropriate communication
protocols, such as Transport Layer Security (TLS) protocol, Internet Protocol Security (IPSec),
Wireless Fidelity (WiFi) associated with IEEE 802.11i for wireless local area network (WLAN)
and ZigBee with elliptic curve cryptography (ECC) for sensor networks, are needed to protect
network traffic.
3.3 Secure Data Handling Practices
Transfer of confidential and private information related to customer’s energy usage, location, and
home device information takes place among DR entities. Third party contractors such as EMCS
or aggregators are responsible for analyzing the received energy information and for sending preprogrammed pricing signals to customer site. It is crucial to protect confidentiality, integrity, and
privacy of customer information by preventing third party to disclose, modify or send incorrect
information to customer site. 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 customer’s energy usage information must be specified to customer. Cryptographic
mechanisms (discussed in section 3.7) for transfer of DR information should be used among
utility, customer and third party contractors.
51
3.4 Access control
Access control ensures that access of resources among demand response system is provided to
authorize personnel. Identification and authentication is a prerequisite for granting access to
resources in demand response system. Identification process verifies the identity of a user,
process, or component through password or a cryptographic token whereas authentication is
challenge process to validate identity of entity. Each DR entity needs to be authenticated to carry
out its individual operation. Access control policies and procedures need to be complied with
federal laws, policies, standards and directives. Role Based Access Control and Mandatory
Access Control for personnel within utility and its sub-systems should be used. A well-formed
document mentioning the roles, responsibilities, and management should be provided to the DR
entities. For example, home devices should not send control signals to utility but only energy
usage and customer information. Installer and maintenance personnel hired by utility or third
party should have appropriate access control through authentication and authorization
mechanisms before accessing devices. Access control lists and capability list (see section 2.2.6.2)
with access privileges can be used to enforce necessary security mechanisms. Access control lists
and capability list need to be managed through adding, altering, and removing access rights from
time to time.
3.5 Account Management
The utility should manage and maintain the DR system by creating, activating, modifying,
analyzing, disabling, and deleting accounts of customer, utility employees and third party
contractors. The system accounts need to be maintained by analyzing on the basis of criticality of
organization. Account management includes the identification of account types (i.e., individual,
group, role based, device-based, and system), establishment of conditions for group membership,
52
and assignment of associated authorizations. Access rights need to be provided to utility
personnel based on official duties. Modification within the account management system needs to
be notified to the account manager of the demand response system.
3.6 Identifier Management
Resident allows the utility and EMCS to monitor and control appliances such as downing the AC
during peak load to reduce heavy energy usage. Homeowners will use portal software supplied by
third party or utility to view the energy usage. This requires identity management to authenticate
and access controls mechanism between resident and the utility. The utility should manage user
identification by uniquely identifying and verifying each user. Identification involves linking an
identifier to a person or device. Utility administrators, device manufactures or third party
contractors issue a digital identity to device/user or string ID corresponding to the user. The
identifier may be a PKI certificate or stored information in the form of identity and password.
Access to DR entities requires authentication to ensure accountability. Authentication through
cryptographic mechanisms (section 3.7) verifies the identity claimed by the entity. Digital
certificates can be used for authentication between the utility and other DR entities. Thus, utilities
must have a solid PKI infrastructure and deploy access control. Roles assigned to authenticated
user by utility allow authorized operations and access to resources. Figure 12, shows an example
of providing an identity and authenticating a user.
53
Figure 12: Example of providing identity and authenticating a user [16]
User identification should be deleted after a pre-determined period of inactivity. The utility
should be able to carry out secure mechanisms for storing the user identities. User identities can
be revoked easily and new identities can be created based on new registered users.
3.7 Cryptographic mechanisms for demand response
This section discusses the cryptographic mechanism to overcome issues related to network and
smart devices. A successful cryptographic mechanism can be achieved through use of encryption,
digital signatures and management of keys. An attacker can carry out traffic analysis, capture data
packets within network through network-sniffing applications and inject/modify contents of the
DR event. For example, sensor network is be used to monitor and control energy usage at resident
54
site. The thermostat uses Zigbee communication to monitor sensor nodes and updates the room
temperature for related electrical appliances. The smart meter records the electric consumption
through Zigbee for monitoring energy usage and sends it to EMCS/utility. In this example the
smart devices, utility and its sub-systems send back and forth the information through wireless
communication, which is more vulnerable to attacks. It is necessary that entities communicating
in DR program are authenticated and data is not modified or lost in transaction. This section
describes cost and energy efficient cryptographic mechanisms for the DR program.
3.7.1 Encryption
Exchange of DR information takes place among home devices, EMCS and utility through various
domains such as WAN, NAN and HAN. Attempts to tampering, eavesdropping, and modification
of transmitted data and insertion of unauthorized messages into network can expose critical
information. To counter such threats, flexible and cost effective mechanisms for secure
communication are essential. The DR system must be able to carry out source authentication to
ensure that incoming transmission is from a valid source and that an unauthorized entity has not
modified the message. Secure communication can be achieved by employing strong cryptography
to ensure confidentiality, integrity, authentication, and non-repudiation according to cost and
energy savings requirements of Smart Gird. Modern encryption algorithms can be divided into
two categories, symmetric and asymmetric.
3.7.1.1 Symmetric Key Encryption
Symmetric key encryption used for authentication purposes between sender and receiver uses the
same shared (private) key over the network. Symmetric cryptography can be used for those
55
applications where public key cryptography is found to be computational expensive. Figure 13,
shows how a single symmetric key (shared key) is used in symmetric key encryption.
Figure 13: Symmetric Key Encryption [17]
A common example of symmetric cryptography is 3DES (Triple Data Encryption Standard).This
encryption technique can provide confidentiality and authentication through challenge-response
protocols. Message authentication can be provided by using message authentication code (MAC).
The MAC algorithm accepts the secret key along with message and outputs a MAC
(authentication tag). The receiver uses the same shared key to verify the MAC to determine if the
message was modified or not. Figure 14, demonstrates the use of MAC for message
authentication.
Figure 14: MAC for message authentication [18]
56
The MAC algorithm could be a hash function such as SHA/MD5 or DES algorithm. The same
shared key can be used among the pair of nodes communicating in the network for authentication.
Key distribution and management of shared key can be done through Kerberos. Thus, even if
shared key is compromised the attacker will not be able to attack the other nodes in the network,
as he would not have the shared key for those pair of nodes. A shortcoming for symmetric key
cryptography is the key distribution as communicating nodes in network need to know shared key
beforehand and this increases the chances of eavesdropping. For example, in a network consisting
of n nodes and a pair wise key distribution between the two nodes would require n-1 keys in each
node which is n(n-1)/2 per network leading to O(n2) , which does not scale efficiently for a large
network. Moreover, addition and removal of node and re-keying is complex. Thus, encryption
proves to be costly if large numbers of nodes are present within network. A solution to this would
be to create keys only when it is necessary through a trusted Key Distribution Center (KDC).
Kerberos system uses KDC to provide a shared key known to every host and KDC. Thus,
employing a KDC requires O(n) keys. Another option is to use single global key. However, if this
key is compromised it will highly affect security of the entire network. The attacker could use this
compromised key to attack all the nodes and gain confidential information.
3.7.1.2 Asymmetric Key encryption
The other form of encryption is the Asymmetric Key encryption (public key cryptography).
Figure 15, shows the working of Public key cryptography.
57
Figure 15: Asymmetric Cryptography [17]
Public key encryption uses key pairs of public and private key between two entities required to
communicate for authentication. Public key is published through Certificate Authority. The
process of providing public key by Certificate Authority to the requestor is discussed in section
3.7.3. Internet Protocols such as SSL and IPSec use public key cryptography to carry out
authentication and to derive shared keys. Asymmetric algorithms provide flexible key
management and authentication. However, they are relatively slower than symmetric
cryptographic algorithms because of the size of the cipher text and they are computationally
complex. Demand response programs are transferred between utility and customer site, which are
handled by smart devices. These smart devices interact with other devices based on DR event. It
is necessary to know resource and computing constraints of these devices used in wireless
communication while carrying out the security mechanisms. According to [19], because of
criticality of energy and limited power of several smart devices at resident site, public key
cryptography through ECC (Elliptic-Curve Cryptography) has been proposed to be used instead
of symmetric key encryption. Communicating smart devices, which use symmetric key
encryption technique such as 128-bit Advance Encryption Standard (AES) through Zigbee
protocol, suffer from the shared key being compromised. Moreover, key distribution is expensive
as Zigbee works on a mesh network because of which all devices need to store keys of all of the
pair nodes. Thus, for a large number of devices, using symmetric encryption would be costly. A
solution for this would be to use public key encryption through Elliptic-Curve Cryptography
58
(ECC). According to [19], ECC with 160-bit key provides equivalent encryption to AES
algorithm with 128-bit key. ECC offers the same cryptographic advantages such as Digital
Signature Algorithm (DSA) and Diffie-Hellman (DH) algorithm but with a smaller key size,
which proves to be beneficial for limited energy resource smart devices. Other than ECC, Rivest,
Samir & Adleman Public Key cryptography (RSA) with 1024-bit keys (RSA-1024) is equivalent
in strength to ECC with 160- bit keys (ECC-160). However, RSA Security recommends RSA2048, which is equivalent to ECC-224 as the new minimum key size [20]. ECC also offers
Elliptic-Curve Digital Signature algorithm (ECCDSA) and Elliptic-Curve Diffie-Hellman
(ECCDH) key exchange provide mutual authentication, key exchange and ECC-based digital
signature for wireless communications.
3.7.2 Digital Signatures
Encryption allows addressing problems associated with eavesdropping and digital signatures
provides defense against impersonation and tampering. Encryption does not protect from
modification of the message. Digital Signature Algorithm along with RSA algorithm can be used
to provide data integrity and assure the receiver that message came from a valid sender. The
sender’s private key along with Secure Hash Standard (SHS) is appropriate for the Digital
Signature Standard DSS [21] for the signing process. Receiver verifies by using the
corresponding public key of sender and same hash function. Receiver decrypts the data with
sender’s public key and compares the hash value with computational result from data evaluated
through hash function. Thus, receiver of the message can ensure that message came from a
trusted source and message is not tampered with by anyone because only corresponding public
key and the same hash function at sender and receiver side can verify the signature part and only
59
the user that possesses the private key can digitally sign message. Figure 16, below describes the
process of signing and verification using Digital Signature.
Figure 16: Use of Digital Signature for data integrity [17]
Utility, participant site and EMCS use digital signature for non-repudiation and message
authentication. Public key used for digital signatures need to be provided from a valid source.
Section 3.7.3 shows secure distribution of public key.
3.7.3 Certificate Authority
Public key needs to be obtained from a valid source. Certificates are electronic documents that
identify an entity such as person, server, and device through their respective public key.
Certificate Authorities issue certificate to verify the identity of subject requesting the certificate.
A public key is bounded to this issued certificate along with name of the requester. This prevents
impersonation of fake public keys. The public key will only work in conjunction with the
corresponding private key possessed by entity identified by the certificate. Certificate Authority
can be internal or external depending upon the type of request made. Internal CAs such as in
Microsoft Windows environment is provided in the Active Directory which issue the certificate to
the requesters within the organization’s domain [22]. For external CAs, X.509 certificates are
60
obtained by submitting a certificate signing request (CSR) by the requestor. Out of the key pairs
generated by the requestor, public key is used along with algorithm type and requestor’s name for
CSR. For internal CAs the X.509 certificate is obtained on the basis of process carried out by the
organization itself. However, CSR can be used for obtaining the certificates as well. Figure 17,
shows how the X.509 certificate is obtained from CA.
Figure 17: The requesting and obtaining process for X.509 certificate [22]
The issued certificate includes the credentials, such as the applicant’s public key, the signature
part (message signed by private key of the CA), issuer’s name, applicant name, and expiration
date. The CA’s public key is distributed in web browsers, and smart device’s operating systems
belonging to the recipient of the digital certificate. This public key of CA is used to verify CA's
signature (CA signs the certificate using its private key) included in the certificate. Thus, each
node in the network is required to have three keys; CA’s public key and its own pair of public-
61
private key. The most common standard for digital certificates is X.509. CA has to revoke X.509
certificates if integrity of certificate is negotiated. The certificate revocation list (CRL) is publicly
available for the recipient of signed message to verify whether certificate has been revoked or not.
3.7.4 Certificate Management
The certificate issued highly depends upon the CA and the purpose for which it is used by the
requestor. The process of issuing a certificate can range from being completely transparent by
providing user’s mail address or complex procedures such as background check and interview for
large organizations. However, the process to issue a certificate should be flexible enough, so that
requestor can make changes in the future. Lightweight Directory Access Protocol (LDAP)
provides flexibility in management of certificates within an organization.
LDAP stores
information related to certificates. For example, CA can use information in a directory to change
certificate information related to a new employee name or other information. The CA can issue
certificates to requestor through directory information depending on security policies of the
requestor’s organization. Certificates have limited time and come with expiration date.
Certificates provided for devices generally have long expiration date as compared to user
certificates for network authentication. Authentication would fail if a certificate has expired.
Thus, mechanisms are required to renew certificate. For example, utility administrator should be
notified when the certificate is about to expire. For other organizations, a requester checks the
expiration of certificate with the CA. The renewal process would consist of the previously used
key pair or generating a new key pair by certificate requestor. Before the certificate expires, it is
necessary to revoke the certificate. The revoking process differs among different organization.
Certificates may be revoked under various conditions such as compromise of key pair used by a
certificate, expiration of certificate, errors within issued certificate, incorrect identity, and new
62
employee joining the organization or compromise of device using a certificate. Once the
certificate is revoked it is removed from the directory and added to the list of revoked certificates
known as Certificate Revocation List (CRL) by the CA. The CRL consists of serial number for
each of the revoked certificates and name of the CA. CA signs the CRL to ensure authenticity of
the document before sending it to the nodes in the network. Nodes taking part in PKI will validate
the certificate by downloading the CRL and scanning it to find the serial number associated with
the certificate received from the sender node. Most of the network devices cache the CRL until it
expires. When the CA generates a new CRL, the device verifies it by downloading it and then
deletes the cached CRL. Figure 18, demonstrates certificate validation with CRL.
Figure 18: Certificate validation with CRL [23]
However, memory space in devices for processing and storing the cached CRL is not enough for
a large PKI infrastructure. Under such circumstances, it is suitable to breakdown the CRL in
multiple files [23]. However, caching CRL on devices may consume large amount of memory. In
such cases, where CRL is not efficient to obtain certificate revocation information Online
Certificate Status Protocol (OCSP) offers a better alternative [23]. OCSP provides real-time
63
mechanism to check the status of certificate. When a device receives a certificate from other
device, it checks the certificate revocation status by sending a query to the OCSP server along
with the certificate’s serial number. The OCSP server examines its copies of CRL to determine if
the CA has listed the updated CRL and sends the status message to the device. This consumes no
memory on the device since it will not have the cached the CRL. Figure 19, shows Certificate
Validation with Online Certificate Status Protocol (OCSP)
Figure 19: Certificate Validation with Online Certificate Status Protocol (OCSP) [23]
3.8 Mutual authentication and Message Authentication
Mutual authentication verifies whether an identity sending data over the network is trustworthy or
not. Digital certificates provide mutual authentication between two communicating nodes in a
network. Each node in the network keeps a public and private key pair. A certificate authority
(CA) collects the public key of all the nodes and issues a certificate to verify the identity of the
node. A digital certificate issued by CA consists of public key, CA’s digital signature and other
64
fields such as device ID, expiration date etc. In brief, all the public keys of the nodes need to be
authenticated to validate their identity. This mutual authentication allows the node to trust the
validity of the other node which is transmitting the data. Thus, an attacker trying to add a new
device to intercept the network will not be able to add since he does not have the related
certificate. However, reverse engineering could be used to study the design of hardware and
software of the devices. According to [24], kleptography attack can be used to steal information
such as private keys, digital signatures, symmetric keys or certificates securely from a device or
software. Adam Young and Moti Yung from Columbia University [24], have used Secretly
Embedded Trapdoor with Universal Protection (SETUP) to leak secret information through
algorithms such as RSA, Diffie Hellman, Digital Signature Algorithm(DSA) and Elliptic Curve
Digital Signature Algorithm (ECDSA) . According to [19], to conserve energy, limited data is
transmitted and an abbreviated X.509 certificate consisting of unique node identification, public
key and signature is used. Mutual authentication in sensor and Zigbee network in HAN can be
carried out through ECC. Each device validates itself by providing its public key to CA. CA
issues certificate to the device. Thus, an attacker cannot inject a device, modify or add
unauthorized message since he would not have the certificate. However, an attacker can fake the
public keys of the CA to a sender with his own fake public key and he can issue fake public keys
by signing them with his private key. In addition to validate the source, it is also necessary to
maintain integrity of the data. Message Authentication provides DR information integrity as well
as verifies the source of DR event. Message authentication can be implemented through digital
signatures (see section 3.7.2).
65
3.9 Key management
Key management is also important aspect in DR systems. Along with security measures for
message transmission, source and message authentication, keys used for cryptographic purpose
also needs to be protected from disclosure. A key management policy is required to maintain
confidentiality, integrity, and authentication of cryptographic keys based on organization
requirement and individual responsibilities. Roles based access controls are required for
management, maintenance, and recovery of the keys. For example, audit logs should be managed
by different personnel other than a system administrator in order to track administrative misuse of
key management. Currently, random key pre-distribution is used to provide pre-established keys
in each node, thereby reducing the attack by a single node to jeopardize the entire network.
However, public key cryptography has been widely acknowledged for wireless communications
for the DR program. The cryptographic keys should be stored and transferred to authorized users
in a secure manner. Different key pairs of private/public key should be used for encryption and
digital signature. Keys used for encryption are short term based whereas keys for authentication
and message integrity are long term based. There is no requirement to backup the private key if it
is used for authentication purposes. A good example for this case is a web client authenticating a
web server. If the key is compromised for these scenarios, it will not lead to loss of data. Private
keys used for encryption purposes or for protecting stored data in an organization should be
backed up. However, if the private key used for digital signature is backed up, the signer could
deny the signature by claiming that another copy of the private key exists that might have been
used by an imposter to forge a signature. Thus, backed up private key used for encryption
purposes should not be used for digital signatures with non-repudiation. Separate key pairs should
be generated and stored for this. Thus, the key backup processes tend to be different based on
what the keys are used for. To protect the key pairs a secure place with proper access control is
66
required. Typically, private key should not be accessed or sent to unauthorized parties. The public
key needs to be protected from unauthorized modification as well. To provide such protection, the
public keys can be obtained from X.509 certificates, which are signed by trusted CA. Key
distribution tends to be different, based on encryption algorithm and resource constraints. For
example, symmetric encryption requires pre-distribution of keys, which can be achieved through
Kerberos whereas for asymmetric encryption Elliptic Curve Diffie-Hellman algorithm (ECDH)
can be used for key exchange.
3.10 Open Automated Demand Response (OpenADR) Security Measures
Several modes of attack ranging from physical to remote attacks can take place to tamper the
demand response system in OpenADR. It is highly crucial to prevent these attacks in the
OpenADR system.
This section addresses the security concerns discussed in chapter 2, analyzes security
requirements, and provides best practices based on the security requirements.
3.10.1 Security Requirements
The OpenADR consists of three basic Web based interfaces such as Utility and ISO Operator
Interface, Participant Operator Interface, and DRAS Client Interface. The DRAS Client Interface
has one Web interface with the DRAS. The following are the set of general security requirements
for the security concerns:

Information transmitted during communication should be protected from unauthorized
access and modification.

Communication between different demand response entities should be authenticated.
67

Web services methods used by different demand response entities should be accessed by
authorized users.

Information related to the DR program such as customer information, pricing
information, energy usage and log information should be accessed, modified or deleted
by authorized user. Proper access control methods should be used.

Transactions and message delivery cannot not be denied either by the origin or by
recipient during bidding or providing acknowledgment of receipt of the message.

Information either transmitted to or from the Demand Response Automated Server
(DRAS) must maintain confidentiality and integrity from third parties.

The DRAS must provide accountability for the information such as prices information,
energy usage, and bids submittal information received by participants.

Proper access control to the information generated, transmitted and stored for the demand
response program must be provided so that only authorized users can carry out pertaining
operations on it.
3.10.2 Security Measures
The OpenADR communications will be based on Internet. According to [5], Web services
technologies will be utilized for interfaces among the OpenADR for demand response programs.
Secure communication protocols, such as Transport Layer Security Protocol (TLS), can be used
to secure network traffic. TLS uses symmetric and asymmetric cryptography for providing
authentication, integrity and privacy. Security in terms of confidentiality, authentication, nonrepudiation, and integrity are among the DRAS interfaces that can be obtained from one of the
following methods.
68

Secure channel communication with server-side certificates

Secure channel communication server-side and client-side certificates

Web Service Security (WS-Security)
According to [5], TLS specification version 1 or newer as published by the Internet Engineering
Task Force (IETF) has been proposed for OpenADR transactions. The TLS handshake protocol
uses public key cryptography (RSA) between server and client to authenticate each other and
negotiate encryption algorithm and cryptographic keys. TLS handshake establishes a session,
authenticates end entities, negotiate authentication and encryption algorithms and keys. When the
handshake is completed, session is used to transfer data between the end entities. The data is
encrypted with the symmetric key and cryptographic algorithm such as 3DES or AES negotiated
during the TLS handshake phase. Reliable data transfer takes place by using Secure hash
functions (SHA, MD5, etc.) After the data transfer is completed, the TLS session is closed.
Current implementations support the following choices:

1024-bit Rivest, Samir & Adleman Public Key cryptography (RSA) for key exchange

3DES (Data Encryption Standard) and AES128 (Advance Encryption Standard) for
symmetric encryption.

SHA1 (Secure Hash Algorithm) for Message Integrity Code (MIC)

Hashed MAC (HMAC) for Message Authentication Code.
3.10.2.1 Secure channel communication with server-side certificates
It is mostly used for providing security in the web servers. The server-side certificate allows the
browser to know that the website requested is the required one and not an imposter. Thus, using a
server certificate it guarantees integrity and confidentiality through use of cryptographic
69
techniques by TLS. However, any application, appliance or system in AutoDR that uses
authentication process is required to use Secure Hypertext Transport Protocol (HTTPS)
connection based on server-side TLS certificates signed by a trusted third-party certificate
provider. The major disadvantage is that the client is not authenticated which can lead to Man-inthe-middle (MITM) attacks, Cracking Ciphers, Clear Text Attack or Replay Attack.
3.10.2.2 Secure channel communication 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. This approach is costly since the client side certificate needs to be issued and
maintained before communicating with the server.
Transport Layer Security (TLS) is subject to a number of serious man-in-the-middle (MITM)
attacks related to renegotiation. TLS negotiation takes place between client and server initially by
sending and receiving the cipher suites, certificate, and encryption key. Figure 20, shows the
basic TLS handshake.
70
Figure 20: Basic TLS handshake [25]
TLS permits server and client to request renegotiation of TLS session at any time to refresh the
cryptographic keys, increase the level of authentication or to have a powerful cipher suite. Thus,
each time the client or server needs to renegotiate, they can carry out the basic TLS handshake.
However, this renegotiating mechanism poses a concern for client authentication. The problem is
in order to obtain and validate the client certificate, the HTTPS server needs to renegotiate the
TLS channel. During the authentication, there is a loss of continuity, which called “the
authentication gap” [25]. Thus, the TLS protocol allows an attacker to carry out a number of
MITM attacks and inject the data into the authenticated SSL communications. MITM attack first
carries out the basic handshake and attaches some random chosen text, after which attacker either
requests a renegotiation or causes the server to carry out renegotiation. The MITM then forwards
the client request and sends message back and forth between client and server. This leads to
71
insertion of some prefix bytes or the attacker adds random data. Figure 21, below shows how an
attacker can exploit the defect in TLS.
Figure 21: TLS handshake with client certificate and MITM attack [25]
72
Until the TLS protocol is fixed, server needs to disable the renegotiation in order to prevent
MITM attack. To implement OpenADR, all the SSL libraries for developing APIs need to be
updated. The short-term fix of this problem is to not allow or disable client-side certificates.
3.10.2.3 Web Service Security (WS-Security)
OpenADR specification has proposed to use web services among its three interfaces [5]. For
example, the DR events will propagate from DRAS client to DRAS through SOAP where the
messages will be in XML format. When DRAS sends the DR event status messages to DRAS
client through SOAP, the DRAS behaves as web service Client whereas DRAS client behaves as
a web service Server. HTTP provides source and mutual authentication, integrity, and
confidentiality when SOAP messages are exchanged over the network. However, HTTP provides
point-to-point security. WS-Security provides end-to-end security through XML signature and
XML encryption.WS-Security is a specification for providing security for Web Services. WSSecurity provides security mechanism by using existing standards and specifications. This has
prevented to define a complete new security mechanism for the Web-Service. It provides
confidentiality and integrity through encryption and provides specification of messages attacked
to security token. This protocol allows communication through various security token format
such as Security Assertion Markup Language (SAML), Kerberos and Public Key Infrastructure
(PKI) certificate format X.509. WS-Security is not specific to the format of the security token.
WS-Security signs the SOAP messages to provide non-repudiation and integrity. It also provides
encryption to ensure confidentiality and provides specification for messages attached to several
security tokens. According to [26], WS-Security adds significant overhead to SOAP-processing
due to the increased size of the message, XML and cryptographic processing leading to faster
CPUs and more memory usage and network bandwidth. This section discusses how to enforce
73
security goals by using PKI cryptographic tools, username/password mechanism, and X.509
certificate format with WS-Security specification.
Cryptography Operations
Mutual authentication can be obtained through Kerberos, X.509 certificate or username/password
validation mechanism in web service. Figure 22, depicts the flow of message in web service.
Figure 22: Message flow in Web Service [27]
The client obtains token from Security Token Service which can be Kerberos, PKI or
username/password validation service. A security token consists of information such as name,
identity, key, group, privilege, and roles associated with the web service client (requestor). The
client adds token to the message and signs the message before sending it to server. XML
Encryption and XML Signature describe ways to encrypt and sign contents of messages. XML
Encryption specifies encryption mechanism through combination of symmetric and asymmetric
encryption over web service to provide confidentiality. The WS-security uses asymmetric
algorithms over the shared key generated and to negotiate with the client. Public key encryption
provides secure exchange of randomly generated pair of symmetric/session key and then using
this symmetric key to carry out data transfer of data through symmetric key encryption. The
public key of the client encrypts a random key also known as the session key. The server decrypts
74
it by using its private key and gains the session key. After which the transfer of all DR events
takes place through symmetric encryption by using this session key. XML signature provides
source authentication and integrity of message in three following ways.
 Sender uses its private key in case of X.509
The sender uses the X.509 certificate obtained from CA and signs it using its private key.
Thus, the message is decrypted only to the known user.
 Kerberos for signing purpose
The sender requests and issues security tokens from security token service such as
Kerberos. It attaches the token to the message and signs the message before transferring.
 Username/password mechanism
The sender uses the hashed password to sign the message. SHA1 hash is used to create a
password digest consisting cryptographic nonce, creation time and password. Receiver
verifies the data by creating a hash and comparing the hash values.
Digital signatures can be used for providing non-repudiation. Non-repudiation is possible because
the message digest is mathematically combined with a security token value (X.509 certificate)
only known to the sender. The receiver can verify the digest by using a value associated with
the security token. In order to reduce the replay attacks timestamp, sequence number, expirations
and message correlation should be included into the signature part of the message or of the SOAP
header for some SOAP extension.
X.509 Certificate
An X.509 certificate may be used to validate a public key for authenticating a SOAP message or
to identify the public key within SOAP message that has been encrypted. The X.509 certificates
issued by the trusted CA verify identity of both server and client. The certificate includes the
75
credentials, such as the identity and public key, and the signature part which is the signing of the
message with the private key of the CA. The certificate store is the place where all the X.509
certificates are stored. When the server receives 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 source that it claims and the X.509 certificate has not expired. Figure 23, indicates
the authentication using X.509 certificate.
Figure 23: Authentication using X.509 certificate [22]
76
Chapter 4
PRIVACY ISSUES AND ITS RELATED BEST PRACTICES IN DEMAND
RESPONSE
4.1 Overview
Demand response program consists of several inter-related technologies with consumer in order
to reduce electricity demand as well as to provide a cost effective mechanism for flexible and
reliable grid. Thus, it is necessary to monitor and control the energy consumption at residential
and commercial level customers. Demand Response signals sent via network to resident
appliances control the energy usage. Attacks such as data manipulation attacks, masquerading,
eavesdropping and repudiation can lead to false DR event configuration and unauthorized access
to customer’s private information. An attacker could monitor and control energy usage, smart
device, and DR signals. It is thus necessary to maintain trust of the customer. This chapter
discusses privacy issues and counter measures affiliated to demand response programs.
4.1.1 Identity Theft
Identity theft occurs when an attacker gains personal information about a customer without their
knowledge to commit fraud. Personal identifiable information includes social security number,
address, date of birth, driver license, email address, IP address, logs records and passwords of the
customer. An opponent can pretend to be someone else by claiming the identity of the subject
through name, SSN, email address, and network information in order to carry out malicious
activities over the resources. Personal identifiable information stored at the utility, EMCS or third
party is vulnerable to identity theft through an insider attack. An attacker can monitor devices
installed and maintained at resident site. According to [28], a search warrant is required by the
77
utility or the third party before monitoring the smart devices at the resident site in order to prevent
identity theft.
4.1.2 Determine Personal Behavior Patterns
The smart devices located at the customer site monitor and collect energy usage based on
incoming DR events. Monitoring of DR events can relate to energy usage, and temperature
activity. For example, residents who are away from their home for a long time will consume less
energy. An attacker can monitor energy consumption to determine customer’s presence and carry
out home invasion. Access to energy usage through smart devices can reveal energy usage
interval, geographical location of customers, customer information, and interval of incoming DR
events. Patterns associated with number of people living in the house, use of electrical appliances,
and absence of residents can be determined through smart devices monitoring techniques.
Utilities, property owners and third party could eavesdrop on real time information associated
with the house through smart meter to determine which devices are switched on/off. This would
expose day-to-day activities of the customer. Appliance manufacturer, maintenance operators and
third parties could use this information for product marketing and purposes.
4.1.3 Determine Specific Appliances Used
Smart devices such as smart meter, thermostats, and sensor networks at residential place can track
the use of specific appliances like washing machine, refrigerator, television, heater, and air
conditioner. Attack on these smart devices could determine the pattern of energy usage and
incoming DR events. For example, an incoming DR event could be to switch off the air
conditioner during peak time. An attacker could obtain this information and track when, how and
78
why the customer is using the specific appliance. An attacker could also carry out home invasion
by tracking the alarm systems.
4.1.4 Issues in data collection and availability
DR entities such as utilities, EMCS, and third parties obtain information associated with
residential equipment, individual appliances, and energy usage through smart devices. A DR
entity or an attacker can misuse the information intentionally or unintentionally. Intentional
misuse would be through an operator at utility or EMCS and forwarding it to the third party
which in turn shares or misuse the information or through attackers. Lack of privacy principals
and rules would lead disclosure of collected information from the compromised smart devices,
HAN or other appliance. Certain appliances consist of a unique serial number or MAC address.
Gaining MAC address can allow the attacker to carry out MAC spoofing [29],which can modify
the access control lists for the device as well as predict which type of appliance is used at resident
site..
4.1.5 Issues in smart meter
Smart meters installed at resident site provide real time energy usage information from smart
home appliances such as thermostat to utility and EMCS. The gathered information is used to
monitor loads and control energy usage through demand response events. Wireless
communication takes place between smart meter, in-home devices, and EMCS. Wireless
communication between smart meter and energy provider are vulnerable to threats such as
eavesdropping, spoofing, flood attacks, interception or message forgery. An insider attacker
through utility personnel, maintenance operator or vendor having access to smart meter can
tamper with billing information, device control and personal customer information. Disclosure of
79
private information by third parties, maintenance and utility personnel’s can be used for
marketing purpose. Smart meter collects information at short period of intervals of 15 minutes to
one hour [30]. This can lure an attacker to find out customer behavior patterns leading to privacy
concerns discussed in 4.1.1 and 4.1.2. Property owners at the residential site will have access to
the smart meter and thus will be able to determine personal behavior patterns as well as home
devices belonging to the tenants which may raise privacy concerns if consent from tenant is not
obtained. A customer willing to change the residential location, personal information or smart
meter is required to register for a new account or change the existing account information with
the utility. Utility will collect, store and transfer smart meter data to customer’s account based on
the electric service identifier (ESI ID) and smart meter ID. ESI ID is a unique number provided to
identify the location of electric service delivered. The customer will be able to read the smart
meter data through web/desktop portal in real time from his new location [31]. Thus, the old
smart data is retained by the utility even if the location of resident or smart device changes.
However, installation and configuration of smart meter to a new location should meet the access
control and cryptographic requirements (section 3.6 and 3.7).
4.1.6 Issues in data storage and processing
Data associated with energy usage is collected at regular interval of time, routed within
residential site through networks and protocols such as sensor network, zigbee, and wifi, and
finally sent to utility where data is collected and processed. Information such as energy data from
the smart devices, customer registration with the DR program, bidding price information, and
utility administrative data is stored, accessed, modified and processed by the utility. The data at
the utility is complied based on electric market prices after which DR signals are routed to other
subsystems of Smart Grid. Information might also require some data preprocessing and data
80
mining techniques for billing, real time information for customer support/technician as well as for
predicting the future values. It is predicted that Smart Grid will generate eight orders of
magnitude of data compared to today’s electric grid. Privacy concerns include questions
regarding the type of data to be collected, which places it will be routed and where and how will
it be stored. If proper access control mechanisms are not maintained then an adversary within
utility and its sub-systems can process incorrect and route data to a different entity. Disclosure of
customer data to the third parties can lead to privacy impact associated with the customer lifestyle
pattern and lead to identity theft.
4.1.7 Issues in Commissioning, Registration, and Enrollment of HAN devices
This section focuses on the privacy issues associated with the EMCS. The main purpose of
EMCS is to collect DR information from utility and carry out load shedding/shifting at resident
site. A home area network is created by the smart devices through a process called
commissioning in which each authenticated device joins the network and exchange information
such as network key, device ID, device type and receive broadcasted signals. However, each
device is able to join the network through an installer and based on the manufacturer’s
instruction. Each smart device registers itself with other devices within the home area network
through mutual authentication process. The customer then enrolls itself with DR program so that
the DR Service Provider can communicate with smart devices. Negligence to maintain access
controls can allow the third party installers and maintenance personnel to determine customer’s
private information. In addition, customer and home device information provided to third party
during registration should be properly secured to avoid privacy issues. Home devices
communicating through wired networks can be attacked through injection of a rogue device to
eavesdrop the communication or tamper the device. Privacy issues such as identity theft,
81
customer lifestyle pattern and specific devices used are discussed in section 4.1.1, 4.1.2, and 4.1.3
can take place.
4.1.8 Issues with Third Party
Personal information from the smart meter will be recorded by the EMCS to control the load at
the resident site. The EMCS could be a third party or a utility sub-entity. The information should
be provided only through costumer’s consent. Until, now a written consent is required by
customer to allow third party to access smart device information. It is crucial for utility to
determine the roles for third party to carry out information handling and processing. Special
controls should be set for third party to distribute information to other DR entities. If proper
secure mechanisms are not met, the third party can carry out marketing practices through
information obtained from devices and private customer information. Precise mechanism has not
yet been provided to determine the type of software and hardware applications used for the DR
programs by third parties. Third parties will play a crucial role in providing devices such as smart
meter, PCT and software applications for interface among DR entities. Failure to achieve secure
mechanisms for maintenance of in-home devices by third party, can result an attacker tampering
with the device leading to incorrect customer bill and load controlling mechanisms. If proper
rules, regulations, polices and standards are not provided to the third parties, then intentional or
unintentional attacks can affect the privacy of the customer.
4.2 Consumer to Utility Privacy Impact Assessment
DR event is sent to control energy usage based on Personal Identifiable Information (PII) such as
customer name, address, SSN, date of birth, and network information. Failure in proper privacy
rules and regulations can lead to several privacy issues in demand response program. Privacy
82
impact assessment determines the privacy risks and mitigation steps associated with personal
information. If proper documented instructions, training, awareness and access controls are not
met at utility site as well among other organizations, then this can affect the private information
of customer as well as the information stored at utility. Intentional attack might occur through an
insider threat in utility and organizations whereas unintentional disclosure of PII information
through attackers can lead to breach in security. Smart device data collected for billing purposes
and DR strategies will be stored at multiple locations with the consent of utility. It is necessary to
notify a customer regarding the type of information, purpose of information and to whom the
information is routed. Until this stage, no real time mechanism has been provided for consumer to
access the PII used by utility or the third party [32]. However, companies such as Google’s
PowerMeter, Microsoft’s Hohm, and GridPoint Inc [33] have proposed solutions for customers to
access their PII information, which is used by utility or third party. There might be times where
customers are unaware of their own private information laid out to the utility and other
organization. For example, social networking sites provide privacy settings however many users
are unaware of these settings. The customers should be allowed to make changes to any
inaccuracies related to their PII. Even if data is kept anonymous, several combinations of each
data item of PII could disclose an individual’s information. For example, according to [34] a
study revealed that combinations of date of birth and geographical location could predict SSN of
an individual. PII information such as customer name, address, meter location and meter ID
combined would reveal electricity load information pertaining to geographical location,
electricity usage, customer behavior patterns and devices used at residential site.
83
4.3 Identification of Legal and regulatory framework of demand response
The success of demand response programs is achieved through timely and reliable transfer of
pricing signals, customer information, energy usage, and financial information among several
entities of the smart grid such as the utility, EMCS, aggregator, and customer. Privacy of
customer and confidential information should be prevented from any breach in the security. It is
necessary for a law enforcement to identify, track, and manage information or technology
associated with people, places, appliances, and applications involved in demand response
programs. Law and social standards together should draw boundary to provide security and
privacy policies for residential site, smart devices and applications used for demand response
strategies. For example, customer related information such as customer name, address, SSN,
geographical information should be protected from malicious attacks. The current privacy laws
may not explicitly reference the smart grid or the entities of the smart grid. However, the existing
laws could be amended for the demand response programs. The Fourth Amendment of the U.S.
Constitution and California Constitution both provide protections against unwanted government
intrusions into home. The first, fourth, and fourteenth amendments provide regulations for
maintaining privacy for personal information and activity. For example, law associated with the
fourteenth amendment; information such as energy usage, and meter usage collected from the
smart devices needs to be investigated before use. Laws associated with protecting the privacy of
customer’s personal information such as SSN, driver’s license, and state ID can also be used for
the demand response programs. Privacy laws are required to prevent unwanted access of
customer information from the third party. The existing Demand response program focuses
primarily on person’s private information, which provides the right to control the integrity of one.
Concerns associated with the ownership and management of data collected from the DR program
are still an issue (discussed in section 5.8). Finally, consumers should also be given some control
84
over the demand response features with consent of utility, in order to assist them to make better
decisions regarding the consumption of electricity.
4.4 Privacy principles in Demand Response
Privacy and security rules and principles occur due to federal and state laws regarding the
processing of particular type of customer information and utility tariffs. Privacy practices and
standards should be established through proper evaluation of principles. For example, interfaces
in demand response interact with each other through internet. Thus, utility must subject specific
rules to the internet provider. Information collected from the residential site should be limited to
the extent that resolves the purpose of demand response program. Utilities also have contractors
with third party service providers, energy usage management or aggregators to manage electricity
delivery, internet service, and billing. Information is circulated among different entities of smart
grid for analyzing energy usage, creating, modifying, and updating the demand response event.
These should be done looking to the access and authority of the entity. The customer is required
to be aware of the type of data collected from its site. Personal data should not be used or
accessed for other purposes without the agreement of the customer. Information should be
processed only for specified and limited purposes only when there is a legitimate need to process
the data that outweighs customer’s privacy interests. For example, information associated with
energy usage collected from smart meter through the demand response programs can expose
customer’s activity; however for customer’s financial and energy savings benefit the information
is collected. Proper secure mechanisms to protect the personal data from unauthorized access or
from malicious attacks can be obtained through cryptographic mechanisms discussed in chapter
3. Customer agreement is required if information is be reused by utility or EMCS to predict future
electric usage.
85
4.5 General Accepted Privacy Principles (GAPP)
General Accepted Privacy Principles (GAPP) are designed to assist management in creating an
effective privacy program to address the privacy issues. GAPP consists of key concepts based on
privacy laws, regulations and guidelines. GAPP can allow the smart grid to address significant
challenges faced in establishing and managing privacy issues and business opportunities. This
section discusses the general privacy principles [35].
 Privacy policy and standards are required to define the use, access and derivation of
personal identifiable information. Standards and policies should be established to provide
documented requirements of smart grid, training and awareness to smart grid entities with
management responsibilities. Smart grid entities should be monitored for the resource
access, configuration and modification through audit functions.
 Policies and standards are required to define by utility to issue notices to customers
regarding the collection, usage, retention and sharing of smart meter data through utility
websites and newspaper articles.
 Information collected from the smart devices can reveal the activities of customers
through locations of energy use, energy usage related to time, devices used in residential
and when the devices are used. It is necessary to establish policies and standards by the
utility to allow the customers to choose what type of data should be collected by utility.
Utilities should obtain consent from customers if the energy data is shared with third
party or if the data is used for other operational purposes

Policies and standards should be determined to collect minimum amount of data that is
necessary for the utility to serve its purpose for energy management and billing.
86
 Personal information collected by the utility will be stored in multiple locations and
shared among other smart grid entities. Currently, customers can access their account
information through electricity bill or electricity service provider’s website but they have
not been provided with a mechanism to access their PII. Thus, policies and standards are
required for customers to access to their corresponding PII data present at utility and third
party location.
 Policies and standards should be established to define how the PII will be used, who will
use it, how derived PII data could be used and which PII data items will not be used.
4.6 Privacy Recommendations in Demand Response
The customer is required to register the DR program through either online or written application.
The DR program will carry out strategies to shift or shed load at the resident site through EMCS.
The DR program will be carried out through two-way communication in the near future through
AutoDR. However, the customer would have to compromise by providing his private information
such as SSN, date of birth, address, energy usage information obtained from smart devices.
Exposure of this information to an attacker can depict the lifestyle, electrical equipment used in
home and invasion of privacy. It is necessary to meet the energy conservation without sacrificing
the customer’s privacy. Privacy concerns can be addressed by limiting the customer information
to the utility and the third party dealing with smart devices and load control mechanism. The
customer should be provided with what kind of information is transmitted to other smart grid
entities, how the information is used, and how long would be the information is stored within the
utility system. Employees with the utility and its sub-systems should be provided with adequate
training regarding the customer information obtained from the DR program. The utility should get
a written consent from the customer, if it intends to provide the customer information to the third
87
party. The PII should be protected by means of encryption techniques as discussed in Chapter 2
of this report. The information sent to the in-home display and load control devices at the resident
site require registration, authentication, and data protection. The information provided should be
straightforward and easy-to-understand manner helping customers to manage their energy
consumption efficiently. The smart meters providing the energy usage and consumer information
through wireless communication to the utility or the EMCS should send minimal information
pertaining to the purpose required. For example, energy usage sent to the billing agents should
provide data only affiliated to the billing such as DR event, DR event ID, customer geographical
location, and energy consumption in KWH. Moreover, when a customer registers for the DR
program and wishes to see the energy consumption through in-home display devices, it is
necessary to provide authentication. The utility is required to document all the access attempts
made by the customer to the smart devices. In case of multiple failure access the utility is required
to disable the account. This prevents unauthorized access, maintains the customer’s trust, and
enhances the likelihood to participate in the DR program.
88
Chapter 5
RESEARCH ISSUES IN DEMAND RESPONSE
5.1 Overview
Security issues associated with the Demand response program, entities, interfaces, application and
devices were discussed in Chapter 2. Chapter 3 discusses the countermeasures for security issues
in Demand response and Auto-DR. However, some of the solutions do not fulfill the requirements
of the Smart Grid. This chapter discusses potential research and development topics for Demand
response Systems in Smart Grid. The goal is to identify specific issues associated with security
mechanism, privacy issues, interfaces, and protocols.
5.2 Authentication and Authorization for Demand Response Devices
Smart devices are integrated with HAN, NAN and WAN to receive and respond to DR signals
back and forth to utilities/DR Service providers and update energy usage. An attacker can carry
out various threats to hinder the DR system. Thus, it is crucial that DR signals and devices
authenticate themselves with the other devices and entities of the Smart Grid to ensure mutual
and message authentication. The research issue is to determine effective authentication techniques
by considering limitations of the smart devices. Complex cryptographic computations based on
key size and algorithms will be used to attain security. However, some devices have limitation
with respect to memory, CPU computation, and battery life, which do not fulfill the requirement
of Smart grid. Authentication process for smart devices should be simple and easy to understand
for non-technical consumers. Role Based Accessed Control should be assigned to authorized
maintenance personnel, installers, utility operators and customers to access HAN devices. Roles
should be assigned in such a way that the consumer himself cannot manipulate the incoming
89
information from the devices. For example, a consumer should not be authorized to change or
reset an energy usage value but only authorized utility program operator should be able to change
the DR event. The research in this area is to identify appropriate set of roles and determine how
those roles can perform specific tasks on devices. Some of the pre-existing access control policies
and techniques implemented in current grid could be used in Smart Grid.
5.3 Key Management for Demand Response Devices
A secure communication is needed to authenticate entities through cryptographic mechanisms for
smart devices such as smart meter, substations, water meter, gas meter, thermostat and routers.
Key distribution, cryptographic limitation of devices, key lifecycles for key type and cipher are
the primary research issue for key management. Home devices will be provided with keys for
carrying out public key encryption or symmetric key encryption or a combination of both to
protect against malicious activities by the attackers. Large number of devices will carry out
cryptographic mechanism through PKI to identify a valid source and maintain integrity of data.
However, some of the devices will not be able to carry out PKI as they would not be connected to
the key servers or CA. Key establishment consists of key generation, distribution and key
material used for communication among the entities. Thus, keys and certificates should be
obtained in advance and stored in devices. Keys that are stored within the devices should be renegotiated, re-established and re-distributed from time to time based on the lifecycle of the keys.
This process should be carried in complaint to NIST [36] regulations. Appropriate key lengths
and algorithms should follow NIST, FIPS, RSA laboratories and other standards
recommendations. For example, NIST [36] recommends using minimum 2048-bit key for RSA
algorithm to protect data beyond 2010 and use of at least three keys for 3-DES or at least 128-bit
key for AES algorithm or 160-bit key ECC for symmetric algorithms. Timestamp, message
90
identifier or a cryptographic nonce used to prevent replay attacks should be determined based on
device limitations. According to [15], the manufacturer will insert a unique random number along
with a cryptographic key in smart devices to verify the DR event. However, if there are new keys
to be added or renewed only the manufacturer can revise it which poses a threat. Thus, we need
significant research in the areas of key distribution and key storage in PKI architecture.
5.4 Role based access control (RBAC)
Each entity such as utility, EMCS, aggregator and customer perform different operations for
energy saving. Access control helps to restrict the operations performed by the users, but it also
helps reduce the impact of failure when some part of the system is compromised since no system
can be 100% secure. Access control mechanism based on roles should be provided to restrict the
access to authorized users. A user can be given with several roles or permitted within a set of
rules to perform its respective operations. These roles must adhere to the policies of the entire
DR system based on hierarchy. Least Privilege principle can be used where an entity accesses
resources associated with its task. Once an adversary hacks some part of the system, he will be
able to perform malicious tasks only for that hacked account. There are issues when
implementing role based access control in demand response programs. It is necessary to know if
the following roles are sufficient in Demand Response Programs [9].

Users having ability to read/verify the devices’ state

Users having access to perform operational functions

Users who are capable for install, maintain, and operate the equipments from third party
vendors.

Roles determined differently according to the operations. For example, an auditor having
the ability to read and verify states of devices should not be able to configure the device.
91
Set of roles that are applicable to the majority of the utility industry, but also can be used
for needs of specific entity. These roles can be Auditors, System dispatchers, Protection
engineers, substation maintainers, Administrators, security officers, and third party
vendors.

Administrative personnel’s with ability to manage and use of these roles.

Access to DR tasks such as configuration, execution and maintenance through
hierarchical role. For example, a person of any group of people can execute DR event or
set the load status, but cannot do the both.

Roles assigned for emergency management such as network failure, failure to receive
load status or device/server failure.
In open demand response, there are three web service interfaces. They are,

Participants Interface

DRAS Client Interface

Utility Interface
There are number of types of users that need access to the DRAS and each of these users may
have different requirements based on functionality that they perform and the data they interact.
These security roles are mainly designed to limit the access to functionalities in each web service
interfaces.
5.5 Security issues in Log information
Personnel such as administrative, technical operators and feedback operators handle DR signals.
The propagation of DR signals takes place through configuration, execution, and maintenance
through DR entities such as Utility Information System (UIS), DRAS (demand response
92
automated server) and participant site. Logs are required to be maintained for each user’s account
performing these operations on the basis of its role and login session information. Logs are also
required for the DR information propagated throughout the DR network. It is necessary to
determine Role Based Access controls to view and delete information from the log. Currently, the
author knows of no clear idea provided to what extent and how long the log information will be
stored [9]. A clear idea is required to provide the schedule to carry out frequent backups of the
log as well as separation of duty for the pertaining operations.
5.6 Traffic Analysis
Traffic Analysis is the examination and interception of information pattern to acquire
information. The DR program consisting of pricing, customer, and energy usages are routed back
and forth between utility and customer. This creates pronounced traffic patterns that can reveal
the flow of DR information, location of devices, utility, and its sub-systems. An attacker can
determine the transfer rate of data packets as well as correlation of time between the nodes
communicating. Traffic analysis can be carried out by monitoring traffic and path of information
even if messages are encrypted. The identity of the communicating entity can be determined from
address or header information sent. Message length, frequency, and other patterns in
communications to specific devices can allow can attacker to predict the behavior pattern of the
customer’s lifestyle. FERC 889 regulation created “Standards of Conduct” can be used for the
DR programs to restrict sharing of information such as energy usage and pricing information
among the market participants. An eavesdropper can carry out traffic analysis to obtain this
restricted information. Multiple Parent Routing scheme could be used to prevent traffic analysis.
This scheme allows a node to forward data to one of the multiple parents. This makes the routing
patterns less definite. Random traversal of packet, introduction of a fake path or high
93
communication activity in the network can prevent traffic analysis. This will allow distributing
packet traffic and confuse the attacker regarding the routing of packets as well as location of the
devices. However, with large number of devices and complex communications taking place in the
grid, this scheme poses a challenge. Devices would have to carry out cryptographic mechanisms
to transfer data to multiple devices through random traversal or fake path. This would lead to
excessive use of cryptography techniques affecting the network throughput since each smart
device has a resource constraint. Thus, research should be carried out to determine effective low
power encryption techniques that could solve the issue of traffic analysis.
5.7 Privacy issues in Data Storage
The success of DR program depends on meeting consumer’s expectations in privacy, and
security. Customer Information collected through registration of DR program and from smart
devices will be circulated among various entities of smart grid. Consumers are required to be
aware of the information sent to the utility and decide whether to grant access to third parties.
Energy usage information collected can provide personal details about the lifestyle of consumers,
such as their daily schedules, devices equipped and behavior patterns. According to [37], surplus
amount of energy data will be sent from smart meter to utility causing the utility to provide a data
center infrastructure through third parties such as Oracle, IBM, and Cisco. Stored customer and
energy usage information requires data management and secure mechanisms. Proper access
controls are required for maintenance, removal, and retrieval of the data. The stored data will be
utilized for future predictions pertaining to electricity prices as well as energy consumption.
However, it has not been determined how long the data will be stored. If the data is deleted, it
should be determined what kind of data should be removed, who performs the operation and if
the customer is required to be notified or not.
94
5.8 Privacy issues in ownership of customer data
The DR events sent at resident site, allows the customer to update the electricity usage. The
energy usage data is sent to the utility and its sub-systems which are reviewed to reduce the
energy consumption at resident site. It has been a debatable topic of who would own the customer
data among several companies. According to [32], either the customer owns the data or the utility.
However, the issue to access the data is more important than ownership of the data. Customers
should have access to customer specific energy usage data (CEUD), and allow the utility and the
third party to access it. Varied companies involved in the DR program have provided different
viewpoints regarding the ownership of the data. Honeywell, EnerNoc, Elster [32] have stated that
the data belongs to the customer, as the customer generates energy data by updating the energy
consumption based on the DR event and revealing personal information to the utility. However,
other companies such as Exelon, Xcel, Southern California Edison (SCE), and Avista [32] refute
to this by stating that the utility installs, executes and maintains the DR program for cost effective
energy usage. The DR event initialized by the utility allows the consumer to update the electricity
usage and thereby producing energy consumption data for billing and other operational
functionalities [2] carried out by utility. Other companies such as CPower and Silver Spring [32]
stated for a middle stand for the ownership of data between utility and customer. Since the
customer generates data and the data is used by utility for operational purposes, they stated that
data should be co-owned between the two. Thus, a clear concise information has not been met
regarding the ownership.
95
Chapter 6
CONCLUSION
6.1 Summary
Demand response programs in Smart grid provide an effective way to reduce energy demand,
energy consumption, customer billing and carbon emitting gases. It provides utility as well as
consumer with cost efficient energy usage by providing enough capability to the customers to
manage the energy usage.
For the success of the DR programs, we require varied interfaces, smart devices, communication
protocols and privacy regulations. The DR program will issue signals to the customer to reduce or
increase the energy usage by monitoring and controlling the devices through various
communicating interfaces.
The aim of this project was to discuss various types of DR signals, security issues, privacy issues
and the related countermeasures. Automation of the DR program carried out by Open Automated
Demand Response provides real time communication among the smart grid entities and the
customer for managing the energy usage. Secure communication channel as well as interfaces
will be used for two-way communication among the utility, EMCS and the customer. This
provides the customer and the utility an ease to manage usage as well as predict future energy
usage to prevent blackout and unreliability in the grid. The OpenADR would be highly dependent
upon the wireless communication such as WIFI, zigbee, IPSec, TLS, WLAN and sensor
networks. There are a number of vulnerabilities associated with the network, devices and
management of the utility. Vulnerabilities associated with people, policy, platform and network
are the deepest concern for the DR program provider. These vulnerabilities tend to weaken the
confidence of the customer to participate in the DR program and jeopardize the grid.
96
Effective best practices are required to overcome these vulnerabilities and threats in the DR
network. This report discusses the countermeasures for the DR program related to the network,
devices and privacy impacts through cryptographic and non-cryptographic techniques. The
security issues and countermeasures are analyzed in this report; however, there are some areas
which need further research. Bottom up approaches are required to meet these requirements. Due
to varied use of communication protocols and smart devices over a massive project for Smart
grid, it is crucial to come up with reliable and cost effective solutions.
6.2 Strength and weakness
OpenADR is predicted to be influential for the success of DR program. The provision of real time
information to the customer and the utility helps to predict the electricity demand. This project
has analyzed security concerns and measures related to DR program to provide timely and
reliable communication. Device and cost effective means have been discussed to maintain
security. Cryptographic techniques including solutions through symmetric, asymmetric
encryption or combinations of both have been proposed by keeping in mind the device and
network constraints. Non-cryptographic techniques associated with the management of utility,
EMCS, third party, load control and smart devices have been proposed. Tools for easy access of
energy information are provided to the customer as well as EMCS through proper authentication
and authorization techniques. Customers are given enough capability for controlling their
personal information which is required to be provided to the utility and EMCS.
The weakness of the project is that the customer can view the energy usage information through
in-home displays obtained from smart meter, but the customer is not able to view the real time PII
information used by the utility. The reason for this weakness is that no mechanism has been
provided for customers. Certificates used in PKI need to be checked if they are revoked or not
97
through CRL. CRL provided to the devices by CA are stored in devices. However, this adds
overhead to the memory space. No specific method has yet been approved for checking the status
of CRL.
6.3 Future Work
The communicating mechanisms proposed for demand response program need thorough testing
for assuring performance of the DR program. Design of smart devices should be compatible with
the computational processes and resource constraints of device. As surplus amount of data will be
collected data mining and data preprocessing techniques should be utilized. Since data center
techniques and cloud computing would be used, it is necessary to have proper guidelines based on
legal regulation to protect the privacy of the customer’s. Until now only theoretical concepts,
current use of regulation, laws and policies have been provided. Further research is required to
layout regulations for third parties to handle load control devices, data storage, manufacturing
smart devices, internet provision and application interfaces.
98
BIBLIOGRAPHY
[1] “What the Smart Grid means to America,” Litos Strategic Communication. [Online].
Available: http://www.oe.energy.gov/ConsumerAdvocates.pdf. [Accessed: August 25,
2010].
[2] D. Taylor, “Plugging In Transportation to Our Energy Future”, Southern California Edison,
August 2008. [Online].
Available: http://energy.wesrch.com/paper_details/pdf/TR1SVVAL6WDZH/plugging-intransportation-to-our-energy-future. [Accessed: September 15, 2010].
[3] “Capacity Bidding Program,” Pacific Gas and Electricity. [Online]. Available:
http://www.pge.com/mybusiness/energysavingsrebates/demandresponse/cbp/ [Accessed:
October 1, 2010]
[4] " Automation of Capacity Bidding with an Aggregator using Open Automated Demand
Response,” Lawrence Berkeley National Laboratory Demand Response Research Center.
[Online]. Available: http://drrc.lbl.gov/pubs/cec-500-2008-059.pdf. [Accessed: November 14,
2010].
[5] M.A. Piette, G. Ghatikar, S. Kiliccote, E. Koch, D. Hennage, P. Palensky, and C. McParland,
“Open Automated Demand Response Communications Specification,” Demand Response
Research Center, April 2009. [Online]. Available: http://drrc.lbl.gov/openadr/pdf/cec-5002009-063.pdf. [Accessed: October 20, 2009]
[6] S. Kiliccote, M.A. Piette, J.H. Dudley, E. Koch and D. Hennage, “Open Automated Demand
Response for Small Commercial Buildings,” Earnest Orlando Lawrence Berkeley National
Laboratory, July 2009. [Online]. Available: http://drrc.lbl.gov/pubs/lbnl-2195e.pdf. [Accessed:
December 25, 2009].
99
[7] “OpenADR specification developed by demand response research center boosted by recovery
act grant to Honeywell,” Lawrence Berkley National Laboratory. [Online]. Available:
http://eetd.lbl.gov/news-archives/news-honeywell.html [Accessed: October 1, 2010].
[8] “Privacy by Design: Achieving the Gold Standard in Data Protection for the Smart Grid,”
Information & Privacy Commissioner of Ontario, Hydro One and Toronto Hydro Corporation,
June 2010. [Online]. Available: http://www.privacybydesign.ca/content/uploads
/2010/03/achieve-goldstnd.pdf [Accessed: October 10, 2010].
[9] A. Lee, T. Brewer, “Smart Grid Cyber Strategy and Requirements (Draft NISTIR 7628),”
National Institution of Standards and Technology (NIST), September 2009. [Online].
Available: http://csrc.nist.gov/publications/drafts/nistir-7628/draft-nistir-7628.pdf. [Accessed:
October 20, 2009].
[10] “Security Profile for Third Party Data Access,” The Advanced Security Acceleration Project
for the Smart Grid (ASAP-SG), January 2010.[Online]. Available: http://collaborate.nist.gov/
twiki-sggrid/pub/SmartGrid/DocumentsforReviewandComment/3PDA_Security_Profile_
-_v0_20_-_20100129.pdf. [Accessed: November 24, 2010]
[11] G.Smith, “Demand Side Management and Demand Response within home,” HD Utility
Services, January 2009. [Online].
Available:http://www.smartgridnews.com/artman/uploads/1/DemandSideManagemenandDe
mandResponse.pdf . [Accessed: October 15, 2010].
[12] “Smart meter security forecast: Heavy investment expected, but vexing vulnerability
remains,” October 15, 2010. [Online]. Available:
http://www.smartgridnews.com/artman/publish/Technologies_Security_News/Smart
100
-meter-security-forecast-Heavy-investment-expected-but-vexing-vulnerabilityremains-3154.html. [Accessed: October 20, 2010].
[13] “WEM-IO: Web Enabled Relay for Energy Management and Load Control,” Energy
Tracking LLC. [Online]. Available:
http://www.energytracking.com/Web_Enabled_Relay_For_Demand_Response.htm.
[Accessed: October 15, 2010]
[14] “Energy Lens - Energy Management software,” BizEE Energy Lens. [Online].Available:
http://www.energylens.com/ .[Accessed: October 19,2010].
[15] E. W. Gunther, “Reference Design for Programmable Communicating Thermostats
Compliant with Title 24-2008,” March 2007. [Online]. Available:
http://drrc.lbl.gov/pct/docs/ReferenceDesignTitle24PC_rev15.doc. [Accessed: October 22,
2009].
[16] “Identity Management,” Skip Slone & The Open Group Identity Management Work
Area. [Online].Available: http://www.opengroup.org/projects/idm/uploads/40/9784/
idm_wp.pdf. [Accessed: November 27, 2010].
[17] “Introduction to Public-Key Cryptography,” October 1998. [Online]. Available:
http://docs.sun.com/source/816-6154-10/contents.htm [Accessed: October 22, 2010].
[18] “Message Authentication code”, Wikipedia, November 2010. [Online]. Available:
http://en.wikipedia.org/wiki/Message_authentication_code.[Accessed: November 27, 2010].
[19] S. Wander, N. Gura, H. Eberle, V. Gupta, S. Chang S.J. Stankovic,“ Energy Analysis of
Public-Key Cryptography on Small Wireless Devices,” Sun Microsystems Laboratories.
[Online]. Available: http://users.soe.ucsc.edu/~awander/stuff/EnergyPaper.pdf [Accessed:
September 25, 2010].
101
[20] A. S. Wander, N. Gura, H. Eberle, V. Gupta, Sheueling C. Shantz, “Energy Analysis of
Public-Key Cryptography for Wireless Sensor Networks,” March 2005. [Online]. Available:
http://research.sun.com/projects/crypto/wandera_energyanalysis.pdf. [Accessed: July 24,
2010]
[21] “DIGITAL SIGNATURE STANDARD (DSS),” May 1994. [Online]. Available:
http://www.itl.nist.gov/fipspubs/fip186.htm. [Accessed: October 31, 2010].
[22] “Web Service Security Scenarios, Patterns, and Implementation Guidance for Web Services
Enhancements (WSE) 3.0,” [Online]. Available: http://msdn.microsoft.com/enus/library/ff647097.aspx. [Accessed: October 22, 2010].
[23] “Public key infrastructure certificate revocation list versus online certificate status
protocol,” Cisco Systems.[Online]. Available: http://www.cisco.com/en/US/prod/
collateral/iosswrel/ps6537/ps6586/ps6638/ps6664/product_data_sheet0900aecd80
313df4.pdf. [Accessed: November 27, 2010].
[24] “Kleptography”, Wikipedia, November 2010. [Online]. Available: en.wikipedia.org/
wiki/Kleptography. [Accessed: November 27, 2010].
[25] M. Ray, S. Dispensa, “Renegotiation TLS version 1.1,” November 2009. [Online].
Available: http://www.packetstormsecurity.com/0911-advisories/Renegotiating_TLS.pdf.
[Accessed: September 14, 2010].
[26] H. Liu, S. Pallickara, G. Fox, “Performance of Web Services Security,” April 2005.
[Online]. Available: http://grids.ucs.indiana.edu/ptliupages/publications/WSSPerf.pdf
[Accessed: December 3, 2009].
[27] “Understanding WS-Security,” Microsoft Corporation. [Online]. Available:
http://msdn.microsoft.com/en-us/library/ms977327.aspx. [Accessed: October 27, 2010]
102
[28] L. Coney, “Comments of the Electronic Privacy Information Center (EPIC) on Proposed
Policies and Findings Pertaining to the EISA Standard Regarding Smart Grid and Customer
Privacy (EPIC),” Electronic Privacy Information Center. [Online]. Available:
http://epic.org/privacy/smartgrid/EPIC_03_10_CPUC_Comments.pdf [Accessed: September
29, 2010].
[29] “MAC Address”, Wikipedia, September 2010. [Online]. Available:
http://en.wikipedia.org/wiki/MAC_address [Accessed: September 29, 2010].
[30] D. K. Mulligan, D. Wagner, U. Shankar, P.A. Subrahmanyam, E. Jones, J. Lerner, "Network
Security Architecture for Demand Response/Sensor Networks," Technical report, On behalf
of California Energy Commission, Public Interest Energy Research Group, January 2005.
[Online]. Available: http://www.law.berkeley.edu/files/demand_response_CEC.pdf.
[Accessed: Sep 15, 2010]
[31] “Frequently Asked Questions,” Smart Meter Texas. [Online]. Available: https://www.
smartmetertexas.com/CAP/public/home/home_faq.html#c3.[Accessed: November 28,
2010].
[32] “Data access and privacy issues related to smart grid technologies,” Department of Energy.
[online]. Available: http://www.gc.energy.gov/documents/Broadband_Report_Data_
Privacy_10_5.pdf.[Accessed: October 27, 2009].
[33] A. Cavoukian, Information and Privacy Commissioner, “SmartPrivacy for the Smart Grid:
Embedding Privacy into the Design of Electricity Conservation,” November 2009. [Online].
Available: http://www.ipc.on.ca/images/Resources/pbd-smartpriv-smartgrid.pdf. [Accessed:
October 2, 2010].
103
[34] A. Acquisti and R. Gross, “Predicting Social Security numbers from public data,” Carnegie
Mellon University, July 2009. [Online]. Available:
http://www.pnas.org/content/106/27/10975.full.pdf+html. [Accessed October 2, 2010].
[35] R. Herold, C.Veltsos,W.Pyles, “ NIST Smart Grid High Level Consumer-to-Utility Privacy
Impact Assessment DRAFT v3.0,” National Institution of Standards and Technology
(NIST), September 2009. [Online].Available: http://collaborate.nist.gov/twikisggrid/pub/SmartGrid/CSCTGPrivacy/NIST_High_Level_PIA_Report__Herold_09_09_09_w-edits.doc. [Accessed: October 2, 2010].
[36] E. Barker, W. Barker, W. Burr, W. Polk, and M. Smid, “Recommendation for Key
Management – Part 1: General (Revised),” National Institute of Standard and Technology
(NIST), Mar 2008. [Online]. Available: http://csrc.nist.gov/publications/nistpubs/80057/sp800-57-Part1-revised2_Mar08-2007.pdf. [Accessed: July 31, 2010].
[37] “Smart Grid Data About to Swamp Utilities,” Gigacom. [Online]. Available:
http://gigaom.com/cleantech/smart-grid-data-about-to-swamp-utilities. [Accessed: October
27, 2009].