Secure Real-time Services for Wireless Sensor Networks in Contiki

Transcription

1 Secure Real-time Services for Wireless Sensor Networks in Contiki Shujuan Master thesis March 17, 2007

2 Abstract With the widespread use of networked embedded systems operating over wireless sensor networks, a standardized architecture is required to enable the rapid development of applications. An embedded operating system serves as an important building block of the standardized architecture. The support of the most commonly used services and protocols should be made available in it as a system service to improve the development speed. Real-time services are commonly required by many time-sensitive applications, such as automation control, real-time monitoring. Events need a global time notion or must happen within a deadline. Collected data should arrive at the destination before it becomes old and loses its meaning. But there is no common notion of time in a wireless sensor network in which all the nodes are physically separated and no global clock or common memory exists. Moreover, there is no guarantee that the sensed data will get to the destination before the deadline. To address these real-time issues, we develop real-time services including time synchronization and low-latency data collection to provide the rapid development of time-critical applications. Meanwhile, security becomes an important issue to wireless sensor network due to the vulnerability of the wireless channel. The adversaries can simply capture and change the data and then resend it. The real-time services utilizing the wireless communication are vulnerable to the attacks and might be the weakest link for the whole system if it is not designed with security in mind. As the building block of real-time services, time synchronization comes into the first place to provide a global time scale for a distributed networking system. We study current time synchronization protocols for wireless sensor networks, propose our protocol design and implement it in the experimental platform, Contiki OS on the hardware platform Tmote Sky. To show the feasibility and performance of our protocol, we perform extensive experimental evaluation. Low-latency data collection services will also play a significant role for the time-critical applications. It aims to provide the guarantee of a time limit for the data collection. Based on the synchronized notion of time over the network, we implement a protocol for data collection aiming at low end-to-end latency for the same platform. To show the performance of data collection using this protocol, we test end-to-end latency in a multi-hop network and evaluate it based on the hop count and the estimation of the point-to-point delay in a single-hop communication. Security issues pose a great challenge to the applications as well as the underlying services due to vulnerability of the wireless channel, hostile environment as well as the severe resource constraint. To make the real-time services resilient to security attacks, we analyse the security attacks that might interrupt the services and present countermeasures to resist these security breaches. The hardware platform in use provides a crypto accelerator in the radio chip and frees the microcontroller from the long computation time for the security operations. We implement the security protocol utilizing hardware-assisted security operation to provide the link-layer security services. In addition, we provide data freshness service using authenticated MAC timestamping for each packet. Then we show how to secure the real-time services using these security services and integrate them into the protocol implementation.

3 Contents 1 Introduction Motivation Researchapproaches Results Thesisoutline Background Security challenges and considerations in WSN Target platform and supported security features Contiki OS and Moteiv Tmote Sky Supported security features in target platform Real-time issues and time synchronization in WSNs Overview and basic concepts Relatedwork Low-latencydatacollection Designs and implementation of services on target platform Link layer security services and authenticated timestamp Packetformat Keymanagement Security settings and protocol for CC2420 secure communication Implementation of CC2420 security and authenticated timestamp Time synchronization with implicit topology formation Logical clock in Tmote Sky Protocoldesign Implementation details Low-latency data collection using Treeroute Treerouteprotocol Schedule-based low-latency data collection Implementation Security analysis and design for the real-time services Security for time synchronization Security for low-latency data collection

4 5 Experimental results and performance evaluation Timesynchronization Experiments and test results Synchronization error analysis and performance evaluation Low-latency data collection based on time synchronization Experiments and results Conclusion and future work Conclusion Futurework Appendices 42 A Glossary 43 B Program flow of security protocol 44 C Program flow of time synchronization protocol 46 2

5 Chapter 1 Introduction 1.1 Motivation Wireless sensor networks represent a new generation of embedded wireless networking systems with a broad range of real-time applications. Examples include fire monitoring, border surveillance, medical care, and highway traffic coordination. Such systems must meet new kinds of timing constraints under severe resource limitations. The data from the sensor network can be used for collaborative operation in automatic control and sometimes critical decision in healthcare or emergency monitoring. Most of these applications need the timing order of events happened in different nodes. This requires all the nodes to maintain a global notion of time in order to determine the timing of events [2]. But there is no common memory or global time clock among different nodes since they are separately deployed in physical environment. Moreover, time-critical data might need to be delivered to a base station within a deadline before the data becomes old and meaningless. For example, a system that monitors and controls temperature in a nuclear power plant would require that the readings be reported to a base station within a maximum time limit for a proper response to a rapid increase in the temperature. So real-time services including time synchronization and low-latency data collection should be presented to provide the common notion of time and keep the data delivery within a desirable latency. Wireless sensor networks can be used for industrial, commercial, and medical applications. They might monitor the performance of critical equipment or situation. Or they might collaborate to make a critical decision. In these cases, the risk of having someone interfere with or shut down the network is unacceptable [18]. Strong security is essential. However, security issues are very common in wireless sensor networks due to the vulnerability of wireless channel and the hostile environment where it is deployed. The real-time services using the wireless sensor network are not exempted from the security attacks [17, 21]. Wireless sensor networks are often deployed in an unattended environment in which nodes might be easy to compromise. For some application scenarios such as medical monitoring crucial decisions might be made according to the collected sensed data. Malicious modification of the critical data might lead to great disasters. Thus the data collection protocol is required to be resilient and secure to counter the malicious modification attacks. If a malicious adversary abuses the underlying time synchronization protocol the applications based on the global clock might be totally disrupted. For example, the disruption of time synchronization in a monitoring system could lead to a false alarm of emergency or fatal delay of reporting a critical event. The whole system might be crashed down by purposed manipulation of the protocols. So security should be included as a built-in property in the protocols design to resist the malicious attacks. 3

6 The above secure real-time services can be used for many applications with timing constraints. To be able to easily reuse these secure real-time services for different applications, it is highly desirable to present them in an operating system as a system service. 1.2 Research approaches This thesis focuses on the design and implementation of a set of secure real-time services and on the evaluation of their performance through experiments. First we carry out a literature survey on related work on existing time synchronization and data collection protocols. Second, we present our protocol design and implementions on the target platform. Third, we implement security services for the target platform. Then we make a security analysis for protocols design and present countermeasures based on the supported security services. Finally, to show the feasibility and study the real-world performance, we test the protocols for the target platform both with and without the security services and measure their performance. 1.3 Results This thesis presents the design and implementation of secure real-time services, including time synchronization and low-latency data collection, and perform several experimental performance evaluation. The main results include the following aspects: a. A network-wide time synchronization protocol is designed, analysed and compared to other existing alternative schemes. A concrete implementation of the protocol is done for the target platform (ContikiOS on Moteiv Tmote Sky). Our protocol is based on the sender/receiver pairwise synchronization. A tree topology is formed implicitly during the pairwise synchronization starting from the sink node and thus reduces the communication overhead. We also use the authenticated MAC-timestamping to reduce synchronization error by excluding send time and receive time and counter some security attacks through authentication of the timestamps. The time synchronization protocol design makes an improvement on the existing protocols, achieving a better performance in some critical metrics, such as communication overhead and adaptability of the dynamic topology while maintaining the same synchronization precision and computational complexity. b. The Treeroute routing protocol is ported to the Tmote Sky platform for multi-hop routing. A demo application of a multi-hop data collection using Treeroute routing is designed and implemented for a multi-hop network. The data collection protocol can achieve lower latency by using slotted communication based on the network-wide time synchronization. The latency for a data packet from a source node to the destination node will be measured in the synchronized time notion among the distributed nodes. So the measured latency will be affected by the synchronization precision. In the experiment, we show that the end-to-end latency of all packets is rather stable and the data delivery is very reliable due to non-collision in the slotted communication. This shows that the time synchronization works well enough to provide a global clock for slot assignment. c. Security services for the target platform are implemented and further used to secure the above real-time services. The implementation of the security services utilize the hardware-based AES 4

7 security operations supported by CC2420 radio. We can enable the security services to secure the real-time services. Then we make a security analysis for the protocols design and present countermeasures to resist the security attacks based on the supported security services. d. Experiments are done for single-hop networks as well as for multi-hop networks. The real-time services are tested, with security enabled and disabled respectively. An analysis of the experimental results is conducted to show the real-world performance of the implemented services. 1.4 Thesis outline Chapter 2 introduces the security challenges in WSNs and the related work on time synchronization and low-latency data collection protocols. Chapter 3 describes the designs and implementation details of the security services, the time synchronization protocol and low-latency data collection protocol. Chapter 4 makes a security analysis for the real-time services implemented and presents how to secure these services using the security services implemented in this platform. Chapter 5 presents the test results of some carefully chosen real-world experiments. Chapter 6 concludes the thesis work and presents the research trends and work. 5

