IEEE Wireless Communications - April 2017 - page 14

IEEE Wireless Communications • April 2017
12
• Avoid fraud (for specific equipment located in
subscriber premises).
The attacker profiles taken into account are typ-
ically:
• A cyberterrorist trying to gain information, dis-
rupt the functioning of the SUNSEED services,
or cause a malfunction of the infrastructure by
compromising either a device, a communica-
tion link, or a cloud platform.
• A subscriber trying to alter the functioning of
the smart grid services to lower their costs or
increase their revenues.
The protection of data communications taking
place in the smart grid system is key to meeting
the security objectives, and different levels of pro-
tection may coexist at different levels of the com-
munication protocol stack:
Network access level security
targets the pro-
tection of the access network. This includes, for
example, the use of SIM cards to authenticate
with 3G or 4G wireless networks, but also the
deployment of VPN, firewalls, etc.
Transport level security
primarily aims at pro-
tecting point-to-point data communication
between two communicating nodes. With
communications being IP based, this type of
data protection is largely independent from the
communication channel (3G, 4G, Wi-Fi, PLC,
…) and is in most cases focused on protection
of TCP communication.
Application level security
addresses the pro-
tection of the payload carrying the applications
data, as described below.
From the security standpoint, the primary
high-level goal of the architecture described here is
to provide end-to-end data protection at the trans-
port level for communication between the monitor-
ing devices and the various smart grid applications
and services that access this data. End-to-end secu-
rity in its simplest form consists of implementing
point-to-point security, typically at the transport
level for every segment in the communication path
from source to destination. Every such segment
is therefore protected using different credentials,
and a rekeying operation is typically needed at
each transiting node, which should therefore be
trusted. Optionally, it should be possible to add
an extra layer of security enabling the ciphering of
application data all the way from source to destina-
tion (using a group traffic encryption key). In this
case the data will remain opaque while moving
through transit nodes, possibly reducing the trust
level required for these nodes.
Figure 2 describes the proposed communica-
tion and security architecture. Data originating
from
m
PMU, PMC, or SM devices is published
to a data sharing platform, possibly transiting
through a gateway or aggregator using popular
publish/subscribe protocols such as Extensible
Messaging and Presence Protocol (XMPP) [7] or
Message Queuing Telemetry Transport (MQTT)
[8]. At the other end of the chain, applications
subscribe to the published data to perform specif-
ic tasks upon receiving the data.
Another security requirement addressed by this
architecture relates to the capability to manage the
authorization rights defining how software entities
may interact and exchange data. For optimal con-
sistency and to minimize the risk of security holes
resulting from human errors, this is best achieved
using a centralized management interface avoid-
ing the need to configure access rights in a dis-
parate way in many different platforms. On that
aspect, the choice was made to use a standalone
F
igure
2.
SUNSEED communication and security architecture.
Security platform
IP
Telco network
Core
•••
•••
eNodeB
Authorization server
Services
Demand response
Reporting and visualization
Analytical platform
DSSE
SM
PLC
Smart meters
SM
SM
SM concentrator
•••
Forecasting
Secure elements
management platform
Publish/subscribe servers
(XMPP/MQTT)
Data storage(s)
Measurements
Topology
Weather
•••
eNodeB
eNodeB
•••
PMU
MQTT
agent
Phasor
measurem.
PMU
MQTT
agent
Phasor measurements
Phasor
measurem.
•••
PMC
MQTT
agent
Power
measurem.
PMC
MQTT
agent
Power quality measurements
Demand-response device control
Power
measurem.
•••
PMC
FPAI agent
and driver
Interface
unit
PMC
FPAI agent
and driver
Interface
unit
Energy
device
Energy
device
1...,4,5,6,7,8,9,10,11,12,13 15,16,17,18,19,20,21,22,23,24,...132
Powered by FlippingBook