Secure Real-time Services for Wireless Sensor Networks inContiki

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

Master thesis

March 17, 2007

Abstract

With the widespread use of networked embedded systems operating over wireless sensor net-works, a standardized architecture is required to enable the rapid development of applications. Anembedded 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 asystem service to improve the development speed.

Real-time services are commonly required by many time-sensitive applications, such as automationcontrol, 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. Butthere is no common notion of time in a wireless sensor network in which all the nodes are physicallyseparated and no global clock or common memory exists. Moreover, there is no guarantee that thesensed data will get to the destination before the deadline. To address these real-time issues, we de-velop real-time services including time synchronization and low-latency data collection to provide therapid development of time-critical applications. Meanwhile, security becomes an important issue towireless sensor network due to the vulnerability of the wireless channel. The adversaries can simplycapture and change the data and then resend it. The real-time services utilizing the wireless commu-nication are vulnerable to the attacks and might be the weakest link for the whole system if it is notdesigned with security in mind.

As the building block of real-time services, time synchronization comes into the first place to providea global time scale for a distributed networking system. We study current time synchronization proto-cols for wireless sensor networks, propose our protocol design and implement it in the experimentalplatform, Contiki OS on the hardware platform Tmote Sky. To show the feasibility and performanceof 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 no-tion of time over the network, we implement a protocol for data collection aiming at low end-to-endlatency for the same platform. To show the performance of data collection using this protocol, we testend-to-end latency in a multi-hop network and evaluate it based on the hop count and the estimationof 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 tovulnerability 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 mightinterrupt the services and present countermeasures to resist these security breaches. The hardwareplatform in use provides a crypto accelerator in the radio chip and frees the microcontroller fromthe long computation time for the security operations. We implement the security protocol utilizinghardware-assisted security operation to provide the link-layer security services. In addition, we pro-vide data freshness service using authenticated MAC timestamping for each packet. Then we showhow to secure the real-time services using these security services and integrate them into the protocolimplementation.

Contents

1 Introduction 31.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Research approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Thesis outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Background 62.1 Security challenges and considerations in WSN . . . . . . . . . . . . . . . . . . . . 62.2 Target platform and supported security features . . . . . . . . . . . . . . . . . . . . 8

2.2.1 Contiki OS and Moteiv Tmote Sky . . . . . . . . . . . . . . . . . . . . . . . 82.2.2 Supported security features in target platform . . . . . . . . . . . . . . . . . 9

2.3 Real-time issues and time synchronization in WSNs . . . . . . . . . . . . . . . . . . 92.3.1 Overview and basic concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4 Low-latency data collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Designs and implementation of services on target platform 143.1 Link layer security services and authenticated timestamp . . . . . . . . . . . . . . . 14

3.1.1 Packet format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.1.2 Key management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.1.3 Security settings and protocol for CC2420 secure communication . . . . . . 163.1.4 Implementation of CC2420 security and authenticated timestamp . . . . . . 18

3.2 Time synchronization with implicit topology formation . . . . . . . . . . . . . . . . 183.2.1 Logical clock in Tmote Sky . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.2 Protocol design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2.3 Implementation details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3 Low-latency data collection using Treeroute . . . . . . . . . . . . . . . . . . . . . . 243.3.1 Treeroute protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3.2 Schedule-based low-latency data collection . . . . . . . . . . . . . . . . . . 253.3.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4 Security analysis and design for the real-time services 264.1 Security for time synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2 Security for low-latency data collection . . . . . . . . . . . . . . . . . . . . . . . . 27

1

5 Experimental results and performance evaluation 295.1 Time synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1.1 Experiments and test results . . . . . . . . . . . . . . . . . . . . . . . . . . 295.1.2 Synchronization error analysis and performance evaluation . . . . . . . . . . 33

5.2 Low-latency data collection based on time synchronization . . . . . . . . . . . . . . 355.2.1 Experiments and results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6 Conclusion and future work 386.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Appendices 42

A Glossary 43

B Program flow of security protocol 44

C Program flow of time synchronization protocol 46

2

Chapter 1

Introduction

1.1 Motivation

Wireless sensor networks represent a new generation of embedded wireless networking systems with abroad range of real-time applications. Examples include fire monitoring, border surveillance, medicalcare, and highway traffic coordination. Such systems must meet new kinds of timing constraints undersevere resource limitations. The data from the sensor network can be used for collaborative operationin automatic control and sometimes critical decision in healthcare or emergency monitoring. Most ofthese applications need the timing order of events happened in different nodes. This requires all thenodes to maintain a global notion of time in order to determine the timing of events [2]. But there isno common memory or global time clock among different nodes since they are separately deployed inphysical environment. Moreover, time-critical data might need to be delivered to a base station withina deadline before the data becomes old and meaningless. For example, a system that monitors andcontrols temperature in a nuclear power plant would require that the readings be reported to a basestation within a maximum time limit for a proper response to a rapid increase in the temperature. Soreal-time services including time synchronization and low-latency data collection should be presentedto 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. Theymight monitor the performance of critical equipment or situation. Or they might collaborate to makea critical decision. In these cases, the risk of having someone interfere with or shut down the networkis unacceptable [18]. Strong security is essential. However, security issues are very common in wire-less sensor networks due to the vulnerability of wireless channel and the hostile environment whereit is deployed. The real-time services using the wireless sensor network are not exempted from thesecurity attacks [17, 21]. Wireless sensor networks are often deployed in an unattended environmentin which nodes might be easy to compromise. For some application scenarios such as medical moni-toring crucial decisions might be made according to the collected sensed data. Malicious modificationof the critical data might lead to great disasters. Thus the data collection protocol is required to beresilient and secure to counter the malicious modification attacks. If a malicious adversary abuses theunderlying time synchronization protocol the applications based on the global clock might be totallydisrupted. For example, the disruption of time synchronization in a monitoring system could lead toa false alarm of emergency or fatal delay of reporting a critical event. The whole system might becrashed down by purposed manipulation of the protocols. So security should be included as a built-inproperty in the protocols design to resist the malicious attacks.

3

Theabove secure real-time services can be used for many applications with timing constraints. To beable to easily reuse these secure real-time services for different applications, it is highly desirable topresent 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 theevaluation of their performance through experiments. First we carry out a literature survey on relatedwork on existing time synchronization and data collection protocols. Second, we present our protocoldesign and implementions on the target platform. Third, we implement security services for thetarget platform. Then we make a security analysis for protocols design and present countermeasuresbased on the supported security services. Finally, to show the feasibility and study the real-worldperformance, we test the protocols for the target platform both with and without the security servicesand measure their performance.

1.3 Results

This thesis presents the design and implementation of secure real-time services, including time syn-chronization and low-latency data collection, and perform several experimental performance evalua-tion. The main results include the following aspects:

