D4.5 Interaction Modeling

Transcription

SEVENTH FRAMEWORK PROGRAMME
Theme SEC-2011.2.5-1 (Cyber attacks against critical infrastructures)
D4.5 Interaction Modeling
Contract No. FP7-SEC-285477-CRISALIS
Workpackage
WP4 - System Discovery
Author
Magnus Almgren
Version
1.0
Date of delivery
M24
Actual Date of Delivery
M24
Dissemination level
Public
Responsible
CHA
Data included from
Davide Balzarotti (IEU), Viktor Botev (CHA), Matthew Elder (SYM),
Zhang Fu (CHA), Vincenzo Gulisano (CHA)
The research leading to these results has received funding from the European Community’s
Seventh Framework Programme (FP7/2007-2013) under grant agreement n°285477.
Theme SEC-2011.2.5-1 (Cyber attacks against critical infrastructures)
The CRISALIS Consortium consists of:
Symantec Ltd.
Alliander
Chalmers University
ENEL Ingegneria e Innovazione
EURECOM
Security Matters BV
Siemens AG
Universiteit Twente
Project coordinator
Contact information:
Dr. Matthew Elder
Symantec Limited
Ballycoolin Business Park (GA11-35)
Blanchardstown
Dublin 15
Ireland
e-mail: matthew_elder@symantec.com
Ireland
Netherlands
Sweden
Italy
France
Netherlands
Germany
Netherlands
Contents
1 Introduction
6
2 Interaction Modeling of AMI Networks
2.1 Introduction . . . . . . . . . . . . .
2.2 Interaction Modeling Approach . .
2.2.1 Host Identification . . . . .
2.2.2 Flow Modeling . . . . . . .
2.3 Interaction Modeling Results . . .
2.4 Conclusion . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Topological Model and Dynamics of Wireless Network
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . .
3.2 Deployed Low-Power Wireless Network . . . . . . .
3.3 Basic Topology Characteristics . . . . . . . . . . .
3.3.1 Tree height and average path length . . . .
3.3.2 Tree-level densities . . . . . . . . . . . . . .
3.4 Analysis of Topological Dynamics . . . . . . . . . .
3.4.1 Inter-tree dynamics . . . . . . . . . . . . . .
3.4.2 Intra-tree dynamics . . . . . . . . . . . . .
3.4.3 Implications . . . . . . . . . . . . . . . . . .
3.5 Analysis of Load-balancing Properties . . . . . . .
3.5.1 Measure the task load . . . . . . . . . . . .
3.5.2 Connectivity responsibility . . . . . . . . .
3.5.3 Implications . . . . . . . . . . . . . . . . . .
3.6 Related Work . . . . . . . . . . . . . . . . . . . . .
3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . .
4 Wireshark Extension: a Tool
4.1 Introduction . . . . . . .
4.2 Problem Statement . . .
4.3 Proposed solution . . . .
for
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
. 7
. 7
. 8
. 8
. 9
. 13
in AMI
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
15
16
17
18
19
20
20
22
24
25
25
26
27
28
28
Parsing DLMS-COSEM
30
. . . . . . . . . . . . . . . . . . . . . . . . . . 30
. . . . . . . . . . . . . . . . . . . . . . . . . . 31
. . . . . . . . . . . . . . . . . . . . . . . . . . 32
3
4.4
4.5
4.6
4.7
DLMS-COSEM Parser . . . . . . .
4.4.1 Overall Architecture . . . .
4.4.2 Design and Implementation
Results . . . . . . . . . . . . . . . .
Discussion . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . .
5 Conclusion
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
32
33
34
36
37
38
39
Abstract
Interaction Modeling investigates new techniques for the automated inference of dynamic
network structures, and the information that flows among their devices. By considering empirical observations performed by sensing devices physically deployed within a
monitored network and passively collecting information on the exchanges of its devices,
we gain a better understanding of the network properties and its structure. This understanding is useful for both end users and for the research work on network-driven
detection (WP6). Last year, the preliminary results reported focused on SCADA networks. This year, we instead concentrated our analysis on the other use case in crisalis,
AMI networks.
1 Introduction
The interaction modeling work package is a precursor to the modeling and the attack
detection in work packages 6 and 7. By better understanding the interactions of the
devices in the network and how the network structure evolves over time, better models
for attack detection can be built that will result in less false alarms.
Last year, the preliminary results reported focused on SCADA and ICS (Industrial
Control System) environments. This year, our work concentrated on the analysis of the
other use case proposed in crisalis, Advanced Metering Infrastructures (AMIs). We
have performed three separate studies. In the first, we extend the tools described last
year used to analyse SCADA and ICS environments to analyse also AMIs. We run these
tools in the test bed provided by Alliander and discuss the results.
In the second, we analyse the topological properties of a very large AMI to better
understand how the network in such an environment would perform. This is important to
create future realistic simulation models, but also to understand the traffic characteristics
to better build models used for attack detection in work package 6. The analysis was
performed on a large deployed AMI, which should be typical of a medium-sized European
city. By using statistics from a real metropolitan-scale network, we can capture large
scale behaviour and more realistic usage of the network than if the traffic had been
captured in a smaller test bed. However, the large-scale capture meant that we had to
use different techniques than what is described in the first chapter of this deliverable.
In the third chapter, we describe a more practical piece of work. We identified a
tool gap for European industries and researchers to efficiently analyse traffic in AMI
environments, and thus developed a tool for such analysis. This is a dissector for the
well-known protocol analyser Wireshark, parsing DLMS-COSEM. This tool has been
tested on traffic captured in the Alliander test bed, for example to clarify the results
from the fuzzing experiment in AMIs.
Deliverable D4.2 reported last year (focusing on SCADA and ICS) and this deliverable
D4.5 (focusing on AMI) together summarize the results from the Interaction Modeling
work package, where each use case defined for the crisalis project has been analyzed
in detail. Together with the final results in protocol learning and device fingerprinting
also delivered this year, this research lays the basic foundation for the work now being
performed in attack detection for work package 6 and 7.
6
2.1 Introduction
The problem being addressed with interaction modeling is to observe and automatically
reconstruct a model of a critical infrastructure environment. The model will address
two aspects of the network: the network static structure and the network dynamics.
Determining the network static structure involves detecting the presence of hosts in the
network as well as inferring their connectivity, i.e., the network topology. The network
dynamics consists of analyzing the information flow within a network.
There are many reasons why interaction modeling is important for critical infrastructure networks, as were outlined previously in deliverable D4.2, even given the safeguards
in place to isolate those networks. In fact, the isolation of the seemingly private networks for ICS is something of a myth. Employees are often granted remote access to
power plants via VPN (virtual private network) in order to more efficiently manage
plants, especially unmanned plants. Another way in which isolation is broken is during
maintenance periods, when employees and contractors access the physical environment
and area allowed to temporarily connect to the private network directly; the machines
that are connected to the network during this maintenance periods can carry infections
and other malware, either accidentally or knowingly. Finally, non-compliant systems
can be introduced onto the network by employees or contractors in order to more efficiently achieve tasks, or intruders can connect rogue devices that must be detected and
ultimately remediated.
The techniques and preliminary results for interaction modeling were introduced previously in deliverable D4.2, applied to ICS and SCADA network data. In this chapter
we summarize the technical approach and present additional results modeling the interactions using AMI network data.
2.2 Interaction Modeling Approach
The approach that we have developed for interaction modeling relies on two technologies:
a passive listener for host identification and a Layer 3 network topology inference engine
for flow modeling. We describe each in the next two subsections.
7
2.2.1 Host Identification
It is important to have ongoing visibility into the hosts that are present on critical
infrastructure networks. However, many commonly used approaches to network topology
mapping, such as nmap network scanning, are ”point in time” solutions that could miss
hosts that come and go between scans. Furthermore, scanning suffers from additional
shortcomings such as possible adverse impacts on the network (e.g., traffic generation)
and on the hosts themselves (depending on the type and level of scanning). For this
reason, an ideal approach to host identification in ICS networks would be passive, simply
listening to traffic, constantly, to identify the presence of hosts.
The prototype that we developed for host identification is called the passive listener.
The passive listener monitors network traffic from a single point in each layer 2 subnet
on the network (or alternately can analyze a packet capture of network traffic from that
single point). This monitoring point need not be a network tap, or mirroring port on a
central network switch, as we cannot rely on that capability in these networks. Operators
sometimes could be reluctant to change the network infrastructure, and there are often
organizational barriers where changes to the network are controlled by a different group
(network administrators) than the group that is responsible for security. For this reason,
the passive listener relies solely on monitoring broadcast traffic, which is traffic that by
definition is transmitted to every part of a layer 2 network. Therefore, the passive
listener can be deployed at any point, on any host, that is under the control of the
security administrator in each layer 2 subnet.
There are many broadcast protocols that can be analyzed to identify the hosts that
are present on the network. Many of these protocols are central to the operation of
a TCP/IP network, and thus fairly reliable from a monitoring perspective. Broadcast
protocols such as Address Resolution Protocol (ARP) and Dynamic Host Configuration
Protocol (DHCP), for example, are commonly and frequently seen and can be relied
upon for identification of hosts (as discussed previously in D4.2).
The output of the passive listener is the inventory of all hosts and devices on the
network that generated broadcast traffic, the types and volume of broadcast traffic that
were recognized, and the information about each host and device that could be extracted
from the broadcast protocols (such as hostname and protocol address).
2.2.2 Flow Modeling
In addition to needing to understand the hosts that are present on the network, we must
also collect information on the dynamic interactions performed by devices on the network. Complementing the host identification component is a flow modeling component
8
2.3 Interaction Modeling Results
that addresses layer 3 network topology, building on top of the details of the layer 2
information collected by the passive listener and extending that network picture with
the additional data from the network flows.
The flow modeling component builds upon concepts from a well-known, open-source
network management tool called EtherApe1 . At a high level, flows at different network
levels (e.g, IP or TCP) are extracted from the network activity in a packet capture,
and these flows are connected to the output of the host identification passive listener
component.
The output of the flow modeling component is an interaction map that shows the
network structure, hosts, and network interactions. These interaction maps are presented
in the next section.
In this section, we provide results from analyzing tcpdump packet traces collected on an
Alliander AMI network.
Previously, in deliverable D4.2, we presented preliminary results applying the interaction modeling technology to tcpdump packet traces collected in the SCADA/ICS validation environment from Livorno (itself described as part of the Validation Support
WorkPackage WP3). Interaction maps for both the field network and process control
network were displayed and discussed. These interaction maps were produced by combining the outputs of the passive listener and flow modeling prototypes to generate static
interaction maps from the information flows observed in real-world network traces.
The generated interaction maps use different color codes to characterize different node
types detected in the network:
Pink color. Hosts that have been detected by the passive listener component.
Yellow color. Hosts that have been detected by the passive listener component, and that
have been inferred through the flow modeling component to be routing devices.
Green color. Hosts that have been seen interacting by the flow modeling component,
but that were not detected by the passive listener.
Gray color. Hosts whose MAC address is unknown (e.g. hosts hidden behind a router)
whose IP was observed by the flow modeling component.
1
http://etherape.sf.net
FP7-SEC-285477-CRISALIS
9
Figure 2.1: AMI network interaction model from packet capture #1
The edges connecting the different nodes have a width that is proportional to the
number of packets exchanged between the endpoints. The current implementation does
not try to group packets into different TCP/UDP flows, but we do know all of the
ports associated with the traffic for each edge and the tool can be tailored to label with
ports/protocols of interest.
In order to comply with the confidentiality requirements enforced by the partners,
we have obfuscated all the IP addresses and hostnames identified by our tool. The
information extracted from the traces was in fact pointing to hostnames and IP addresses
commonly used in real operational environments, and it was judged that the disclosure
of such information to the public may have led to security risks, and thus the interaction
maps presented have been ”anonymized” with generic labels.
Figure 2.1 depicts the interaction model from a network packet capture of an AMI
infrastructure. The passive listener component had limited detection value, as shown
by only two hosts depicted in pink, IP1 and IP2, because this packet capture was taken
from a single subnet in the network. The broadcast traffic from those two hosts included
hostname information; one of them could be identified as the machine introduced onto
the network by CRISALIS for monitoring (IP2) and the other as the AMI managing
client (IP1).
The flow modeling component was able to identify many more devices interacting on
the network. The flow modeling component discovered four subnets with multiple but
varying numbers of devices in each, and then a variety of other devices with IP addresses
10
that were not on shared subnets. A total of 28 IP addresses and associated interactions
were detected by the flow modeling component. IP3 can be seen interacting with a
number of nodes on the network using the DLMS/COSEM protocol and thus it can
be identified as the AMI head end server. In particular, IP addresses IP4 through IP9
were known to be associated with smart meters on the network based on their traffic
(labeled DLMS/COSEM manually for ease of identification in these maps) and they
each have a connection to the AMI head end server. A significant volume of traffic was
detected between the AMI head end server (IP3) and the AMI managing client (IP1), as
indicated by the thicker connecting line. There are a number of other IP addresses that
are discovered by the flow modeling component that are not directly associated with
AMI operations.
Figure 2.2 depicts the interaction model from another network packet capture of the
same AMI infrastructure, taken one month later. The interaction maps generated from
these two packet captures are fairly similar, though not exactly the same. Some difference
is due to the duration of the packet capture: this second one was much shorter, containing
only 4,176 packets versus 21,621 packets in the first packet capture. Again, the passive
listener component is run from the same subnet as before (anonymized, but the same
subnet address matched in the original data) and the same three machines are detected
11
in that subnet: the AMI head end server (IP3), the AMI managing client (IP1), and the
CRISALIS monitor (IP2). The flow modeling component only identified 16 IP addresses
and associated interactions this time, again due to the shorter duration of the packet
capture, but 11 of the 16 devices are seen to interact with the known AMI head end
server in this capture. From the non-anonymized data, the same subnet that contained
smart meters in the first packet capture also contains smart meters in this second packet
capture, but a second subnet is also seen to contain smart meters.
Finally, figure 2.3 depicts the interaction model from another network packet capture
of the same AMI infrastructure, this one taken around the same time as the second
(one month later than the first capture), but this one similar in size to the first capture
(20,943 packets). This interaction map matches the first two for the most part. The
passive listener component is run from the same subnet as in the first two captures;
it detects the same three machines as before (the AMI head end server IP3, the AMI
managing client IP1, and the CRISALIS monitor IP2), as well as a fourth device (a
laptop IP4). The flow modeling component identifies 39 IP addresses and associated
interactions. Again, interactions with the AMI head end server (IP3) show that smart
meters reside in two of the subnets. However, there are again a number of other IP
addresses and devices identified by the flow modeling component in the packet capture
that are not directly associated with AMI operations.
12
2.4 Conclusion
2.4 Conclusion
In this chapter we have presented the interaction modeling prototype, which was previously run against SCADA network data, and provided the results from running against
AMI network data. The interaction modeling prototype consists of two complementary
components: a passive listener for host identification and a flow modeling component to
determine interactions between hosts. The interaction modeling prototype combines the
results from these two components to produce an interaction map. From the analysis of
the packet captures using the interaction modeling prototype, we can see that the flow
modeling component in particular is able to identify many interactions between devices
on the network, those associated with AMI operations as well as other interactions. The
passive listener component was less useful in this context given the network topology
of the AMI network; the passive listener requires presence on every subnet in order to
identify hosts by their broadcast traffic, and that might be an unrealistic assumption for
this environment. To further enhance the understanding and discovery of the network,
the interaction modeling prototype must be combined with device fingerprinting and
protocol learning capabilities. This combination and integration of capabilitiies will be
further discussed in the prototypes of workpackage WP6.
13
3 Topological Model and Dynamics of Wireless
Network in AMI
It is commonly agreed that reliable communication networks play important roles in
an Advanced Metering Infrastructure (AMI). All the interactions between smart devices
(e.g. smart meters), or between meters and the control server are supported by the
communication networks. In the current AMI deployments, different communication
techniques (protocols) are usually used in different blocks of the system. For example,
meters can communicate with each other through wireless mesh networks or ZigBee
networks; they can also directly communicate with the control server through cellular
networks (e.g. GPRS); wireless or wired communication techniques can also be used for
data concentrators, where the data from the meters is gathered and may be processed
preliminarily, to connect meters and the control server. The network properties, such as
topological structures and dynamics, reflect the behaviors of the corresponding protocols
which affect the interaction pattern between smart devices. The corresponding interaction model is suitable for detection of suspicious interactions likely to be associated to
intrusions (D6.3).
In particular, in this chapter,1 we present new and real-world insights from a deployed
metropolitan-scale low-power wireless network: It includes 300,000 individual wireless
connected meters and covers a city with roughly 600,000 inhabitants. Low-power wireless, such as IEEE 802.15.4, is envisioned as one key technology for wireless control
and communication. In the context of the Advanced Metering Infrastructure (AMI),
it serves as an energy-efficient communication technology for both communications at
building-scale networks and city-scale networks.
Roughly speaking, we study the common topological properties of the network, such
as size of the routing trees, average path length, tree-balance. We also introduce new
metrics to capture the network dynamics which is not established in the literature.
Our findings help to estimate real-world parameters of low-power wireless network,
thus facilitate the understanding and the realistic calibration of simulation models in
1
This chapter is based on the peer-reviewed article Z. Fu, O. Landsiedel, M. Almgren, M. Papatriantafilou: Managing your Trees: Insights from a Metropolitan-Scale Low-Power Wireless Network,
2014 IEEE INFOCOM Workshop on Communications and Control for Smart Energy Systems, April
2014.
14
3.1 Introduction
key properties such as reliability and throughput. Moreover, our findings reveal and
quantify the inherent network dynamics which is essential for system status monitoring
and anomaly detections.
3.1 Introduction
A key vision in Wireless Sensor Network (WSN) research has always been large-scale
deployment: tens of thousands of sensor nodes potentially covering large metropolitan
areas shall sense and interact with the environment to enable new applications. With
the recent trends towards Machine-To-Machine Communication (M2M) and Internet of
Things (IoT) we gradually see these visions enfolding [4, 16, 18, 21].
In this chapter, we present our insights from a metropolitan-scale network of 300,000
wireless nodes, i.e. smart meters, covering a city with roughly 600,000 inhabitants. Meters employ IEEE 802.15.4 [12] and ZigBee [1] for wireless communication and provide
the Advanced Metering Infrastructure (AMI) of the city. The deployment began in 2008
and the network has been operating at production level since 2009.
To our best knowledge, this chapter is the first work to present insights into such a
large-scale low-power wireless network. We present common metrics for this network
to characterize topological properties. In addition, we introduce new metrics, useful
to describe the network dynamics. Our findings will (1) help researchers in developing
topology models for simulation studies and (2) guide engineers when deploying large-scale
networks to achieve high performance and ease network maintenance. In the following,
we summarize our contributions.
Realistic Topology Characteristics: We conduct holistic studies including 300,000
wireless nodes and present common topology characteristics such as distances, paths,
etc. We argue that based on our findings, detailed network models of low-power wireless networks can be derived. Such models enable the generation of synthetic network
topologies with realistic properties and, as a result, ease protocol evaluation in controlled environments when real network data, especially on a large scale, is unavailable.
Network Dynamics: Wireless link-dynamics impact the link quality between two
devices and potentially lead to connectivity and topology changes. Such link dynamics
are especially common in low-power wireless communication, e.g., IEEE 802.15.4, as
their low transmission power makes its signals susceptible to interference and noise. We
investigate such topological dynamics and study correlations between these dynamics
and selected deployment factors, such as received signal strength indication (RSSI), and
geographical deployment density. We believe that the network dynamics characterized
15
3 Topological Model and Dynamics of Wireless Network in AMI
Notation
Ti
tdi
mj
li
Meaning
routing tree of coordinator i
the dth snapshot of Ti , d ∈ {1, · · · , Di }, where Di is the
number of snapshots of Ti
meter j
tree level i (li , i ∈ Z+ ). In a ZigBee tree, nodes in li are the
nodes which are i hops away from the coordinator.
Table 3.1: An overview of the notations used in this chapter.
in this chapter can guide engineers when deploying and maintaining low-power wireless
networks and ease their management.
Routing Trees: In low-power networks, multi-hop routing is a crucial building block:
it ensures that packets from a source are forwarded to the sink where processing takes
place. In this setting, connectivity and load-balancing are crucial to ensure network reliability and performance. We investigate how packet forwarding tasks are distributed
among the nodes in order to identify the hotspots, i.e., the critical points, in the network. Our findings shed light on how to choose network parameters when deploying
low-power wireless networks and they provide insights for developing new routing protocols with further improved network reliability, reduced delay and increased energy
efficiency.
The remainder of this chapter is organized as follows: In Section 3.2, we introduce
the studied metropolitan-scale network and our data traces. In Section 3.3, we begin by
presenting basic characteristics of the network topology. Next, we conduct a deeper analysis and describe topology dynamics and load balancing in Section 3.4 and Section 3.5,
respectively. We discuss related work in Section 3.6 and conclude in Section 3.7.
3.2 Deployed Low-Power Wireless Network
The low-power wireless network discussed in this chapter contains around 300,000 wireless nodes. These nodes are smart electricity meters belonging to the Advanced Metering
Infrastructure (AMI) [11] of a city. The network covers a metropolitan area with roughly
600,000 inhabitants and about 450 km2 in size. Its main task is to collect metering data
from smart meters and forward it to the central server for processing and billing. In
addition, it handles monitoring of the meters, including error-reporting and over-the-air
configuration.
16
12
10
8
6
4
2
0
7
Average path length
Average tree height
3.3 Basic Topology Characteristics
0 50 100 200 300
Average tree size
6
y = log10 (x)
5
y = log3 (x)
4
3
2
1
0
-1
0.1
1
10
100
1000
Average tree size (in log scale)
Figure 3.1: Average heights of all rout- Figure 3.2: Average path lengths of all
ing trees.
routing trees.
The 300,000 meters communicate with each other via IEEE 802.15.4 and a variant of
ZigBee for routing. In addition, 7,600 coordinator nodes are deployed throughout the
city. Coordinators serve as data sinks and employ a cellular radio, commonly GPRS,
next to the 802.15.4 radio. Meters connect to these coordinators either directly or use
other meters as relays. Thus, throughout the city there are 7,600 routing trees, each
with a coordinator node as the root. Nodes can connect and later change to any of
these trees, but at any time point a meter can belong to only one tree. Coordinators
and electrical meters have built-in power supplies. In addition, batteries are used in the
presence of power outages.
The results presented in this chapter are based on a data trace of nearly two months
(56 days) during the year 2012. For each day, it contains a snapshot of the complete
topology of all active nodes.2 The notations used in this chapter are given in table 3.1.
In this section, we present standard graph-related parameters of routing trees in the
studied network, as these are useful for (i) registering these characteristics as parameters
that can be used in simulation studies, (ii) getting implications for network performances
(such as latencies) that can be affected by those parameters, (iii) using them in the analysis and study of higher level properties and measures, such as dynamics and balancing
2
Note that due to ongoing network maintenance, some coordinators and their child nodes are omitted
for individual days.
17
properties, as proposed and presented in the subsequent sections.
More specifically, we study a) tree heights, b) path lengths from nodes to the corresponding coordinators, and c) the node distributions at different tree levels. Since each
of these measures depends on the number of nodes in the tree topology, we study the
measures relative to the sizes of the corresponding routing trees.
3.3.1 Tree height and average path length
Tree height is an important topology characteristic indicating the depth of a tree. It can
be used in measuring the tree balance [13], through the comparison to the tree size. If
it has logarithmic relation to the tree size, then the tree has a good balancing property,
which implies good message delivery latencies from leaf nodes to the root. However, tree
height can be affected by changes of only a small part of the tree (i.e., adding a child
node to a node in the maximum tree level is enough to make the tree height grow by
1), while average path length of a tree can imply the network latencies on average cases,
which will not be affected by extreme
P values. Thus we study both of them: The average
height of Ti is computed as D1i 1≤d≤Di height of tdi ; the average path length of Ti
P
is computed as D1i 1≤d≤Di average path length of tdi . Fig. 3.1 and Fig. 3.2 show the
average tree heights and average path lengths of all routing trees, respectively. Based
on the figures, we found the following:
In Fig. 3.1, we observe significant “step” growth of tree heights taking place at approximately network sizes 15, 50, 100, 200. This is an expected pattern in a relatively
balanced tree topology, as each tree level has its capacity of containing nodes and, the
number of nodes at each level is a multiple of those at the previous level, thus the minimum number of tree levels (i.e., the lower bound of tree height) grows approximately
logarithmically with the tree size.
The variance of tree heights can be large for similar tree sizes. For example, in Fig. 3.1
when the average tree sizes are around 100, the corresponding average tree heights
vary from 3 to 10. This is because the maximum distance between a node and the
coordinator is highly depending on the physical locations of the meters, which may
have large variations in real-world deployments.
In Fig. 3.2, we observe that, in general, the average path lengths grow logarithmically
with the tree sizes. We plot two lines: log10 x and log3 x, noting that most points are
bounded by these two lines. This observation implies good performance of message
delivery latencies for average cases.
18
0.7
tree size within (0,15]
tree size > 200
0.6
Proportion
0.5
0.4
0.3
0.2
0.1
0.00
2
4
6
8
Tree levels
10
12
14
Figure 3.3: Proportion of nodes in each tree level with different categories of tree sizes
3.3.2 Tree-level densities
Next we study the tree-level densities, i.e., the node distribution upon different tree
levels, which is an important topology characteristic for generating synthetic topologies
and can also give an explanation from this aspect for what we observed in Fig. 3.1,
and 3.2. The nodes distribution upon different tree levels were studied for the different
categories of tree sizes, following the “step” pattern observed in Fig. 3.1. The results
are shown in Fig. 3.3. We observe that:
When there are a small number of nodes in a routing tree, then most of the nodes are
connected directly to the coordinator (i.e., reside in l1 in the tree).
When the tree size is growing, the broadest tree level moves down. In Fig. 3.3 we can
see that the broadest tree level is l1 when the tree size is below 15; when the tree size
grows, it moves to l2 ; when tree size reaches 200, it is l3 .
The size of li does not always increase exponentially when i increases. This explains
why the heights of many trees are not logarithmic to the tree sizes. Instead, the
size of li increases with i increasing until it reaches the broadest level; then it decreases
exponentially with i increasing. Therefore, the proportion of nodes with a large distance
to the root is quite small, i.e. the trees are diamond-like in shape, thus explaining why
the average path lengths are logarithmic to the tree sizes.
19
Tree size dynamic ratio
2.0
1.5
1.0
0.8
0.5
0.2
0.0
0
100 200 300350
Average tree size
Figure 3.4: Tree size dynamic ratios of all routing trees
3.4 Analysis of Topological Dynamics
Reachability-distances
The dynamic nature of wireless sensor networks influences network management and
communication reliability. In this study, we try to capture such dynamics from the
aspects of inter-tree dynamics and intra-tree dynamics, indicating changes of tree participations and changes of parent-child relations among nodes, respectively.
10.00
1.00
0.50
0.30
0.10
0.01
Coordinators
Figure 3.5: Reachability-distances (in km) of all coordinators plotted in log scale
3.4.1 Inter-tree dynamics
We propose the following measures to describe the inter-tree dynamics features:
20
Definition 1 (Tree size dynamic ratio) The tree size dynamic ratio of Ti is defined
as the ratio of the standard deviation of its tree size to its average tree size.
Definition 2 (Core-set and Core-set ratio ) The core-set of Ti is defined as:
def CoresetTi == mj : d : mj ∈ tdi ≥ Φ
(3.1)
i.e., the set of nodes that have been part of this particular routing tree in at least Φ
snapshots. In our study, we choose Φ as 50 (considering there are 56 snapshots of the
network in the data trace), meaning that if a meter belongs to more than 50 tree snapshots
of Ti , then this meter is counted in the core-set of Ti .
The core-set ratio of Ti is defined as:
def
Core-set ratio of Ti ==
|CoresetTi |
average tree size of Ti
(3.2)
The tree size dynamic ratio describes how the nodes are associated with the routing
trees and how big the changes of such associations can be. Fig. 3.4 shows tree size
dynamic ratios of all routing trees. We can see that most (95%) of routing trees do not
have big size dynamic ratios (less than 0.2), which leads us to the following question:
Q 1 Can we induce that most of the nodes always stay in the same routing trees?
To have deeper insight of inter-tree dynamics, the core-set ratio can help us to see
what is the proportion of nodes that are “faithful”, i.e., that always stay in the same
routing trees. Whether a meter chooses to change its routing tree depends on whether
there are other routing trees nearby offering better communication performance. Thus,
the density of neighbor coordinators of Ti can affect its core-set ratio. Taking this into
consideration, we study the core-set ratio based on different geographical deployment
densities of coordinators.
We use a well-known density-based clustering algorithm, called OPTICS [3], to find
the variance of deployment densities of the coordinators. In the OPTICS algorithm,
the standard way to identify clusters is to plot the reachability-distances (RD) of all the
points to their neighbor cluster cores in an algorithm-specified order, which is called
reachability-plots. The reachability-distances describe how dense the points are located:
smaller reachability-distances indicate denser deployment, while bigger ones indicate
sparser deployment. Figure 3.5 shows the reachability-plots of coordinators in the studied network.
21
We identified three levels of reachability-distances based on which we conducted the
study on core-set ratios of the routing trees. The results are shown in Fig. 3.6, from
where we can see the followings:
When the tree sizes are small (smaller than 10), the core-set ratios are usually high
(above 0.8).
When the coordinators are deployed more sparsely, the proportion of routing trees who
have high core-set ratios increases, e.g., in Fig. 3.6c, we see that most of the core-set
ratios are concentrated between 0.6 and 0.8.
The observations above are what we expected: When the coordinators are deployed
sparsely, meters do not find many routing trees nearby, it is more likely that they always
stay at the same routing trees. For most of the small routing trees, coordinators and
meters are physically located very closely (e.g., in the same room), to get the optimal
routing service, the best choice for those meters is to stay in the routing trees of the
coordinators co-located with them.
From Fig. 3.6, we know that it is not true that most of the meters always stay in the
same routing trees (answer for question 1). And combined with the observation from
Fig. 3.4, it is interesting to observe that even though the node sets of routing trees vary
a lot, the relative sizes among routing trees are quite stable.
3.4.2 Intra-tree dynamics
After studying the inter-tree dynamics, we focus on the dynamics within routing trees.
Since within a routing tree, a node may change its parent node, its parent node in
different snapshots may be different. To this end, we study the parent-child associations
among meters and give the following measure:
Definition 3 (Parent-dynamics) The parent-dynamics of meter mi is defined as the
number of different parent nodes that mi has in the data trace.
Important factors which may affect the parent-dynamics are the coordinators deployment density, the received signal strength indication (RSSI) and the tree levels that
meters belong to. Fig. 3.7 shows the probability density functions (PDFs) of parentdynamics affected by the three factors. Based on that, we found the followings:
Coordinator-deployment density does not have big influence to the parent-dynamics. It
is observed from Fig. 3.7a that the three PDFs corresponding to different coordinatordeployment densities are quite similar.
22
1.0
0.8
0.6
0.4
0.2
0.0
0.026
Core-set ratio
Core-set ratio
0
100 200 300 0.000
Average tree size
1.0
0.8
0.6
0.4
0.2
0.0
0.02
0
100 200 300 0.00
Average tree size
(b)
Core-set ratio
(a)
1.0
0.8
0.6
0.4
0.2
0.0
0.016
0 50
150
250 0.000
Average tree size
(c)
Figure 3.6: Probability density function of bivariate distribution of <average tree size,
core-set ratio> under the three reachability-distances levels of coordinators:
(a) reachability-distances are smaller that 100m, (b) reachability-distances
∈ [100m, 300m], (c) reachability-distances are bigger than 300m
Higher RSSI does not necessarily lead to less parent-dynamics. Based on Fig. 3.7b,
it is not possible to conclude that higher RSSI3 (higher than −30dBm) implies higher
probability of small parent-dynamics than lower RSSI, e.g., within (−70dBm, −30dBm).
Meters which are close to the coordinator do not have less parent-dynamics. From
Fig. 3.7c we observe that for a meter within 3 hops away from the coordinator, the
3
In our network, the maximum value of RSSI is 0dBm.
23
PDF
0.05
0.12
RD < 100m
RD within [100m,300m]
RD > 300m
0.08
0.06
0.03
0.01
0.000 10
RSSI>=-30
RSSI within (-30,-70)
RSSI<=-70
0.10
PDF
0.07
0.04
0.02
30
50
Parent-dynamics
70 80
(a) PDF of parent-dynamics under different
coordinator-deployment densities
0.09
0.07
0.000
5
15
25
Parent-dynamics
35 40
(b) PDF of parent-dynamics with different
RSSI levels
average hops<=3
3<average hops<=6
average hops>6
PDF
0.05
0.03
0.01
0.000 10
30
50
70
Parent-dynamics
90
(c) PDF of parent-dynamics with different hops
Figure 3.7: Parent-dynamics affected by different factors.
probability that it has more than 15 parents is higher than the corresponding probability
for a meter further (e.g. more than 3 hops) away from the coordinator.
3.4.3 Implications
Network dynamics may imply difficulties for network maintenance. For example, in
the AMI system, communications between the control server and the meters are done
through coordinators. If a meter changes its routing tree frequently, then it is difficult for
the control server to track it when the server needs to communicate with the meter, which
24
ABSP
3.5 Analysis of Load-balancing Properties
1.2
1.0
0.8
0.6
0.4
0.2
0.0
0 50
150 250
Average tree size
350
Figure 3.8: Average biggest subtree proportion of all routing trees
may impair the two-way communication ability of AMI [11]. In the meanwhile, within
a routing tree, high parent-dynamics may cause Orphan problems[19]. For instance, a
node may attract many nodes to connect to it due to the good signal strength, which
can make it reach the limit of the number of children it can have. So the node cannot
accept new connections anymore which may lead some nodes to be unable to join the
network since that node is the only parent node that they can find.
Our findings suggest that sparser deployment of coordinators may ease the work of
tracking meters. However, deploying less coordinators can increase the sizes of routing
trees, thus affecting the network latencies (observed in Section 3.3). This motivates
further investigation on the optimal deployment of coordinators. Parent-dynamics seems
to be inherent to the routing trees. Our findings provide insights of its behavior with
different deployment factors. To control such dynamics, it can be also helpful to use some
static routing strategies or parent-child associations with the combination of dynamic
strategies, which was also suggested in [16] for large-scale WSNs.
3.5.1 Measure the task load
A node acting as a router in a routing tree carries responsibility for forwarding the
messages for the nodes in the subtree rooted at it. The sizes of these subtrees have
therefore implications on the robustness of the network, as large subtrees place large
task loads to the routers. Therefore, we propose the following measure for analyzing the
25
load-balancing properties of routing trees.
Definition 4 (Average biggest subtree proportion (ABSP)) The ABSP of Ti is
defined as
def
ABSPTi ==
1
|Di |
X
1≤d≤Di
the biggest subtree size of tdi
size of tdi
(3.3)
This measure describes the average biggest task load for routers in a routing tree. It
is important, since usually a router in a tree is just an ordinary node who acts in the full
function mode without having more computation power. Its performance is crucial for
the message deliveries, especially when all the nodes in its subtree try to send messages
simultaneously. Fig. 3.8 shows the ABSP with the average tree size for each routing
tree. We observed the following:
“Hot spots” do exist in many routing trees: Although there is a big proportion of
routing trees having their ABSPs less than 0.4, there are still around 15% of routing
trees with their ABSPs greater than 0.6. This means that in such a routing tree, there
exists a node that has to forward messages for more than %60 of the nodes in the tree.
3.5.2 Connectivity responsibility
For fine-grained information of load-balancing, we investigate the connectivity responsibility of routers, which can be implied by the following question:
Q 2 Is there a small set of routers in li that always connect most of the nodes in li+1 ,
or do all routers in li connect similar number of nodes in li+1 ?
To capture such balance-related property, we compute the degree distribution of nodes
in different tree levels. From the study in section 3.3, we know that most of the nodes
reside in the top 4 tree levels, so most of the routers reside in the top 3 levels. Therefore,
we focus on the degree distribution of nodes in l1,2,3 . Since the tree sizes may also
affect the nodes distribution of different tree levels which may also affect the degree
distribution, we conduct our study for each of the tree size categories4 : (16, 50], (50, 100],
(100, 200], (201, +∞]. Figure 3.9 shows the results. We found that:
In all cases, the proportion of nodes that have degree x decreases exponentially with
the growth of x.
4
We do not consider routing trees who have less than 15 nodes, since in such cases, most of the nodes
are leaf nodes and are directly connected to the coordinators. Studying the node-degree distribution
for them is trivial.
26
100
tree level 1
tree level 2
tree level 3
10-1
10-2
10-3
10-4
10-5 0 2 4 6 8 10 12 14 16 18
Node degrees
Proportion (plotted in log scale)
100
10-1
10-2
10-3
10-4 0 2 4 6 8 10 12 14 16 18
Node degrees
tree level 1
tree level 2
tree level 3
10-1
10-2
10-3
10-4 0 2 4 6 8 10 12 14 16 18
Node degrees
(c) tree sizes ∈ (100, 200]
(b) tree sizes ∈ (50, 100]
(a) tree sizes ∈ (16, 50]
100
tree level 1
tree level 2
tree level 3
100
tree level 1
tree level 2
tree level 3
10-1
10-2
10-3
10-4 0 2 4 6 8 10 12 14 16 18
Node degrees
(d) tree sizes > 200
Figure 3.9: Degree distribution of nodes in different tree levels. Trees are categorized
according to their sizes
In each tree level, most of the nodes are leaf nodes (having degree of 1)
Answer to question 2: most of the nodes in li+1 are connected to routers in li that have
small degrees (e.g., between 2 and 5).
3.5.3 Implications
The energy consumption of a wireless node depends on its subtree size, as the wireless
radio chip consumes by far the most power on a sensor node. We showed that nodes
27
can have big subtrees with non-negligible probabilities. If such critical nodes run out
of battery, then a big part of nodes may be temporally disconnected from the network.
This is not acceptable for AMI in smart grid, especially when time-critical messages need
to be delivered to the server. Therefore, our findings give the insights for controlling
the sizes of routing trees and nodes deployment [8]. It also implies the need for rules
to choose parent nodes and ensure tree-balancing when a new node is joining into the
network. Moreover, besides the basic topological parameters given in Section 3.3, the
distributions of ABSP and nodes degrees can be used as parameters of topology models
for WSN simulation studies.
3.6 Related Work
Previous studies on network characteristics of low-power wireless networks are always
based on simulations[10, 15, 9, 24]. Here we focus on studies of big-scale real network
deployments. Large-scale deployments of wireless sensor nodes can be classified into two
groups: (1) commercial, production-level deployments, and (2) deployment for research
purpose.
Commercial deployments often contain tens of thousands of nodes. For example, the
City Center Hotel in Las Vegas has 4,200 wireless automated rooms and contains a total
of 136,000 wireless ZigBee nodes [17]. The Jackson Memorial Hospital at the University
of Florida has 14,000 Zigbee-based tags helping to track assets [6]. While these and
many others are large-scale deployments, to our best knowledge, none of them have
been analyzed from a research point of view as we do in this chapter.
Next to these production-level deployments, there exists a large body of research
deployments. While many of their network properties are discussed in scientific publications, these deployments are commonly limited to some thousands of nodes. For
example, the Smart Santander deployment in Spanish city of Santander contains about
5,000 wireless nodes [21]. Similarly, GreenOrbs [16] contains about 2,000 nodes, CitySee
about 1,200 [18], and ExScal about 1,000 [4]. In contrast to these, we present insights
into a metropolitan-scale network, containing 300,000 nodes and covering a city of about
600,000 inhabitants. Furthermore, our study focuses on topological properties and dynamics which were not mainly considered in the previous work.
3.7 Conclusion
In this chapter, we presented a detailed study analyzing key properties of a metropolitanscale low-power wireless network, which belongs to the AMI of a European city. It
28
3.7 Conclusion
contains 300,000 wireless nodes (meters) and comprises several thousands of routing trees
to which the wireless nodes connect. In particular, with our study we can characterize
(i) the shape of the trees, (ii) proportions of the nodes that “migrate” between trees
relative to the deployment density (inter-tree dynamics) and proportions of nodes that
change parents within the same tree (intra-tree dynamics), and (iii) contention and
balancing properties through distributions of node degrees and biggest subtree sizes.
Analyzing those key properties and building corresponding models can ease network
operation and management for practitioners and simulation projects for researchers.
These new models are required as low-power networks differ in key aspects from other
large-scale deployments such as the Internet itself [22] or cellular networks [20].
29
4 Wireshark Extension: a Tool for Parsing
DLMS-COSEM
4.1 Introduction
One of the protocol standards in Europe for advanced metering infrastructure (AMI)
is the DLMS-COSEM protocol suite. A large number of devices are going to use this
protocol across advanced metering infrastructures in different countries in Europe, which
in turn increases the risk of attackers focusing their effort to analyze this protocol for
weaknesses that could be exploited across a considerable number of installations.
The acronym DLMS stands for “Device Language Message Specification” while the
acronym COSEM stands for “COmpanion Specification for Energy Metering”. DLMSCOSEM is an object model that abstract the interface and the communication with
meters. The ultimate goal is to provide a way to access meter information that does
not depend on the specific type of meter, its brand or the type of network that connects
it to the utility. Such decoupling of the interaction with the devices from their specific
implementation also enables for easier expansion of networks (in a sort of plug-and-play
fashion). DLMS-COSEM defines both a messaging method to communicate with meters
and a transporting method to forward and retrieve data. From the security perspective,
one of the important features of DLMS-COSEM is its integrated encryption functionality,
which reduce the possibility of stealing sensible users’ information.
The protocol specification, as opposed to many protocols used for services over Internet, remains closed to the members of the DLMS User Association[5]. Most of the
manufacturers that produce metering equipment are obliged to become members of this
organization to access the specifications. The membership gives them access to literature about the protocol, techniques about how to test it and several useful examples on
how to certify their meters. Members are also allowed to add new codes and objects to
the COSEM specification. The policy for closed protocol, though, gives less access to
the public, so research organizations and security experts do not have the possibility to
freely monitor or test the protocol for security threads. The fact that DLMS-COSEM is
a complex protocol (it covers all layers above 2 in relation to the OSI model) supports
the hypothesis that there is a high risk associated to untested or not foreseen harmful
behavior.
30
4.2 Problem Statement
A de facto protocol analysis tool is Wireshark. It is used by practitioners and researchers when they need to analyze network traces or understand what is happening
within their network. Its visualization capabilities allow for direct extraction of bytes
of interest. It is widely used in security community because it is open source, it supports a big variety of protocols and provides good managing of both live data streams
and file stored streams. However, in the current version, Wireshark does not have any
support for protocols found within AMI such as DLMS-COSEM. It can parse TCP/IP
if the communication is using such protocols but it cannot access the application level
protocol, making it thus difficult to understand the interactions within one’s network or
develop specific security tools to detect anomalous behavior. For that reason, we developed an extension to Wireshark so that it can also be used within advanced metering
infrastructures.
4.2 Problem Statement
Since the usage of smart metering devices is increasing, a need for new security approaches is growing. A problem for working on such approaches is the fact that it is
difficult for security experts and researchers to analyze the protocol for security threats,
because there are no tools that can be integrated in a widely used traffic analyzer such
as Wireshark. Most of the available libraries are built for manufacturers and can only
be used for direct communication with the metering device and not for listening to the
whole traffic. In fact, there are even some aspects of the protocol that make it nontrivial to extend such libraries to only passively listening to the traffic, as is the case
with Wireshark and other network capture tools. However, without a proper way to
analyze the traffic, it is very difficult to further develop and use new techniques for security evaluation of the metering systems. The DLMS User Association has restricted the
access to some parts of the protcol, which may have reduced the threat from attackers
up until now. However, with the growing usage of metering devices and exposure to
more threats there is a clear need for publicly available tools that are able to parse such
traffic.
In order to analyze the protocol and already available devices for potential security
problems the crisalis project has established a metering testbed, where experiments
can be carried out. Also in this closed environment, a tool for analyzing the traffic is
mandatory in order to conduct our research. For this reason, we identified early in the
project the need for a parser that listens to the traffic conversation between a metering
device and a server, and, given some security information about the encryption, is able
to decrypt and visualize the content of the packets in XML format. The vital constraints
31
4 Wireshark Extension: a Tool for Parsing DLMS-COSEM
of the tool development are the time-to-develop and easy integration in a commonly used
tool for traffic analysis. This parser can thus be of use in later workpackages within the
crisalis project.
4.3 Proposed solution
The problem of few available tools for analyzing DLMS-COSEM has also been identified
by the DLMS-COSEM association itself. Some companies have started to develop software for parsing and visualizing protocol information to their customers. So far they are
working in close cooperation with the manufacturers and their software is used mainly
for testing the new metering devices. Some relaxation in the restrictions is done by those
companies since they allow free usage of their software for non-commercial use. During
the work described in this chapter, such software has been investigated and then partially
used for the implementation of our parser integrated with Wireshark. We identified two
main companies that provide free solutions to manufacturers for non-commercial applications that can be used to test their meters.
The first company produces the Icube software [23], which is a library that allows
for parsing of the DLMS protocol and represents an APDU (Application layer Protocol
Data Unit) with XML. The library is available in several programming languages C++, Java, Python, etc. A problem identified with this library is the ciphering and
deciphering of packets exchanged between a smart meter and its server. The library is
designed for direct communication with a meter, meaning that certain assumptions given
retransmissions of data, internal state, etc. are made. For that reason, modifications
were required in order to use it to analyze traffic in a passive fashion.
The second library (Gurux [14]) is also designed for direct communication with a meter, but besides only parsing the DLMS protocol (leaving the OBIS code interpretation
to the user) it has functionality for parsing the COSEM objects as well. Moreover, this
library allows the manufacturers to add their own COSEM object and classes. Unfortunately all this functionality is built tightly together in the software and decoupling the
needed functionality for monitoring the traffic is deemed to be difficult.
These two libraries have a lot of good features but still do not provide full implementation of a DLMS-COSEM parser that could allow traffic monitoring.
4.4 DLMS-COSEM Parser
The DLMS-COSEM Parser is implemented as a Java application. This application uses
Icube software [23] for parsing an unencrypted PDU to XML. For packets that need
32
deciphering it uses the BouncyCastle library [7] that implements the AES-CGM-128
standard, which is defined in the DLMS for low and high security profile. The parsing
starts with extracting the raw PDU from a DLMS packet, and after that step the PDU is
processed by the ICUBE library. If deciphering is needed the XML values are deciphered
using a common deciphering pattern and the BouncyCastle provider. Finally, the result
is collected and merged into one final XML representing the DLMS-COSEM packet.
In order to integrate this parser to Wireshark and ensure convenient deployment, some
intermediate communication middle-ware has been developed. A C++ DLL library is
built to encapsulate the invocations to the application from a C++ environment, which
is needed by Wireshark, and a Lua Script is made to wrap the DLL functions, when
dissection is required by Wireshark. This integration allows for an easy deployment by
non-skilled users.
4.4.1 Overall Architecture
Figure 4.1: DLSM-COSEM Parser Architecture
As can be seen in Figure 4.1 the application consists of three parts. All those three
parts are enclosed in the Wireshark application. The Lua Script is run by the Wireshark
internal Lua Interpreter, when DLMS is the protocol used at the stack being analyzed.
The DLL with the C++ code is loaded within the Wireshark application at start-up, so
the Lua interpreter can access it at any time.
The Wireshark application starts its dissection process when it finds the predefined
33
DLMS port (by specification it is 4059). It passes the payload of the previous stack
protocol to the registered DLMS dissector. In other words it calls the Lua script. The
Lua script on the other hand, parses the initial part of the packet and checks if the
packet is really a DLMS packet. If so, the script calls the C++ DLL function that in
turn creates a Java Virtual Machine to run the java parser. After the java program
finishes its execution, the result is returned to the C++ code, which returns the result
to the Lua script. The Lua script fills the Wireshark representation tree with the parsed
content and displays it to the user. The result as seen by the user is shown in Figure
4.2.
Figure 4.2: Wireshark Stack Tree - Parser Result
4.4.2 Design and Implementation
The application is currently designed to dissect communication between a single meter
and a single server. The authentication key, encryption keys and device system titles
are defined in a configuration file whose format is shown in Figure 4.3. The application
includes a log system that logs every action in a log file. In Figure 4.4 it can be seen that,
internally, the java application uses the ICUBE library and the BouncyCastle library.
authentication_key=9317194964F2056B91C8E3767A891B12
encryption_key_unicast=9317194964F2056B91C8E3767A891B12
encryption_key_broadcast=9317194964F2056B91C8E3767A891B12
device_system_title_requester=2709670102030405
device_system_title_responder=49534BFF030A3D90
Figure 4.3: DLSM-COSEM Configuration File Example
After being pre-processed by the Lua script, the message is passed to the C++ code
and then to the DLMS-COSEM parser implementation. The parser checks what type
of message is being analyzed. If it is an Association Request or Response, the parser
checks if the device titles are appropriate; if not, they are updated dynamically. If the
34
Figure 4.4: DLSM-COSEM Parser Design - Java Application
35
message is another type of request it starts with verifying the security policy. If the
packet is unencrypted it passes the PDU directly to the ICUBE library for translation
to XML. If it is encrypted, the packet is separated into Authentication Tag, Encrypted
PDU (xPDU) and Header. The xPDU is decoded with the Bouncy Castle library and
the result is then again passed to ICUBE to get the final XML.
In the final step, the Lua script receives the message in XML format and displays it
in Wireshark. Three tree elements are shown – Synchronization Sequence, Payload Len,
and Data (see Section 4.5). The first and second field are extracted by the script itself
and are used to classify whether the packet is DLMS-COSEM.
4.5 Results
(a) Without DLMS-COSEM parser
(b) With DLMS-COSEM parser
Figure 4.5: Results - DLSM-COSEM parser
Figure 4.5 shows how two instances of Wireshark - one relying on its predefined dissectors and one using the dissector we developed - parse traffic that contains DLMS-COSEM
packets. As it can be seen, our dissector recognizes the DLMS-COSEM fields and shows
36
4.6 Discussion
that it is now parsing this specific protocol instead of TCP with unknown payload as
it does when relying on its predefined dissectors. Current response time of the java application is of approximately 1 second for a ciphered message; furthermore, we observe
a 0.2 seconds overhead from the C++ application to start the JVM, and a 0.2 seconds
overhead for the Lua Script to attach the C++ function. In total, the response time is
of approximately 1.5 seconds. This could be rather slow for live streams of data but the
reason is the complex procedure of ciphering and deciphering.
Figure 4.6: Protocol Dissection
At the bottom of the Figure 4.6 one can see the parts of the protocol that are parsed
with the dissector. The first part (red) is the Synchronization Sequence, the second (blue
part) is the Payload Len and the third (yellow) is the content of the DLMS-COSEM
message.
4.6 Discussion
The presented solution was analyzed and tested with the testbed setup in the crisalis
project [2]. Response time measures and validity checking were done during the parsing.
Parsed messages were also evaluated based on their actual content. Overall, the solution
is simple to install and operate, but relatively complex to maintain. This is mainly due
to the fact of the very complex integration environment. For the current project the
expectations of the proposed solution are satisfied. It fulfills the requirements for fast
implementation, easy installation and parsing of messages.
If the tool is supposed to be used for general purpose monitoring of traffic between
several meters, high speed traffic and large amount of data, there are some improvements
that need to be considered. The integration between the three different environments
37
seems to be very complex and creates a big overhead in the response time (approximately 33%). A possible future work could be conducted to find a way to integrate a
solution with Wireshark via pre-built DLL library fully in C++ and migrate the Java
implementation to C++; this will reduce the response time approximately with 66%,
and allow smooth operation with large live streams. Another approach might be to run
the Java application as a server process and allow Wireshark to connect to it. This will
reduce the overhead for the response time with around 40%.
Another possible improvement could be the visualization of DLMS-COSEM data.
Right now the parser fills in an XML directly into the Wireshark field ”Data”, which
makes the result difficult to read. Wireshark allows sub-tree elements, so it should be
possible to visualize a dynamic tree from XML and thus represent the data in a more
human readable way.
In the crisalis testbed the system contains only five metering devices. The current
configuration file allows configuration of keys and device system titles for only one device
at a time. Probably a mapping between device IP and configuration could be made so
that the dissector can handle several devices at once. That would correspond more to
a real situation for metering service providers where security investigations seem to be
more needed.
4.7 Summary
In crisalis, we identified the need for European researchers and industry to have tools
to understand and analyze traffic within their environments. Not many tools existed
for the dominating standard, DLSM-COSEM. The specification of the protocol is closed
(membership required) and existing parsers worked with the assumption that they would
speak directly to a meter (or headend device). For that reason, we implemented a
dissector for the de facto standard network analyzer program Wireshark. The dissector
that we plan to make available to other researchers has been designed and implemented to
allow traffic monitoring for AMI. An existing parser library, available for non-commercial
use, was rewritten so that necessary features for configuration, logging, and correct
output was added. The result was packed and integrated into Wireshark in a way so
that even a non-skilled user can quickly install the dissector in less than 5 minutes. The
goal with the current dissector was to have a working prototype quickly to support the
work in other workpackages. It is possible to streamline the implementation and improve
its speed and versatility to be able to run it in more diverse types of environments than
the current testbed with a limited number of smart meters.
38
5 Conclusion
Deliverable D4.2 (focused on SCADA & ICS) and D4.5 (this deliverable, focused on AMI
environments) together summarize the work done in interaction modeling for the two use
cases in the crisalis project. This year, the focus has been on AMI environments. We
have developed and tested techniques that can be used to map the network interaction
between devices, much in line with the work proposed last year for SCADA & ICS
network data. We have also performed a case study of a large deployed AMI, utilising
a mesh network for communication, where we measured topology changes over time
as well as other network changes. This work forms fundamental building blocks when
developing better future simulation models of metropolitan-scale networks before their
actual deployment. We have also improved the toolbox for the network administrator
of AMI networks by developing a dissector for the well-known tool Wireshark suited for
protocols found in the AMI environment, where, for example, this dissector was used
to clarify the results from the fuzzing experiment in AMIs. These activities, combined
with the fingerprinting and protocol learning activities also in the interaction modeling
work package, form the basis for the now ongoing work in work package 6.
39
Bibliography
[1] Z. Alliance. Zigbee specification, http://www.zigbee.org/Specifications.aspx,
2013.
[2] V. Angeletti, E. Kooi, M. Caselli, T. Limmer, and C. Leita. D3.1 setup detailed
description. SEVENTH FRAMEWORK PROGRAMME - Theme SEC-2011.2.5-1
(Cyber attacks against critical infrastructures), 2011.
[3] M. Ankerst, M. M. Breunig, H.-P. Kriegel, and J. Sander. Optics: ordering points
to identify the clustering structure. In Proceedings of the 1999 ACM SIGMOD
international conference on Management of data, SIGMOD ’99, 1999.
[4] A. Arora, R. Ramnath, E. Ertin, P. Sinha, S. Bapat, V. Naik, et al. Exscal: elements
of an extreme scale wireless sensor network. In Embedded and Real-Time Computing
Systems and Applications, 2005. Proceedings. 11th IEEE International Conference
on, 2005.
[5] D. U. Association. Dlms user association web site - http://www.dlms.com.
[6] Awarepoint Corporation. Awarepoint expands its real-time location solution (rtls)
at jackson health system. Press Release, 2009.
[7] BouncyCastle library. https://www.bouncycastle.org/.
[8] Z. Cheng, M. Perillo, and W. Heinzelman. General network lifetime and cost models for evaluating sensor network deployment strategies. Mobile Computing, IEEE
Transactions on, 7(4):484–497, 2008.
[9] F. Cuomo, S. Della Luna, E. Cipollone, P. Todorova, and T. Suihko. Topology
formation in ieee 802.15.4: Cluster-tree characterization. In Pervasive Computing
and Communications, PerCom 2008. Sixth Annual IEEE International Conference
on, 2008.
[10] F. Cuomo, S. Della Luna, U. Monaco, and T. Melodia. Routing in zigbee: Benefits
from exploiting the ieee 802.15.4 association tree. In Communications, 2007. ICC
’07. IEEE International Conference on, pages 3271–3276, 2007.
40
Bibliography
[11] H. Farhangi. The path of the smart grid. Power and Energy Magazine, IEEE,
8(1):18–28, 2010.
[12] J. Gutierrez, M. Naeve, E. Callaway, M. Bourgeois, V. Mitter, and B. Heile. Ieee
802.15.4: a developing standard for low-power low-cost wireless personal area networks. Network, IEEE, 15(5):12–19, 2001.
[13] P. L. Karlton, S. H. Fuller, R. E. Scroggs, and E. B. Kaehler. Performance of
height-balanced trees. Commun. ACM, 19(1):23–28, Jan. 1976.
[14] M. M. Kurunsaari. Gurux - http://www.gurux.fi/index.php?q=guruxweb.
[15] J.-S. Lee. An experiment on performance study of ieee 802.15.4 wireless networks.
In Emerging Technologies and Factory Automation, ETFA 2005. 10th IEEE Conference on, 2005.
[16] Y. Liu, Y. He, M. Li, J. Wang, K. Liu, L. Mo, et al. Does wireless sensor network
scale? a measurement study on greenorbs. In INFOCOM, 2011 Proceedings IEEE,
2011.
[17] R. Maley. Zigbee standards and adoption. In Johnson Controls Eastern ABCS
Conference, 2012.
[18] X. Mao, X. Miao, Y. He, X.-Y. Li, and Y. Liu. Citysee: Urban co2 monitoring with
sensors. In INFOCOM, 2012 Proceedings IEEE, 2012.
[19] M.-S. Pan, C.-H. Tsai, and Y.-C. Tseng. The orphan problem in zigbee wireless
networks. Mobile Computing, IEEE Transactions on, 8(11):1573–1584, 2009.
[20] U. Paul, A. Subramanian, M. Buddhikot, and S. Das. Understanding traffic dynamics in cellular data networks. In INFOCOM, 2011 Proceedings IEEE, pages
882–890, 2011.
[21] L. Sanchez, J. A. Galache, V. Gutierrez, J. M. Hernandez, J. Bernat, A. Gluhak,
et al. Smartsantander: The meeting point between future internet research and
experimentation and the smart cities. In Future Network & Mobile Summit (FutureNetw), 2011.
[22] G. Siganos, M. Faloutsos, P. Faloutsos, and C. Faloutsos. Power laws and the
as-level internet topology. IEEE/ACM Trans. Netw., 11(4):514–524, aug 2003.
[23] I. software. icube - http://www.icube.ch/index.html.
41
Bibliography
[24] J. Zheng and M. J. Lee. A comprehensive performance study of ieee 802.15.4. Sensor
Network Operations, Chapter 4, pp.218-237, 2006.
42

D4.5 Interaction Modeling

Transcription

Similar documents

Town Of Babylon North Amityville

D A R E T O M O V E

You re beautiful James Blunt C (1) My life is brilliant G My love is

MACHINE CONDITION MONITORING FOR A CARIBBEAN RESORT

get protected! - Pine Cellular

- Saurashtra University

European Nienhuis Montessori Retreat 2014

SignalPro® - EDX Wireless