WIRELESS SENSOR NETWORK ARCHITECTURE AND ITS SECURITY CHALLENGES
Dan Khanh Vu
B.S., California State University, Sacramento, 2000
PROJECT
Submitted in partial satisfaction of the requirements for the degree of
MASTER OF SCIENCE in
COMPUTER ENGINEERING at
CALIFORNIA STATE UNIVERSITY, SACRAMENTO
SPRING
2010

© 2010
Dan Khanh Vu
ALL RIGHTS RESERVED ii

WIRELESS SENSOR NETWORK ARCHITECTURE AND ITS SECURITY CHALLENGES
A Project by
Dan Khanh Vu
Approved by:
__________________________________, Committee Chair
Isaac Ghansah, Ph. D.
Approved by:
__________________________________, Second Reader
Jing Pang, Ph. D.
____________________________
Date iii

Student: Dan Vu
I certify that this student has met the requirements for format contained in the University format manual, and that this project is suitable for shelving in the Library and credit is to be awarded for the project.
__________________________, Graduate Coordinator
Suresh Vadhva, Ph. D.
Department of Computer Engineering
___________________
Date iv

Abstract of
WIRELESS SENSOR NETWORK ARCHITECTURE AND ITS SECURITY CHALLENGES by
Dan Vu
Wireless Sensor Devices are becoming a more attractive choice as a sensor platform compared to hardwired sensor devices because of the ease of installation and freedom in sensor placement.
Wireless Sensor Devices are usually installed in mass quantity to form a Wireless Sensor
Network to sense environmental changes, to track movement in battlefield or military zones, and to monitor any desired function in the industrial or commercial setting.
This project is an effort to learn about the security requirements of a Wireless Sensor Network by analyzing the security mechanisms that have been developed through the TinyOS project.
However, certain basic knowledge must be obtained first in order to fully understand the security requirements of a Wireless Sensor Network. Thus, the project starts with an overview of the
Wireless Sensor Devices hardware architecture. Then, the project describes the Wireless Sensor
Devices network stack and its security mechanisms. The Wireless Sensor Network security requirements are introduced along with some common Wireless Sensor Network attacks and their counter measures. Finally, the project describes the software development process for Wireless
Sensor Devices using TinyOS. The results of the project are a procedure for setting up the
TinyOS development environment to program Wireless Sensor Devices to form a Wireless
Sensor Network, and an analysis of Wireless Sensor Network security software suites such as v

IEEE 802.15.4, ZigBee, SPINS (SNEP and uTesla), TinySec, SomeSec, TinyPK, and TinyECC.
______________________, Committee Chair
Isaac Ghansah, Ph. D.
______________________
Date vi

ACKNOWLEDGMENTS
Special thank you to my advisor, Dr. Isaac Ghansah, for guiding me to understand what a Master
Project is, and for guiding me through this project.
Special thank you to Dr. Jing Pang for being the second reviewer of the report. vii

TABLE OF CONTENTS
Page
Acknowledgments..…………………………………………..…………………………………. vii
List of Figures.…….………………………………………...……………………………….……ix
Chapter
1. INTRODUCTION ……………… …..………..………………………………….……………1
2. WIRELESS SENSOR NODE HARDWARE ARCHITECTURE.…………..……………….6
2.1 Crossbow TelosB Wireless Development Kit………….……………………………8
2.2 Texas Instrument eZ430-RF2500 Wireless Development Kit………………………9
3. WIRELESS SENSOR NODE NETWORK STACK…………………………….…………..11
3.1 IEEE 802.15.4 Specification……....………………………………………………..15
3.2 ZigBee Specification……...……………………………………………………...…22
3.3 ROLL and 6LoWPAN……………………………………………………...………24
4. TINYOS SOFTWARE DEVELOPMENT METHOD AND EXPERIMENT..…….……….25
5. TINYOS’S SECURITY MECHANISMS…………………………………………….……..35
6. CONCLUSION………………………………………………………………………………42
References……………………………………………………………………………………..….44 viii

5.
6.
7.
8.
9.
LIST OF FIGURES
Page
1. Figure 1: Hardware Block Diagram of a Wireless Sensor Device.…………………..7
2. Figure 2: TelosB Wireless Development Kit..…………………………………….....8
3.
4.
Figure 3: eZ430-RF2500 Wireless Development Kit...…………...………………..10
Figure 4: Point-to-Point and Star Network Topologies………….………………….12
Figure 5: A sample WSN……..……………………………….…….………………13
Figure 6: Simple Network Stack……………..…………………………….………...15
Figure 7: ZigBee Network Stack………………….…....…………………………....23
Figure 8: Experiment – A simple star network………………...……………………30
Figure 9: Experiment – A simple multihop network.….…….…….…..…………….31
10. Figure 10: Experiment – A simple multihop network #2...….…...………………….32
11. Figure 11: Screenshot of Java program……………………………………………...33 ix

Chapter 1
INTRODUCTION
1
Wireless Sensor Network (WSN) is a low-powered wireless network formed by inexpensive devices that are battery-powered with limited computing resources. A WSN consists of many
Wireless Sensor Devices (WSD) that are deployed in the field to sense physical phenomena such as humidity, temperature, vibration, light, etc… The Wireless Sensor Devices would form pointto-point low-powered wireless links to each other as specified by the IEEE 802.15.4 protocol for communication. Low-powered wireless link has a limited transmission range. Therefore, the
Wireless Sensor Devices have to support multihop routing to send the sensor data from one node through another to arrive at the final destination, usually a server, for data processing.
The challenges that Wireless Sensor Devices have to overcome to become useful have always been the WSD’s lack of a permanent source of power and the WSD’s limited computing resources. However, recent technological advances are making Wireless Sensor Networks
(WSNs) becoming a reality [1]. The first technological advance is the growth of the semiconductor technology, which is continuing to increase the number of transistors on a chip.
The number of transistors on a cost-effective chip doubles every year or two, following Moore’s law. The increase in the number of transistors on a chip makes the circuit in the chip more powerful to perform more computations. The second technological advance is the increase in battery capacity and power reduction techniques. More battery capacity and advanced power reduction techniques for electrical circuit both increase the WSN lifetime so that the WSN can be functional for a longer time to perform useful work. The last technological advance is the

2
System-on-a-Chip (SoC) integration technology. SoC technology enables the integration of all the WSD’s required components such as sensors, microcontroller, RAM, ROM, and wireless interface at a small scale and still be power efficient.
The technological advances mentioned above are helping Wireless Sensor Devices (WSD) to become more practical for everyday use because of the lower prices and increased lifetime.
Wireless Sensor Devices’s ease of installation and freedom of placement are also helping WSD to become a more attractive choice as a sensor platform than hard-wired sensors. Wireless Sensor
Devices can be installed in places that are very difficult for hard-wired devices to be installed at because there are no wires to run. Thus, this is enabling many more applications to use the
Wireless Sensor Devices than ever before. Wireless Sensor Networks can be formed to monitor environmental changes such as climate monitoring, seismic detection, and pollution tracking [2].
WSNs can be formed in the medical field to monitor changes in patients such as heart rate, and pulse rate [2]. WSNs can be formed in the military for surveillance, for communication, to track troop movement, and to detect hazardous agents such as nuclear, biological, and radioactive [2].
WSNs can also be formed in urban setting for civic duties such as traffic monitoring, in industrial usage such as product inventory, and in residential usage such as home security [2].
Since Wireless Sensor Network can be used in many critical applications as stated, the data being transmitted must be secured to prevent data security issues that can cause serious consequences such as eavesdropping, data manipulation, and denial of service, etc... In short, the critical