a. A network-wide time synchronization protocol is designed, analysed and compared to otherexisting alternative schemes. A concrete implementation of the protocol is done for the tar-get platform (ContikiOS on Moteiv Tmote Sky). Our protocol is based on the sender/receiverpairwise synchronization. A tree topology is formed implicitly during the pairwise synchro-nization starting from the sink node and thus reduces the communication overhead. We also usethe authenticated MAC-timestamping to reduce synchronization error by excluding send timeand 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 andadaptability of the dynamic topology while maintaining the same synchronization precision andcomputational complexity.

b. The Treeroute routing protocol is ported to the Tmote Sky platform for multi-hop routing. Ademo application of a multi-hop data collection using Treeroute routing is designed and im-plemented for a multi-hop network. The data collection protocol can achieve lower latency byusing slotted communication based on the network-wide time synchronization. The latency fora data packet from a source node to the destination node will be measured in the synchronizedtime notion among the distributed nodes. So the measured latency will be affected by the syn-chronization precision. In the experiment, we show that the end-to-end latency of all packets israther stable and the data delivery is very reliable due to non-collision in the slotted communi-cation. This shows that the time synchronization works well enough to provide a global clockfor slot assignment.

c. Security services for the target platform are implemented and further used to secure the abovereal-time services. The implementation of the security services utilize the hardware-based AES

4

security operations supported by CC2420 radio. We can enable the security services to securethe real-time services. Then we make a security analysis for the protocols design and presentcountermeasures 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-timeservices are tested, with security enabled and disabled respectively. An analysis of the experi-mental 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 synchronizationand low-latency data collection protocols. Chapter 3 describes the designs and implementation detailsof 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 securethese services using the security services implemented in this platform. Chapter 5 presents the testresults of some carefully chosen real-world experiments. Chapter 6 concludes the thesis work andpresents the research trends and work.

5

Chapter 2

Background

Wireless sensor networks(WSN) is an information gathering paradigm based on the collective effortsof hundreds or thousands of small wireless sensor devices. The devices are equipped with one ormore sensors, a short-range radio transceiver, a small microcontroller, and a power supply. The sensordevices autonomously form networks through which sensor data is transported. The sensor devicesare often severely resource-constrained. An on-board battery or solar panel can only supply limitedamounts 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 100kilobytes, and less than 20 kilobytes of RAM.

Applications for sensor networks can be found in many different areas [20, 15], ranging from biologyand medicine to industry. One of the potential applications are wireless automation systems whichare supported by the real-time control services over sensor networks. Automatic control is a centralcomponent of any modern process and manufacturing industry. The information flows between sen-sor, actuator and control nodes have traditionally been hardwired synchronous communication. Overthe last decade, there has been a transition to communication buses, such as field bus and Ethernettechnology, in these control systems. Currently there is a major drive to take the next step in thisevolution by moving to wireless communication. More efficient and lower costs for installation andcommissioning are important factors. There is also a large potential for major technological advancesdue 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-timeservices 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 unreliableand serious resource-limited environment, to achieve the reliability of the system, security is a greatissue 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 targetplatform. Then it gives an overview of time synchronization and data collection protocols and furtherdiscusses the related work.

2.1 Security challenges and considerations in WSN

There are several challenges to achieve security in a wireless sensor network:

6

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, forsecurity-critical applications, all the underlying protocols or services need to be designed with secu-rity in mind. According to what needs to be protected, security services such as encryption, authen-tication, authorization and access control, should be in place to provide the necessary protection ofcritical data, such as timestamps for time synchronization service, temperature data for fire monitor-ing, life-critical data for healthcare monitoring, etc.

According to the sources of the security breaches (i.e. unprotected wireless link, distributed com-munication protocol design, compromised nodes) in a wireless sensor network, security is basicallyconcerned with the following aspects:

a. Securing the communication linkThe wireless in nature is exposed physically, so to secure the link means protecting the commu-nication data from being disclosed, modified. This can be achieved through the cryptographicoperations.

b. Securing distributed services and protocolsCryptographic techniques help to secure the protocols. But pure cryptographic techniques insome 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 manipulatingthe 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 attackA WSN is commonly deployed in an unattended environment, so sensor nodes are easily cap-tured. Due to lack of tamper resistance, the embedded cryptographic secret in the compromisednodes can be recovered. Subsequently the compromised nodes can be manipulated as autho-rized nodes to inject bogus data to trigger false events or stall the reporting of real events. It’sout of the realm of cryptography which is based on the secret. But it can be detected or avoidedto some extent on proper protocol design.

Due to the severe resource constraints in a wireless sensor network, there are several design con-siderations 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 usepre-shared keys; use a global key instead of pair-wise keys;

d. Traditional public-key cryptographies such as RSA is not computationally feasible: more effi-cient public key techniques such as ECC might work [31].

7

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 securityservices 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 severememory-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 controlwithout complex state machines or full multi-threading. Each proto-thread handles certain events suchas event timer expiration according to the kernel scheduling, but it never consumes processor cycleswhile 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 thebasic clock source of real-time services. Besides, based on this logical clock, there are also two typesof timers implemented in Contiki, i.e., timer and etimer. With the timers we can easily implementtime-critical services.

For the security aspect, there is no support of security services in current Contiki. However theradio chip in the hardware platform provides the security crypto acceleration. We can utilize thishardware-assisted feature to support security services and free the microcontroller from long-periodsecurity 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 applica-tions [24]. It is integrated with microcontroller MSP430F1611 and the CC2420 radio [27] whichis a first Zigbee-ready radio chip compliant with 2.4 Ghz IEEE 802.15.4 specification. The CC2420radio provides high-level security using 128-bit AES crypto accelerator with which we can providethe link-layer secure services.

8

2.2.2 Supported security features in target platform

Currently there are no security features implemented for the target platform -Tmote Sky in ContikiOS. 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 se-cure 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 hardwareIEEE 802.15.4 MAC security operations. All security operations are based on AES encryption using128-bit keys. With the extensive hardware support for data encryption and authentication [13], thechallenge to counter security attacks for sensor nodes with constrained resource capacity is relievedgreatly. It is very flexible and different security services can be selected via one of the followingmodes: None-security, CBC-MAC authentication only, CTR mode encryption-only, and CCM, whichcombines authentication with encryption.

When utilizing these security features, we refer to the security pitfalls in IEEE802.15.4 specifica-tion pointed out in [25]. In fact there is an ongoing work on the IEEE802.15.4b [29] which aims toresolve 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 onlyexisting in wired networks but also in wireless sensor networks since it is easy for an attacker to ini-tiate 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 informationis illegally stored without authorization and then retransmitted to trick the receiver into unauthorizedoperations such as false identification or authentication or a duplicate transaction. Even though thecaptured 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 accessto the network. Typically a replay attack can be prevented using strong digital signatures that includetime stamps and inclusion of unique information from the previous transaction such as a constantlyincremented 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 isnot modified. Two packets can not be sent by a node at the same time, i.e, with the same sendingtimestamp.

2.3 Real-time issues and time synchronization in WSNs