8 Chapter 2 Background Wireless sensor networks(wsn) is an information gathering paradigm based on the collective efforts of hundreds or thousands of small wireless sensor devices. The devices are equipped with one or more sensors, a short-range radio transceiver, a small microcontroller, and a power supply. The sensor devices autonomously form networks through which sensor data is transported. The sensor devices are often severely resource-constrained. An on-board battery or solar panel can only supply limited amounts of power. The small physical size and low per-device cost limit the complexity of the system. Typical sensor devices are equipped with 8-bit micro-controllers, code memory on the order of 100 kilobytes, and less than 20 kilobytes of RAM. Applications for sensor networks can be found in many different areas [20, 15], ranging from biology and medicine to industry. One of the potential applications are wireless automation systems which are supported by the real-time control services over sensor networks. Automatic control is a central component of any modern process and manufacturing industry. The information flows between sensor, actuator and control nodes have traditionally been hardwired synchronous communication. Over the last decade, there has been a transition to communication buses, such as field bus and Ethernet technology, in these control systems. Currently there is a major drive to take the next step in this evolution by moving to wireless communication. More efficient and lower costs for installation and commissioning are important factors. There is also a large potential for major technological advances due to increased flexibility and mobility, which may lead to totally new system designs. Reliable real-time control is the basic requirement for most automation system. It requires real-time services such as data collection with low latency and implicitly a time-synchronization service. Meanwhile, as we know, the wireless channel is vulnerable to many kinds of attacks. In such an unreliable and serious resource-limited environment, to achieve the reliability of the system, security is a great issue to be addressed and should be a built-in property for the system design. This chapter presents the common security issues in a WSN and the related features of the target platform. Then it gives an overview of time synchronization and data collection protocols and further discusses the related work. 2.1 Security challenges and considerations in WSN There are several challenges to achieve security in a wireless sensor network: 6

9 a. Poorly protected channels - eavesdropping, signal jamming attacks b. Insecure cooperative network protocols - man-in-the-middle attacks c. Stringent resource constraints on sensor nodes - no computationally intensive security operation d. No physical security - compromised nodes These challenges make security in a wireless sensor network difficult to achieve. However, for security-critical applications, all the underlying protocols or services need to be designed with security in mind. According to what needs to be protected, security services such as encryption, authentication, authorization and access control, should be in place to provide the necessary protection of critical data, such as timestamps for time synchronization service, temperature data for fire monitoring, life-critical data for healthcare monitoring, etc. According to the sources of the security breaches (i.e. unprotected wireless link, distributed communication protocol design, compromised nodes) in a wireless sensor network, security is basically concerned with the following aspects: a. Securing the communication link The wireless in nature is exposed physically, so to secure the link means protecting the communication data from being disclosed, modified. This can be achieved through the cryptographic operations. b. Securing distributed services and protocols Cryptographic techniques help to secure the protocols. But pure cryptographic techniques in some cases can not help to resist some malicious manipulations, such as delay or replay attacks. If the protocols mechanism is poorly designed, it might suffer from the attacks by manipulating the mechanism weakness. So we should design the protocols or services, such as secure routing, secure data gathering or secure time synchronization, in a secure way. c. Tolerating compromised nodes attack A WSN is commonly deployed in an unattended environment, so sensor nodes are easily captured. Due to lack of tamper resistance, the embedded cryptographic secret in the compromised nodes can be recovered. Subsequently the compromised nodes can be manipulated as authorized nodes to inject bogus data to trigger false events or stall the reporting of real events. It s out of the realm of cryptography which is based on the secret. But it can be detected or avoided to some extent on proper protocol design. Due to the severe resource constraints in a wireless sensor network, there are several design considerations for providing security services in a sensor node. a. Radio is very power-intensive: minimize communication overhead; b. Making deployment easy: It is difficult to setup different keys for each node in a large network; c. Must avoid complex key management: use an efficient key distribution protocol or just use pre-shared keys; use a global key instead of pair-wise keys; d. Traditional public-key cryptographies such as RSA is not computationally feasible: more efficient public key techniques such as ECC might work [31]. 7

10 2.2 Target platform and supported security features In this section, we first briefly introduce the target platform, and then give an analysis of the security services it supports Contiki OS and Moteiv Tmote Sky Contiki OS Contiki OS is a highly portable, networked, multi-tasking operating system for severe memory-constrained systems [5, 7]. It provides protocol implementations for the sensor devices [6], dynamic loading of programs, native TCP/IP support using the uip stack [10, 11]. In Contiki OS, one outstanding feature is the use of proto-threads [4, 9, 8] that provide sequential flow of control without complex state machines or full multi-threading. Each proto-thread handles certain events such as event timer expiration according to the kernel scheduling, but it never consumes processor cycles while waiting for future events. This meets the concurrency processing requirement for sensor nodes. To support the timing of events, in Contiki there is a logical clock represented by a tick count variable, which will keep counting the timer interrupt (tick interrupt). Local clock measured in ticks is the basic clock source of real-time services. Besides, based on this logical clock, there are also two types of timers implemented in Contiki, i.e., timer and etimer. With the timers we can easily implement time-critical services. For the security aspect, there is no support of security services in current Contiki. However the radio chip in the hardware platform provides the security crypto acceleration. We can utilize this hardware-assisted feature to support security services and free the microcontroller from long-period security computation. Moteiv Tmote Sky The experiment hardware platform is Tmote Sky shown in Figure 2.1. Figure 2.1: Tmote Sky module Tmote Sky is an ultra low power wireless module for use in low-power sensor network applications [24]. It is integrated with microcontroller MSP430F1611 and the CC2420 radio [27] which is a first Zigbee-ready radio chip compliant with 2.4 Ghz IEEE specification. The CC2420 radio provides high-level security using 128-bit AES crypto accelerator with which we can provide the link-layer secure services. 8

11 2.2.2 Supported security features in target platform Currently there are no security features implemented for the target platform -Tmote Sky in Contiki OS. But the radio chip CC2420 provides extensive flexible hardware support for security operations. We exploit the benefit from the hardware security support and implement the security features to secure the time synchronization protocol and data collection protocol. We first look at the security modes built in CC2420. CC2420 security and IEEE Spec For compliance with IEEE specification [30], the CC2420 radio features hardware IEEE MAC security operations. All security operations are based on AES encryption using 128-bit keys. With the extensive hardware support for data encryption and authentication [13], the challenge to counter security attacks for sensor nodes with constrained resource capacity is relieved greatly. It is very flexible and different security services can be selected via one of the following modes: None-security, CBC-MAC authentication only, CTR mode encryption-only, and CCM, which combines authentication with encryption. When utilizing these security features, we refer to the security pitfalls in IEEE specification pointed out in [25]. In fact there is an ongoing work on the IEEE b [29] which aims to resolve those security pitfalls. Data freshness service using authenticated timestamp Data freshness is a security service to counter replay attacks, a very common security issue not only existing in wired networks but also in wireless sensor networks since it is easy for an attacker to initiate a replay attack by just simply recording the packet and then resending it later to get illegal access. A replay attack, also known as a man-in-the-middle attack, is a breach of security in which information is illegally stored without authorization and then retransmitted to trick the receiver into unauthorized operations such as false identification or authentication or a duplicate transaction. Even though the captured messages may be encrypted, the attacker does not need to know the actual keys and passwords and just perform the retransmission of valid logon messages which is sufficient to gain access to the network. Typically a replay attack can be prevented using strong digital signatures that include time stamps and inclusion of unique information from the previous transaction such as a constantly incremented sequence number. Time stamping can be utilized to counter a replay attack. A replay packet can be detected by checking its timestamp of sending. With the authenticated time stamping we can ensure the timestamp is not modified. Two packets can not be sent by a node at the same time, i.e, with the same sending timestamp. 2.3 Real-time issues and time synchronization in WSNs Real-time issues are concerned with requirements of certain type of temporal relationship between different events and typically are presented in the one of the following aspects: 9

12 a. The relative timeliness ordering of events happened in different nodes (e.g. event X must happen before event Y happens); b. The time interval between two events happened on different nodes (there is a deadline for event Y to happen after event X happened); c. The time of the day at which an event happened on a specific node. These aspects are necessary for the collaborative work of the sensor nodes for the decisions of the central base station (also referred as Sink). To meet the above real-time requirements, a common time axis is needed to provide the timeliness relationship [2, 28]. Since time synchronization is critical to sensor networks for both schedule-based protocols and timesensitive applications. In this thesis, we will study the current time synchronization protocols for sensor network and the related security issues Overview and basic concepts Time synchronization is a common issue in distributed systems, since all the nodes are physically separate and have no common memory. Each node has its own internal clock and its own notion of time, but no common notion of time with other nodes in the network. The real-time issues mentioned in the previous chapter need to be addressed through the time synchronization over the network. There are three reasons for the nodes lack of a common notion of time: Offset nodes. The nodes might not be started at the same time and thus a clock offset exists between these Skew The crystal oscillator might be running at slightly different frequencies, making the clock value to diverge gradually from each other. This is termed as Skew error. Drift The frequency of the clocks might change over time because of aging or changes of conditions such as temperature. This is termed as Drift error. Among these, skew and drift error are related to the hardware and physical conditions and change over a long period and not instantaneously. We aim at not only reducing the time offset between nodes to get instantaneous synchronization but also compensating for drift and skew by periodical network-wide synchronization. To achieve time synchronization through message exchanges, there are six delay factors (sources of synchronization error) in the time-critical transfer path, which means the path of a sync message that contributes to non-deterministic errors in the protocols. Send time This is the time period from the moment a timestamp is taken for sending a timesync packet to the point the packet is buffered into the TXFIFO. 10