3
Wireless Sensor Network data should be protected just as critical communication network data with the data confidentiality, data integrity, data authentication, resource availability, and data freshness principles. All of these principles are going to be discussed later on in the project as background material.
There are many research papers about Wireless Sensor Network security. However, most of these papers assume that the readers have a certain level of knowledge to understand the topics.
Additionally, these papers typically only cover the software side of Wireless Sensor Network and rarely provide the whole picture of both the hardware and software aspects of Wireless Sensor
Network. TinyOS has been the software development platform for many security suites, but there has not been an analysis of how these security suites relate to each other in terms of strengths and weaknesses.
This project has two purposes. The first purpose is to provide a thorough understanding of the
Wireless Sensor Network in hardware, firmware, and software architecture. The Wireless Sensor
Devices hardware architecture needs to be studied to see how firmware and software for Wireless
Sensor Devices are designed, and to understand about the hardware limitations that the Wireless
Sensor Devices’s firmware and software have to cope with. The project examines the Crossbow
TelosB and Texas Instrument eZ430-RF2500 Wireless Sensor Development kits to study the hardware architecture. Then, the Crossbow TelosB kits are programmed using TinyOS platform to form a Wireless Sensor Network to understand the firmware and software development

4 process. The TinyOS framework is developed at U.C Berkeley to enable researchers to have a common software development on supported hardware platforms to facilitate the research and development of security software suites for Wireless Sensor Network. The TinyOS framework is going to be discussed in more detail later.
The second objective of the project is to analyze the security features that have been implemented through the TinyOS project with respect to limitations of Wireless Sensor Devices and Wireless
Sensor Network. The first limitation is the Wireless Sensor Network’s over the air transmission that can be captured by anyone. The second limitation is the Wireless Sensor Devices’s lack of a permanent power source, which means that the security algorithm must be very efficient to conserve the depletable battery source. The second objective begins with providing an overview of the Wireless Sensor Devices network stack. Industry standard protocols such as IEEE
802.15.4 and ZigBee are discussed with special emphasis on their security features. The project also list Wireless Sensor Network security requirements, and some common Wireless Sensor
Network attacks and their counter measures. Lastly, the project presents an analysis of the
TinyOS’s developed security features through SPINS (SNEP and uTesla), TinySec, SomeSec,
TinyPK, and TinyECC.
The organization of the rest of the project report is as follows. Chapter 2 presents an overview of the Wireless Sensor Node hardware architecture. Chapter 3 presents an overview of the WSN network stack and its security features. Chapter 4 reports the procedure to setup the TinyOS

5 development environment to program Wireless Sensor Devices to form a Wireless Sensor
Network. Chapter 4 also reports an experiment with a functional Wireless Sensor Network to see how network formation is performed. Chapter 5 lists the Wireless Sensor Network security requirements, attacks against WSN and their counter measures. Chapter 5 also presents an analysis of the progression of the TinyOS’s security features. Chapter 6 provides the conclusion of the project.

Chapter 2
WIRELESS SENSOR NODE HARDWARE ARCHITECTURE
6
In general, a Wireless Sensor Device has five main building blocks all residing on the same
Printed Circuit Board. The first building block contains a low power microprocessor and a limited amount of RAM (for runtime memory), and ROM (for code space). The second building block contains the sensors (light, humidity, vibration, motion, etc…). The sensors are connected to I/O pins on the microcontroller, and the sensors would send the sensor data to the microcontroller at some pre-programmed time interval. The third building block has a lowpowered radio chip to transmit data from the mote (used to refer to a Wireless Sensor Device) using multihop routing back to the central server to be processed. The fourth building block is a battery to provide power for the entire board. The fifth building block is a user I/O block to provide a limited debug interface for programmers. The debug interface usually has a few push buttons to send input in to the microcontroller, and a few LEDs for visual outputs. See Figure 1 for a block diagram of the Wireless Sensor Device hardware architecture.

Power Block
(for the entire board – usually is a battery)
7
ROM
(for code storage)
Sensors
(light, humidity, temperature, etc…)
Low Powered CPU
RAM
(for runtime memory)
Radio Interface
(transmit and receive data over the air)
Push Buttons
(for test inputs) LEDS
(for test outputs)
Figure 1: Hardware Block Diagram of a Wireless Sensor Device
Companies such as Crossbow, Dust, Ember, Millennial Net, Moteiv, Sensicast, Texas Instrument, and Sensoria are marketing Sensor Network Devices hardware [25]. This project uses two different wireless sensor platforms from Crosswbow and Texas Instrument to conduct the study.

8
The first platform is the TelosB from Crossbow Technology (see Figure 2,) the second platform is the eZ430-RF2500 from Texas Instrument (see Figure 3.)
2.1 Crossbow TelosB Wireless Development Kit
Figure 2 - TelosB Wireless Development Kit
Figure 2 above is a picture of the TelosB Wireless Development Kit from Crossbow Technology
[36]. It is available in two versions: one with an integrated sensor suite, and one without the integrated sensor suite. The model number for the kit with the integrated sensor suite is
TPR2420CA [34]. The model number for the kit without the integrated sensor suite is
TPR2400CA from Crossbow Technology [34]. The TPR2420CA has light, humidity, and temperature sensors while the TPR2400CA does not have any sensors. Both the TPR2420CA and the TPR2400CA have the 8 MHz Texas Instrument MSP430 Microcontroller with 10K RAM and 48K Program Flash Memory [36]. Both models use the Texas Instrument CC2420 radio chip, which is IEEE 802.15.4 compliant (IEEE 802.15.4 protocol is going to be covered in

9
Chapter 3.) There are two methods for the mote to receiver power. The mote can receive power through the USB interface if the mote is plugged in to a computer’s USB port. There is also a battery housing on the mote for two AA batteries to provide power to the mote if it is not connected to the USB port. There are also a red LED, and a blue LED along with a push button to send an interrupt to the microprocessor for programmers debug purposes.
2.2 Texas Instrument eZ430-RF2500 Wireless Development Kit:
Figure 3 [19] is a picture of the eZ430-RF2500 Wireless Development Kit from Texas Instrument
[33]. The kit also uses the Texas Instrument MSP430 as the microprocessor. However, this kit only has 1K RAM, and 32K Program Flash compares to 10K RAM and 48K Program Flash that the Crossbow TelosB has. The limited 1K RAM of the eZ430-RF2500 means that the running code cannot use more than 1K RAM of memory. The 32K Program Flash on the eZ430-RF2500 also limits the code size that can be written for the board. The eZ430-RF2500 only has one sensor: temperature. The other three building blocks (power, radio chip, and debug interface) are the same as that of the TelosB. There is a cost advantage to the eZ430-RF2500 because the kit offers two motes: one is powered by the USB interface, and the other one is powered by two AA batteries.

