A Security Protocol for Information Centric Networking in Smart Grids

A Security Protocol for
Information Centric
Networking in Smart Grids
Bárbara Vieira and Erik Poll
[email protected]
Radboud University Nijmegen
The Netherlands
1
Smart Grids
Uses ICT* to improve:
Efficiency
Reliably
Economics
Sustainability
of the electrical grid.
*
ICT stands for Information and Communication Systems
2
Smart grid
challenges
Enforce power quality (no losses of
performance);
Energy efficiency (minimising losses);
Match demand with supply (demand/
response);
Efficient energy generation (e.g., renewables);
Energy storage;
Etc.
3
EU FP7 European
Project C-DAX
Explores the concept of Information-Centric
Networking (ICN) for control and monitoring of
Smart Grids
Requirements:
(Self-)Configuration;
Communication;
Data management;
Security.
4
C-DAX Use cases
Medium voltage (MV) network:
Communication between RTUs/IDEs and Distributed
Control Center (DCC);
Communication between PMUs and the PDCs and
SCADA systems;
Communications taking place in the future retail energy
market:
Electrical Vehicle (EV) Charging;
Smart metering.
5
What is ICN* ?
Communication model that is content-based instead
of connection-based;
Content plays the central role (rather than origin
and destination);
Naming schemes target the content and not senders
and receivers;
Naming the content Vs
Naming the hosts where the content comes from;
Advantage: easily share and exchange (the same)
information between many different parties.
*
Information-Centring Networking
6
Idea of ICN in
C-DAX
Currently
Energy
Provider
…
Source|| Destination || data
Smart Grid App
(Home meter)
Smart Grid App
(SCADA System)
Smartphone
APP
7
Idea of ICN in
C-DAX
C-DAX
Smart Grid App
(SCADA System)
C"
Energy
content-identifier || data
Provider
Smart Grid App
(Home meter)
…
Smartphone
APP
8
C-DAX
communication model
C-DAX is an information-centric
networking following the pub-sub
model;
C-DAX platform operates as an
overlay over the IP network;
C-DAX middleware hosts Smart Grid
applications;
9
Pub-Sub Model
Publishers generate information and
sent it to the network;
Subscribers express interest in a
specific content and subscribe
content-related information;
10
C-DAX pub-sub
paradigm
C-DAX clients (i.e., Smart Grid applications) correspond
to publishers and subscribers;
Publishers label information and sent it to the C-DAX cloud;
Subscribers express their interest on specific contents (i.e.
labels);
C-DAX cloud corresponds to a set of nodes
geographically distributed in the network;
C-DAX nodes store published data and forward it to the
intended subscribers;
Information is labelled according to pre-defined names
— topics.
11
C-DAX Pub-Sub
Abstraction
Home meter
SCADA System
Topic
data
PDC
(data concentrator)
Topic
data
PMU
(sensor devices)
Energy Provider
Topic
data
Electric
Smartphone APP
Vehicle
12
Publishers
Home meter
C-DAX Pub-Sub
Abstraction
SCADA System
Topic
data
PDC
(data concentrator)
Topic
data
PMU
(sensor devices)
Energy Provider
Topic
data
Electric
Smartphone APP
Vehicle
Subscribers
13
C-DAX Pub-Sub
in practice
SCADA System
Home meter
C"
PDC
(data concentrator)
PMU
(sensor devices)
Energy Provider
Topic-data
Topic-name || Data
Electric
Vehicle
Smartphone APP
EV_battery_status || Value
14
Security requirements
of C-DAX
End-to-end security between C-DAX
clients;
End-to-end integrity;
End-to-end confidentiality (in
some cases);
Availability of the C-DAX cloud;
15
Advantages of ICN
(in terms of security)
Improved resilience - information is
replicated over different C-DAX nodes;
Spatiotemporal decoupling of source and
destination:
C-DAX clients do not need to know
each other IP addresses;
Mitigates some of network-born attacks.
16
Challenges
Design of security solutions that aim at securing the
content rather than the connection;
Content authentication has to be independent of:
knowing where information comes from;
how it was transported;
Trust in the C-DAX nodes (cloud) should be as
minimal as possible:
i.e., we do not trust the cloud to enforce integrity and
confidentiality of the content.
17
Can we use standard
security protocols such as
TLS or SSL?
Not really. Why?
Aim at securing the connections pipes;
In TLS or SSL trust in the content is tied
to the trust in the host that originates it;
Imposes several scalability issues when
applied to secure many-to-many
communications.
18
Possible solutions
Symmetric key-based:
faster
but less flexible
Asymmetric key-based:
robust
but slower.
19
Symmetric key per
topic
Associate to each topic a
symmetric key k
Topic-key k shared
between publishers and
subscribers of the topicdata.
Topic-name || {Data}k
C"
Publisher
Publisher
Disadvantage: when one
of the clients is
compromised, all the
communications are
compromised.
Topic-name || {Data}k
20
Subscriber
Subscriber
Diversified
Symmetric keys
Associate to each topic a
master symmetric key k
Publisher
Topic-name || {Data}k2
Topic-name || {Data}k1
Topic-name || {Data}k1
Derive symmetric keys
from k for each
publisher;
C"
Publisher
Give k to subscribers;
Topic-name || {Data}k2
Disadvantage: places the
security of the whole
system on the subscribers
side.
21
Subscriber
Asymmetric keys
per topic
Each topic has 2 pairs of
public-private keys
Topic-name || {Data}(PKe,SKs)
Enc-keys: (PKe,SKe) and
C"
Sign-keys: (PKs,SKs)
Publisher
Publisher
Publishers hold (PKe,SKs)
- encryption + sign
Topic-name || {Data}(PKe,SKs)
Subscribers hold
(PKs,SKe) - verification +
decryption
22
Subscriber
Subscriber
Advantages of asymmetric
keys per topic:
Fine-grained access control at pub-sub
level;
Public verifiability - C-DAX nodes can
check whether topic-data comes from
valid users or not;
Scalability problem when using a PKI with
2 pairs of keys per topic - storage issues;
23
Content-based
signcryption (CBS)
Based on the concept of:
Identity-based encryption - publickey crypto where the public key is
the entity identifier;
Signcryption - combination of
encryption and signatures in one
single scheme.
24
Content-based
Signcryption (CBS)
Each topic has 3 different keys:
(Unique)Public key is the topic-name;
Publishing secret key;
Subscribing secret key;
Security Server - trusted third party
responsible for generation of topic keys
and public parameters;
25
CBS in practice
Publishingkey
Subscribingkey
Security
Server
Public
parameters
Publisher
Topic-data
Subscriber
Topic-data
C"
C-DAX Cloud
Topic-data
Publisher
Topic-data
Topic public key =
Topic-name
26
Subscriber
CBS in practice
Subscribing-
Publishing-
key
key
Security
Server
Public
Subscriber
parameters
Topic-name || {Data}Publishing-key
C"
C-DAX Cloud
Unsigncryption using
topic subscribing-key
Topic-name || {Data}Publishing-key
Validation using
Publisher
topic public-key
Signcryption using
topic publishing-key
27
CBS in practice
Publishing-
Subscribing-
key
key
Security
Server
Public
parameters
Home meter
Meter_Readings || {Value}
Pub-key
SCADA System
Meter_Readings || {Value}Pub-key
C"
C-DAX Cloud
Meter_Readings || {Value}
Pub-key
Energy Provider
Meter_Readings || {Value}
Pub-key
Smartphone APP
28
Technical Details
CSB consists of four algorithms:
1. Setup: derives the public parameters PParam
and two pairs of master keys:
1.
(MSK_s, MPK_s) for signcryption and
2.
(MSK_d, MPK_d) for unsigncryption;
2. Key extraction: derives two topic secret keys
for each topic identifier ID from the (MSK_e,
MSK_s):
1.
Signcryption-key SK_s for publishing;
2.
Unsigncryption-key SK_d for subscribing;
29
Technical Details
continuation)
(
3. Signcryption: given a message m outputs
a pair (c,S) signcrypted with (ID, SK_s)
and PParam, where:
1.
c is ciphertext and
2.
S is the signature;
4. Unsigncryption: given a signcryption (c,S):
1.
2.
verifies the signature S and if succeeds;
decrypts with (ID,SK_d) and PParam.
30
CBS
Security Server generates:
Master keys (MSK_s,MPK_s)
and (MSK_d,MPK_d)
Public parameters - PParams
Topic secret keys: SK_s and
(more details)
SK_d
Pub-key: SK_s,
Security
Sub-key: SK_d,
PParams
Server
PParams
PParams
Publisher
Subscriber
ID|| {Data}SK_s
Signcryption
ID|| {Data}SK_s
C"
C-DAX Cloud
Unsigncryption
using SK_s and
with SK_d and
PParams
PParams
Validation using
PParams
31
Properties
No subscriber can publish valid topic-data since it
cannot produce valid signatures;
No publisher can read others topic-data since it
cannot decrypt the content;
Authentication only relies on public a parameters —
publicly verifiable;
Public parameters require constant storage space;
Mitigates communication overhead caused by
certificate transmission;
32
Properties
(continuation)
Revocation of public keys can be done by
concatenating their validity to the identifier —
no need of CRLs:
e.g., topic-name || expiration-date;
A more fine-grained access control can be
implemented at the pub/sub level by creating
attribute-dependent topic-keys, i.e., topic-keys
are concatenated with a set of attributes:
e.g., considering topic Meter_Readings;
then topic-PK can be: [Meter_Readings || location].
33
Main conclusions
We have proposed a content-based signcryption
scheme for information-centric networks (not
limited to C-DAX);
It provides fine-grained access control at pub/sub
level;
Minimises the memory space necessary to store
public parameters needed to perform
authentication.
As in IBE schemes CBS does not require certificates
to authenticate public-keys — all C-DAX entities
have access to the topic-names of their interest;
34
Directions for
future work
Re-keying when clients join/leave a certain
topic;
Drawback — the security server can be a
single point of failure of the entire system;
Weak resilience against exposure of
publishing-keys — since once compromised,
anyone can be disguised as a legitimate
publisher and overload the system.
35
References
36
http://cdax.eu
Thanks for your
attention.
[email protected]
37

Download Report