13 Media access time This delay depends on what kind of media access protocol is using. In Tmote Sky, the CC2420 radio use CSMA/CA for media access control. In this case media access delay is the delay for the packet waiting for a clear channel to transmit. This competition-based media access mechanism leads to highly non-deterministic delay and thus contributes to the major source of synchronization error. Transmission time This is the time for the CC2420 radio to transmit a packet over the radio link. It can be computed based on the packet length and transmit speed for the radio. So this delay is a constant and can be estimated. Radio propagation time This is the time for a radio signal to propagate over the air to reach a receiver. Radio propagation speed is velocity of light which is 300 meters per microsecond. This error is negligible with normally less than 100 meters of coverage for a wireless sensor. Reception time This refers to the time taken to receive the bits and passing them to the MAC layer. This is mainly deterministic in nature for a hardware based RF transceiver. Receive time The bits are then constructed into a packet and then this packet is passed on to the application layer where it is decoded. The value of receive time changes due to the variable delays introduced by the operating system. According to the varying requirements, such as diverse precision requirements, network density, degree of mobility and topology stability, several proposals for time synchronization protocols have been presented. Time synchronization typically is based on message exchange containing the timestamp and the measurement of delay. There are three basic solutions for synchronization between two nodes: 1. sender/receiver-based synchronization 2. receiver/receiver-based synchronization 3. delay measurement synchronization One-way message exchange is commonly used in receiver/receiver synchronization solution such as Reference Broadcast Synchronization(RBS) [12], while two-way message exchange is commonly used in sender/receiver-based synchronization solution, such as Timing-sync Protocol for Sensor Networks(TPSN) [16]. There are also some synchronization protocols based on one-way message exchange as well as the measurement of delay. Typical use of delay measurement is Delay Measurement Time Synchronization(DMTS) [26] Related work We make an analysis on these popular protocols in use for sensor networks, pointing out what are the advantages and disadvantages of our protocol compared to these protocols. 11

14 Reference Broadcast Synchronization(RBS) In RBS, a reference node broadcasts a message and all the nodes in the coverage will timestamp the local time of receiving this reference message [2, 12]. Then they exchange the recorded time and thus every node has the knowledge of time offset between itself and the other nodes in the network. In this method, the difference in propagation time from different nodes to the reference node is negligible since the typical coverage range of a sensor network is less than 100 meters, which means the maximum propagation time is about 0.33 microseconds. RBS avoids the largest sources of error (send time and media access time) in the time-critical path and the synchronization error depends only on the difference of propagation time which is negligible and the time difference between receivers and the radio synchronization error, which is typically a few microseconds. As a result, RBS can achieve high synchronization precision as to several microseconds. The disadvantage is the high message exchange and lack of synchronization of reference node itself. For a single hop WSN of n nodes, it needs at least n messages to be exchanged. In contrast to RBS, our protocol expects lower computational complexity and achieves the synchronization of the whole network, i.e., including the reference node. In the time-criticla path, if media access time and transmission time are deterministic, our protocol can expect an equivalent synchronization precision as in RBS. So the precision difference to RBS will depend on the uncertainty of transmission time and media access time in the time-critical path. Timing-sync Protocol for Sensor Networks(TPSN) TPSN aims at providing network-wide time synchronization and establishes a unique global timescale by creating a self-configuring hierarchical tree. There are two phases to achieve network-wide synchronization using TPSN: the level discovery phase and the synchronization phase. In the level discovery phase a hierarchical tree is established. In the synchronization phase, pair-wise synchronization is performed along the edge of the tree to establish a global timescale throughout the whole network. The synchronization accuracy does not degrade significantly with the number of nodes increasing, so the protocol is scalable But due to its dependence on the hierarchical infrastructure, TPSN is not suitable to highly dynamic networks with mobile nodes [2, 16]. In contrast to TPSN, our protocol can expect lower communication overhead and better adaptability to dynamic topology changes through the dynamic implicit tree formation while maintaining an equivalent synchronization precision. The synchronization precision in our protocol depends on the uncertainty of the same factors as in TPSN, i.e., media access time, transmission time, propagation time and reception time in the time-critical path. Delay Measurement Time Synchronization(DMTS) DMTS is very energy-efficient and computationally lightweight since it only needs one time broadcast to synchronize all the nodes in a single-hop network. The receivers measure the time delay and set their time as the sender s sending timestamp plus measured time transfer delay [2, 26]. DMTS can achieve very low computational complexity and communication overhead, but its synchronization precision depends on how well the measurement is made on all the delay factors along 12

15 the time-critical path. Our protocol can expect higher synchronization precision since some sources of synchronization error are eliminated in our protocol but exist in DMTS. 2.4 Low-latency data collection Sensor networks can be used for collaborative work or control decision. The decision will be made according to collected data from the different sensor nodes. But if the collected data is too old to be used for a time-critical decision, the system will lose its function. Protocols aiming at the low-latency collection of specified data are required to guarantee the timing requirement of data collection operations. Latency means the end-to-end delay of data communication between two nodes. The goal of lowlatency data collection is to achieve a time-bounded data delivery within a deadline. Here, by latency we mean the time duration for a packet from the sending time to receiving time it a network. But to measure the real latency, the sending time and receiving time of a data packet should be timestamped with reference to a global clock. The measurement of latency should be based on the synchronization of time between the relevant nodes. There are three traffic patterns in a wireless sensor network: a. from a sensor node to the sink b. from the sink to a sensor node c. from a sensor node to another sensor node These can happen in a single-hop network or a multi-hop network. In a single-hop network, the latency is the point-to-point delay. It will be more deterministic if schedule-based MAC is used. And if the contention-based MAC, such as CSMA/CA, is used, the uncertainty in latency will exist due to the contention time. In a multi-hop network, the data traffic will go through the route generated by the routing protocols, which will influence the latency. The routing protocol will decide the route from the source node to the destination node. The increase of hop count in a route will increase the latency. There are also some sensor networks which support the sleep/active schedule to save the energy consumption. In sleep/active networks, more latency will be introduced due to additional sleeping latency [14]. But the significant amount of data traffic in a WSN application will go only from the sensor nodes to the sink node (i.e., the data aggregator). So in this thesis, we will focus on only the first traffic pattern, data from a sensor node to the sink. 13

16 Chapter 3 Designs and implementation of services on target platform In this chapter we design and present the implementation of the secure service mechanisms including time synchronization and low-latency data collection for the target platform. The security services are provided by a link-layer security protocol which is based on the built-in security support from the CC2420 radio. We first introduce the design of CC2420 security protocol, highlighting the critical points when using its security features. 3.1 Link layer security services and authenticated timestamp Packet format In the current CC2420 MAC driver in Contiki, MAC data packets are defined as in Figure 3.1. Figure 3.1: Data packet format with non-security mode. The CC2420 radio supports the security features which can be implemented using the packet formats as in Figure 3.2 for the three basic AES security modes. We will implement the security services using these security features according to the security suite specifications in IEEE spec [30]. The authenticated part includes timestamp and data payload. The encrypted part includes timestamp, data payload and MIC when in authentication modes. As we mentioned in previous chapter, we timestamped every MAC packet and this will serve for time synchronization and also can be used to counter replay attacks targeting the time synchronization service. 14

17 Figure 3.2: Data packet format with security modes Key management In CC2420, all security operations are based on the two individual 128-bit keys which are located at fixed RAM space. We can simply configure the Security Control Register to indicate which key for sending or receiving messages. The keys space can be programmable so we can reload the keys to the corresponding RAM address every time before transmitting or receiving a secure message. Key management issues include the selection of key distribution methods and the selection of global key or pairwise key. Pre-shared key or dynamic key exchange There are no key exchange protocols in ContikiOS right now. Instead, we use a pre-shared key which can be configured before compiling the system. We configure every node in the network with a secret key shared with the base station. Therefore, each node and the root node can authenticate to each other and encrypt or decrypt data. Data from an attacker not having the right secret key will be simply discarded due to the failure to authenticate or decrypt data correctly. Group key or pairwise key Depending on the security requirements of different applications, all nodes in the network can just simply share a global key, or each node can share a different pairwise key between itself and the root node. The group key scheme is convenient for key deployment and easily changed later. But it is vulnerable to compromised node attack. If the key in one node is compromised, the whole network will not have any security at all until the key is changed to a new one. The pairwise key scheme will be 15