10
Figure 3 - eZ430-RF2500 Wireless Development Kit

11
Chapter 3
WIRELESS SENSOR NODE NETWORK STACK
Wireless Sensor Devices communicate by using a multihop routing algorithm that transmits data from the source node to the end node through many intermediate nodes. Each of the devices has the routing capability built-in to forward the data to the end node. There are two basic topologies that can be formed by the Wireless Sensor Devices: point-to-point and star (please see Figure 4
[4].) In a point-to-point topology, each device would form a link to its neighbor devices. In the star topology, all devices in a local network would form a point-to-point link to a leader device.
All outbound and inbound communication from that ‘star’ group would go through that leader device. Then, each of the leader devices of the local star network would form a point-to-point link to another leader node in a different local network to transfer data between the different networks. A typical Wireless Sensor Network would consist of both types of network topologies with the star topology as the local network. Please see Figure 5 [4] for a sample Wireless Sensor
Network topology.

12
Figure 4: Point-to-Point and Star Network Topologies
There are three types of devices in Figure 4 to make up either a Star Topology or a Point-to-Point
Topology. The first device is the Reduced Function Device (RFD.) It is the simplest device out of the three devices. Its main function usually is to sense some data, and then to send that data to a Full Function Device (FFD.) A FFD has more features built in to route data, to support more security features, etc... A FFD can also become a PAN (Personal Area Network) coordinator.
There is only one PAN coordinator per network. The PAN coordinator controls the entire network. A RFD can only talk to another RFD, while a FFD can talk to a RFD or to other FFDs.
A FFD usually is more powerful and has more battery power than a RFD to support the extra capabilities.

FFD
FFD
RFD
RFD
FFD RFD
RFD RFD
Figure 5: A sample WSN network with both star and point-to-point topology
13

14
In Figure 5, the hexagon-shaped or yellow-colored devices are the Reduced Function Devices.
The square-shaped or blue-colored devices are the Full Function Devices. Figure 5 shows how both the star and point-to-point topologies make up a Wireless Sensor Network.
Figure 6 [5] is a simple network stack of two wireless sensor devices. The radio layer provides the radio hardware to communicate over the wireless medium. The HAL (Hardware Abstraction
Layer) provides the mechanism for the PHY layer to talk to the various radio chips in the radio layer. The radio layer and the HAL layer are hardware manufacturer specific and are created to communicate to the PHY layer. The PHY layer and the MAC layer are based on the IEEE
802.15.4 protocol. Finally, the Application and Network layers sit on top of the PHY and MAC layers to provide functions and capabilities that the PHY and MAC layers cannot provide such as multihop routing, and security. There are two network layers: ZigBee [6], and ROLL [7, 8, 37]
(Routing Over Low Powered and Lossy Network) in conjunction with 6LoWPAN [7, 8, 37].
This chapter continues to discuss IEEE 802.15.4, ZigBee, and their security features. This chapter also provides a quick description of ROLL and 6LoWPAN. More detail about ROLL and
6LoWPAN can be found in the citations [7, 8, 37].

15
Figure 6 - Simple Network Stack
3.1 IEEE 802.15.4 Specification Overview:
IEEE 802.15.4 [9] is a simple, short-range wireless communication protocol for low-cost devices with limited power and relaxed throughput requirements. The protocol supports four over the air transmission rate of 250 kb/s, 100 kb/s, 40 kb/s, and 20 kb/s. The devices can operate in any of the four speed based on the signal strength between each other. The stronger the signal strength,

16 the faster the devices can transmit data. The protocol supports star and point-to-point network topologies as seen in Figures 4 and 5. The protocol can operate in sixteen channels in the 2400 to
2483.5 MHz band for worldwide use, thirty channels in the 902 to 928 MHz band for North
America use, and one channel in the 868 to 868.6 MHz band in Europe. The devices have to pick a free channel to use to avoid contention. Channel contention or noise can lead to poor link quality and decreased throughput transmission rate. The protocol also supports receiver acknowledgement for reliable data transfer. This means that anytime a receiver (device A) receives a packet from the sender (device B); device A also sends back to device B an
‘acknowledgement’ packet to indicate that device A has received the packet from device B. The protocol also supports Link quality indication (LQI) to indicate the strength of the link between the two devices. LQI is used to determine the signal strength to determine if there is channel contention and transmission throughput. The protocol provides two methods for wireless devices to gain access to the shared wireless channel to send data: carrier sense multiple access with collision avoidance (CSMA-CA), and guaranteed time slots (GTSs). In a CSMA-CA scheme, a device that wishes to transmit data must first have to listen to the channel for a set amount of time to check for activity on the channel. Once the channel is sensed as free, the device sends a signal to tell other devices not to transmit, and then the device can send its packet. This means that devices must compete with each other to send data. Therefore, there is no guarantee of timely delivery of critical data. The GTS mode is similar to the TDMA (Time Division Multiplex
Access) time slot allocation in that a packet can be guaranteed to be sent in a given time to the destination. However, only the PAN coordinator can use the GTS mode to send data. All other

17 devices (RFD and FFD) must use CSMA-CA to send data. There are three types of packets in
IEEE 802.15.4: data frame, beacon frame, and acknowledgement frame. The data frame is used for all transfer of data. The beacon frame is only used by the PAN coordinator to transmit special data to other devices within the network. The acknowledgement frame is used to confirm successful data frame reception.
IEEE 802.15.4 defines behavior for the PHY and MAC layers. The PHY layer of IEEE 802.15.4 is responsible for activation and deactivation of the radio transceiver, Link Quality Indicator
(LQI), channel selection, clear channel assessment (CCA), and transmitting as well as receiving packets from the physical medium. The MAC layer is responsible for beacon management, channel access, GTS management, frame validation, and acknowledged frame delivery. The
MAC layer also provides hooks for implementing application appropriate security mechanisms such as key management, etc… IEEE 802.15.4 Protocol does not define network formation algorithm. Instead, the network layer performs network formation [10.] IEEE 802.15.4 also has been designed for devices with battery as the power source; so, the devices would spend most of its time in ‘sleep’ state, and only wake up occasionally to sample the RF channel to see if there’s a message pending.
IEEE 802.15.4 protocol also has some basic built-in security features in the MAC layer. The security features rely on symmetric cryptography to protect transmitted frames. However, this does not mean that IEEE 802.15.4 security features are enabled by default. The network layer

