D4.5 Interaction Modeling
Transcription
D4.5 Interaction Modeling
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. SEVENTH FRAMEWORK PROGRAMME 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: [email protected] 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 Interaction Modeling of AMI Networks 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 Interaction Modeling of AMI Networks 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 SEVENTH FRAMEWORK PROGRAMME 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. 2.3 Interaction Modeling Results 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 2 Interaction Modeling of AMI Networks 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 SEVENTH FRAMEWORK PROGRAMME 2.3 Interaction Modeling Results Figure 2.2: AMI network interaction model from packet capture #2 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 FP7-SEC-285477-CRISALIS 11 2 Interaction Modeling of AMI Networks Figure 2.3: AMI network interaction model from packet capture #3 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 SEVENTH FRAMEWORK PROGRAMME 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. FP7-SEC-285477-CRISALIS 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 FP7-SEC-285477-CRISALIS 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 SEVENTH FRAMEWORK PROGRAMME 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. 3.3 Basic Topology Characteristics 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. FP7-SEC-285477-CRISALIS 17 3 Topological Model and Dynamics of Wireless Network in AMI 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 SEVENTH FRAMEWORK PROGRAMME 3.3 Basic Topology Characteristics 0.7 tree size within (0,15] tree size within (16,50] tree size within (50,100] tree size within (100,200] 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. FP7-SEC-285477-CRISALIS 19 Tree size dynamic ratio 3 Topological Model and Dynamics of Wireless Network in AMI 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 SEVENTH FRAMEWORK PROGRAMME 3.4 Analysis of Topological Dynamics 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. FP7-SEC-285477-CRISALIS 21 3 Topological Model and Dynamics of Wireless Network in AMI 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 SEVENTH FRAMEWORK PROGRAMME 1.0 0.8 0.6 0.4 0.2 0.0 0.026 Core-set ratio Core-set ratio 3.4 Analysis of Topological Dynamics 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. FP7-SEC-285477-CRISALIS 23 3 Topological Model and Dynamics of Wireless Network in AMI 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 SEVENTH FRAMEWORK PROGRAMME 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 Analysis of Load-balancing Properties 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 FP7-SEC-285477-CRISALIS 25 3 Topological Model and Dynamics of Wireless Network in AMI 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 SEVENTH FRAMEWORK PROGRAMME 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) Proportion (plotted in log scale) 3.5 Analysis of Load-balancing Properties 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] Proportion (plotted in log scale) Proportion (plotted in log scale) (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 FP7-SEC-285477-CRISALIS 27 3 Topological Model and Dynamics of Wireless Network in AMI 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 SEVENTH FRAMEWORK PROGRAMME 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]. FP7-SEC-285477-CRISALIS 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 FP7-SEC-285477-CRISALIS 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 SEVENTH FRAMEWORK PROGRAMME 4.4 DLMS-COSEM Parser 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 FP7-SEC-285477-CRISALIS 33 4 Wireshark Extension: a Tool for Parsing DLMS-COSEM 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 SEVENTH FRAMEWORK PROGRAMME 4.4 DLMS-COSEM Parser Figure 4.4: DLSM-COSEM Parser Design - Java Application FP7-SEC-285477-CRISALIS 35 4 Wireshark Extension: a Tool for Parsing DLMS-COSEM 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 SEVENTH FRAMEWORK PROGRAMME 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 FP7-SEC-285477-CRISALIS 37 4 Wireshark Extension: a Tool for Parsing DLMS-COSEM 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 SEVENTH FRAMEWORK PROGRAMME 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. FP7-SEC-285477-CRISALIS 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 SEVENTH FRAMEWORK PROGRAMME