18 more secure than the group key scheme. But the pairwise key scheme will assume more memory for the root node to maintain a key lookup table, which we call keystore. Incoming secure data packets from the network require a lookup to find the appropriate key in the keystore, followed by data decryption and/or MIC authentication according to the security mode set for the whole network. Meanwhile, outgoing data also require a key lookup, followed by MIC computation and/or data encryption if indicated. Choosing one of these two schemes needs to consider the trade-off between memory usage, computation time and convenience of deployment Security settings and protocol for CC2420 secure communication As mentioned in the previous chapter, CC2420 supports hardware IEEE MAC security operations. All security operations are based on AES encryption using 128-bit keys. Security operations are performed within the transmit and receive FIFOs on a frame basis. CC2420 can do MAC security operations (encryption, decryption and authentication) on frames within the TXFIFO and RXFIFO. These operations are called inline security operations. CC2420 also includes stand-alone AES encryption. In this thesis, we consider only the inline security operations. To enable the inline security operations, we first need to configure the Security Control Registers (SECCTRL0 and SECCTRL1). Then we need to set the keys for transmission and receiving. For counter-mode operations, we also need to set up the nonces for each transmission and receiving. After these settings, we can add the security operations in CC2420 MAC driver for each transmission and receiving [27]. SECCTRL0 setting In security control register SECCTRL0, the following settings can be done: Key selection: bit field SEC TXKEY SEL for TX Key selection and SEC RXKEY SEL for RX Key selection. Security modes selection: configure bit field SEC M[2 : 0] and SEC MODE[1 : 0] for the modes selection. Protection enable: bit field RXFIFO PROTECTION is set to 1 to enable security. SECCTRL1 setting According to which part of data you want to protect (encrypt or authenticate), we can configure fields SEC TXL and SEC RXL in SECCTRL1. In our application, we are going to protect the data payload as well as the timestamp. So in the implementation, for non-counter modes we set the plaintext length to be length of MAC packet header (i.e. M AC HDR LEN); for counter modes the plaintext length will be (MAC HDR LEN + 5). The number 5 is the total length of frame counter and key sequence counter. Key settings Before sending a packet, we should set the keys for transmission and receiving located in the corresponding RAM memory space: KEY 0 or KEY 1. According the key selection in SECCTRL0 register, the transmission and receiving will accordingly select the right key. Note that we should make sure the same key is used for encryption in sender and decryption/authentication in receiver. 16

19 Nonce settings In security engineering, a nonce is a number used once. In CC2420, a nonce is valid only for counter modes (CTR and CCM)., not for the authentication mode(cbc-mac). The receive and transmit nonces are located in RAM memory addresses. According to the IEEE spec, a nonce in CC2420 consists of the values of counters and source node s long address, as shown in Table 3.1. This ensures that a nonce is used only once to get a probabilistically insignificant chance of repeating a previously generated value. 1bytes 8bytes 4bytes 1bytes 2bytes Flags SourceAddress F ramecounter KeySequenceCounter Blockcounter Table 3.1: IEEE Nonce When a node sends a packet, it needs to setup the transmit nonce according to the last value of counters and its IEEE address. Similarly, when a node receives a packet it needs to set the receive nonce according to the IEEE address of the sender by looking up address mapping table (see below) and the counters value in the packet. Setup short address and IEEE address mapping table To get data decrypted/authenticated correctly, the receiver node needs to set up the same nonce as the sender used for transmission. The IEEE address is a part of nonce and nonce is valid in a counter mode. But we can only get the sender s short address which is sent within the packet, but not the IEEE address. So in a counter mode, each node needs to maintain a mapping relation between the short addresses and long addresses (i.e. IEEE addresses) of all nodes participating in the network. When a receiver node receives a packet, it needs to search for the sender s IEEE address in the mapping list according to the sender s short address. Secure communication processes Transmission process For each new packet to send, we i. Increase frame counter and key sequence counter according to the last values of counters; ii. Update these two fields (frame counter and key sequence counter) in transmit nonce using the new counter values; iii. Insert values of frame counter and key sequence counter in TXFIFO; iv. Issue strobe command STXONCCA to start encryption/authentication operation and transmission. Receiving process For each new packet arrived, we i. Read the values of frame counter and key sequence counter from RXFIFO; 17

20 ii. Lookup for the corresponding IEEE address according to the source address; iii. Update these three fields (frame counter, key sequence counter and IEEE address) in receive nonce; iv. Issue strobe command SRXDEC to start decryption/authentication Implementation of CC2420 security and authenticated timestamp As we describe above, the secure transmission and receiving process will be based on the security settings in CC2420. To protect the MAC-layer timestamp from being illegal modification, the secure communication process encrypts or authenticates the MAC timestamp in each packet. The programming flow is shown in Figure B Time synchronization with implicit topology formation In this section, we first investigate the logical clock settings in our target platform. Then we describe the time synchronization protocol design and the implementation details Logical clock in Tmote Sky A wireless sensor node has typically two clocks: a system clock and a crystal oscillator external to the microcontroller. The system clock will stop when a device enters into deep power saving mode and loses all of its time information. Therefore, it cannot be used for time keeping by itself. But the external oscillator continues to operate when the MCU and other peripherals are powered off. It can be used to build a software logical clock for timekeeping and time synchronization. A clock is measured by the following commonly used factors: Resolution The smallest possible increase of time a clock model allows. If a clock increases its value once per second, then its resolution is one second. The resolution for a node is limited by the frequency of the hardware crystal oscillator since it increments only when the associated hardware interrupt occurs. Precision Precision can be defined in two ways: absolute precision (i.e., the clock deviation with respect to an external standard such as UTC) and relative precision (i.e., the clock deviation with respect to a reference node within the network). In this thesis, we concern only about the relative precision to a the reference node. So the time synchronization precision means the maximum clock deviation between the synchronized nodes and reference node. Our target platform Tmote Sky has a 8MHz system clock and an external 32768Hz crystal oscillator. The external oscillator can be used by timers in the microcontroller configured to provide independent clock interval and clock resolution. Our logical time is represented by a 32-bit counter variable which will increase each time the hardware interrupt occurs. We call each interrupt as a clock tick. Table 3.2 shows the different settings of the logical clock which gives different resolution and clock precision as well as time span with a 32-bit data structure to record the number of clock ticks. 18

21 TicksFrequency Resolution T imespan(days) Table 3.2: optinal clock settings in target platform For testing the time synchronization service in Contiki OS for Tmote Sky we set the ticks frequency (i.e. CLOCK SECOND Micro in Contiki) to be 512. This will give the resolution about 1 millisecond and time span of about 97 days. This means the sensor node can keep running for 97 days continuously before the 32-bit counter variable overflows. Theoretically the highest resolution can be achieve at 1/32768 second, i.e. about 30 microseconds. We can run the time synchronization protocol using different clock settings based on different requirements for time span and resolution Protocol design This section describes the time synchronization protocol design and compares it with other popular protocols, such as RBS, TPSN and DMTS mentioned before in previous chapter. WSN features self-organization, dynamic topology, limitation in resources including computation ability, communication bandwidth and storage memory. Scalability means the synchronization accuracy will not degrade significantly with the increase in number of nodes in a multi-hop network. We will focus on providing flexibility, which means being adaptive to dynamic change in the network topology. Our protocol design will consider the following performance metrics: communication overhead: synchronization precision: the network; the number of message exchanged in a network of n nodes; the maximum deviation among the logical clock readings of nodes in mobility: the support for dynamic addition of new nodes or failure of existed nodes; computational complexity: run-time and memory requirements. According to the analysis by Sundararaman etal in [2], TPSN achieves a good compromise between communication overhead, synchronization precision, computational complexity. DMTS has the advantage of low computational complexity and extremely low communication, but lower synchroniza- 19

22 tion precision compared to TPSN due to more uncertainty from delay factors. RBS obtains high synchronization precision at the expense of high communication overhead, computational complexity, and with the disadvantage that the reference node is not synchronized. Based on the comparison, we take the idea of TPSN [16] to achieve the good trade-off among the performance metrics. But with implicit topology formation in our protocol design, it will achieve lower computation overhead, lower computational requirements and better mobility support than TPSN while maintaining the same performance in other metrics. The protocol mechanism mainly consists of the following aspects: i. The root node is designated to provide a common clock reference and is the only one authorized to initiate the network-wide synchronization. ii. Every node synchronizes itself to its direct parent through sender/receiver-based pairwise synchronization. iii. A hierachical tree will be implicitly formed using the pairwise synchronization messages, thus saving a lot of communication overhead and providing better mobility and flexibility support. iv. The sender/receiver-based pairwise synchronization will be conducted along the edge of the implicit hierarchical tree until all nodes relatively synchronize to the root node. In the following, we discuss the main components of our time synchronization protocol design. Sender/receiver-based synchronization In this section, we analyse sender/receiver-based solution to pairwise synchronization shown in Figure 3.3. The security attacks on the pairwise time synchronization mechanism will be presented in the next chapter. Let T0 be the client node (sender) timestamp on the request message, T1 the parent node (receiver) timestamp upon arrival, T2 the parent node timestamp on departure of the reply message and T3 the client node timestamp upon arrival. Figure 3.3: Sender/receiver-based pairwise synchronization 20