18 must choose to enable IEEE 802.15.4 security features. The network layer must also provide these services: symmetric key management, device authentication, and data freshness.
Symmetric key management refers to the principle that data are encrypted with a shared key between two devices (device A and device B.) When device A is sending some data to device B, and device A wants to keep device B a secret, then device A would encrypt the data with a ‘key.’
Device B must have this ‘key’ to decrypt the data. The ‘key’ that is needed by device A to encrypt the data, and needed by device B to decrypt the data is referred to as the ‘symmetric key.’
Symmetric key management is how device A keeps the ‘key’ secret and still able to send the
‘key’ to device B to decrypt the data. Unfamiliar readers should research the ‘symmetric key management’ problem on the Internet.
An IEEE 802.15.4 device can be in the following modes: unsecured mode, Access Control List
(ACL) mode, and secured mode. In unsecured mode, the devices operate without any security protection. In ACL mode, a device only receives data frames from other devices that are on the
Access Control List. For example, device A’s ACL has 3 devices: B, C, and D. Therefore, device
A only receives data frames from device B, C, and D. If device E sends data frames to device A, device A can choose to ignore those data frames. There are no other security protections in ACL mode. Therefore, an adversary device can capture data frames to listen to the conversation.
Finally, in the secured mode, an IEEE 802.15.4 device has these extra security features over the
ACL: data encryption using symmetric key, frame integrity, and data freshness. Data encryption is used to keep data secret from other unintended receivers. Data encryption is achieved using

19 symmetric cryptography in IEEE 802.15.4. Frame integrity refers to the ability to protect the data frame from being altered by an adversary. This is usually done with the sender calculating a oneway hash of the data frame, and sending the one-way hash code (called a MIC – Message
Integrity Code in IEEE 802.15.4) along with the frame. The receiver of the data frame would then also calculate the one-way hash (hash result A) of the decrypted data, and then comparing the calculated hash (A) with the MIC that is sent along with the data frame. If hash (A) and MIC are equal, then the data frame is not altered during transmission. Data freshness is usually achieved with inserting an increasing counter into each transmitted data frame. The receiver of the data frames would compare each received data frame’s counter value and make sure that the counter value is increasing. A counter value that is increasing with each data frame means that the received data frames are in order and are not stale data.
As seen from the description above, IEEE 802.15.4 provides a full suite of security at the MAC layer that applications can choose to use. However, IEEE 802.15.4 security mechanisms have the following three vulnerabilities according to Naveen Sastry and David Wagner in Security
Considerations for IEEE 802.15.4 Networks [11]: IV (nonce) management, key management, and insufficient integrity protection.
IV (nonce) management problem essentially is referring to how the confidentiality requirement can be violated in the IEEE 802.15.4 protocol. Confidentiality means keeping information secret from unauthorized parties and is typically achieved with encryption. However, encryption can be

20 weakened if encrypting the same plaintext (normal text) at two different times would generate the same ciphertext (encrypted text.) The attackers can build a dictionary with ‘known ciphertext’ for substitution. Thus, a random variable called ‘nonce’ would be included with each encryption to provide the extra randomness needed to prevent obtaining the same ciphertext from encrypting the same plaintext at two different times. A ‘nonce’ can be implemented by a simple counter that would increase after every sent message. The issue with the nonce is if the node operating in the
AES-CCM-64 mode (encryption with ACL) has the same key for two entries. Each of the entries would have its own nonce state and thus the node can send the first message (0xAA00) to recipient ‘A’ using the nonce of (0x0), the node will then send the other message (0x00BB) to the recipient ‘B’ using the same nonce (0x0) as it starts at 0. The attacker can then ‘xor’ the two ciphertexts to get the ‘xor’ of the plaintext (OxAABB) which breaks the confidentiality requirement.
Key management in IEEE802.15.4 refers to how the encryption key can be managed in the symmetric encryption scheme. There are four common types of symmetric keying models used by Wireless Sensor Devices. They are network shared keying, pair-wise keying, group keying, and hybrid approaches. In the network shared keying model, all devices use the same key to encrypt data. This is simple and easy to implement, but if a node is compromised and its key is stolen, then the entire network is compromised. In the pair-wise keying model, each pair of nodes would have its own key. Thus, security is much more improved, but key management is harder and takes more resources because each node has more keys to store. The group keying

21 model is a combination of both the network shared keying model and the pair-wise keying model.
A single key is shared among a group of set local nodes and is used for all pair-wise key in that group. Outside communication from that group of nodes would have a different pair-wise key.
Thus, the group keying model is a little bit more robust against a stolen key from node capture.
The hybrid keying approaches can use any combination of any of the above three keying models.
Network shared keying model, pair-wise keying model, and group keying model are not well supported by IEEE 802.15.4. Network shared keying is incompatible with replay protection.
Pair-wise keying is only useful if the radio chip designer includes a sufficient number of ACL entries. However, the number of minimum ACL entries is not set by the 802.15.4 specification.
Therefore, it is up to the radio chip designer to decide the number of ACL entries. Lastly, group keying is not workable because the ACL only has room for one destination node per ACL entry.
So, one can attempt to list the same ‘key’ for multiple ACL entries. But, then this will create the nonce management problem that is mentioned earlier.
Lastly, IEEE 802.15.4 does not provide any integrity protection on acknowledgement packets.
This vulnerability can lead to attackers providing false acknowledgement packets in the network to manipulate the sender to keep on resending packets. Eventually, the sender drains all its battery power and is rendered useless in the network. However, IEEE 802.15.4 still provides sound security mechanism if the users avoid the vulnerabilities that are mentioned.

22
3.2 ZigBee Specification Overview:
As seen in the IEEE 802.15.4 specification so far, symmetric key management and multihop algorithm are left for the network layer to perform. ZigBee is a high-level communication standard built on top of IEEE 802.15.4 specification for the PHY and MAC layers. ZigBee defines the network layer and the application layer framework that provide services such as security and multihop routing. ZigBee provides the following security services: key establishment, key transport, frame protection, and device management [12.]
ZigBee has a device in the network allocated to be the Trust Center to handle key establishment and key transport. There are two types of keys in a ZigBee network for two types of communication: a link key for unicast communication between two devices, and a network key for multicast communication from the leader device to the other devices within the local network.
When a new device joins a secured ZigBee network, the new device would query the Trust
Center for the current network key and the link key. The new device could open a secured channel to the Trust Center using a ‘master default key’ that is loaded during production. Then, all communication between the Trust Center and the new device during the key establishment and key transport would be secured. However, if the new device does not have the ‘master default key’ loaded during production, then key transport between the Trust Center and the new device would be unsecured. ZigBee acknowledges the brief moment of vulnerability where the key

23 could be obtained by any listening devices. This vulnerability can lead to a critical security compromise if an untrusted device is listening at this point to obtain the transmitted key [13.]
ZigBee protocol also introduces encryption at the network and application protocol. This allows the upper layers to encrypt their payload before transmitting to the MAC and PHY layers. Figure
7 [14] is a picture of the ZigBee Network Stack.
Figure 7: ZigBee Network Stack