Real-time issues are concerned with requirements of certain type of temporal relationship betweendifferent events and typically are presented in the one of the following aspects:

9

a. The relative timeliness ordering of events happened in different nodes (e.g. event X must happenbeforeevent Y happens);

b. The time interval between two events happened on different nodes (there is a deadline for eventY 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 thecentral base station (also referred as Sink). To meet the above real-time requirements, a common timeaxis 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 forsensor 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 physicallyseparate and have no common memory. Each node has its own internal clock and its own notionof time, but no common notion of time with other nodes in the network. The real-time issues men-tioned 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 thesenodes.

Skew The crystal oscillator might be running at slightly different frequencies, making the clockvalue 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 conditionssuch as temperature. This is termed as Drift error.

Among these, skew and drift error are related to the hardware and physical conditions and changeover a long period and not instantaneously. We aim at not only reducing the time offset betweennodes to get instantaneous synchronization but also compensating for drift and skew by periodicalnetwork-wide synchronization.

To achieve time synchronization through message exchanges, there are six delay factors (sourcesof synchronization error) in the time-critical transfer path, which means the path of a sync messagethat 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 timesyncpacket to the point the packet is buffered into the TXFIFO.

10

Media access time This delay depends on what kind of media access protocol is using. In TmoteSky, the CC2420 radio use CSMA/CA for media access control. In this case media access delayis the delay for the packet waiting for a clear channel to transmit. This competition-based mediaaccess mechanism leads to highly non-deterministic delay and thus contributes to the major source ofsynchronization 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 aconstant and can be estimated.

Radio propagation time This is the time for a radio signal to propagate over the air to reach areceiver. Radio propagation speed is velocity of light which is 300 meters per microsecond. Thiserror 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 theapplication layer where it is decoded. The value of receive time changes due to the variable delaysintroduced by the operating system.

According to the varying requirements, such as diverse precision requirements, network density, de-gree of mobility and topology stability, several proposals for time synchronization protocols have beenpresented. Time synchronization typically is based on message exchange containing the timestampand 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 suchas Reference Broadcast Synchronization(RBS) [12], while two-way message exchange is commonlyused 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 ex-change as well as the measurement of delay. Typical use of delay measurement is Delay MeasurementTime 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 theadvantages and disadvantages of our protocol compared to these protocols.

11

Reference Broadcast Synchronization(RBS)

In RBS, a reference node broadcasts a message and all the nodes in the coverage will timestamp thelocal time of receiving this reference message [2, 12]. Then they exchange the recorded time andthus 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 neg-ligible since the typical coverage range of a sensor network is less than 100 meters, which means themaximum propagation time is about 0.33 microseconds.

RBS avoids the largest sources of error (send time and media access time) in the time-critical pathand the synchronization error depends only on the difference of propagation time which is negligibleand the time difference between receivers and the radio synchronization error, which is typically a fewmicroseconds. As a result, RBS can achieve high synchronization precision as to several microsec-onds. The disadvantage is the high message exchange and lack of synchronization of reference nodeitself. 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 synchro-nization of the whole network, i.e., including the reference node. In the time-criticla path, if mediaaccess time and transmission time are deterministic, our protocol can expect an equivalent synchro-nization precision as in RBS. So the precision difference to RBS will depend on the uncertainty oftransmission 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 timescaleby creating a self-configuring hierarchical tree. There are two phases to achieve network-wide syn-chronization using TPSN: the level discovery phase and the synchronization phase. In the level discov-ery phase a hierarchical tree is established. In the synchronization phase, pair-wise synchronization isperformed 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 notsuitable to highly dynamic networks with mobile nodes [2, 16].

In contrast to TPSN, our protocol can expect lower communication overhead and better adaptabil-ity to dynamic topology changes through the dynamic implicit tree formation while maintaining anequivalent synchronization precision. The synchronization precision in our protocol depends on theuncertainty of the same factors as in TPSN, i.e., media access time, transmission time, propagationtime 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 broadcastto synchronize all the nodes in a single-hop network. The receivers measure the time delay and settheir 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 syn-chronization precision depends on how well the measurement is made on all the delay factors along

12

the time-critical path. Our protocol can expect higher synchronization precision since some sourcesof 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 ac-cording to collected data from the different sensor nodes. But if the collected data is too old to be usedfor a time-critical decision, the system will lose its function. Protocols aiming at the low-latency col-lection 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 latencywe mean the time duration for a packet from the sending time to receiving time it a network. But tomeasure the real latency, the sending time and receiving time of a data packet should be timestampedwith reference to a global clock. The measurement of latency should be based on the synchronizationof 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 ifschedule-based MAC is used. And if the contention-based MAC, such as CSMA/CA, is used, theuncertainty 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 proto-cols, which will influence the latency. The routing protocol will decide the route from the sourcenode to the destination node. The increase of hop count in a route will increase the latency. Thereare 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 tothe 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

Chapter 3

Designs and implementation of serviceson target platform

In this chapter we design and present the implementation of the secure service mechanisms includingtime synchronization and low-latency data collection for the target platform. The security servicesare provided by a link-layer security protocol which is based on the built-in security support from theCC2420 radio. We first introduce the design of CC2420 security protocol, highlighting the criticalpoints 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 packetformats as in Figure 3.2 for the three basic AES security modes. We will implement the securityservices using these security features according to the security suite specifications in IEEE802.15.4spec [30].

The authenticated part includes timestamp and data payload. The encrypted part includes times-tamp, data payload and MIC when in authentication modes. As we mentioned in previous chapter, wetimestamped every MAC packet and this will serve for time synchronization and also can be used tocounter replay attacks targeting the time synchronization service.

14

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 atfixed RAM space. We can simply configure the Security Control Register to indicate which key forsending or receiving messages. The keys space can be programmable so we can reload the keys tothe corresponding RAM address every time before transmitting or receiving a secure message. Keymanagement issues include the selection of key distribution methods and the selection of global keyor pairwise key.

Pre-shared key or dynamic key exchange There are no key exchange protocols in ContikiOSright 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 anattacker not having the right secret key will be simply discarded due to the failure to authenticate ordecrypt data correctly.

Group key or pairwise key Depending on the security requirements of different applications, allnodes in the network can just simply share a global key, or each node can share a different pairwisekey between itself and the root node.

The group key scheme is convenient for key deployment and easily changed later. But it is vul-nerable to compromised node attack. If the key in one node is compromised, the whole network willnot have any security at all until the key is changed to a new one. The pairwise key scheme will be

15

more secure than the group key scheme.

But the pairwise key scheme will assume more memory for the root node to maintain a key lookuptable, which we call keystore. Incoming secure data packets from the network require a lookup to findthe appropriate key in the keystore, followed by data decryption and/or MIC authentication accordingto 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, com-putation 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 op-erations. All security operations are based on AES encryption using 128-bit keys. Security operationsare performed within the transmit and receive FIFOs on a frame basis. CC2420 can do MAC securityoperations (encryption, decryption and authentication) on frames within the TXFIFO and RXFIFO.These operations are called inline security operations. CC2420 also includes stand-alone AES en-cryption. 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 andSECCTRL1). Then we need to set the keys for transmission and receiving. Forcounter-mode operations, we also need to set up the nonces for each transmission and receiving. Afterthese settings, we can add the security operations in CC2420 MAC driver for each transmission andreceiving [27].