23 We can calculate the clock offset and the roundtrip delays with offset =[(T 1 T 0) + (T 2 T 3)]/2, (3.1) MAC-layer or UDP-layer time synchronization? delay =(T 3 T 0) (T 2 T 1). (3.2) In Contiki OS, time synchronization protocol can be implemented either above the upper layer, uip/udp layer, or above the lower layer, MAC layer, as shown in Figure 3.4. Figure 3.4: MAC-layer or UDP-layer time synchronization The benefit to implement the service at MAC layer is that we use MAC packets which have a smaller packet size than UDP packets and get timestamps at the MAC layer which means less time uncertainty. But the disadvantage with the MAC-layer based time synchronization is the tight integration of the service with the MAC protocol and thus can not reused for other hardware platforms with different MAC protocols. But time synchronization protocol using uip/udp packet can be reused in other platforms which also support the uip/udp protocol. So running the time synchronization service over uip/udp can reduce the degree of coupling between the service and the MAC layer. In this case the service is not based on the specific MAC protocol but on the common UDP layer interface. Meanwhile, we can still timestamp the packet at MAC layer to reduce the uncertainty from the varying software stack processing time which might be affected by the scheduling mechanisms of operating systems. In this case, a slight change of the protocol implementation might be needed to adapt to MAC timestamping in the new hardware platforms. So we will choose the UDP-layer time synchronization while timestamping at the MAC layer. The protocol will run over the UDP layer and the timestamping of timesync packets is done in the MAC layer. Network-wide time synchronization with implicit topology To achieve network wide time synchronization, there are two aspects: A hierarchical tree is implicitly established over the network with the sink node as time reference node; pairwise time synchronization 21

24 is performed along the tree. Implicit hierarchical tree formation To form a hierarchical tree, we do not need an extra message exchange, such as level discovery message in TPSN [16]. Since all the sync packet will contain a hopcount, so when a node receives a sync message, it will check the hopcount of the sender. If its own hopcount is greater than the sender s hopcount plus one, it will update its hopcount and set its parentid to be this sender s ID. So implicitly, the hierarchical tree can be constructed dynamically and adapted to the topology changes. Network-wide time synchronization We assume that only the sink node has the right to initialize a network-wide synchronization. The network synchronization message NETSYNC BROADCAST, which can be sent only by the sink node, will inform the nodes to start a new round of synchronization. The sink node will send the message NETSYNC BROADCAST periodically to achieve a periodical resynchronization of network. The periodical synchronization needs to be conducted because the clock might lose synchronization because of the gradually clock skew due to slightly crystal frequency difference or clock drift due to environmental conditions such as temperature. For a non-sink node in level 1(next to sink node), when it gets NETSYNC BROADCAST message from the sink node, it will update their hopcount and parentid, wait a random delay(to avoid collision with other nodes in the same level), and then send the PSYNC REQ to the sink node to start the pairwise synchronization. For a non-sink node in a level greater than 1, it will overhear the PSYNC REQ from nodes in the upper level, and then update its hopcount and parentid. And then it will wait a random delay plus an estimated roundtrip delay before sending PSYNC REQ message to synchronize itself to the parent node. When receiving a PSYNC REQ message addressed to it, the node will send back a PSYNC ACK message immediately to the source node. The timestamps of sending and receiving PSYNC REQ will be included in the PSYNC ACK message and send back to the requesting node. When receiving a PSY NC ACK message, the node will record the receiving and sending timestamp of the PSYNC ACK message. And till now, the node has got the four timestamps for the pairwise synchronization. According to the four timestamps, it can calculate the time offset between it and its parent and then correct its local logical clock to be the same as the parent node according to the time offset. The selection of the random delay will affect the happening of a collision when the children nodes send the PSYNC REQ to their parent. So a proper value should be chosen to avoid collision. But it is difficult to choose an optimized value for it. Since the chance of collision will depend on the number of nodes belonging to the same parent and the time in a pairwise synchronization. In the current implementation, we assume the maximum number of nodes(i.e. max num) belonging to the same parent to be a fixed value. And the time for a pairwise synchronization is estimated according to the round-trip delay(i.e. round delay) of the message exchange. Let fa to be the factor to adjust the chance of collision occurrence. 22

25 Then the random delay (i.e. random delay) to send PSYNC REQ should be set as following. When receiving a NETSYNC BROADCAST from sink node, the random delay will be set to random delay0: random delay0 =rand()%(max num round delay fa) (3.3) When overhearing PSY NC REQ from the parent, the random delay will be set to random delay1: random delay1 =rand()%random delay0+(hopcount 1) random delay0 (3.4) Special problem provisions This part addresses the special problems due to the exceptional node failure or isolation. In a WSN, a node can die due to energy exhaustion or other interruption. Nodes also can be isolated from the network due to the instability of the wireless link. These problems are described below and corresponding solutions is presented. a. Node isolation Due to the instability of the radio link, a sensor node at level n might overhear timesync request from node at level n-2, i.e. the parent s parent, and thus update its hopcount to be n-1. But the problem is that this is just an occasional event and the node may never be able to overhear from that node again. Meanwhile it will neglect timesync request from node at the same level, n-1. In this case, the node will wait infinitely for the message from level n, but in fact it is too far to get timesync request again. As a result this node will be isolated from the time synchronization process. We can reduce the happening of this situation according to the signal strength of the timesync packet. To reduce the occurrence of this situation, we can set a threshold value of the signal strength of the timesync packets. Only if the signal strength of the received timesync packet is greater than the threshold value, the node will handle this packet. Otherwise, this packet will be simply discarded. The threshold value of signal strength needs to be set properly to make he network running in stable way. But it is hard to get an optimized threshold value because lots of experiments need to be conducted and analysis depending on the real environment where the network is deployed. Since there is still a chance for this problem to happen, we can set a timeout period (set by a timer) for each node. The timer will be reset every time a pairwise synchronization is done. If the timer times out, it means the node did not get success pairwise synchronization with its current parent for the fixed period. So to be able to accept timesync packet from other nodes and select new parent, the node resets its hopcount and parentid when the timer expired. In this case, the isolated node can get the chance to synchronize to the network with a new parent. b. Node failure This problem will happen when a node dies due to energy exhaustion or other unexpected interference. If this node is at the lowest level, it will not affect the time synchronization at all. But if it is the parent of other nodes, then all its children will be isolated from the network because of no response from the parent node. 23

26 To solve this problem, the solution of setting a timeout period to avoid node isolation can be used. Each node should check if a timeout period (set by a timer) has passed without any message from its parent node. If the timer expired, it regards its parent to be dead and will update its hopcount when getting message from other node. In this case, it might also get the message from nodes at next level or the same level, but according to the rule, it will keep updating its hopcount until it get the message from the node in the coverage with the highest level. In both case, the value of the timeout period needs to be set properly according to the network synchronization period. It should be at least greater than one network synchronization period. In the current implementation, we set the time out period to be five times of network synchronization period. Since as we observe, if the node did not get synchronized for five network synchronization periods, it is already isolated or its parents is not working any more Implementation details The time synchronization protocol is implemented in Contiki for Tmote Sky. Flow of network-wide synchronization is shown in Figure C.1. In the implementation, there are some values, such as the random delay and timeout period, needed to be optimized, but it will need plenty of experiments and complicated analysis of results. So for the current implementation we choose the feasible values but not necessary optimized. We will test the network-wide time synchronization in Tmote Sky and present the test result and analysis in later chapter. 3.3 Low-latency data collection using Treeroute Treeroute is a routing protocol implemented in Contiki. Currently Treeroute is not implemented in Tmote Sky platform, but in some other platforms, i.e., netsim and ESB. But it is easy to port this protocol to run in Tmote Sky motes since it is based on the common uip/udp layer in Contiki. We analyse the protocol design and port it to Tmote Sky platform. Then we implement a demo application for low-latency data collection in a multi-hop network using the Treeroute protocol. In the demo application, periodical time synchronization is running among the network so we can measure the latency for each data packet arrived based on the global synchronized clocks between different nodes in the network Treeroute protocol As we mentioned before, a majority of the data traffic in a sensor network goes from sensor nodes to the sink node (i.e., the data aggregator). Since Treeroute provides the routing path from a sensor node to the sink node, we can use it for data collection between the sink node and the sensor nodes not in the single-hop coverage. The routing protocol is based on the Trickle [22] flooding protocol, originally intended for code propagation in sensor networks. Once one node is set as the sink, it will send the trickle routing broadcast with hopcount 0. When a neighboring node receives this broadcast it will check if its hopcount is equal to 1. If not, it will update its neighbor table and change its hopcount to be 1. Then it 24