24
As can be seen above, the IEEE 802.15.4 defined PHY and MAC layers are in pink color. The
ZigBee protocol defines the Network layer (NWK), the Application Support Sublayer (APS), and the Application Layer (APL). Each of the NWK and APS layers has its own security management functions. The NWK layer also has the routing management function to handle multihop routing.
3.3 Routing Over Low power and Lossy network (ROLL) and 6LoWPAN:
ROLL is an Internet Engineering Task Force (IETF) work group that focuses on routing issues for Low power and Lossy network. Wireless Sensor Network is considered as a subset of Low power and Lossy network. Currently, ROLL only focuses on using 6LoWPAN, which is IPv6 over IEEE 802.15.4, routing issues. ROLL is still in the process of evaluating and proposing a routing algorithm to be used with IPv6 for Wireless Sensor Network. The ROLL work group is also focusing on researching a security framework for ROLL. Interested readers can read the materials [7, 8, 37] for more details about ROLL and 6LoWPAN.

25
Chapter 4
TINYOS SOFTWARE DEVELOPMENT METHOD AND EXPERIMENT
The previous two chapters provide background materials such as the Wireless Sensor Devices
Hardware Architecture and the Wireless Sensor Node Network Stack that are needed to be understood before attempting to develop firmware or software for Wireless Sensor Devices. This chapter describes the Wireless Sensor Network software development environment. This chapter also reports an experiment with a fully functional Wireless Sensor Network.
A hardware platform is needed before one can develop firmware for that platform. In this case, developing firmware for Wireless Sensor Devices involve knowing the processor family, and the various I/O devices on the Wireless Sensor Development Kits. The Crossbow TelosB and the
Texas Instrument eZ430-RF2500 kits both use the Texas Instrument MSP430 as the microprocessor. So, one could have just read the TI MSP430 microprocessor manual to figure out how to initialize the processors to recognize the RAM, ROM, various sensors, radio chip transceiver, and the LEDs and push buttons. Once that is done, one needs to read the radio chip transceiver manual to figure out how to set up the radio chip transceiver so that it can send and receive packets. Then, one needs to start setting up the processors interrupts to receive data from the sensors. Essentially, one needs to read all the specifications of all the devices on the
Development Kits to figure out how to set the devices up. Then, one may need to write firmware to enable various features in the IEEE 802.15.4 protocol. One also needs to write firmware for

26 the network layer to do routing, to implement security, etc… However, this project is not about writing firmware for a Wireless Sensor Device. So, the project uses Open Source Operating
Systems for Wireless Sensor Devices to program the Crossbow TelosB to set up a Wireless
Sensor Network as fast as possible in order to study the devices in a functional Wireless Sensor
Network. There are several Open Source Operating Systems available to simplify the programming of Wireless Sensor Devices. Some of the more popular ones are: TinyOS [15],
Contiki [16], and FreeRTOS [17]. This project uses TinyOS to program the Crossbow TelosB to provide the researcher with hands-on experience with the hardware and the software.
TinyOS was developed as part of a research project in 2001 at University of California, Berkeley.
TinyOS low-level code (library) is written in C and the main program is written in NesC
(Network Embedded System C.) NesC is developed as part of the TinyOS project to simplify and reduce race conditions that can be exhibited in C parallel programming. TinyOS provides a framework for dealing with extensive concurrency and fine-grained power management, while providing substantial modularity for robustness and application-specific optimization. The
TinyOS framework establishes the rules for constructing reusable components that can support extensive concurrency on limited processing resources. TinyOS has a lightweight event scheduler, where all program execution is performed in tasks that run to completion. Users can learn how to program in NesC language by using the online tutorials offered at http://docs.tinyos.net/index.php/TinyOS_Tutorials [18].

27
The tutorial covers things such as basic overview of TinyOS, the boot-up sequence, radio-radio communication, the TinyOS network stack, TOSSIM (TinyOS simulator), and security features through the CC2240 chip (which is IEEE 802.15.4 compliant.) Users are encouraged to read and follow the tutorial to understand TinyOS. Below is a TinyOS installation guide that is created as part of this project. This is somewhat different from the installation guide on TinyOS website is not well suited to the researcher needs.
1.
Download Ubuntu 8.04 from www.ubuntu.com
2.
Burn ISO from download file onto a CD
3.
Install Ubuntu onto system using Ubuntu CD (may need to install alongside another OS)
4.
Update all software on Ubuntu using the System->Administration->Update Manager
5.
Install Sun Java 6 RunTime from Applications->Add/Remove Software
6.
Add the following to /etc/apt/sources.list:
‘deb http://tinyos.standford.edu/tinyos/dist/ubuntu hardy main’
7.
Execute ‘sudo apt-get update’ at the shell to update the sources.list
8.
Execute ‘sudo apt-get install tinyos’ to install TinyOS
9.
Instruction 8 above may prompt you to select between two versions of TinyOS. Always select the later version. The TinyOS version selected at the time of this guide was 2.1
10.
Wait for installation to complete
11.
Add the following line to your ~/.bashrc or ~/.profile file in your home directory to set up the environment for TinyOS development at login: ‘source /opt/tinyos-2.1.0/tinyos.sh’

28
12.
Inspect ’/opt/tinyos-2.1.0/tinyos.sh’ and make sure the below line exists, if it doesn’t in: exist, add it
‘CLASSPATH=$CLASSPATH:$TOSROOT/support/sdk/java/tinyos.jar/:.’
If there are any questions about the Ubuntu installation procedure, please refer to the Ubuntu installation instruction at: http://www.ubuntu.com/getubuntu/download . Make sure to follow instruction to download and install Ubuntu version 8.04. If there are questions about the installation procedure with TinyOS, please refer to: http://docs.tinyos.net/index.php/Installing_TinyOS_2.1#Twostep_install_on_your_host_OS_with
_Debian_packages
The installation procedure that is provided may need to be modified if some software depot changes, or if there are software dependency errors during the installation process. There are too many errors to list to watch out for. However, the three most important programs that are needed to set up TinyOS are: Ubuntu as the OS, the TinyOS 2.1 software depot, and Java. Once all the needed software are installed and set up correctly, one still may run into C compiler issues, Java issues, and just general Linux issues. One may also run into the actual TinyOS code module issues. Users are encouraged to read about Linux configuration, C compiler installation, and Java installation procedures to correct problems as they appear. Users should join the TinyOS help reflector at http://www.tinyos.net/scoop/special/support#mailing-lists for information and for help as needed.

