Secure Real-time Services for Wireless Sensor Networks in Contiki

(1)

Secure Real-time Services for Wireless Sensor Networks in Contiki

Shujuan Chen{shuj-che@dsv.su.se}

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)

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.

(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

(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.

(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. Mean- while, 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:

(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].

(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.

2.2.1 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 802.15.4 specification. The CC2420 radio provides high-level security using 128-bit AES crypto accelerator with which we can provide the link-layer secure services.

(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 IEEE802.15.4 2003 Spec

For compliance with IEEE802.15.4 2003 specification [30], the CC2420 radio features hardware IEEE 802.15.4 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 IEEE802.15.4 specification pointed out in [25]. In fact there is an ongoing work on the IEEE802.15.4b [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 pass- words 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 check- ing 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:

(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 time- sensitive applications. In this thesis, we will study the current time synchronization protocols for sensor network and the related security issues.

2.3.1 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 The nodes might not be started at the same time and thus a clock offset exists between these nodes.

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.

(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 Net- works(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].

2.3.2 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.

(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

(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 low- latency 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 consump- tion. 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.

(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

3.1.1 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 IEEE802.15.4 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.

(17)

Figure 3.2: Data packet format with security modes.

3.1.2 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

(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.

3.1.3 Security settings and protocol for CC2420 secure communication

As mentioned in the previous chapter, CC2420 supports hardware IEEE 802.15.4 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 (SECCT RL0 and SECCT RL1). 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].

SECCT RL0 setting

In security control register SECCTRL0, the following settings can be done: Key selection: bit field SEC T XKEY SEL for TX Key selection and SEC RXKEY SEL for RX Key selection. Se- curity modes selection: configure bit field SEC M [2 : 0] and SEC M ODE[1 : 0] for the modes selection . Protection enable: bit field RXF IF O P ROT ECT ION is set to 1 to enable security.

SECCT RL1 setting

According to which part of data you want to protect (encrypt or authenticate), we can configure fields SEC T XL and SEC RXL in SECCT RL1. 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 (M AC 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 cor- responding RAM memory space: KEY 0 or KEY 1. According the key selection in SECCT RL0 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.

(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 IEEE802.15.4 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: IEEE802.15.4 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 ST XON CCA to start encryption/authentication operation and trans- mission.

Receiving process

For each new packet arrived, we

i. Read the values of frame counter and key sequence counter from RXFIFO;

(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.

3.1.4 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 program- ming flow is shown in Figure B.1.

3.2 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.

3.2.1 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.

(21)

TicksFrequency Resolution T imeSpan(days)

64 2⁻⁶ 776

128 2⁻⁷ 388

256 2⁻⁸ 194

512 2⁻⁹ 97

1024 2⁻¹⁰ 48.5

2048 2⁻¹¹ 24

4096 2⁻¹² 12

8192 2⁻¹³ 6

16384 2⁻¹⁴ 3

32768 2⁻¹⁵ 1.5

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.

3.2.2 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: the number of message exchanged in a network of n nodes;

synchronization precision: the maximum deviation among the logical clock readings of nodes in the network;

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 ad- vantage of low computational complexity and extremely low communication, but lower synchroniza-

(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 Fig- ure 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

(23)

We can calculate the clock offset and the roundtrip delays with

of f set = [(T 1 − T 0) + (T 2 − T 3)]/2, (3.1)

delay = (T 3 − T 0) − (T 2 − T 1). (3.2) MAC-layer or UDP-layer time synchronization?

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 integra- tion 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

(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 N ET SY N C BROADCAST , which can be sent only by the sink node, will inform the nodes to start a new round of synchroniza- tion. The sink node will send the message N ET SY N C 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 N ET SY N C BROADCAST mes- sage 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 P SY N C 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 P SY N C 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 P SY N C REQ message to synchronize itself to the parent node.

When receiving a P SY N C 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 P SY N C REQ will be included in the P SY N C ACK message and send back to the requesting node.

When receiving a P SY N C ACK message, the node will record the receiving and sending times- tamp of the P SY N C 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 P SY N C 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 f a to be the factor to adjust the chance of collision occurrence.

(25)

Then the random delay (i.e. random delay) to send P SY N C REQ should be set as following.

When receiving a N ET SY N C BROADCAST from sink node, the random delay will be set to random delay0:

random delay0 = rand()%(max num ∗ round delay ∗ f a) (3.3) When overhearing P SY N C 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.

(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.

3.2.3 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.

3.3.1 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

(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.

3.3.2 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.

3.3.3 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.

(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.

(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.

(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 retrans- mit 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.

Secure Real-time Services for Wireless Sensor Networks in Contiki