27 will wait a random delay and send a new routing broadcast with its hopcount to inform the neighboring node in next level to update their hopcount and neighbor table. This process will run until all the nodes have updated their hopcount and neighbor table. At the same time, a node might also get the broadcast from the neighboring nodes in the same level or from the children in next level, it might also add these nodes into its neighbor table if the neighbor table has a neighbor entry with higher hopcount or the same hopcount but with lower signal strength. After this routing process, every node has a hopcount, representing its level in the network, and a table of all its neighbors with good connectivity. Sensed data will be sent from the sensor node to the sink along the routing path derived from the neighbor table in each node. Data packets will be forwarded to the best neighbor, i.e., the neighbor node with highest signal strength of the ones that have the lowest hopcount. To maintain a reliable communication, retransmissions with a maximum limit will be carried out if an implicit ACK is not received at a fixed period. An implicit ACK means the packet forwarded by the receiver. That is, if the sender finds out that the same packet is forwarded by the receiver, it means the packet has been received successfully Schedule-based low-latency data collection To achieve low-latency and reliable data collection using Treeroute routing, the main problem is to reduce the collision between different nodes, thus reducing contention time and the number of retransmissions. Based on the time synchronization, we can schedule the time for different nodes, i.e., assigning each node with different slot. Then a sensor node will send data only in its slot and thus avoid collision with other nodes. With the scheduled slots, the data delivery will be more reliable and fast. In our data collection protocol, slot assignment is done according to the time schedule for different nodes. We divide one second to be 16 slot periods. Then we assign one slot to each node according to its nodeid (the unique identifier of the node). After getting synchronization, the sensor nodes will start to send the data packets in its slot every second. If we need more than 16 slots per second, we can make the slot period shorter but we need to guarantee that it can tolerate the sync error and the time needed for a data delivery Implementation We port Treeroute protocol to Tmote Sky and develop a demo application based on the time synchronization as well as Treeroute routing to collect data from sensor nodes in a multi-hop network. The end-to-end latency is measured for each packet and a statistics of one-hop latency oand two-hop latency in the experiment will be conducted. 25

28 Chapter 4 Security analysis and design for the real-time services In this chapter, we analyse the security goals for the real-time services, identify the attacks and present the countermeasures to resist the identified attacks with the security services we implemented for Tmote Sky platform. 4.1 Security for time synchronization To analysis the security issues in a time synchronization service, we should first find out the main security goals. We have identified two main goals for the time synchronization service. Security goals 1. Protection of the critical data (i.e., the timestamps) from being modified and delayed. This is to get the correct time offset for the clock correction. 2. Prevention of nodes from synchronizing to a malicious node. This is to guarantee the sensor nodes synchronize themselves only to the legal nodes in the network. Recalling the security challenges and considerations in a WSN, to achieve the security goals, we can look at the possible attack scenarios and then find out how to counter these attacks. Attack scenarios a. Modification of timestamps An adversary can simply modify the values of the timestamps which are included in sync packets. b. Pulse-delay attack As described in [17], this attack can be done by simply jamming the initial pulse, storing in its memory and then replaying it at a arbitrary time later. By manipulating the pulse-delay, an adversary can arbitrarily change the computed time offset. c. Replay attack An adversary can capture a packet and replay it at a later time. The old packet with an old timestamp will lead to a wrong computed offset. 26

29 d. Compromised nodes As we mentioned in Chapter 2, compromised nodes attacks are common for a wireless sensor network without physical security. An adversary can manipulate the compromised node to send false data. It can lie about its level, pretending to be the sink node with level 0, or the parent of other nodes in level n. It can also act as a man in the middle to delay or modify the timestamps in the sync packets. Countermeasures with the security services Based on the attack scenarios, we present the countermeasures to secure the time synchronization using CC2420 security services we have implemented in Contiki OS. a. Modification This can be solved with the cryptographic methods, such as data authentication or encryption. To prevent the modification, the timestamps in a sync packet are authenticated by using CBC- MAC for authentication so there are no ways to change it without being detected. A secret key is shared between the sender and receiver for the authentication. b. Pulse-delay attack Any delay attacks which lead to delayed timestamping can be detected by setting a threshold value according to the estimated maximum one-way transmission delay. A one-way transmission delay includes transmission processing time, media access time, propagation delay, and receiving processing time. A node will calculate the round-trip delay in a pairwise synchronization. If the delay exceeds the threshold value, it will discard the packet. c. Replay attack Replay attack can be detected by the authenticated timestamp or the sequence number. A node will maintain the value of last timestamp or sequence number from its parent. When it receives a broadcast from its parent, it will check if it is an old message. If so, it will regard it as a replay message and just simply discard it. d. Compromised nodes Resisting attacks from compromised nodes goes beyond the scope of cryptographic methods. Although using tamper-resistant hardware can help protect those secrets, it is still impractical for sensor networks. There are some researches on how to resist attacks from compromised nodes. A location-based approach, where the secret keys are bound to geographic locations of the sensor nodes, is proposed in [19]. But it needs locations information of all nodes in the network so it is not a practical solution for those networks without location positioning service. Another approach based on diversifying the data and code obfuscation methods in different nodes is proposed in [1]. Both the location-based service support and the obfuscation methods are not in the place in our system. Currently we do not consider compromised nodes in the protocol security design for time synchronization. 4.2 Security for low-latency data collection The main security goals in a low-latency data collection protocol include the following aspects: 1. Protection of the collected data from being modified and disclosed by malicious attackers. 27

30 2. Make sure the data packets arrive at the destination node, i.e., the sink, in a tolerable latency. 3. Make sure the data packets are not the old ones replayed by an adversary. An adversary can modify the data easily if no authentication mechanism is used. If the data is confidential, it needs to be encrypted to prevent the disclosure. To protect the collected data in transit, we propose to use the security mode, CCM, to encrypt and authenticate all data packets. Every sensor node shares a secret key with the sink. The latency for data collection using Treeroute depends on the hopcount of sender as well as the number of retransmission. An adversary might arbitrarily delay the data packets, but the retransmission mechanism according to the implicit ACK in Treeroute will, to some extent, counter this attack. If the sender does not receive the implicit ACK in a short period, it will regard it to be lost and retransmit it. After maximum retransmissions, it will remove this neighbor and find another route to send the data. To reduce the latency, maximum number of retransmissions should be chosen properly. Replay attacks can also happen. If the data packet contains data about a time-critical event, it should not be reported repeatedly to trigger a false alarm. So sequence numbers can be used in each packet for each sensor node. The sink node needs to keep track of the last sequence number of data from each node. When the replayed packet is received, the sink node will discard it. As an alternative, the authenticated timestamp can be also used to ensure the data freshness. 28

31 Chapter 5 Experimental results and performance evaluation This chapter describes the experiments to test the protocols and gives the test results. Then a performance evaluation will be conducted to the protocols respectively. The development environment is Linux(Fedora Core 3). Contiki kernel along with the service code is compiled and programmed into Tmote Sky. The version of the compiler is msp430-gcc The Contiki ELF loader is used to program the nodes. 5.1 Time synchronization We test the time synchronization protocol in Tmote Sky motes to see how the nodes in the network get synchronized for the networks with dynamic topology. Experiments will be conducted with and without security, respectively. And the protocol will be running in a single-hop network as well as multi-hop network. The clock setting in Contiki is: CLOCK SECOND = 512. The oscillator frequency is 32768Hz. So the INTERVAL is set to be 32768/CLOCK SECOND = 64. So one tick represents 64 oscillation periods Experiments and test results In this section, we conduct the experiments to test the time synchronization protocol and give the experimental results. The synchronization precision will be measured in ticks. According to the clock setting for the experiments, tick frequency (i.e., CLOCK SECOND) is set to be 512. So one tick is equal to 1/512 second, i.e., roughly 2 milliseconds. Synchronization without security In this part, we disable the security operations for all communications, so the time synchronization will not be protected. Eleven nodes will be deployed for the experiments, respectively, running in a single-hop fashion and a multi-hop fashion. Single-hop networks In a single-hop network, one node will be set as sink node and initiate the network-wide time synchronization. The remaining ten nodes will synchronize themselves to the sink 29