29
In general, Wireless Sensor Devices would be programmed with firmware so that the devices can detect the desired data with sensors. Then, the devices would send sensor data back through the
WSN to a root mote. The root mote would then provide all the data to a ‘processing program.’
This ‘processing program’ would analyze the data to recommend some actions. In this project, five TelosB motes (Wireless Sensor Devices) are programmed with the MultiHopOscilloscope application from the /opt/tinyos-2.1.0/apps/MultihopOscilloscope directory. One TelosB mote is programmed as the root mote with ID of 500, while the other four motes are programmed as regular devices with ID of 0, 1, 2, and 3. The root mote of ID 500 is connected to the computer through the USB interface. The root mote would receive data through wireless links from the other four motes (ID 0, 1, 2, and 3). The data could be any of the sensors on the TelosB
(humidity, temperature, or light.) The sensor data is then displayed on the computer with the root mote connected through a ‘processing program’. The processing program in this case is written with Java.
Varieties of mote placements were conducted to see how the MultiHop routing algorithm works.
The exact MultiHop algorithm in the program is not known. The algorithm is probably an experimental algorithm that is good enough for a study. The successful criterion is if the Java program on the computer with the root mote connected still displays sensor data from the remote motes. The range of the radio on the TelosB CC2420 radio chip is about 50 meters [19] or roughly 164 feet before the two motes lose communication with each other. However, this range is also significantly affected by the orientation of the board and by the environment [19]. The first experiment involves placing motes ID 0, 1, 2, and 3 at about 40 feet away from the root

30 mote. The five motes form the star network topology in this experiment. The Java programmed shows data from all four motes (ID 0, 1, 2, 3) being received at the root mode. Please see figure 8 below for an illustration of how the links are connected.
0
1
500
2
Simple Network with Root
Node (500) at the Base
(Computer)
Figure 8: Experiment – A simple star network
3

31
The second experiment (see figure 9) shows that mote 0 and mote 1 are placed out of range of the root mote. Thus, mote 0 and mote 1 are using multihop routing to transmit data back to the root mote.
Mote 0 is going through mote 2 to get to the root mote. Mote 1 is going through mote 3 to get to the root mote. The Java program shows data for all four motes (ID 0, 1, 2, 3).
0
2
500
MultiHop Routing with 0 through 2, and 1 through 3
Figure 9: Experiment – A simple multihop network
3
1

32
The last experiment (see figure 10) has mote ID 2 and mote ID 3 closer together along with mote
1 still connected to mote 3, and mote 0 still connected to mote 2. Then, mote 3 is removed from the network to force mote 1 to connect to mote 2 to send data to the root mote. The Java program shows data from mote 0, 1, and 2. .
0
500
2
1
MultiHop Routing with 0 and 1 through 2
Figure 10: Experiment – A simple multihop network #2

33
Figure 11 shows a screenshot of the Java program running on the computer that has mote 500 connected. The Java program is acting as the ‘data processor’ program. For example, this Java program could be analyzing data coming from security sensors inside a house. The Java program could alert the police to go check out the house if the Java program determines that the data from the sensors is indicating that the house has been broken in. In this particular experiment, the Java program is reading all the packets that mote 500 is receiving through the USB port. The Java program then displays the sources of the packets. Look at the top left corner of the screenshot to see the IDs of the motes. This area is considered as the inventory of the motes that mote 500 sees. Mote 1 is represented with gray color. Mote 2 is represented with yellow color. Mote 3 is represented with red color. Mote 500 is represented with white color. If mote 500 is not able to receive data packets from motes, 1, 2, or 3, the Java program would not have included mote 1, 2 and 3 in the inventory list.

34
Figure 11: Screenshot of Java Program showing Mote 1, 2, 3, and 500

35
Chapter 5
TINYOS’S SECURITY MECHANISMS
This chapter discusses the security features that TinyOS has to offer. Some of these features are developed by the TinyOS core team while others are user-developed as part of other projects.
IEEE 802.15.4 does not fall into either camps even though TinyOS is also capable of using the
IEEE 802.15.4 security suite. The TinyOS core team develops SPINS (SNEP and uTesla) [20] and TinySec [21]. The user-developed security features are SomeSec [26] (similar to ZigBee),
TinyPK [25], and TinyECC [30]. This chapter also discusses some basic security goals that a
Wireless Sensor Network needs to have, some of the attacks that can be launched against a WSN, and some of the challenges that a WSN faces in the quest to secure communication. These basics are provided to help the readers better understand the discussion of the TinyOS’s security mechanisms in this chapter.
First, here are the security goals that a WSN aims to achieve: data confidentiality or privacy, data integrity, data authentication, availability, and data freshness [22]. Data confidentiality ensures only authorized parties can access the data. Data integrity ensures only authorized parties can modify the data and the data is not altered during transmission. Data authentication ensures the data is really sent by the claimed sender instead of fabricated by someone else. Availability ensures reliable delivery of data against denial of service attacks. Data freshness ensures the data is current and fresh (i.e., is not replayed by an adversary.)

36
Secondly, here are some of the attacks that could be launched against a WSN: eavesdropping, compromising node, insertion node, and denial of service [22]. Eavesdropping is a passive attack and is easy to do in a wireless medium because an adversary can tap in to that space to monitor transmission between sensor devices to capture the data. Attackers can also capture deployed devices to steal information stored in the devices such as link and network encryption key or other important information that device has. Once the attackers have the encryption key (link and/or network,) they can insert their own node into the network to capture even more data or to launch other attacks against the network. There are also other attacks aimed at disrupting the routing protocol in order to cause denial of service. Denial of service attacks are not mentioned in this report. Interested readers can read about those attacks in Chapter 1 of Security in Sensor
Networks by Yang Xiao [23].
The attacks against WSN could also be categorized against the Wireless Sensor Devices’s network stack [22]. At the physical layer, the most common attack is jamming the radio frequency that the network is using. Jamming a radio frequency can be just as simple as having a transmitter keeps transmitting noise onto the desired frequency. This effectively degrades that channel so much that no one else can use it. The standard defense against jamming is spreadspectrum communication so that the jammers must either follow the precise hopping sequence or jam a wide section of the band of launch the attack. Jamming a wide section of the band means that the attacker has many enough equipments so that they can send noise onto all the channels

37 that the Wireless Sensor Device’s are capable of using. The most common attack at the MAC layer is eavesdropping for sensitive information. Link layer cryptography protects against eavesdropping. At the networking layer, there are many attacks against the routing protocol to disrupt routing in the network. Interested readers can read about routing protocol attacks in
Chapter 1 of Security in Sensor Networks by Yang Xiao [23].
TinyOS first distribution was released in 2001. Shortly after that, SPINS was also released in
2001 by Perrig, Szewczyk, Tygar, Wen, and Culler [20] from University of California, Berkeley.
SPINS is a security protocol for sensor networks. SPINS has two components: SNEP (Sensor
Network Encryption Protocol) and uTesla. SNEP provides security functions such as encryption, two-party data authentication, replay protection, freshness, and integrity. uTesla is similar to
Tesla [24] to provide broadcast authentication. However, uTesla has been modified to reduce overhead from Tesla, which is designed for a regular network, to run on the resource-restricted
WSN devices. A quick description of how Tesla [24] works is below:
The main idea of TESLA is that the sender attaches to each packet a MAC computed with a key k known only to itself. The receiver buffers the received packet without being able to authenticate it. A short while later, the sender discloses k and the receiver is able to authenticate the packet. Consequently, a single MAC per packet suffices to provide broadcast authentication, provided that the receiver has synchronized its clock with the sender ahead of time.
Essentially, in a TESLA scheme, the sender would send the receiver the key ‘k’ to authenticate a packet that was sent in the past. SPINS network architecture assumes that devices only communicate with a super base-station. Thus, the network topology formed is a star network.