SECCTRL0 setting

In security control register SECCTRL0, the following settings can be done: Key selection: bit fieldSEC TXKEY SEL for TX Key selection andSEC RXKEY SEL for RX Key selection. Se-curity modes selection: configure bit fieldSEC M [2 : 0] andSEC MODE[1 : 0] for the modesselection . Protection enable: bit fieldRXFIFO 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 configurefieldsSEC TXL andSEC RXL in SECCTRL1. In our application, we are going to protect thedata payload as well as the timestamp. So in the implementation, for non-counter modes we set theplaintext length to be length of MAC packet header (i.e.MAC HDR LEN ); for counter modes theplaintext length will be (MACHDR LEN + 5). The number 5 is the total length of frame counterand 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 inSECCTRL0register, the transmission and receiving will accordingly select the right key. Note that we shouldmake sure the same key is used for encryption in sender and decryption/authentication in receiver.

16

Nonce settings

In security engineering, a nonce is a ’number used once’. In CC2420, a nonce is valid only forcounter modes (CTR and CCM)., not for the authentication mode(CBC-MAC). The receive and trans-mit nonces are located in RAM memory addresses. According to the IEEE802.15.4 spec, a noncein 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 repeatinga previously generated value.

1bytes 8bytes 4bytes 1bytes 2bytes

Flags SourceAddress FrameCounter 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 ofcounters and its IEEE address. Similarly, when a node receives a packet it needs to set the receivenonce 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 asthe sender used for transmission. The IEEE address is a part of nonce and nonce is valid in a countermode. But we can only get the sender’s short address which is sent within the packet, but not the IEEEaddress. So in a counter mode, each node needs to maintain a mapping relation between the shortaddresses and long addresses (i.e. IEEE addresses) of all nodes participating in the network. When areceiver node receives a packet, it needs to search for the sender’s IEEE address in the mapping listaccording 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 thenew counter values;

iii. Insert values of frame counter and key sequence counter in TXFIFO;

iv. Issue strobe commandSTXONCCA 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;

17

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 receivenonce;

iv. Issue strobe commandSRXDEC 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 securitysettings in CC2420. To protect the MAC-layer timestamp from being illegal modification, the securecommunication 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 describethe 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 tothe microcontroller. The system clock will stop when a device enters into deep power saving modeand loses all of its time information. Therefore, it cannot be used for time keeping by itself. But theexternal oscillator continues to operate when the MCU and other peripherals are powered off. It canbe 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 itsvalue once per second, then its resolution is one second. The resolution for a node is limited by thefrequency of the hardware crystal oscillator since it increments only when the associated hardwareinterrupt occurs.

Precision Precision can be defined in two ways: absolute precision (i.e., the clock deviation with re-spect to an external standard such as UTC) and relative precision (i.e., the clock deviation with respectto a reference node within the network). In this thesis, we concern only about the relative precisionto a the reference node. So the time synchronization precision means the maximum clock deviationbetween 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 independentclock interval and clock resolution. Our logical time is represented by a 32-bit counter variable whichwill increase each time the hardware interrupt occurs. We call each interrupt as a clock tick. Table 3.2shows the different settings of the logical clock which gives different resolution and clock precisionas well as time span with a 32-bit data structure to record the number of clock ticks.

18

TicksFrequency Resolution T imeSpan(days)64 2−6 776128 2−7 388256 2−8 194512 2−9 971024 2−10 48.52048 2−11 244096 2−12 128192 2−13 616384 2−14 332768 2−15 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 fre-quency (i.e. CLOCKSECOND Micro in Contiki) to be 512. This will give the resolution about 1millisecond and time span of about 97 days. This means the sensor node can keep running for 97 dayscontinuously before the 32-bit counter variable overflows. Theoretically the highest resolution can beachieve at 1/32768 second, i.e. about 30 microseconds. We can run the time synchronization protocolusing 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 popularprotocols, such as RBS, TPSN and DMTS mentioned before in previous chapter.

WSN features self-organization, dynamic topology, limitation in resources including computationability, communication bandwidth and storage memory. Scalability means the synchronization accu-racy will not degrade significantly with the increase in number of nodes in a multi-hop network. Wewill focus on providing flexibility, which means being adaptive to dynamic change in the networktopology.

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 inthe 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 betweencommunication overhead, synchronization precision, computational complexity. DMTS has the ad-vantage of low computational complexity and extremely low communication, but lower synchroniza-

19

tion precision compared to TPSN due to more uncertainty from delay factors. RBS obtains highsynchronizationprecision at the expense of high communication overhead, computational complex-ity, 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 per-formance metrics. But with implicit topology formation in our protocol design, it will achieve lowercomputation overhead, lower computational requirements and better mobility support than TPSNwhile 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 authorizedto initiate the network-wide synchronization.

ii. Every node synchronizes itself to its direct parent through sender/receiver-based pairwise syn-chronization.

iii. A hierachical tree will be implicitly formed using the pairwise synchronization messages, thussaving 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 theimplicit 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 thenext 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 theclient node timestamp upon arrival.

Figure 3.3: Sender/receiver-based pairwise synchronization

20

We can calculate the clock offset and the roundtrip delays with

offset = [(T1 − T0) + (T2 − T3)]/2, (3.1)