32 node. The topology is shown in Figure 5.1. Figure 5.1: Single-hop network topology for test The key problem here is that all neighboring nodes need to send the requests(psync REQ) in different time to avoid the collision after they get the NETSYNC BROADCAST message from the sink at the same time. So a random delay is used for the neighboring nodes to send the request at a different time. As we discussed before, we set the random delay as: random delay = max num round delay fa. In this experiment, let max num to be 10, round delay to be 6, and fa to be 10. Thus the random delay is 600 (in ticks). We program all the nodes and start to run the time synchronization process in each node. If a node gets a button press event, it will set itself to be the sink node and send the NETSYNC BROADCAST message to initiate the synchronization. All the other nodes in the neighborhood will get the message at the same time. They will wait a random delay and then send the request to the sink to proceed with a pairwise synchronization with the parent node. Due to the lack of USB connections to monitoring terminals, we collect the test data for only the sink node and three neighboring nodes out of the ten nodes. Each node is designated a short address, which can be derived from its IP address. For the node with IP address , its short address is set to be 0x0100. We set the node 0x0300 to be the sink node. Then we can see that the neighboring nodes start synchronization with the sink node. In our test, we record the test results for 50 periodical synchronizations. In these 50 rounds of periodical synchronization, similarly we monitor only three nodes (0x0100, 0x0200 and 0d00) out of ten nodes synchronizing with the sink node and analyse the synchronization error between these three nodes. The statistics of the test result is shown in Figure 5.2. According to the test result, in the monitoring period, these three nodes achieve synchroniza- 30

33 Figure 5.2: Synchronization result in a single-hop network without security tion with average synchronization error of 1.4 ticks. Meanwhile, the sink node gets about 97.6% of requests from the neighboring nodes. That is, only about 2.4% of requests are lost due to collisions. Multi-hop networks To run the synchronization in a multi-hop network, we move the sink node to the place 3 hops away from the three monitored nodes, and put the other nodes in the middle to bridge the communication between the monitored nodes and the sink node. The topology is shown in Figure 5.3. Similarly, we record the test results in the three nodes (0x0100, 0x0200 and 0d00) in level 3 for 50 rounds of periodical synchronization and analyse the synchronization error between these three nodes and its parent node (0x0c00). The statistics of the test result is shown in Figure 5.4. According to the test result, in the monitoring period, these three nodes achieve synchronization with average synchronization error of 1.1 ticks. The average synchronization error is lower than that of the previous test in a single-hop network. It is reasonable since only three nodes in the same neighborhood synchronizing to the same parent. But in the single-hop network, ten neighboring nodes are synchronizing to the parent, i.e., the sink node. Thus the chance of collision between the neighboring nodes might be much higher and lead to more uncertainty in the time-critical path. Synchronization with security In this part, we enable the MAC-layer security operations to protect all communications in the time synchronization process will not be protected. The same network topology as above will be configured with the eleven nodes (one as the sink node) for the experiments. In the experiment, we choose the authentication mode, CBC-MAC with 128-bit MIC, to protect the timestamps for synchronization from illegal modification. We do not use the encryption mode because we are not concerned if the timestamps are captured by an adversary but concerned if the timestamps are changed in transit. The MAC-layer security operation is transparent to the protocol, but it can detect the modification of data packet and discard the packet if the packet does not pass the MIC check. Single-hop networks For a single-hop network running with security, we record 50 rounds of periodical synchronization for three nodes synchronizing with the sink node. 31

34 Figure 5.3: Multi-hop network topology for test The statistics of the test result is shown in Figure 5.5. According to the test result, in the monitoring period, these three nodes achieve synchronization with average synchronization error of 1.5 ticks. Multi-hop networks We move the sink node to a place three hops away from the three monitored nodes to form a multi-hop network running with security, we record 50 rounds of periodical synchronization for the three nodes synchronizing with its parent node (0x0c00). These three nodes are located in level 3 (i.e., 3 hops away from the sink node). The statistics of the test result is shown in Figure 5.6. According to the test result, in the monitoring period, these three nodes achieve synchronization to its parent with average synchronization error of 1.0 ticks. According to the above test results, the time synchronization protocol we design can achieve networkwide synchronization with synchronization error about 1 to 2 ticks, i.e., 2 to 4 milliseconds. Moreover, synchronization with MAC-layer security works well as synchronization without security. The time for security operation on a fixed length of synchronization packet should be deterministic, so as we can see the synchronization error is not affected obviously by the MAC-layer security operation. 32

35 Figure 5.4: Synchronization result in a multi-hop network without security Figure 5.5: Synchronization result in a single-hop network with security Synchronization error analysis and performance evaluation First we analyse sources of synchronization error in our protocol design and then give an evaluation on the performance metrics we mentioned before. Synchronization error analysis According to the source of synchronization error, we analysis how most of the sources of error are eliminated in our protocol design while some uncertainties are inherent in the current system and thus can not removed. a. Drift & skew The inherent skew and the drift among the crystal based clocks of sensor nodes can lead to large clock deviation. Hence, even if we synchronize the whole network once, nodes will still go out of sync in a few minutes. In our protocol, periodical resynchronization is needed to compensate the skew and drift. b. Uncertainty in time-critical path As we discussed before, the synchronization error comes from the uncertainty of the following 33

36 Figure 5.6: Synchronization result in a multi-hop network with security delay factors: send time, media access time, transmission time, radio propagation time, reception time and receive time. Since we timestamp the sending time of a packet in the MAC layer, the send time is excluded in the time-critical path. Media access time uncertainty due to the competition-based mechanism in CC2420 contributes to the major source of synchronization error. To get the same transmission time for the message exchange in a pairwise synchronization, we construct the two message with the same packet length. Radio propagation time is negligible with normally less than 100 meters of coverage for a wireless sensor. Reception time for the packets with the same length is deterministic in nature. Receive time in our implementation means the UDP receiving time, which is also deterministic in Contiki OS. Communication overhead In our protocol, communication overhead in terms of transmitted packets is linear to the network size, i.e., the number of nodes in the network. One network synchronization process with n nodes (the sink node excluded) needs only one broadcast message from the sink node and n message exchanges, a message exchange for a pairwise time synchronization. Compared to TPSN, at least n flooding broadcast messages need to be sent among the whole network to form the hierarchical tree. Meanwhile n rounds of pairwise synchronization need to proceed along the tree. Mobility Mobility means the support of dynamic addition of new nodes or unexpected failure of existed nodes. As we observe in the experiments, the protocol can be easily adapted to the change of the network topology. Addition of a new node can be easily associated with the network and synchronize itself to its neighboring node with the lowest level. When we remove some nodes from the network or change their positions, the active nodes who lost the original parent will seek to synchronize to the new parent in its coverage. TPSN does not support the dynamic network since it needs to conduct a new phase of network flooding to adapt to a new network topology. It is not practical to redo a network flooding frequently to form a hierarchical tree since it consumes a lot of communication bandwidth and CPU cycle. Computational complexity As TPSN, our protocol is computationally less expensive when compared to RBS. But it is computationally more expensive than DMTS since DMTS trades synchroniza- 34

37 tion accuracy for low computational complexity. Resilience to security attacks: With the authenticated timestamps, our protocol is resilient to a set of security attacks. This has been discussed in detail in previous chapter. 5.2 Low-latency data collection based on time synchronization In this section, we perform an experiment to measure the end-to-end latency for data packets sent between sensor nodes and sink node in the network. The network experiment for test is shown in Figure 5.7. Figure 5.7: Network model for data collection test We need to assign the slot for each nodes according to the nodeid which is unique and derived from the IP address. Figure 5.8 shows the slot schedule for each second. Each slot period is 32 ticks, the channel capacity is 16 per second. The six sensor nodes, from 0x0700 to 0x0c00 are assigned with slots from 7 to 12, respectively. Figure 5.8: Slot schedule of one second 35

38 5.2.1 Experiments and results We run the demo application with time synchronization providing a global clock and Treeroute providing multi-hop routing. After a sensor node gets synchronized with the network, it will start to send a data packet in its slot period every second. The latency is measured for each data packet in ticks. In the sink node, we collect 5000 data packets from both one-hop nodes and two-hop nodes. Then we make statistics on the one-hop latency as well as on the two-hop latency. Figure 5.9 shows the statistics of latency in data delivery from one-hop nodes. The average endto-end latency for a one-hop data collection is 5.3 ticks. Figure 5.9: Latency statistics in from one-hop nodes Figure 5.10 shows the statistics of latency in data delivery from two-hop nodes. The average end-to-end latency for a two-hop data collection is 10.3 ticks. Figure 5.10: Latency statistics in from two-hop nodes From the result statistics, we can see that the latency will increase with the hopcount between the source node to the sink increasing. One-hop latency is maintained to be around 5 to 6 ticks, while twohop latency is around 10 to 11 ticks. The latency is stable so we can conclude that the sensor nodes are 36

39 stably synchronized and the collision is eliminated by the schedule-based slotted data communication. According to the network topology and size, we can decide how to schedule the slots for all the nodes i the network to send sensed data to the sink. There should be a reserved period between two successive slots to prevent the overlapped time due to synchronization error. 37