38
The types of communication in a star network are: device to base-station, base-station to device, and broadcast from base-station. SNEP would provide security protection for the device to basestation, and base-station to device communication while uTesla would protect the base-station broadcast communication to devices. SPINS uses symmetric cryptography because of the belief that public key cryptography is too intensive for the resource-limited WSN nodes [25]. SPINS is not fully implemented and is never released by TinyOS [21]. The next security suite development from University of California of Berkeley is TinySec [21].
TinySec is designed by Chris Karlof, Naveen Sastry, and David Wagner at University of
California, Berkeley in 2003 [21.] TinySec is a software link-layer security suite that provides three basic security properties: access control, message integrity, and message confidentiality.
Access control means that the link-layer protocol should prevent unauthorized parties from participating in the network. Message integrity means that the receiver can detect if a received message is tampered with or not. Message confidentiality means that message is kept secret and is usually achieved with encryption. TinySec has two modes that users can select: authentication and encryption, or just authentication. TinySec also uses symmetric encryption, and it is implemented with chain block ciphers. TinySec is fully implemented and is included in the official release of TinyOS 1.0 under the path /opt/tinyos-1.x/tos/lib/TinySec. However, TinySec is not included in the latest TinyOS 2.1 release probably because TinySec is now replaced by
IEEE 802.15.4. It makes sense to use IEEE 802.15.4 which is now supported by recent radio chips. Having the IEEE 802.15.4 compliant radio chip takes care of security would be faster than

39 executing the software link-layer TinySec on the resource-limited microcontroller on the Wireless
Sensor Devices. The WSD’s RAM and FLASH usage is also reduced by not compiling and loading TinySec into TinyOS. So far, TinySec protects against eavesdropping and packet injection. However, TinySec does not protect against ‘replay attack’ as a link-level security protocol.
SomeSec [26] is developed by M. Hays and D. Moss at Rincon Research Corporation in March
2006. SomeSec is designed based off the ZigBee 1.1 specification. However, SomeSec is not a
ZigBee implementation. SomeSec just uses the ZigBee security primitives and protocols to eliminate the replay vulnerability in TinySec. Below is a quick description of SomeSec versus
TinySec from “SomeSec: Practical TinyOS Security” [26]:
This enhanced security and portability come at a cost, of course: SomeSec currently requires twice the RAM, three times the code space, and more energy [19] than TinySec.
The two systems represent different prioritizations of requirements. TinySec demands minimal resource and performance impacts at the expense of absolute security; SomeSec demands higher absolute security at the expense of resource utilization and performance degradation. TinySec’s design included replay vulnerability due to the unacceptable cost of preventing it [9]; SomeSec makes exactly the opposite trade on this point.
SomeSec offers TinyOS users another security suite choice besides TinySec. Users can choose to use SomeSec, which is more secured than TinySec with the increased cost in more RAM, more code space, and more energy.

40
So far, there are two viable options for WSN security with the TinyOS framework: software encryption such as TinySec or SomeSec, and hardware encryption in IEEE 802.15.4. However,
TinySec, SomeSec, and IEEE 802.15.4 all use symmetric encryption, which has the fundamental concern of proper key management [25]. Public Key technology is a widely used tool to support symmetric key management in the Internet and high-bandwidth connections [25]. But, there has always been the belief that Public Key technology or other Internet-level security techniques are too heavyweight for WSN and that other alternatives must be developed [25]. There are other studies into how Public Key technology can be used to solve the key management issue in WSN.
One such study is: “TinyPK: Securing Sensor Networks with Public Key Technology” by Ronald
Watro, Derrick Kong, Sue-fen Cuti, Charles Gardiner, Charles Lynn and Peter Kruus from BBN
Technologies [25]. They set out to prove that with careful design, the widely used RSA public key cryptosystem and Diffie-Hellman key agreement techniques can be deployed on even the most constrained of the current sensor network devices.
However, the quest is still on to find a Public Key Technology implementation that is more energy efficient than RSA. Nils Gura, Arun Patel, Arvinderpal Wander, Hans Eberle, Sheueling
Chang Shantz from Sun Microsystems Laboratories compares the performance between Elliptic
Curve Cryptography [27] and RSA [28] on WSN devices in a paper: “Comparing Elliptic Curve
Cryptography and RSA on 8-bit CPUs” [29]. The study shows that the relative performance advantage of ECC point multiplication over RSA modular exponentiation increases with the

41 decrease in processor word size and the increase in key size. So, ECC implementation should be used over RSA implementation as the Public Key technology in a Wireless Sensor Network because ECC uses less energy than RSA for the relatively same level of security.
An Liu and Peng Ning have provided TinyECC for TinyOS in a study “TinyECC: A
Configurable Library for Elliptic Curve Cryptography in Wireless Sensor Networks” [30].
TinyECC is a Public Key cryptography that is based Elliptic Curve Cryptography that is efficient enough to run on the resource-limited WSN nodes. TinyECC is built using the TinyOS framework and TinyECC can be downloaded at the TinyECC website [31.]

Chapter 6
CONCLUSION
42
This project has provided a basic Wireless Sensor Network knowledge for a WSN researcher.
The project covers the hardware architecture of a Wireless Sensor Device by breaking the
Wireless Sensor Device into different hardware blocks to explain how the different blocks work together in order to sense the data and then send the data to the central server for processing. The project covers the Wireless Sensor Device’s network stack with an overview of the IEEE
802.15.4 specification for the PHY and MAC layers, and an overview of the ZigBee specification for the Network and Application layers. The project also shows the network topologies that the
Wireless Sensor Devices can form in order to form a Wireless Sensor Network to transfer data using multi-hop routing protocol to the ‘central server’ for processing. The project then covers
TinyOS, which is an Open Source Operating System for Wireless Sensor Devices, in two aspects: how to program a Wireless Sensor Device using the TinyOS framework, and an analysis of the
Wireless Sensor Network security features that have been built using the TinyOS framework.
The project details the progression and an overview of the security features that have been built with TinyOS starting with SPINS, TinySec, IEEE 802.15.4 security features, SomeSec which is based on ZigBee security mechanisms, TinyPK, and ending with TinyECC. SPINS, TinySec,
IEEE 802.15.4 security features, and SomeSec are all based on Symmetric Cryptography, which has an inherent complex problem with key management. Therefore, the project then talks about