delay = (T3 − T0) − (T2 − T1). (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 asmaller packet size than UDP packets and get timestamps at the MAC layer which means less timeuncertainty. 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 withdifferent MAC protocols.

But time synchronization protocol using uIP/UDP packet can be reused in other platforms whichalso support the uIP/UDP protocol. So running the time synchronization service over uIP/UDP canreduce the degree of coupling between the service and the MAC layer. In this case the service is notbased on the specific MAC protocol but on the common UDP layer interface. Meanwhile, we canstill timestamp the packet at MAC layer to reduce the uncertainty from the varying software stackprocessing time which might be affected by the scheduling mechanisms of operating systems. In thiscase, a slight change of the protocol implementation might be needed to adapt to MAC timestampingin the new hardware platforms.

So we will choose the UDP-layer time synchronization while timestamping at the MAC layer. Theprotocol will run over the UDP layer and the timestamping of timesync packets is done in the MAClayer.

Network-wide time synchronization with implicit topology

To achieve network wide time synchronization, there are two aspects: A hierarchical tree is implicitlyestablished over the network with the sink node as time reference node; pairwise time synchronization

21

is performed along the tree.

Implicit hierarchical tree formation To form a hierarchical tree, we do not need an extra messageexchange, such as leveldiscovery message in TPSN [16]. Since all the sync packet will contain ahopcount, so when a node receives a sync message, it will check the hopcount of the sender. If itsown hopcount is greater than the sender’s hopcount plus one, it will update its hopcount and set itsparentID to be this sender’s ID. So implicitly, the hierarchical tree can be constructed dynamicallyand adapted to the topology changes.

Network-wide time synchronization We assume that only the sink node has the right to initialize anetwork-wide synchronization. The network synchronization messageNETSY NC 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 messageNETSY NC BROADCAST periodically to achieve aperiodical resynchronization of network. The periodical synchronization needs to be conducted be-cause the clock might lose synchronization because of the gradually clock skew due to slightly crystalfrequency 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 getsNETSY NC BROADCAST mes-sage from the sink node, it will update their hopcount and parentID, wait a random delay(to avoidcollision with other nodes in the same level), and then send thePSY NC REQ to the sink node tostart the pairwise synchronization.

For a non-sink node in a level greater than 1, it will overhear thePSY NC REQ from nodes inthe upper level, and then update its hopcount and parentID. And then it will wait a random delayplus an estimated roundtrip delay before sendingPSY NC REQ message to synchronize itself tothe parent node.

When receiving aPSY NC REQ message addressed to it, the node will send back a PSYNCACKmessage immediately to the source node. The timestamps of sending and receivingPSY NC REQwill be included in thePSY NC ACK message and send back to the requesting node.

When receiving aPSY NC ACK message, the node will record the receiving and sending times-tamp of thePSY NC ACK message. And till now, the node has got the four timestamps for thepairwise synchronization. According to the four timestamps, it can calculate the time offset betweenit and its parent and then correct its local logical clock to be the same as the parent node according tothe time offset.

The selection of the random delay will affect the happening of a collision when the children nodessend thePSY NC REQ to their parent. So a proper value should be chosen to avoid collision. Butit is difficult to choose an optimized value for it. Since the chance of collision will depend on thenumber of nodes belonging to the same parent and the time in a pairwise synchronization. In thecurrent implementation, we assume the maximum number of nodes(i.e.max num) belonging to thesame parent to be a fixed value. And the time for a pairwise synchronization is estimated accordingto the round-trip delay(i.e.round delay) of the message exchange. Letfa to be the factor to adjustthe chance of collision occurrence.

22

Then the random delay (i.e.random delay) to sendPSY NC REQ should be set as following.

When receiving aNETSY NC BROADCAST from sink node, the random delay will be set torandom delay0:

random delay0 = rand()%(max num ∗ round delay ∗ fa) (3.3)

When overhearingPSY NC REQ from the parent, the random delay will be set torandom 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 nodefailure or isolation. In a WSN, a node can die due to energy exhaustion or other interruption. Nodesalso can be isolated from the network due to the instability of the wireless link. These problems aredescribed 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 requestfrom node at level n-2, i.e. the parent’s parent, and thus update its hopcount to be n-1. But theproblem is that this is just an occasional event and the node may never be able to overhear fromthat 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 toget timesync request again. As a result this node will be isolated from the time synchronizationprocess.

We can reduce the happening of this situation according to the signal strength of the timesyncpacket. To reduce the occurrence of this situation, we can set a threshold value of the signalstrength of the timesync packets. Only if the signal strength of the received timesync packet isgreater than the threshold value, the node will handle this packet. Otherwise, this packet willbe simply discarded. The threshold value of signal strength needs to be set properly to make henetwork running in stable way. But it is hard to get an optimized threshold value because lotsof experiments need to be conducted and analysis depending on the real environment where thenetwork is deployed.

Since there is still a chance for this problem to happen, we can set a timeout period (set bya 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 itscurrent parent for the fixed period. So to be able to accept timesync packet from other nodesand select new parent, the node resets its hopcount and parentID when the timer expired. In thiscase, 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 unexpectedinterference. If this node is at the lowest level, it will not affect the time synchronization atall. But if it is the parent of other nodes, then all its children will be isolated from the networkbecause of no response from the parent node.

23

To solve this problem, the solution of setting a timeout period to avoid node isolation can beused.Each node should check if a timeout period (set by a timer) has passed without any mes-sage from its parent node. If the timer expired, it regards its parent to be dead and will updateits hopcount when getting message from other node. In this case, it might also get the messagefrom nodes at next level or the same level, but according to the rule, it will keep updating itshopcount 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 net-work synchronization period. It should be at least greater than one network synchronizationperiod. In the current implementation, we set the time out period to be five times of networksynchronization period. Since as we observe, if the node did not get synchronized for fivenetwork 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-widesynchronization is shown in Figure C.1.

In the implementation, there are some values, such as the random delay and timeout period, neededto be optimized, but it will need plenty of experiments and complicated analysis of results. So forthe current implementation we choose the feasible values but not necessary optimized. We will testthe network-wide time synchronization in Tmote Sky and present the test result and analysis in laterchapter.

3.3 Low-latency data collection using Treeroute

Treeroute is a routing protocol implemented in Contiki. Currently Treeroute is not implemented inTmote Sky platform, but in some other platforms, i.e., netsim and ESB. But it is easy to port thisprotocol to run in Tmote Sky motes since it is based on the common uIP/UDP layer in Contiki. Weanalyse the protocol design and port it to Tmote Sky platform. Then we implement a demo applicationfor low-latency data collection in a multi-hop network using the Treeroute protocol. In the demoapplication, periodical time synchronization is running among the network so we can measure thelatency for each data packet arrived based on the global synchronized clocks between different nodesin 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 tothe sink node (i.e., the data aggregator). Since Treeroute provides the routing path from a sensor nodeto the sink node, we can use it for data collection between the sink node and the sensor nodes not inthe single-hop coverage.

The routing protocol is based on the Trickle [22] flooding protocol, originally intended for codepropagation in sensor networks. Once one node is set as the sink, it will send the trickle routingbroadcast with hopcount 0. When a neighboring node receives this broadcast it will check if its hop-count is equal to 1. If not, it will update its neighbor table and change its hopcount to be 1. Then it

24

will wait a random delay and send a new routing broadcast with its hopcount to inform the neighbor-ing node in next level to update their hopcount and neighbor table. This process will run until all thenodes 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 levelor from the children in next level, it might also add these nodes into its neighbor table if the neighbortable 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 tableof all its neighbors with good connectivity.

Sensed data will be sent from the sensor node to the sink along the routing path derived from theneighbor table in each node. Data packets will be forwarded to the best neighbor, i.e., the neighbornode with highest signal strength of the ones that have the lowest hopcount. To maintain a reliablecommunication, retransmissions with a maximum limit will be carried out if an implicit ACK is notreceived at a fixed period. An implicit ACK means the packet forwarded by the receiver. That is, ifthe sender finds out that the same packet is forwarded by the receiver, it means the packet has beenreceived 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 toreduce the collision between different nodes, thus reducing contention time and the number of re-transmissions. 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 thusavoid collision with other nodes. With the scheduled slots, the data delivery will be more reliable andfast.

In our data collection protocol, slot assignment is done according to the time schedule for differentnodes. We divide one second to be 16 slot periods. Then we assign one slot to each node accordingto its nodeid (the unique identifier of the node). After getting synchronization, the sensor nodes willstart to send the data packets in its slot every second. If we need more than 16 slots per second, wecan make the slot period shorter but we need to guarantee that it can tolerate the sync error and thetime 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 syn-chronization 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-hoplatency in the experiment will be conducted.

25

Chapter 4

Security analysis and design for thereal-time services

In this chapter, we analyse the security goals for the real-time services, identify the attacks and presentthe countermeasures to resist the identified attacks with the security services we implemented forTmote Sky platform.

4.1 Security for time synchronization

To analysis the security issues in a time synchronization service, we should first find out the mainsecurity 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 toget the correct time offset for the clock correction.

2. Prevention of nodes from synchronizing to a malicious node. This is to guarantee the sensornodes synchronize themselves only to the legal nodes in the network.

Recalling the security challenges and considerations in a WSN, to achieve the security goals, wecan look at the possible attack scenarios and then find out how to counter these attacks.

Attack scenarios

a. Modification of timestampsAn adversary can simply modify the values of the timestamps which are included in sync pack-ets.

b. Pulse-delay attackAs described in [17], this attack can be done by simply jamming the initial pulse, storing inits memory and then replaying it at a arbitrary time later. By manipulating the pulse-delay, anadversary can arbitrarily change the computed time offset.

c. Replay attackAn adversary can capture a packet and replay it at a later time. The old packet with an oldtimestamp will lead to a wrong computed offset.

26

d. Compromised nodesAs we mentioned in Chapter 2, compromised nodes attacks are common for a wireless sensornetwork without physical security. An adversary can manipulate the compromised node to sendfalse data. It can lie about its level, pretending to be the sink node with level 0, or the parent ofother nodes in level n. It can also act as a man in the middle to delay or modify the timestampsin the sync packets.

Countermeasures with the security servicesBased on the attack scenarios, we present the countermeasures to secure the time synchronization

using CC2420 security services we have implemented in Contiki OS.

a. ModificationThis 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 keyis shared between the sender and receiver for the authentication.

b. Pulse-delay attackAny delay attacks which lead to delayed timestamping can be detected by setting a thresholdvalue according to the estimated maximum one-way transmission delay. A one-way transmis-sion delay includes transmission processing time, media access time, propagation delay, andreceiving processing time. A node will calculate the round-trip delay in a pairwise synchro-nization. If the delay exceeds the threshold value, it will discard the packet.

c. Replay attackReplay attack can be detected by the authenticated timestamp or the sequence number. A nodewill maintain the value of last timestamp or sequence number from its parent. When it receivesa broadcast from its parent, it will check if it is an old message. If so, it will regard it as a replaymessage and just simply discard it.

d. Compromised nodesResisting attacks from compromised nodes goes beyond the scope of cryptographic methods.Although using tamper-resistant hardware can help protect those secrets, it is still impracticalfor sensor networks. There are some researches on how to resist attacks from compromisednodes. A location-based approach, where the secret keys are bound to geographic locations ofthe sensor nodes, is proposed in [19]. But it needs locations information of all nodes in thenetwork 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 differentnodes is proposed in [1]. Both the location-based service support and the obfuscation methodsare not in the place in our system. Currently we do not consider compromised nodes in theprotocol 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

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 isconfidential, 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 sensornode shares a secret key with the sink.

The latency for data collection using Treeroute depends on the hopcount of sender as well as thenumber of retransmission. An adversary might arbitrarily delay the data packets, but the retransmis-sion 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 thedata. 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 shouldnot be reported repeatedly to trigger a false alarm. So sequence numbers can be used in each packetfor each sensor node. The sink node needs to keep track of the last sequence number of data fromeach node. When the replayed packet is received, the sink node will discard it. As an alternative, theauthenticated timestamp can be also used to ensure the data freshness.

28

Chapter 5

Experimental results and performanceevaluation

This chapter describes the experiments to test the protocols and gives the test results. Then a perfor-mance evaluation will be conducted to the protocols respectively.

The development environment is Linux(Fedora Core 3). Contiki kernel along with the service codeis compiled and programmed into Tmote Sky. The version of the compiler is msp430-gcc3.2.3. TheContiki 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 networkget synchronized for the networks with dynamic topology. Experiments will be conducted with andwithout security, respectively. And the protocol will be running in a single-hop network as wellas multi-hop network. The clock setting in Contiki is: CLOCKSECOND = 512. The oscillatorfrequency is 32768Hz. So the INTERVAL is set to be 32768/CLOCKSECOND = 64. So one tickrepresents 64 oscillation periods.

5.1.1 Experiments and test results

In this section, we conduct the experiments to test the time synchronization protocol and give theexperimental results. The synchronization precision will be measured in ticks. According to the clocksetting for the experiments, tick frequency (i.e., CLOCKSECOND) is set to be 512. So one tick isequal 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 synchronizationwill not be protected. Eleven nodes will be deployed for the experiments, respectively, running in asingle-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 thenetwork-wide time synchronization. The remaining ten nodes will synchronize themselves to the sink

29

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(PSYNCREQ)in different time to avoid the collision after they get the NETSYNCBROADCAST message fromthe sink at the same time. So a random delay is used for the neighboring nodes to send the re-quest at a different time. As we discussed before, we set the random delay as:random delay =max num∗ round delay ∗fa. In this experiment, letmax num to be 10,round delay to be 6, andfa 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 nodegets a button press event, it will set itself to be the sink node and send the NETSYNCBROADCASTmessage to initiate the synchronization. All the other nodes in the neighborhood will get the messageat the same time. They will wait a random delay and then send the request to the sink to proceed witha pairwise synchronization with the parent node. Due to the lack of USB connections to monitoringterminals, we collect the test data for only the sink node and three neighboring nodes out of the tennodes. Each node is designated a short address, which can be derived from its IP address. For thenode with IP address 172.16.0.1, 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 startsynchronization with the sink node. In our test, we record the test results for 50 periodical synchro-nizations. 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 syn-chronization 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

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% ofrequests 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 nodeto the place 3 hops away from the three monitored nodes, and put the other nodes in the middle tobridge the communication between the monitored nodes and the sink node. The topology is shown inFigure 5.3.

Similarly, we record the test results in the three nodes (0x0100, 0x0200 and 0d00) in level 3 for 50rounds of periodical synchronization and analyse the synchronization error between these three nodesand 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 synchronizationwith average synchronization error of 1.1 ticks. The average synchronization error is lower than thatof the previous test in a single-hop network. It is reasonable since only three nodes in the sameneighborhood synchronizing to the same parent. But in the single-hop network, ten neighboringnodes are synchronizing to the parent, i.e., the sink node. Thus the chance of collision between theneighboring 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 timesynchronization process will not be protected. The same network topology as above will be config-ured 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 thetimestamps for synchronization from illegal modification. We do not use the encryption mode becausewe are not concerned if the timestamps are captured by an adversary but concerned if the timestampsare changed in transit. The MAC-layer security operation is transparent to the protocol, but it candetect the modification of data packet and discard the packet if the packet does not pass the MICcheck.

Single-hop networks For a single-hop network running with security, we record 50 rounds of peri-odical synchronization for three nodes synchronizing with the sink node.

31

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 monitorednodes to form a multi-hop network running with security, we record 50 rounds of periodical syn-chronization for the three nodes synchronizing with its parent node (0x0c00). These three nodes arelocated in level 3 (i.e., 3 hops away from the sink node). The statistics of the test result is shown inFigure 5.6.

According to the test result, in the monitoring period, these three nodes achieve synchronizationto its parent with average synchronization error of 1.0 ticks.

According to the above test results, the time synchronization protocol we design can achieve network-wide 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 timefor security operation on a fixed length of synchronization packet should be deterministic, so as wecan see the synchronization error is not affected obviously by the MAC-layer security operation.

32

Figure 5.4: Synchronization result in a multi-hop network without security

Figure 5.5: Synchronization result in a single-hop network with security

5.1.2 Synchronization error analysis and performance evaluation

First we analyse sources of synchronization error in our protocol design and then give an evaluationon the performance metrics we mentioned before.

Synchronization error analysis According to the source of synchronization error, we analysis howmost of the sources of error are eliminated in our protocol design while some uncertainties are inherentin the current system and thus can not removed.

a. Drift & skewThe inherent skew and the drift among the crystal based clocks of sensor nodes can lead to largeclock deviation. Hence, even if we synchronize the whole network once, nodes will still go outof sync in a few minutes. In our protocol, periodical resynchronization is needed to compensatethe skew and drift.

b. Uncertainty in time-critical pathAs we discussed before, the synchronization error comes from the uncertainty of the following

33

Figure 5.6: Synchronization result in a multi-hop network with security

delay factors: send time, media access time, transmission time, radio propagation time, recep-tion time and receive time.

Since we timestamp the sending time of a packet in the MAC layer, the send time is excluded inthe time-critical path. Media access time uncertainty due to the competition-based mechanismin CC2420 contributes to the major source of synchronization error. To get the same trans-mission time for the message exchange in a pairwise synchronization, we construct the twomessage with the same packet length. Radio propagation time is negligible with normally lessthan 100 meters of coverage for a wireless sensor. Reception time for the packets with the samelength is deterministic in nature. Receive time in our implementation means the UDP receivingtime, which is also deterministic in Contiki OS.

Communication overhead In our protocol, communication overhead in terms of transmitted pack-ets is linear to the network size, i.e., the number of nodes in the network. One network synchronizationprocess with n nodes (the sink node excluded) needs only one broadcast message from the sink nodeand n message exchanges, a message exchange for a pairwise time synchronization. Compared toTPSN, at least n flooding broadcast messages need to be sent among the whole network to form thehierarchical 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 ex-isted nodes. As we observe in the experiments, the protocol can be easily adapted to the change of thenetwork topology. Addition of a new node can be easily associated with the network and synchronizeitself to its neighboring node with the lowest level. When we remove some nodes from the networkor change their positions, the active nodes who lost the original parent will seek to synchronize to thenew parent in its coverage. TPSN does not support the dynamic network since it needs to conduct anew phase of network flooding to adapt to a new network topology. It is not practical to redo a networkflooding frequently to form a hierarchical tree since it consumes a lot of communication bandwidthand CPU cycle.

Computational complexity As TPSN, our protocol is computationally less expensive when com-pared to RBS. But it is computationally more expensive than DMTS since DMTS trades synchroniza-

34

tion accuracy for low computational complexity.

Resilience to security attacks: With the authenticated timestamps, our protocol is resilient to a setof 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 sentbetween sensor nodes and sink node in the network. The network experiment for test is shown inFigure 5.7.

Figure 5.7: Network model for data collection test

We need to assign the slot for each nodes according to thenodeid which is unique and derivedfrom 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 withslots from 7 to 12, respectively.

Figure 5.8: Slot schedule of one second

35

5.2.1 Experiments and results

We run the demo application with time synchronization providing a global clock and Treeroute pro-viding multi-hop routing. After a sensor node gets synchronized with the network, it will start to senda 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 packetsfrom both one-hop nodes and two-hop nodes. Then we make statistics on the one-hop latency as wellas on the two-hop latency.

Figure 5.9 shows the statistics of latency in data delivery from one-hop nodes. The average end-to-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 averageend-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 thesource node to the sink increasing. One-hop latency is maintained to be around 5 to 6 ticks, while two-hop latency is around 10 to 11 ticks. The latency is stable so we can conclude that the sensor nodes are

36

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 thenodes i the network to send sensed data to the sink. There should be a reserved period between twosuccessive slots to prevent the overlapped time due to synchronization error.

37

Chapter 6

Conclusion and future work

6.1 Conclusion

In this thesis, we design and implement the two real-time services in Contiki, time synchronizationand low-latency data collection. To make the services resilient to the security attacks, the MAC-layersecurity services based on hardware-supported AES-128 security operations are implemented and in-tegrated with the MAC protocol. We conduct security analyses for the protocol design and proposecorresponding countermeasures with the support of the implemented security services.

To show the feasibility and performance, we test the time synchronization both with and withoutsecurity protection running a network with more than ten sensor nodes. In the experiments both withand without security enabled, we show that the time synchronization protocol works with synchro-nization 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 determinis-tic and thus the synchronization precision is not degraded by the security operations. We conduct aperformance analysis on the time synchronization protocol design to highlight its advantages in lowcommunication overhead, mobility and dynamic topology support and the resilience to security at-tacks.

We achieve low-latency and reliable data collection by the schedule-based communication based onthe time synchronization and Treeroute routing protocol. The Treeroute routing is ported to TmoteSky to provide the multi-hop routing. An experiment for a two-hop network shows we can achieveone-hop latency of about 5 to 6 ticks while two-hop latency of about 10 to 11 ticks. The fluctuation isreasonable 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 appli-cation. 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 canbe running at the backend of a sensor node, transparent to the application-writer. In the real-time ser-vices 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

we should can get more empiristic data through extensive experiments to find the appropriate values.Whenwe have a good simulation environment, theoretical analysis for optimization can be done withthe simulations.

For the security services, there are no key distribution protocols and security service layer existingin the current Contiki. To support the security-sensitive protocols and applications, a security layerand 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. se-cure exchange of the secret keys between different sensor nodes. With more and more securityconcerns in a sensor networks, secure channel might be needed for secure association of sensornodes with the network. Instead of using the preshared key, an efficient public key technique canbe used for secure key distribution for sensor networks. ECC is an emerging technique whichis more efficient and computationally feasible for resource-constrained systems. There are al-ready some implementations and evaluations of ECC for the popular sensor platforms, such asMICA2, MICAz and TelosB etc [3, 23]. More research should be made on the improvementand verification of the use of ECC for sensor networks.

b. Software-based security services in Contiki OSMost of the sensor platforms (i.e. motes) do not support hardware implementation for secu-rity crypto acceleration. So there is a need to support the software implementation of securityfor those motes without hardware-assisted security. A security layer should be implemented inContiki OS to provide the basic security services, including encryption/decryption and authen-tication. A suitable key management scheme is also needed to support both hardware-based andsoftware-based security.

39

Acknowledgments

First I would like to thank my supervisors, Thiemo Voigt, Adam Dunkels, Prof. Mikael Johansson fortheir 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 duringthe entire time I have worked on this thesis. Special thanks to Bj¨orn Gronvall, Zhitao He, Fredrikosterlind 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 mystudy.

40

Bibliography

[1] Wenliang Du Abdulrahman Alarifi. Diversify sensor nodes to improve resilience against node compro-mise.Proceedings of the fourth ACM workshop on Security of ad hoc and sensor networks, 2006.

[2] A.D. Kshemkalyani B. Sundararaman, U. Buy. Clock synchronization for wireless sensor networks: Asurvey.Ad-hoc Networks, May 2005.

[3] M. Smith D. Malan, M. Welsh. A public-key infrastructure for key distribution in tinyos based on ellipticcurve cryptography. InIn First IEEE International Conference on Sensor and Ad Hoc Communicationsand Network, Santa Clara, California, October 2004.

[4] A. Dunkels. Protothreads web site. Web page. Visited 2005-10-14.http://www.sics.se/˜adam/pt/

[5] A. Dunkels. The Contiki Operating System. Web page. Visited 2005-03-18.http://www.sics.se/˜adam/contiki/

[6] A. Dunkels. Full TCP/IP for 8-bit architectures. InProceedings of The First International Conference onMobile Systems, Applications, and Services (MOBISYS ‘03), May 2003.

[7] A. Dunkels, B. Gronvall, and T. Voigt. Contiki - a lightweight and flexible operating system for tinynetworked sensors. InProceedings of the First IEEE Workshop on Embedded Networked Sensors, Tampa,Florida, USA, November 2004.

[8] A. Dunkels and O. Schmidt. Protothreads – Lightweight Stackless Threads in C. Technical ReportT2005:05, Swedish Institute of Computer Science.

[9] A. Dunkels, O. Schmidt, and T. Voigt. Using protothreads for sensor node programming. InProc. of theWorkshop on Real-World Wireless Sensor Networks (REALWSN’05), Stockholm, Sweden, June 2005.

[10] A. Dunkels, T. Voigt, and J. Alonso. Making TCP/IP Viable for Wireless Sensor Networks. InProc.EWSN’04 work-in-progress session, January 2004.

[11] A. Dunkels, T. Voigt, J. Alonso, H. Ritter, and J. Schiller. Connecting Wireless Sensornets with TCP/IPNetworks. InWWIC2004, February 2004.

[12] Girod L. Estrin D. Elson, J. Fine-grained network time synchronization using reference broadcasts. InInProceedings of the Fifth Symposium on Operating Systems Design and Implementation (OSDI), Boston,MA, December 2002.

[13] NIST FIPS. Advanced encryption standard (aes). Web page. Visited 2006-12-07.http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf

[14] Cauligi S. Raghavendra G. Lu, B. Krishnamachari. An adaptive energy-efficient and low-latency mac fordata gathering in sensor networks. InIn Int. Workshop on Algorithms for Wireless, Mobile, Ad Hoc andSensor Networks (WMAN), Santa Fe, NM, April 2004.

[15] R. Szewczyk D. Culler etc. G. Tolle, J. Polastre. A macroscope in the redwoods. InSenSys, pages 51–63,2005.

41

[16] Kumar R. Srivastava M. B. Ganeriwal, S. Timing-sync protocol for sensor networks. InIn Proceed-ings of the First ACM Conference on Embedded Networked Sensor Systems (SenSys), Los Angeles, CA,November 2003.

[17] S. Ganeriwal, S. Capkun, C. Han, and M. Srivastava. Secure time synchronization service for sensornetworks. InWiSE, September 2005.

[18] S. Ganeriwal, S. Capkun, C. Han, and M. Srivastava. Security for industrial communication systems. InProceedings of the IEEE, June 2005.

[19] Jerry Cheng etc. Hao Yang, Fan Ye. On resiliency to compromised nodes: A case for location basedsecurity in sensor networks.

[20] F. Mattern K. Romer. The design space of wireless sensor networks.IEEE Wireless Communications,11(6):54–61, December 2004.

[21] P. Ning K. Sun and C. Wang. Secure and resilient clock synchronization in wireless sensor networks. InIEEE Journal on Selected Areas in Communications, February 2006.

[22] P. Levis, N. Patel, D. Culler, and S. Shenker. Trickle: A self-regulating algorithm for code propagationand maintenance in wireless sensor networks. InIn First Symposium on Network Systems Design andImplementation (NSDI), March 2004.

[23] A. Liu and P. Ning. Tinyecc: Elliptic curve cryptography for sensor networks. Web page, September2005. Visited 2006-12-28.http://discovery.csc.ncsu.edu/software/TinyECC/

[24] Moteiv. Tmote Sky). Web page. Visited 2006-12-07.http://www.moteiv.com/products-tmotesky.php

[25] David Wagner Naveen Sastry. Security considerations for ieee 802.15.4 networks. Web page. Visited2006-12-07.http://www.cs.berkeley.edu/ daw/papers/

[26] S. Ping. Delay measurement time synchronization for wireless sensor networks. InIntel Research, June2003.

[27] Chipcon product from Texas Instruments. CC2420 Datasheet). Web page. Visited 2006-12-07.http://www.chipcon.com/files/CC2420DataSheet1 3.pdf

[28] K. Romer, 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 andSons, September 2005.

[29] Christian Schumacher. 6lowpan security considerations, November 2005.

[30] IEEE Computer Society. Ieee 802.15.4 spec. Web page. Visited 2006-12-07.http://standards.ieee.org/getieee802/download/802.15.4-2003.pdf

[31] David Wagner. Security for sensor networks: Cryptography and beyond. InACM Workshop on Securityin Ad Hoc and Sensor Networks (SASN’03), October 2003.

42

Appendix A

Glossary

AES: Advanced Encryption StandardCBC: Cipher Block Chaining (CBC) modeCCM: Counter with CBC-MAC modeCTR: Counter modeECC: Elliptic Curve CryptographyMAC: Media Access ControlMIC: Message Integrity Code

43

Appendix B

Program flow of security protocol

Flow of CC2420 security protocol is shown in Figure B.1.

44

Figure B.1: CC2420 secure communication driver flow.

45

Appendix C

Program flow of time synchronizationprotocol

Flow of network-wide synchronization is shown in Figure C.1.

46

Figure C.1: Flow of network-wide synchronization

47