40 Chapter 6 Conclusion and future work 6.1 Conclusion In this thesis, we design and implement the two real-time services in Contiki, time synchronization and low-latency data collection. To make the services resilient to the security attacks, the MAC-layer security services based on hardware-supported AES-128 security operations are implemented and integrated with the MAC protocol. We conduct security analyses for the protocol design and propose corresponding countermeasures with the support of the implemented security services. To show the feasibility and performance, we test the time synchronization both with and without security protection running a network with more than ten sensor nodes. In the experiments both with and without security enabled, we show that the time synchronization protocol works with synchronization error of 1 to 2 ticks and the sync error is not degraded greatly with the hopcount increasing. The execution time of security operations on the sync packets with the same length is deterministic and thus the synchronization precision is not degraded by the security operations. We conduct a performance analysis on the time synchronization protocol design to highlight its advantages in low communication overhead, mobility and dynamic topology support and the resilience to security attacks. We achieve low-latency and reliable data collection by the schedule-based communication based on the time synchronization and Treeroute routing protocol. The Treeroute routing is ported to Tmote Sky to provide the multi-hop routing. An experiment for a two-hop network shows we can achieve one-hop latency of about 5 to 6 ticks while two-hop latency of about 10 to 11 ticks. The fluctuation is reasonable considering the synchronization error of 1 to 2 ticks. 6.2 Future work There is still some work to do to use the secure real-time services in a real-world time-critical application. There are many application-specific features in the protocol design. We envision providing the secure real-time services as system APIs over motes. The services can be running at the backend of a sensor node, transparent to the application-writer. In the real-time services design, it is very hard to get the optimized values for some parameters, such as the random delay, one-way transmission delay, in the protocols design. Most of parameters are application-specific, so 38

41 we should can get more empiristic data through extensive experiments to find the appropriate values. When we have a good simulation environment, theoretical analysis for optimization can be done with the simulations. For the security services, there are no key distribution protocols and security service layer existing in the current Contiki. To support the security-sensitive protocols and applications, a security layer and suitable key distribution methods can be designed for Contiki. a. Secure key distribution in sensor networks with ECC techniques All the secure solutions based on secure keys will need a secure association of keys, i.e. secure exchange of the secret keys between different sensor nodes. With more and more security concerns in a sensor networks, secure channel might be needed for secure association of sensor nodes with the network. Instead of using the preshared key, an efficient public key technique can be used for secure key distribution for sensor networks. ECC is an emerging technique which is more efficient and computationally feasible for resource-constrained systems. There are already some implementations and evaluations of ECC for the popular sensor platforms, such as MICA2, MICAz and TelosB etc [3, 23]. More research should be made on the improvement and verification of the use of ECC for sensor networks. b. Software-based security services in Contiki OS Most of the sensor platforms (i.e. motes) do not support hardware implementation for security crypto acceleration. So there is a need to support the software implementation of security for those motes without hardware-assisted security. A security layer should be implemented in Contiki OS to provide the basic security services, including encryption/decryption and authentication. A suitable key management scheme is also needed to support both hardware-based and software-based security. 39

42 Acknowledgments First I would like to thank my supervisors, Thiemo Voigt, Adam Dunkels, Prof. Mikael Johansson for their constructive advice and guidance throughout this thesis work. Second, I would like to express my gratitude to all the people at SICS for a great environment during the entire time I have worked on this thesis. Special thanks to Björn Grönvall, Zhitao He, Fredrik österlind for self-giving help and valuable discussion during the my work at SICS, Special thanks to all of my friends for their great support and encouragement during the thesis work. And last but not least I am very grateful to my family, who supported me all the time during my study. 40

43 Bibliography [1] Wenliang Du Abdulrahman Alarifi. Diversify sensor nodes to improve resilience against node compromise. Proceedings of the fourth ACM workshop on Security of ad hoc and sensor networks, [2] A.D. Kshemkalyani B. Sundararaman, U. Buy. Clock synchronization for wireless sensor networks: A survey. Ad-hoc Networks, May [3] M. Smith D. Malan, M. Welsh. A public-key infrastructure for key distribution in tinyos based on elliptic curve cryptography. In In First IEEE International Conference on Sensor and Ad Hoc Communications and Network, Santa Clara, California, October [4] A. Dunkels. Protothreads web site. Web page. Visited adam/pt/ [5] A. Dunkels. The Contiki Operating System. Web page. Visited adam/contiki/ [6] A. Dunkels. Full TCP/IP for 8-bit architectures. In Proceedings of The First International Conference on Mobile Systems, Applications, and Services (MOBISYS 03), May [7] A. Dunkels, B. Grönvall, and T. Voigt. Contiki - a lightweight and flexible operating system for tiny networked sensors. In Proceedings of the First IEEE Workshop on Embedded Networked Sensors, Tampa, Florida, USA, November [8] A. Dunkels and O. Schmidt. Protothreads Lightweight Stackless Threads in C. Technical Report T2005:05, Swedish Institute of Computer Science. [9] A. Dunkels, O. Schmidt, and T. Voigt. Using protothreads for sensor node programming. In Proc. of the Workshop on Real-World Wireless Sensor Networks (REALWSN 05), Stockholm, Sweden, June [10] A. Dunkels, T. Voigt, and J. Alonso. Making TCP/IP Viable for Wireless Sensor Networks. In Proc. EWSN 04 work-in-progress session, January [11] A. Dunkels, T. Voigt, J. Alonso, H. Ritter, and J. Schiller. Connecting Wireless Sensornets with TCP/IP Networks. In WWIC2004, February [12] Girod L. Estrin D. Elson, J. Fine-grained network time synchronization using reference broadcasts. In In Proceedings of the Fifth Symposium on Operating Systems Design and Implementation (OSDI), Boston, MA, December [13] NIST FIPS. Advanced encryption standard (aes). Web page. Visited [14] Cauligi S. Raghavendra G. Lu, B. Krishnamachari. An adaptive energy-efficient and low-latency mac for data gathering in sensor networks. In In Int. Workshop on Algorithms for Wireless, Mobile, Ad Hoc and Sensor Networks (WMAN), Santa Fe, NM, April [15] R. Szewczyk D. Culler etc. G. Tolle, J. Polastre. A macroscope in the redwoods. In SenSys, pages 51 63,

44 [16] Kumar R. Srivastava M. B. Ganeriwal, S. Timing-sync protocol for sensor networks. In In Proceedings of the First ACM Conference on Embedded Networked Sensor Systems (SenSys), Los Angeles, CA, November [17] S. Ganeriwal, S. Capkun, C. Han, and M. Srivastava. Secure time synchronization service for sensor networks. In WiSE, September [18] S. Ganeriwal, S. Capkun, C. Han, and M. Srivastava. Security for industrial communication systems. In Proceedings of the IEEE, June [19] Jerry Cheng etc. Hao Yang, Fan Ye. On resiliency to compromised nodes: A case for location based security in sensor networks. [20] F. Mattern K. Römer. The design space of wireless sensor networks. IEEE Wireless Communications, 11(6):54 61, December [21] P. Ning K. Sun and C. Wang. Secure and resilient clock synchronization in wireless sensor networks. In IEEE Journal on Selected Areas in Communications, February [22] P. Levis, N. Patel, D. Culler, and S. Shenker. Trickle: A self-regulating algorithm for code propagation and maintenance in wireless sensor networks. In In First Symposium on Network Systems Design and Implementation (NSDI), March [23] A. Liu and P. Ning. Tinyecc: Elliptic curve cryptography for sensor networks. Web page, September Visited [24] Moteiv. Tmote Sky). Web page. Visited [25] David Wagner Naveen Sastry. Security considerations for ieee networks. Web page. Visited daw/papers/ [26] S. Ping. Delay measurement time synchronization for wireless sensor networks. In Intel Research, June [27] Chipcon product from Texas Instruments. CC2420 Datasheet). Web page. Visited Data Sheet 1 3.pdf [28] K. Römer, P. Blum, and L. Meier. Time synchronization and calibration in wireless sensor networks. In I. Stojmenovic, editor, Handbook of Sensor Networks: Algorithms and Architectures. John Wiley and Sons, September [29] Christian Schumacher. 6lowpan security considerations, November [30] IEEE Computer Society. Ieee spec. Web page. Visited [31] David Wagner. Security for sensor networks: Cryptography and beyond. In ACM Workshop on Security in Ad Hoc and Sensor Networks (SASN 03), October

45 Appendix A Glossary AES: Advanced Encryption Standard CBC: Cipher Block Chaining (CBC) mode CCM: Counter with CBC-MAC mode CTR: Counter mode ECC: Elliptic Curve Cryptography MAC: Media Access Control MIC: Message Integrity Code 43

46 Appendix B Program flow of security protocol Flow of CC2420 security protocol is shown in Figure B.1. 44

47 Figure B.1: CC2420 secure communication driver flow. 45

48 Appendix C Program flow of time synchronization protocol Flow of network-wide synchronization is shown in Figure C.1. 46

49 Figure C.1: Flow of network-wide synchronization 47