43 the need for Public Key technology to alleviate the complicated key management issue. TinyOS has two Public Key implementations: TinyPK which is based on RSA, and TinyECC which is based on ECC. TinyECC has the advantage over TinyPK because TinyECC requires less overhead and consumes less power than TinyPK.
The project also has a hands-on side that involves the researcher programming five Wireless
Sensor Nodes using TinyOS with Open Source Code to simulate a working Wireless Sensor
Network to observe how the network works.
There are many possible future security-related projects that could stem from this foundation project. The possible security-related projects are:
1.
A Hands-on project involving setting up 6LoWPAN/ROLL on the Wireless Sensor
Devices (TelosB) using TinyOS to see if the existing Internet Security features can be used in a Wireless Sensor Network.
2.
A Hands-on project to set up a Public Key Infrastructure with TinyECC for the TelosB.
3.
A Hands-on project involving writing programs for the TelosB using TinyOS to use the
TelosB as an IP device for any applications that require wireless communication.
4.
A Hands-on project involving adding TinyOS support for the eZ430-RF2500 development kit.

REFERENCES
[1] NiruPama Bulusu, Sanjay Jha. Wireless Sensor Networks: A Systems Perspective.
44
Massachusetts: Artech House, 2005.
[2]
Eric Anderson. “Wireless Sensor Networks.” Arizona State University.
< http://impact.asu.edu/~mcn/cse591wsn/Wireless%20Sensor%20Networks.ppt
>.
[3]
“Wireless Sensor Networks: Internet Application Development.”
< http://www.docstoc.com/docs/2252652/Wireless-Sensor-Networks-Wireless-Sensor-Networks-
What-is-a-sensor >.
[4] Wikipedia. “IEEE 802.15.4.” < http://en.wikipedia.org/wiki/IEEE_802.15.4-2006 >.
[5]
“Atmel 802.15.4 MAC User Guide.”
< http://www.atmel.com/dyn/resources/prod_documents/doc5182.pdf
>.
[6] ZigBee Alliance. < http://www.zigbee.org/ >.
[7] Jonathan Hui. University of California, Berkely. “6LoWPAN Information Web Site.”
< http://www.cs.berkeley.edu/~jwhui/6lowpan.html
>.
[8] David Culler. “Time to ROLL: Routing Over Low Powered and Lossy Network.”
< http://vimeo.com/3264574 >.
[9] Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for
Low-Rate Wireless Personal Area Networks (LR-WPANs). IEEE Standard, 802.15.4-2003, May
2003. Page 22.

[10] Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for
45
Low-Rate Wireless Personal Area Networks (LR-WPANs). IEEE Standard, 802.15.4-2003, May
2003. Page 23.
[11] Naveen Sastry, David Wagner. “Security Considerations for IEEE 802.15.4 Networks.”
< http://www.cs.berkeley.edu/~daw/papers/15.4-wise04.pdf
>.
[12] Zigbee Specification. ZigBee Document 053474r17. Page 419.
[13] Zigbee Specification. ZigBee Document 053474r17. Page 420.
[14] Zigbee Specification. ZigBee Document 053474r17. Page 2.
[15] TinyOS Web Site. < http://tinyos.net
>.
[16] Contiki Web Site: < http://www.sics.se/contiki/ >.
[17] FreeRTOS Web Site: < http://www.freertos.org/ >.
[18] TinyOS Tutorials. < http://docs.tinyos.net/index.php/TinyOS_Tutorials >.
[19] “eZ430-RF2500 Development Tools: User’s Guide.”
< http://focus.ti.com/lit/ug/slau227e/slau227e.pdf
>.
[20]
A. Perrig, R. Szewczyk, V. Wen, D. Culler, J.D. Tygar. “SPINS: Security Protocols for
Sensor Networks.” Proceedings of Seventh Annual International Conference on Mobile
Computing and Networks (MOBICOM 2001), July 2001.
< http://www.ece.cmu.edu/~adrian/projects/mc2001/spins-wine-journal.pdf
>.
[21]
C. Karlof, N. Sastry, D. Wagner. “TinySec: A Link Layer Security Architecture for
Wireless Sensor Networks.” Proceedings of the Second ACM Conference on Embedded

Networked Sensor Systems (SenSys 2004), Baltimore, MD, November 2004.
< http://naveen.ksastry.com/papers/tinysec-sensys04.pdf
>.
[22] Yang Xiao. Security in Sensor Networks. Florida: Auerbach Publication, 2007. Page
239.
[23] Yang Xiao. Security in Sensor Networks. Florida: Auerbach Publication, 2007.
[24] A. Perrig, R. Canetti, J.D. Tygar, Dawn Song. “The TESLA Broadcast Authentication
Protocol.”
46
< http://www.eecs.berkeley.edu/~tygar/papers/TESLA_broadcast_authentication_protocol.pdf
>.
[25] Ronald Watro, Derrick Kong, Sue-fen Cuti, Charles Gardiner, Charles Lynn, and Peter
Kruus. “TinyPK: Securing Sensor Networks with Public Key Technology.”
[26] M. Hays, and D. Moss. “SomeSec: Practical TinyOS Security.”
< http://motevate.com/docs/SomeSec.pdf
>.
[27] Wikipedia. “RSA.” < http://en.wikipedia.org/wiki/RSA >.
[28] Wikipedia. “Elliptic Curve Cryptography.”
< http://en.wikipedia.org/wiki/Elliptic_curve_cryptography >.
[29] Nils Gura, Arun Patel, Arvinderpal Wander, Hans Eberle, Sheueling Chang Shantz.
“Comparing Elliptic Curve Cryptography and RSA on 8-bit CPUs.” Proceedings of the
Workshop on Cryptographic Hardware and Embedded Systems (CHES 2004). Boston, August
2004.

47
[30] An Liu, Peng Ning. "TinyECC: A Configurable Library for Elliptic Curve Cryptography in Wireless Sensor Networks." Proceedings of the 7th International Conference on Information
Processing in Sensor Networks (IPSN 2008), SPOTS Track, pages 245--256, April 2008.
< http://discovery.csc.ncsu.edu/pubs/ipsn08-TinyECC-IEEE.pdf
>.
[31] TinyECC download website.
< http://discovery.csc.ncsu.edu/software/TinyECC/register.html
>.
[32] IEEE Standard 802.15.4a-2007.
< http://standards.ieee.org/getieee802/download/802.15.4a-2007.pdf
>.
[33] Texas Instrument ez430-rf2500 Ordering Web Site.
< http://focus.ti.com/docs/toolsw/folders/print/ez430-rf2500.html
>.
[34] Crossbow TelosB Ordering Web Site.
< http://www.xbow.com/Products/productdetails.aspx?sid=252 >.
[35] Donggang Liu, Peng Ning. Security for Wireless Sensor Networks. Texas: Springer,
2007.
[36] Crossbow TelosB Datasheet.
< http://www.xbow.com/Products/Product_pdf_files/Wireless_pdf/TelosB_Datasheet.pdf
>.
[37] Routing Over Low power and Lossy network working group.
https://datatracker.ietf.org/wg/roll/charter/