an analysis of wsn security managemant - kth

An Analysis of WSN Security Managemant

P E H R S Ö D E R M A N

Master of Science Thesis Stockholm, Sweden 2008

An Analysis of WSN Security Managemant

P E H R S Ö D E R M A N

Master’s Thesis in Computer Science (30 ECTS credits) at the School of Computer Science and Engineering Royal Institute of Technology year 2008 Supervisor at CSC was Mikael Goldmann Examiner was Johan Håstad TRITA-CSC-E 2008:036 ISRN-KTH/CSC/E--08/036--SE ISSN-1653-5715 Royal Institute of Technology School of Computer Science and Communication KTH CSC SE-100 44 Stockholm, Sweden URL: www.csc.kth.se

Pehr Söderman An Analysis of WSN Security Management

Wireless Sensor Networks

To my family

You always believe in me



Abstract

An Analysis of WSN Security Management

ZigBee is one of the technologies competing to become the dominating standard for general-purpose wireless sensor networks. These networks are intended to provide omnipresent computing with minimal maintenance and low cost. They are self-organized and use ad-hoc routing to find paths for the data.

ZigBee provides a network and application layer, building on top of the IEEE 802.15.4 standard for low rate personal area networks. It is optimized for low data rates (250kbps), limited range (50m) and long life times (years). The protocol complexity is low to facilitate implementation on limited hardware, lowering the deployment cost.

Even if the security primitives of ZigBee are strong there remain issues not properly addressed in the standard. The goal of this thesis is to analyze the ZigBee 2006 standard, identify security issues and offer recommendations. Issues with authentication, initialization vectors, group keys, MAC layer acknowledgements, cipher modes, security guarantees, key protection, node compromise, revocation and denial of service attacks are examined. Suggestions for ZigBee compatible improvements when deploying the framework are offered. Some changes to ZigBee and IEEE 802.15.4 are also discussed.

ZigBee is suitable as a foundation for a secure network, but care has to be taken in the usage of the numerous settings. Many settings provide tradeoffs and the security impacts are not always obvious. The main vulnerabilities are in the area of denial of service attacks while the confidentiality, integrity and authenticity are better protected. ZigBee networks are vulnerable to insider attacks, facilitated by the physical exposure of the hardware. Sensor node capture is a large threat to the networks.

Keywords

IEEE 802.15.4, ZigBee, wireless sensor networks, security, cryptography, security management, AquisGrain 2



Sammanfattning

En analys av säkerhetshanteringen i trådlösa sensornätverk

ZigBee är en av de tekniker som tävlar om att bli den dominerande standarden för trådlösa sensornätverk. Sensornätverken är tänkta att användas till övervakning och kontroll av inbyggda system till en låg kostnad och med minimalt underhåll.

ZigBee är ett nätverkslager och applikationslager som bygger på IEEE 802.15.4 standarden för PAN (Personal Area Networks, personliga nätverk). IEEE 802.15.4 är optimerat för långsam dataöverföring (250kbps), begränsad räckvidd (50m) och lång livslängd (år). ZigBee och IEEE 802.15.4 är relativt enkla för att underlätta implementation, både i hårdvara och i mjukvara, vilket minskar kostnaden för den slutgiltiga produkten.

Även om de kryptografiska metoderna i ZigBee är säkra så återstår ett antal problem som inte löses på ett tillfredställande sätt i standarden. Målet med denna uppsats är att undersöka ZigBee 2006, beskriva säkerhetsproblem och ge rekommendationer. Problem med initialiseringsvektorer, gruppnycklar, garanterad överföring, kryptografiska metoder, säkerhetsgarantier, nyckelskydd, fysiska attacker och överbelastningsattacker undersöks. Förslag på hur problemen kan kringgås ges också.

ZigBee är lämpligt som en bas för att bygga säkra sensornätverk, men det är viktigt att undersöka alla inställningar som finns i ZigBee för att undvika säkerhetsproblem. Många av inställningarna har effekter på säkerheten som inte är lätta att överblicka. De huvudsakliga svagheterna i ligger i känsligheten för störningsattacker. ZigBee nätverk är känsliga för attacker från medlemmar av nätverken. Den fysiska utsattheten är ett stort hot då det gör det enklare att få tillgång till tillräckligt med material för att ta sig in i nätverket.

Nyckelord

AquisGrain 2, IEEE 802.15.4, ZigBee, säkerhet, kryptografi, säkerhetshantering, sensornätverk



Preface When I started the work on this Master’s thesis in January 2007 I had no idea of what I was really getting myself into. I got the offer late in 2006 and there was very little time to prepare or even reflect on what I was supposed to do. I had not heard of IEEE 802.15.4 or ZigBee before and did not expect to program embedded systems such as the AquisGrain 2.

It has been a rollercoaster ride from the start, working with new standards, new software, new hardware and new people. Parts of the project have been challenging in the extreme.

Special thanks go to Dr. Axel Hübner, my main advisor. Without his knowledge and experience I would not have been able to complete this thesis. He has helped me and shown me new ways when I have gotten lost in details. He has offered advice both on the theoretical work and help with practical issues.

I would also like to thank Peter May for helping me with the embedded programming on the AG2 and his eternal patience. He has listened to my long complaints over bugs in the software and my frustration when learning how to program on the AG2. Embedded programming is harder than it first seems.

Pehr Söderman

June 2007



Table of Contents 1 WIRELESS SENSOR NETWORKS ............................................................................................ 1

1.1 BACKGROUND ............................................................................................................................... 1 1.2 TECHNOLOGY EXAMINED ............................................................................................................ 1 1.3 MOTIVATION................................................................................................................................. 3 1.4 AIMS AND SCOPE ........................................................................................................................... 3 1.5 OUTLINE OF THE THESIS .............................................................................................................. 3 1.6 A BRIEF SUMMARY OF THE RESULTS ........................................................................................... 4

2 SECURITY IN WSN ...................................................................................................................... 6

2.1 CRYPTOGRAPHY ........................................................................................................................... 6 2.2 FUNDAMENTAL PROPERTIES........................................................................................................ 7

3 SCENARIOS ................................................................................................................................. 13

3.1 SCENARIO DETAILS..................................................................................................................... 13 3.2 LIGHTING AND RESIDENTIAL HOME CONTROL......................................................................... 14 3.3 BUILDING MONITORING AND CONTROL .................................................................................... 15 3.4 LONG TERM MEDICAL MONITORING ......................................................................................... 17 3.5 EMERGENCY MEDICAL MONITORING........................................................................................ 18 3.6 DISASTER MONITORING SYSTEM ............................................................................................... 19 3.7 CONCLUSIONS ............................................................................................................................. 21

4 SECURITY ANALYSIS OF ZIGBEE........................................................................................ 23

4.1 IEEE 802.15.4-2003.................................................................................................................... 24 4.2 ZIGBEE 2006 ............................................................................................................................... 33

5 SECURITY SOLUTIONS............................................................................................................ 47

6 IMPLEMENTATION .................................................................................................................. 50

6.1 THE SETUP................................................................................................................................... 50 6.2 IMPLEMENTED CHANGES ........................................................................................................... 52 6.3 PERFORMANCE ISSUES ............................................................................................................... 54

7 CONCLUSIONS ........................................................................................................................... 57

7.1 STRENGTHS OF ZIGBEE.............................................................................................................. 57 7.2 WEAKNESSES OF ZIGBEE........................................................................................................... 57 7.3 CHANGES TO ZIGBEE ................................................................................................................. 57 7.4 OPEN QUESTIONS ........................................................................................................................ 58

ABBREVIATIONS ............................................................................................................................. 59

DEFINITIONS .................................................................................................................................... 60

REFERENCES .................................................................................................................................... 62



Table of Figures Figure 1: The AquisGrain 2..................................................................................................................... 2

Figure 2: Illustration of the IEEE 802.15.4 and ZigBee Stack. Notice the complex relationships. ...... 23

Figure 3: PAN topologies (IEEE 802.15.4 standard). ........................................................................... 24

Figure 4: Clustered tree network (IEEE 802.15.4 standard) ................................................................. 25

Figure 5: Super frames in IEEE 802.15.4 (IEEE 802.15.4 standard).................................................... 25

Figure 6: Beacon frame ......................................................................................................................... 26

Figure 7: Command frame .................................................................................................................... 26

Figure 8: MAC layer data frame ........................................................................................................... 26

Figure 9: MAC layer acknowledgement frame ..................................................................................... 27

Figure 10: Counter mode encryption (Public domain).......................................................................... 28

Figure 11: Cipher block chaining MAC (Public domain). .................................................................... 29

Figure 12: MAC layer secure payload. Notice the addition of a Frame counter (IV). .......................... 29

Figure 13: MAC layer acknowledgement, no MAC payload (IEEE 802.15.4 standard)...................... 30

Figure 14: The IEEE 802.15.4 beacon frame (IEEE 802.15.4 standard) .............................................. 31

Figure 15: Mac layer security (ZigBee standard).................................................................................. 37

Figure 16: Network layer security (ZigBee standard). .......................................................................... 37

Figure 17: Application layer security (ZigBee standard). ..................................................................... 38

Figure 18: Key establishment (ZigBee standard). ................................................................................. 39

Figure 19: The SKKE protocol. ............................................................................................................ 39

Figure 20: Joining a network (ZigBee standard). .................................................................................. 41

Figure 21: Residential authentication (ZigBee standard). ..................................................................... 42

Figure 22: Commercial Authentication (ZigBee standard). .................................................................. 43

Figure 23: The Java application ............................................................................................................ 50

Figure 24: AquisGrain 2........................................................................................................................ 51

Figure 25: Update sensor window (Screenshot).................................................................................... 52



1

1 Wireless Sensor Networks Since the introduction of the NMT (Nordic Mobile Telephone) system in 1981 and release of

the IEEE 802.11 (Wi-Fi) standard 1999, the market for short-range wireless networks with

limited regulation has expanded many times. Today first generation (mobile phone) and

second-generation (wireless LAN) public wireless networks are widely deployed and bring us

closer to omnipresent computing and communications. To continue the trend of smaller,

cheaper, and denser networks new technologies are needed. The wireless sensor networks are

intended to cover the need for cheap, low speed, short-range communications everywhere.

1.1 Background A wireless sensor network (WSN) is a group of sensor nodes cooperating to form a network over wireless links. The goal is to make the sensor nodes cheap and disposable, allowing them to be deployed everywhere and creating omnipresent networks.

Originally, the technology was developed for military monitoring systems, with the goal of creating a system that was cheap and quick to deploy at the same time as it was hard to destroy.

The low price of sensor nodes, ease of deployment and geographical distribution make WSN technologies attractive. The WSN can offer better capabilities and higher flexibility to a lower cost compared to traditional wired systems or large and capable sensor nodes.

The basis of a WSN is a sensor node, containing a radio, a power source, a sensing unit and a processing unit. The sensor nodes are intended to be cheap and disposable as they are deployed in environments that range from uncontrolled to intensely hostile where the loss of sensor nodes can be expected.

Typically, the sensor nodes are deployed in large numbers. A small network may contain up to fifty sensor nodes while a large network contains many thousands. The high number of sensor nodes helps providing good coverage and compensates for failures of individual sensor nodes. The sensor nodes are deployed densely and each node has contact with several other sensor nodes. After the sensor nodes are deployed they connect and organize an ad-hoc network to communicate. The ad-hoc nature of the large-scale networks results in a new class of management, routing, and security problems.

The sensor nodes are typically battery powered and very tightly power constrained, making the energy consumption a limiting factor in the design. Calculations and communication have to be kept at a minimum to avoid a premature failure of the sensor nodes. As the sensor nodes have to be as cheap as possible they also have limited hardware, limited memory, and are usually not tamper proof.

1.2 Technology examined As WSN is not yet a tightly defined concept a large number of specialized frameworks and hardware bases for WSN exist. A list of some of the many possible applications (tsunami warning systems, medical monitoring, avalanche rescue, and military systems) and associated hardware for WSN can be found in a paper by Römer and Mattern [1]. These implementations vary in several orders of magnitude in both cost and size.



2

In this thesis the general-purpose WSN framework “ZigBee” will be examined. It is built upon the “IEEE 802.15.4 WPAN” (wireless personal area network) standard for short-range communication. The hardware platform is the AquisGrain 2 developed by Philips GmbH.

1.2.1 AquisGrain 2

AquisGrain 2 is a fully integrated system, with the exception of external IO and power source. It is intended to become a general-purpose block to be used when constructing larger products and systems, but is still an experimental platform. The AquisGrain 2 is 16x24x4 mm in size. The hardware is not commercially available, but similar hardware is available from several vendors.

Each AquisGrain 2 contains a CC2430 from Texas Instruments (ChipCon), supporting hardware, a radio antenna, two diodes (yellow and red), IO port, and power supply connector.

Figure 1: The AquisGrain 2

1.2.2 CC2430

The CC2430 [2] is a specially developed system on chip, minimizing the number of additional components needed. It is built by Texas Instruments (ChipCon) to be used for ZigBee and similar applications. It offers a 32 MHz 8051 MCU, built-in 2.4 GHz radio, 8 Kbytes SRAM, and 32, 64, or 128 Kbytes flash memory. It also has hardware AES support.

Texas Instruments is selling the system for $7.301.

1.2.3 IEEE 802.15.4 WPAN

The IEEE 802.15 Task Group 4 was chartered to investigate a low data rate solution with multi-month to multi-year battery life and very low complexity. It is operating in an unlicensed, international frequency band. Potential applications are sensor nodes, interactive toys, smart badges, remote controls and home automation. (From the description of the IEEE 802.15.4 Task Group [3])

IEEE 802.15.4 [3] is a standard for simple, low power, low data rate WSN. Depending on the frequency the throughput is 250 kbps, 40 kbps, or 20 kbps. It can be compared to IEEE 802.15.1

1 In packets of 100 chips. The cost of a mounting boards has to be added. Price in November 2007 from http://focus.ti.com/docs/prod/folders/print/cc2430.html



3

(Bluetooth) and IEEE 802.11 (Wi-Fi), which both offer considerably higher data rates at the cost of complex sensor nodes and higher energy demands.

IEEE 802.15.4 specifies the physical (PHY) and the medium access (MAC) layers. Thereby it provides point-to-point links. It uses (up to) 64 bit addresses for a theoretical maximum of 264 possible sensor nodes in a single network, but in most applications 16 bit short addresses are used. IEEE 802.15.4 supports point-to-point links and has reliable transport built in. It also offers basic cryptographic security services based on AES [4].

1.2.4 ZigBee

The ZigBee Alliance is developing a very low-cost, very low power consumption, two-way, wireless communications standard. Solutions adopting the ZigBee standard will be embedded in consumer electronics, home and building automation, industrial controls, PC peripherals, medical sensor applications, toys and games (From the ZigBee specification [5]).

ZigBee [5] builds upon IEEE 802.15.4 to provide a network layer complete with routing and an application layer to simplify the development of applications for WSN. Networks can be built as star networks, trees, or full mesh networks. ZigBee also includes a security framework built upon the basis of IEEE 802.15.4.

ZigBee is intended to be a general-purpose solution for WSN where different application profiles can be used to define how the sensor node is supposed to function and which services the sensor-node offers. For Home Automation, Industrial Control, and Consumer Electronics application profiles already exist.

1.3 Motivation In WSN, security is a field of great importance. The networks are likely to carry critical information from sensor nodes as well as be used in controlling diverse applications. If an attacker can monitor or disturb the WSN much more easily than he could attack a similar wired system there will be little demand for usage of WSN in security sensitive applications. Widespread attacks could also limit the deployment of WSNs in customer applications and leave producers of WSN products liable.

1.4 Aims and scope The goal of this thesis is to develop a ZigBee compliant security management solution for WSNs, including all necessary key management mechanisms like generation, distribution, update, and revocation. As a part of the work a detailed security review of ZigBee and IEEE 802.15.4 is required. The final solutions are implemented on the AquisGrain 2 platform to evaluate the performance and compliance of the solution.

1.5 Outline of the thesis • Chapter 2: Security in WSN examines of the state of the art when it comes to security of WSN,

concentrating on the handling of keys and security material.

• Chapter 3: Scenarios includes some scenarios where ZigBee might be deployed and examines the suitability of ZigBee for each.

• Chapter 4: Security analysis discusses the security in IEEE 802.15.4 and ZigBee 2006.

• Chapter 5: Security solutions offer solutions to some of the security issues identified.



4

• Chapter 6: Implementation details the implementation of several extensions of the security framework.

• Chapter 7: Conclusions contains an analysis of the results and concluding remarks.

• Chapter 0: Abbreviations is a list of the abbreviations used in the thesis.

• Chapter 0: Definitions offers commonly used definitions of technical terms.

• Chapter 0: References holds the reference list.

1.6 A brief summary of the results ZigBee is the first commercially available wireless sensor network protocol with a security management infrastructure intended for omnipresent deployment. Building a security framework with tight constraints on memory, CPU and battery is not an easy task and ZigBee is not yet perfect.

While this thesis presents a number of possible weaknesses and attacks, it is not clear which of these attacks will actually be employed against ZigBee networks. Most of the attacks are of disruptive nature and not compromising nature, making them less valuable. ZigBee is still being developed and some of the issues are being addressed in the drafts for the next version of ZigBee.

1.6.1 Strengths of ZigBee

The fundamental cryptographic functions in ZigBee are strong and well constructed. The trust centre and standardized methods to handle key material and key setup work well. So far no similar security management solution for a commercial WSN has been deployed. The security framework in ZigBee can be made transparent to the users, which is useful in applications where the user will not be able to monitor or influence the settings of the device. Correctly deployed ZigBee networks can be configured to offer a good level of security.

1.6.2 Weaknesses of ZigBee

A large amount of variables and options exists in ZigBee, many of them offering tradeoffs between security and performance. Some of the tradeoffs are not trivial to understand, while others are clearly dangerous. For example, the full impact of turning off integrity protection is not clear.

There exist issues with initialization vectors, MAC layer acknowledgements, cipher modes, key handling and security guarantees. Awareness of these issues makes it reasonably easy to work around them.

The ZigBee networks are vulnerable to attacks involving capture of sensor nodes. Capture of a single sensor node gives access to the shared network key and therefore opens the network both to packet injection and attacks on the routing and management frameworks. The authentication procedure has several security issues. One such problem is the fact that the network does not authenticate to a sensor node, making it impossible for a sensor node to ensure it joins the correct network. The authentication procedure might also be possible to exploit in a replay attack. These problems are not easy to eliminate, as they are fundamental parts of the standard. The reliance on the shared network key complicates the creation of secure networks. These weaknesses have to be carefully considered in an application to avoid creating a network that is easy to break into. The trust centre is a single point of failure in the network.

1.6.3 Some of the suggested changes to ZigBee

ZigBee requires some form of distributed key setup and authentication to avoid overloading the trust centre, which is a single point of failure. I have suggested using a simple key pre-distribution scheme



5

to establish link keys between devices that are already part of the network without trust centre involvement. The unsecured joining phase is problematic and needs to be revised to avoid attacks where a sensor node is lured to join the wrong network. This is a fundamental change to the standard.

One important security issue is the initial trust establishment. Without any support for public key cryptography the key establishment needs to be carefully considered. The two current methods are not suitable for all applications.

Removal of keys is not supported in ZigBee. This makes management of the memory dedicated to keys harder and prevents efficient revocation of sensor nodes. The addition of a remove key command could easily solve this issue.


Security in WSN

6

2 Security in WSN Due to the resource, space, and cost constraints placed on sensor nodes in a WSN many of

the security solutions for IP networks (and similar systems) are not suitable for WSN security.

This, combined with a large number of threats, makes it unusually hard to build security

solutions for WSN.

Security in WSN is a very active research area where new and creative solutions to the security issues are suggested on a regular basis. This chapter introduces the design of security management solutions for wireless sensor networks. Those familiar with the design of IP network security solutions will be familiar with many of the issues described in this chapter.

2.1 Cryptography From Greek: kryptós gráfo “Secret writing”

Cryptography is a diverse engineering field with contributions from mathematics, physics and computer science. Cryptography can be said to be the art of keeping communication secure even when your enemy can read and change all your communications. Cryptographic methods can be used to encrypt and decrypt messages (to keep the secrecy of their content) as well as to create and verify signatures for messages (to authenticate the content). A full introduction to cryptography is far beyond this thesis, but several excellent books exist on the subject, such as, e.g.[6].

Cryptography has an opposing science in the cryptanalysis, the art of exposing information that has been secured using cryptographic methods. Cryptanalysis concentrates on the security of cryptographic functions.

Two major paradigms exist in cryptography, symmetric cryptography and asymmetric cryptography. Frequently the two types of cryptography are used together as they offer different benefits and drawbacks.

2.1.1 Symmetric cryptography

Symmetric cryptography is old; simple symmetric ciphers have been used since 500BC. Classic substitution and transposition ciphers were used until the development of machine ciphers in the early 1900. These were replaced by modern symmetric ciphers around 1950 and forward [7].

In symmetric cryptography both sides share a key that they can use to secure the information that is being transferred. This key has to be kept secret from all outsiders or the information secured will be exposed. Symmetric cryptographic methods are well studied, fast, and can often be implemented in hardware to minimize performance loss.

Two types of symmetric ciphers are in use today, block ciphers that work on blocks of a specific length and stream ciphers that work bitwise on the data. A steam cipher can be seen as a block cipher with a block length of 1 bit. A large number of available and carefully examined algorithms exists, such as AES[4], Blowfish [8], and DES [9].

Most security schemes for WSN use only symmetric cryptography, due to its ease of implementation on limited hardware and small energy demands, especially if the implementation is done in hardware. In a symmetric scheme the keys need to be kept confidential, which can be quite hard in the exposed environment where WSNs are used. Consequently, additional mechanisms are needed to solve the key distribution problem.


Security in WSN

7

2.1.2 Asymmetric cryptography

First published in the 1970s asymmetric cryptography (or public key cryptography) relies on two keys with a mathematic relationship. A private key can be used to decrypt and sign data while a public key can be used to encrypt and verify data.

Only the private key needs to be kept confidential, the public key can be published freely. Public key cryptography has been very successful and popular on the Internet where the ability to transfer key data and verify signatures has been used to build up an extensive public key infrastructure.

Certificates are mathematically signed public keys and identities. By verifying the signature it is possible to bind a key to an identity. As the certificates rely on the mathematical security of the signatures and not on secrecy they can be transferred freely over an insecure network.

Public key cryptography tends to be resource intensive, as most systems are based on large integer arithmetic. This is in conflict with the limited processing power of a WSN node. Additionally, the key sizes are large (1024 bit keys are typical for RSA, compared to 128 bit for AES) which uses up valuable memory. For a number of years many researchers discarded public key cryptography as infeasible in the limited hardware used in WSN. Lately the interest in asymmetric cryptography for WSN has increased after it has been shown to be possible to implement Elliptic Curve Cryptography (ECC) [10] on WSN hardware[11, 12]. ECC uses smaller keys and has unusually light computational demands compared to other public key schemes. However, the intellectual property situation for ECC is unclear which hampers implementation of ECC in WSN outside research environments.

2.2 Fundamental properties When designing a security management solution we need to decide on the security properties of the system. To do this we need to examine the goals and the threats to the complete solution. The boundaries imposed by the nature of WSNs are also of interest. This is a top down examination where the global outcome is more interesting than technical details.

2.2.1 Goals

The goals of a security system are a set of properties. These are not absolute; instead the properties are traded against each other and external costs. The security goals of a protocol suite for a WSN do not differ much from the security goals of any other secure network. A more detailed description of these goals can be found in literature such as the first chapter of Handbook of Applied Cryptography [6]

2.2.1.1 Confidentiality

The goal of confidentiality protection is to ensure that an attacker cannot read data being transferred. As a sensor network might carry critical information, such as medical data, it is important that the confidentiality is properly protected from an attacker. Cryptographic methods are used to protect confidentiality of the data.

2.2.1.2 Data Authenticity

The goal of authenticity protection is to ensure that the source of the data is possible to trace. In a wireless network it is easy to inject data, which could disturb communications or even take down the network. Authenticity is usually protected using codes such as a message authentication code (MAC2).

2 This is not the same as the medium access control layer MAC.


Security in WSN

8

2.2.1.3 Data Integrity

The goal of integrity protection is to ensure that the data being transferred has not been changed by accident or through malice during the transfer from source to destination. This prevents an attacker from changing an authenticated message. Integrity is usually protected by using a MAC and can often be combined with the authenticity protection.

2.2.1.4 Freshness

The goal of freshness is to ensure that the data being transferred has not been sent before. Freshness protection prevents replay attacks, where an attacker captures and later resends a packet with correct authenticity and integrity codes. Freshness is usually protected with freshness counters.

2.2.1.5 Robustness

The goal of robustness is to ensure that the network handles errors properly and that a large amount of resources is needed to take down the network. Typically an attacker should have to spend at least as many resources as exist in the network to destroy it. For example, it is currently not possible to protect a network from an attacker that has a stronger radio transmitter than the sensor nodes has. However, the attacker should not be able to use a single weak transmitter to jam the whole network.

If an attacker controls a majority of the sensor nodes in the network building security is exceptionally hard, but the attacker should not be able to take control of the network with only a minority of the sensor nodes under his control.

Robustness is usually introduced by a careful design of protocols.

2.2.2 Threats

The threats to a system describe type of attacks in an abstract manner. A threat usually has a negative effect on the security goals and if the security fails they expose vulnerabilities. Some of the threats a WSN faces are well known and well studied, other threats are specific to WSN and less well studied. The security framework should minimize the impact of these threats.

2.2.2.1 Snooping

As a WSN uses radio for communication it is impossible to prevent an attacker from monitoring the communication as long as the attacker is within range of the network. The attacker can listen to and record any data sent through the radio interface of the sensor node.

2.2.2.2 Node capture

As the nodes might not be in a physically secure location an attacker can capture a node and get access to all the information stored on the node. This gives the attacker access to all keys stored on the node as well as the ability to monitor all messages sent through the node. The attacker can also do selective forwarding and send messages using the identity of the node.

2.2.2.3 Node trapping

Another form of capture can be done by luring a sensor node to join an attacker-controlled network, saving the attacker from doing a physical attack. In this case the attacker does not automatically gain access to the security material on the sensor node, however the sensor node will be trapped in the wrong network.

2.2.2.4 Node injection

An attacker can with, or without, previously captured credentials try to insert additional nodes in the network. This might allow him to change global sensor readings from the network, disturb routing, and snoop on communications. If the attacker tries to use a large number of identities, the attack is known as a Sybil attack [13]. This can be especially dangerous to voting mechanisms and routing.


Security in WSN

9

2.2.2.5 Data injection

The attacker might also try to insert various forms of data into the network without joining the network. The nature of wireless networks makes it relatively easy to inject a message by using a timeslot a device is not using, unlike a wired network. The injected data can be data previously captured from the network. This kind of attack is known as a replay attack.

2.2.2.6 Denial of Service

An attacker might try to use up all the resources in the network, either globally or locally. A denial of service (DoS) attack is directly aimed at the robustness of the network. DoS attacks can be aimed at different layers of the protocol and are often hard to offer good protection against these attacks. DoS attacks in sensor networks are an area where only limited research has been done. In general, attacks on the higher layers require less power but more sophistication.

2.2.2.6.1 Physical layer

A DoS attack at the physical layer tries to jam the radio transmissions. As the sensor nodes have very limited power they can usually not compete in raw power output. The modulation of the signal can offer some protection.

2.2.2.6.2 MAC layer

The wireless protocols require a certain level of cooperation between sensor nodes. An attacker can try to use up resources by constantly sending or violating guaranteed time slots (GTS) forcing the other sensors to retransmit data many times and use up power.

2.2.2.6.3 Network layer

Typical attacks on the network layer involve sending data long ways through the network, which uses up power, or disturbing the routing protocol. Reporting false routes or routing messages incorrectly can have devastating effects on the global network performance. Attacks on the network layer usually require the sensor to be an authenticated part of the network.

2.2.2.6.4 Application layer

The applications on the sensors can be forced to do extensive computation or use up the limited memory. These attacks tend to be very specific for a certain implementation.

2.2.3 Obstacles

While the limitations of traditional computer networks are well known the exact limitations of WSN are less clear. The limitations tend to come from the hardware platform, which is in turn decided by the intended application of the sensor nodes.

2.2.3.1 Price

The first and foremost limiting factor in sensor node design is the price. For WSN to have an advantage over traditionally wired systems they have to be as cheap as possible. For large-scale deployment costs of $1 or less is a popular target. This cost should include all the hardware in the sensor node. No modern, general purpose WSN has reached this price point so far, but some devices based upon the more complex but very popular BlueTooth standard are getting close, with costs of less than €5 for each device. The price for ZigBee devices are expected to drop sharply once they are widely deployed. While the original projections of €2 per sensor at the end of 2007 have not been


Security in WSN

10

reached, the price is close to €7 currently3. The price of a ZigBee sensor node will most likely be dominated by the hardware platform, as the standard is designed to be easy to implement in software.

2.2.3.2 Battery

As the sensor nodes are likely to be deployed in places where they do not have access to a permanent power source they have to bring their own power. This is done with the help of a battery. If the battery fails the sensor is useless, which means that the design has to minimize power drain. In some applications power scavenging methods such as solar arrays and motion power generators can help to provide additional power.

2.2.3.3 Tradeoffs

When constructing the hardware and software for a sensor node the limitations on price and battery endurance will have a large effect on the hardware and the software. Once the price and battery amount have been fixed tradeoffs have to be done in other areas. The major tradeoffs are memory, processor, and communications.

2.2.3.3.1 Memory

To minimize the cost and energy drain the sensor nodes will have a minimal amount of memory. Typical values are less than 128 Kbytes of flash memory and a few Kbytes of RAM (see CC2430 [2]). The flash memory is slow but can be used for permanent storage. The flash usually has a limited number of erase-write cycles, in the CC2430 as low as 1000 cycles. RAM is fast but also expensive and it uses more power than flash. In some hardware platforms the data in part of the RAM is lost when the sensor node goes into power saving mode.

2.2.3.3.2 Processor

The processor is one of the larger power consumers of a typical sensor node. Today low power general-purpose processors are used, typically clocked at less than 50 MHz, unless there are specific demands for large scale processing on the sensor node. Advanced ultra low power processors exist, but the cost of the hardware might not be worth the extra performance. Many processors implement power saving modes to minimize the power drain when the full performance is not needed.

2.2.3.3.3 Communications

The radio is typically the largest energy consumer of the sensor node, both when sending and receiving. Minimizing the listening time, the number of packets and the size of each packet are important to preserve battery power. Due to this fact communications have to be kept at a minimum. In some configurations the sensor nodes can enter sleep mode during extended periods of time and shut down the radio to save energy, relying on a precise clock and scheduled communication periods to remain in contact with the neighbours.

2.2.4 Key management

Efficient key management is used to support and maintain the security of a network through the careful management of the security material in the network. This includes not only the actual keys, but also related security material such as nonce and master secrets. Key management can limit the effect of attacks on the protocols and cryptographic primitives. Unless the network is strictly static some kind of key distribution solution is needed. For a WSN, the hardest part is typically the establishment and revocation of keys.

3 The AquisGrain 2 is not commercially available, but hardware SoC used costs around $7.30 currently. (November 2007) http://focus.ti.com/docs/prod/folders/print/cc2430.html


Security in WSN

11

2.2.5 Initialization of members

Initialization is the process used to load the initial security settings and security material that do not need special protection onto the sensor node. It involves the uploading of initial information such as ID and the protocols to use. It is assumed that an attacker has access to this information, but is unable to change it.

Initialization is usually done during production or when the sensor node is first deployed. In the case of WSN, initialization is usually not a hard problem, as it can be done in a secure environment prior to deployment. The memory constraints of a WSN node limit the flexibility of the solution. Usually, there is no room for optional cipher modes and algorithms, so the sensor nodes are initialized with a configuration suitable for a specific network setup.

2.2.6 Generation of keys

Key generation is the process used to generate keys in a secure and random manner. It should not be possible to monitor the sensor node and see what key is generated, nor to control what key is generated.

The generation of keys on the nodes can be complicated if there is no access to good random data. Some solutions use data from the radio receiver to provide random numbers, but the quality of this random data is not always clear. Often the key generation is done at a capable sensor node, with access to a good source of random data, and then the keys are transported to the less capable sensor nodes in a secure manner instead of generating the key on the sensor node itself. This makes sense, as the keys need to be exchanged anyway.

2.2.7 Key establishment

To negotiate a key between two sensor nodes without allowing an attacker to find out this key a so-called key establishment protocol is used. This procedure tries to solve a complicated problem, especially when dealing with sensor nodes having limited resources. Today, three major methods to establish keys between two sensor nodes are known and widely used.

2.2.7.1 Key transport

Key transport is a method where one side establishes the key and afterwards (securely) transfers it to the other side. The key can be transferred using a certificate (using public key cryptography), relying on a public key infrastructure for security. It is also possible to use a trusted third party that both sides share a key with to distribute the key. A third method is to use a previously shared key to transfer the key.

In some cases physically secure methods can be used for the key transport.

2.2.7.2 Key agreement protocols

A key agreement protocol is a protocol where the two sides, using local information and communication over an insecure medium, calculate a common key. Diffie-Hellman [14] can be used for this. There are also symmetric protocols, such as SKKE (part of the ZigBee specification, some details in [15]), based on shared master secrets. In a key agreement protocol the key that is created should not be dependent on the information used to secure the exchange.

Diffie-Hellman makes it possible to securely establish a key even when an attacker can monitor all communications between the sensor nodes and the sensor nodes do not share any secret. In other words, the disclosure of the communication does not have any effect on the security of the exchange. A key can be used to authenticate the exchange, and as long as the key is secure at the moment of the exchange (preventing man in the middle attacks) the final key will be secure. This is important, as it allows bootstrapping as well as recovery from a broken key in the absence of active attackers. The ability to generate a session key that cannot be recovered even if the authentication keys used in the


Security in WSN

12

exchange are broken is sometimes called perfect forward secrecy. It limits the impact of captured nodes or broken keys. A more detailed description can be found in [14].

2.2.7.3 Key pre-distribution protocols

In a pre-distribution protocol the keying material is transferred over a secure channel (usually out of band) before the exchange starts. This material is fixed and cannot easily be changed. The issue of key pre-distribution schemes for WSN is an area of intensive research.

When two nodes wish to begin communications in a pre-distribution protocol, they exchange a set of identity information. Using this information, the sensor nodes calculate the security material from a set of locally stored keying material. Using this material they generate link keys to be used in the following communication. Beyond the trivial pre-distribution schemes, where either all nodes share the same key or all nodes have link keys to all nodes, there exist a number of random pre-distribution schemes (see for example [16, 17]).

The idea of a random pre-distribution scheme is to first create a key pool (usually much larger than the capacity of each sensor). Each sensor gets a set of keys from the pool, chosen in a particular manner. These keys can be used to create link keys to neighbouring nodes, as long as the sensor nodes share at least one key. The capture of a single sensor will expose the keys the sensor has, but it is only a part of the total key pool. Therefore not all links in the network will be exposed.

In a random pre-distribution scheme there is a trade-off between the memory in the sensor nodes, the security of the links, and the risk of the network not being connected after deployment. The keys are distributed in a strictly random manner and only probabilistic guarantees can be given. Random schemes are often simple to implement.

Deterministic key pre-distribution schemes offer provable properties, such as guaranteed number of secure links in the network after the deployment. Using a specific scheme for the distribution of the key material (instead of purely random distribution) these guarantees can be reached. Several such schemes are suggests in [16]. Beyond the proven properties the deterministic schemes are very similar to the random schemes.

2.2.8 Control of key usage

As the communication in a WSN needs to be minimized, a distributed system to control the keys is needed. To avoid having to transport large amounts of usage information along with the keys they are usually divided into key classes with fixed security properties and demands. In this way, a simple identifier can be used to specify how the key is to be handled. This type of control system assumes that all sensors have been pre-programmed with the correct policies for key handling.

2.2.9 Revocation of broken keys

The distributed nature of a WSN makes revocation of keys both costly and slow. Using a trusted third party that revokes the keys, voting in the network, and time stamps are examples of possible solutions. Revocation is important and has to work correctly if the network is to still be secure after the removal or capture of sensor nodes from the network.

2.2.10 Storage of keys

The goal of key storage is to store all keys and associated security material needed to perform the security operations in a safe manner.

Most sensor nodes do not have tamper resistant key storage, since it is expensive. In addition to this, the sensor nodes have limited memory. Therefore only a few keys can be stored on a sensor node at each time and it should be assumed that if an attacker gets physical access to the sensor node its keys are broken.


Underlying security analysis

13

3 Scenarios To continue the development of a security management solution for ZigBee, scenarios

detailing how ZigBee could be used are needed. These scenarios will give additional insight

on what kind of properties these ZigBee networks will have. These scenarios would typically

be a part of the application profile.

I will now describe a number of scenarios to give an idea of what WSN can be used to and evaluate the suitability of ZigBee for each. The evaluation is based on the work in chapter 4, 5 and 6.

3.1 Scenario details For each scenario a large number of critical parameters have to be examined to get a functional network design. The ZigBee standard fixes a large number of parameters and therefore they are not examined here. In addition, parameters with little influence on the security, such as the choice of radio band, have been left out. All the parameters considered in the following chapter have a large impact on how the network will function and what limitations the security framework will have. Most of these parameters can be found in [1].

3.1.1 Deployment

Deployment describes how the system gets to the place where it is intended to be used. Deployment can be one time or iterative, depending on if all sensor nodes in the network are deployed at the same time or if additional sensor nodes are added later to the system. Deployments have effects on the initialization of the sensor nodes as well as the handling of new sensor nodes in the network.

3.1.2 Mobility

Mobility is how often and far sensor nodes in the network will move. While a large number of mobility factors exist, only a few will be examined. A network can be immobile, when all sensor nodes in the network stay in one position. It can also have partial mobility or full mobility if some or all sensor nodes move. Additionally the mobility can be occasional, when sensor nodes move and then stop, or continuous, if the sensor nodes are in constant motion. Mobility is how often a sensor can expect to gain or lose contact with other sensor nodes, which in turn has effects on how heavy the association protocols may be.

3.1.3 Cost, size, and resources

The hardware platform AquisGrain is well defined and would be expensive to change, so all applications have to fit inside this platform. The AquisGrain 2 itself is 16x24x4 mm. Battery life can be increased if a larger and more expensive sensor is acceptable. With larger sensor nodes and more power more heavy computations and traffic can be allowed as a part of the security.

3.1.4 Topology

ZigBee allows three topologies. These are star, clustered tree, and mesh. For small-scale networks the star network is usually preferable, while large-scale networks can be built either as mesh or as clustered trees depending on the exact application. Topology has effects on how many connections a sensor can be expected to keep alive.



14

3.1.5 Connectivity

Connectivity decides the number of sensors nodes another sensor node can expect to have contact with. Together with the mobility it gives an idea of the frequency of connection establishment a sensor node has to handle and the number of connections it needs to keep alive.

3.1.6 Network Size

The size of the network is given by the maximum number of sensors that can be expected to take part in this particular network. Large networks make the network keys more vulnerable and make key distribution harder. Furthermore the trust centre quickly is a single point of failure and becomes more vulnerable as the network size increases.

3.1.7 Lifetime

The lifetime of the network is the time the network has to survive to fulfil its purpose. In some cases part of the network may have to be replaced during the lifetime due to failures of the sensor nodes. A network with a long lifetime will have to be more conservative with power. In addition, it gives an attacker more time to exploit security issues.

3.1.8 Attackers

What kind of attackers can be expected on this kind of network? What are their motivations to attack the network and what kind of resources are available? It is very hard to predict what kind of attackers we can expect, but the attackers will not deploy resources with a value that is larger than the value of the data in the network (to the attacker).

3.1.9 Security demands

What specific security demands does this application of ZigBee imply?

3.2 Lighting and residential home control Here follows the first of the scenarios.

A lighting control system is used to control the light in a part of a building. It is a replacement for wired control systems and is supposed to offer better flexibility and easier installation. It is mostly intended for home applications and other situations where a large-scale network is not needed or even wanted.

The system consists of three parts: Lamp control units that can switch a lamp on and off, buttons to control the lamps, and optional routers to extend the range.

The system is sold in common warehouses as a simple solution to avoid cabling for end users. All parts are sold separately and the user chooses a set of control units, buttons, and routers to suit his needs. After bringing them home the end user installs the control units and sets up the network. If more lamps or buttons are needed the user buys them and adds them to the network.

3.2.1 Deployment

Deployment is iterative. It starts with just a few lamps and slowly increases as more and more lamps are connected to the system. A professional does not deploy the system; instead the homeowner deploys the network himself using a simple instruction manual.



15

3.2.2 Mobility

The system is mostly immobile after deployment. Sensor nodes are usually not moved away from the area where they have been deployed. The network does not need to handle any big changes in the topology.


The sensor nodes have to fit in the same size as previously deployed lighting buttons. They may not be considerably more expensive than the installation of a wired system.

3.2.4 Topology

In most cases the topology is that of a local star network or a clustered tree. There is little need for mesh communication as most of the traffic is control information from the control sensor nodes out to all lamps that are part of the network.

3.2.5 Connectivity

Each sensor node can expect to be connected to a few (between 1 and 5) other sensor nodes. More sensor nodes can be added if it is needed for routing, but this will usually not be done as long as there is a single connection. The networks are typically limited to one room, but might in soma applications cover the whole building.

3.2.6 Network size

The networks size is limited to less than 100 sensor nodes in each network.

3.2.7 Lifetime

The network has to survive several years (3 years) after deployment. Part of the network (the lamps) is likely to have external power, but the buttons will most likely not have external power.

3.2.8 Attackers

The network does not carry any critical data and attackers are more likely to be motivated by curiosity than monetary gain. It is possible that an attacker wishes to use the network to monitor the habits of the homeowner, for example in the preparation of a burglary. Attackers do not have access to any expensive tools. The attacker can be assumed to have the resources of a skilled individual.


The security needs to be flexible and very easy to set up. No specialized knowledge can be assumed on the side of the user and the user has no specialized tools. The cost of recovering from a breach of security is limited.

3.3 Building monitoring and control The goal with a building monitoring and control system is to provide a single system to monitor the environment in a building or building complex. This system should be able to control the climate inside the building in an optimal manner, including heating, AC, ventilation, humidity, lighting, and external sunshades. The system might also be linked into security systems, such as burglar alarm and



16

fire detectors. The goal is to optimize energy usage in the building, provide a good indoor climate and help to enhance security.

The system might be connected to a large number of external actors and systems, such as, for instance, climate control, security stations (to provide real time information), fire department (to warn of fires and help fire fighting activities such as smoke ventilation), weather prediction services (to optimize over all energy usage) and booking systems (to leave rooms not expected to be used unheated).

Installation of the system is done while the building is built or it can be retrofitted to an existing building during large-scale renovations. A professional company installs the system in the building and connects it to all systems it needs to communicate with.

3.3.1 Deployment

The deployment is one time and done by a professional company. There is no need to change the system once it has been deployed. If changes are done to the system, professionals are called in and the system is rebuilt to include the changes.

3.3.2 Mobility

The system is immobile.


The sensor nodes may not be considerably larger or more expensive than comparable wired technology. Most of the sensor nodes are between the size of a matchbox and the size of a brick depending on where they are deployed.

3.3.4 Topology

The network is too large for the star topology; therefore either the mesh or the tree topologies have to be used. Communication is mostly localized in areas so the mesh layout is better suited for this network.

3.3.5 Connectivity

The network can expect to be connected with a few (between 5 and 10) neighbouring sensor nodes. Where the density is too low for routing, additional sensor nodes are added to act only as routers.

3.3.6 Network size

The network is medium to large in size, containing between 200 and 2000 sensor nodes, depending on the size of the building.

3.3.7 Lifetime

The sensor nodes will have to last at least 5 years after deployment. Most of the sensor nodes are in locations where they can take advantage of the electrical grid.

3.3.8 Attackers

The network carries important information about the building and could be used to facilitate break-ins. If a company uses the building for critical tasks the network might also be used for spying. Attackers



17

have clear economic interest and a lot of time to employ their attacks. The attacker can be assumed to have the resources of several skilled individuals or a small company.


As professionals do the deployment the initial configuration of the sensor nodes is less of an issue. The installers can be assumed to have specialized equipment and knowledge of the system. Still, the network needs to run for a long time in a single place and recovering from a security breach would be very expensive. Therefore it is critical to ensure long time security. The low mobility allows the network to use expensive protocols in the initial exchanges.

3.4 Long term medical monitoring A long-term medical monitoring system is a system intended to continuously monitor a patient at home. It can be deployed if the patient is considered at risk after a surgery or has a heart disorder. The system offers more freedom to the patient than a traditional wired system and provides better communication than a simple recorder. If needed the system can also be used to call for help.

The patient carries a set of sensor nodes on the body and these sensor nodes continuously send information to the fixed network in the home. The data is aggregated and sent to the hospital as needed by a gateway.

The system should offer security and performance similar to a wired system.

3.4.1 Deployment

Deployment is done at one time and is done by the user or a nurse. The system might be set up before deployment at the hospital where special equipment is available.

3.4.2 Mobility

While the core network is immobile, the patient and the sensor nodes the patient carries move continuously. The network has to handle the case when the patient moves out of range from the network.


The core of the network has large resources and can be rather expensive. It has access to external power. The sensor nodes are limited in size and need to be light enough to be easily carried by the patient.

3.4.4 Topology

The topology of the network is a clustered tree. Most of the communication is directed from the sensor nodes on the patient to the gateway.

3.4.5 Connectivity

The connectivity of the network will be medium, with each sensor having 5-10 neighbours. The network may regularly become disconnected if the patient leaves the monitored area.



18

3.4.6 Network size

The networks will be small, with less than 30 sensor nodes in each network.

3.4.7 Lifetime

The network has to survive several months (6 months) without failing. The core of the network has external power while the carried sensor nodes do not.

3.4.8 Attackers

Attackers might be interested in monitoring the patient. It is less likely that the attacker wishes to disturb the readings. An insurance company might hire an investigator to receive details on how the patient is doing. The attacker is assumed to have access to the resources of a few skilled individuals and a small company.


The network has to be resilient and handle frequent changes in connectivity. Long-term security is also critical. Due to the frequent topology changes the association protocol may not be too heavy; if possible the sensor nodes should store security material to connect to all routers in the network.

3.5 Emergency medical monitoring An emergency medical monitoring system is intended for quick deployment and short time use in a limited area in a hospital. It is an integrated solution where sensor nodes follow the patient through the whole stay at the hospital.

When a patient arrives at the hospital (or during the transport to the hospital if it is done with an ambulance) sensor nodes are deployed on the patient and associated with the patient’s ID. During the stay in the emergency area of the hospital these sensor nodes continuously send readings from the patient to a central database where they are stored. The staff at the hospital can access the stored data as well as real time data from the network using capable terminals. It is also possible to connect mobile sensor nodes to the network to locally display information about the patient.

The system can warn staff at the hospital if any patient needs attention. The network has to handle quick deployment and high mobility as well as be robust.

3.5.1 Deployment

The core network is deployed by a professional and left in place. Additional sensor nodes are added and removed dynamically by trained users.

3.5.2 Mobility

While the core network is immobile, groups of sensor nodes might move frequently.

3.5.3 Cost, size and resources

The core of the network has large resources and can be rather expensive. It has access to external power. The sensor nodes are limited in size and need to be small, light, and disposable.



19

3.5.4 Topology

The topology of the network is mesh based. Most of the communication goes either from sensor nodes to the gateway or from sensor nodes to nearby monitoring equipment.

3.5.5 Connectivity

The connectivity of the network is high, with each sensor having 10-30 neighbours.

3.5.6 Network size

The network is large with up to 1000 active sensor nodes in the network. In addition sensor nodes may frequently be removed and added to the network.

3.5.7 Lifetime

The core of the network has to survive for many years (5+ years) without failing. Individual sensor nodes have much lower demands, only needing to work for a few weeks (1 month) without failure.

3.5.8 Attackers

An attacker may be interested in gaining information about patients in critical care. Furthermore attacks could be intended to disturb the system in an attempt to hurt individuals. The attacker may have the resources of a large team of professionals backed by a company. Attackers might be ideologically motivated.


The network must be stable and reliable. Despite the frequent addition and removal of sensor nodes the security must be kept at a high level. Deployment of sensor nodes has to be very fast and easy for a skilled user. Association of sensor nodes must be fast to ensure that data is not lost when the sensor nodes are moved around.

It is important not only to protect the integrity of the data, but also the confidentiality.

3.6 Disaster monitoring system A disaster monitoring system is a system intended for usage by emergency services in a disaster area. The system contains general-purpose routers as well as specialized sensor nodes. The system is a complement, not replacement for other communication systems (such as radio) used by emergency services.

The system can quickly be deployed in the area of an emergency and provides low bandwidth communication (using text messages) as well as specialized sensor nodes depending on the type of disaster. Some sensor nodes may be permanently deployed on vehicles (such as measuring flow and water levels on a fire truck).

Typical mobile sensor nodes could be motion sensor nodes (to warn of motions in a house that has collapsed), humidity sensor nodes (to monitor flooding), position sensor nodes (for personnel), and communication stations (providing readings from the network and allowing uploading of information).

The goal of the network is to provide information to aid monitoring the situation and to ensure that the rescue teams can concentrate on other tasks.



20

3.6.1 Deployment

The network is deployed by hand in the area and more sensor nodes can be added as needed. The deployment is done quickly and without much precision. Very little time can be devoted to the deployment.

3.6.2 Mobility

Any part of the network may move.


The core of the network is brick sized routers. The sensor nodes are between brick sized and matchbox sized.

3.6.4 Topology

The topology of the network is mesh based. It is hard to predict which way data will take in the network.

3.6.5 Connectivity

The connectivity of the network is hard to predict, but most likely low, with around 3-10 neighbours for each sensor. In some places there may be up to 30 sensor nodes gathered.

3.6.6 Network size

The network is large with up to 1000 active sensor nodes in the network. In addition, sensor nodes may frequently be removed and added to the network.

3.6.7 Lifetime

The network has to survive up to one month after deployment. There are no external power sources to use.

3.6.8 Attackers

If the disaster is man made an attacker can be interested in disturbing the rescue efforts as much as possible. It can be hard to prevent the attacker from getting physical access to the area where the network is deployed. An attacker might also simply be a curious individual wishing to know what is happening. An attacker might have the resources of a large team of professionals as well a company. The attackers might have any amount of resources up to what a nation state can deploy. Attackers might be ideologically motivated.


The network has to be stable and reliable. Despite the frequent addition and removal of sensor nodes, the security has to be kept at a high level.

Deployment of sensor nodes has to be very fast and easy for a skilled user. Association of sensor nodes has to be fast to ensure that data is not lost when the sensor nodes are moved around.



21

3.7 Conclusions When comparing the scenarios with the security services offered by ZigBee, the following demands have become clear and need to be addressed in order to make the ZigBee security framework suitable for the scenarios. It is important to notice that we cannot blindly use the estimation of the attackers’ resources, as ZigBee is a general-purpose network and might be used in unexpected places.

The conclusions here are partly based on the work in chapter 4,5 and 6, so reading these chapters will make it much easier to follow the conclusions here.

3.7.1 Ease of setup

Sensor nodes, by their nature, have limited abilities to interact with humans. Despite these limitations the network has to be managed in a secure manner. In some scenarios the speed of the setup is important (such as in the emergency medical monitoring scenario), while the lighting and long term medical monitoring scenarios give simplicity higher priority.

3.7.2 High mobility

In many of the scenarios, parts of the network are mobile. The network has to function even with frequent changes in the topology. To support high mobility the overhead of the security framework has to be minimized.

3.7.3 Network membership issues

In all the scenarios sensor nodes need to be both added and removed from the network. It is important to support efficient and secure network management.

3.7.4 Scalability

In large or dynamic networks the scalability of the network becomes an issue in itself. In the disaster monitoring scenario the network has to scale up to 1000 potential sensor nodes. Due to this fact the overhead of the security framework has to be kept small to ensure that the limited hardware can handle the load.

3.7.5 Suitability of ZigBee

The only secure method to setup ZigBee networks require pre-programmed keys. This is not a very flexible or fast solution. An alternative, secure, method of key establishment is needed to improve the speed and security of the joining phase.

ZigBee supports mobility, but moving nodes in the network is a rather expensive operation.

Currently ZigBee only has limited ability to handle the network membership. The trust centre can control which sensor nodes are allowed to join the network, but revocation of sensor nodes is a very expensive operation in large networks (as the network key has to be changed).

Theoretically a ZigBee network can scale up to 216 sensors in a single network. The design of the ZigBee network limits the amount of resources required for end devices and routers, but the trust centre has to keep state for all members of the network. In addition, all sensor nodes in the network have to communicate with the trust centre, making the part of the network where it is located a hot spot.



22

Switching to the residential security model limits the vulnerability of the trust centre, but decreases the overall security of the network.

3.7.5.1 Lighting and residential home control

ZigBee can be successfully and securely deployed in the home scenario. The major issue is making the setup of the sensor nodes simple enough. The scalability of the network is not a problem.

3.7.5.2 Building monitoring and control

The low mobility nature of the network allows ZigBee to be deployed without significant overhead from the security framework.

3.7.5.3 Long term medical monitoring

Even if a number of sensor nodes moves around the rest of the network can stay connected. This limits the overhead from the topology changes. As the network is not especially large it should be possible to use ZigBee in this scenario.

3.7.5.4 Emergency medical monitoring

The mobile nature of the network along with the frequent membership changes and high security demands make the commercial security model a requirement. Even if the trust centre can handle the load (which does not seem reasonable on the hardware examined), the large scale of the network will put a heavy load on the routers close to the trust centre. In addition, there is not any suitable key establishment routine. On the current hardware it is not possible to deploy such a network in commercial mode due to the memory limits.

3.7.5.5 Disaster monitoring

The disaster-monitoring scenario shares many of the properties of the emergency medical monitoring scenario. The size of the network makes the security infrastructure of ZigBee ill suited and the overhead of frequent membership changes along with the security framework makes it hard to deploy ZigBee in such an environment. On the examined hardware it is not possible in commercial mode due to the memory limits.



23

4 Security analysis of ZigBee The only real security that a man can have in this world is a reserve of knowledge, experience

and ability. (Henry Ford)

This analysis is based upon the study of the standard documents, including the IEEE 802.15.4 standard [3] and version 053474r14 [5] of the ZigBee 2006 standard. It does not contain any examination of the physical layer, due to limited time and resources. Applications have also been left out, as they depend only on the usage of the network and are not part of the ZigBee specification.

The IEEE 802.15.4 standard contains the specifications of the physical (PHY) and the media access (MAC) while ZigBee covers the network (NWK) and application (APL) layers. The application layer is named Application support sub layer (APS) in the ZigBee standard, but this term will not be used.

Figure 2: Illustration of the IEEE 802.15.4 and ZigBee Stack. Notice the complex relationships.

While IEEE 802.15.4 and ZigBee have coevolved to a large degree they still retain a strict interface and are two separate standards. IEEE 802.15.4 is often used as a stand-alone link protocol when the network and application functionality of ZigBee is not needed and it is theoretically possible to run ZigBee on top of another protocol, even if I am not aware of any such implementation. For that reason IEEE 802.15.4 and ZigBee are examined separately.

When deploying ZigBee a number of choices have to be made, and one of the most important is how much of the software and hardware to buy and how much to develop internally. Certifications are needed both for compatibility with the IEEE 802.15.4 standard and with ZigBee. If an already certified implementation of IEEE 802.15.4 and ZigBee is used the certification process is significantly simplified. The certifications are intended to prevent interference and ensure interoperability between ZigBee devices.



24

4.1 IEEE 802.15.4-2003 Compared to the widely deployed IEEE 802.11 the IEEE 802.15.4 is limited. Limited speed,

limited code size, limited range, limited power usage and most importantly: Limited cost.

The IEEE 802.15.4 standard is used for low data rate communication between battery-powered devices over long periods. An expressed goal of the standard is to make the stack simple in order to keep the stack size down. It is intended for networks needing to function for months or years.

The standard defines the PHY and MAC layers in the architecture. It provides point-to-point links as well as broadcasting and reliable single hop transport. Security is performed on link level and the security services offered are access control, integrity, confidentiality, and replay protection.

AES is used for the encryption and integrity checking. Sastry and Wagner have done an analysis of the security in IEEE 802.15.4-2003 networks, and below I present a summary of their findings [18] along with some of my comments on the improvements made in IEEE 802.15.4-2006.

4.1.1 Introduction

An IEEE 802.15.4 network is divided into PAN (Personal Area Networks) with separate PAN IDs. Each pan is controlled by a PAN Coordinator. For communication a short-range 2.4 GHz radio is used. Multiple PAN can be linked together to form larger networks. Inside each PAN two topologies can be used: star or mesh. In a star topology all traffic goes through the PAN coordinator, in the Mesh sensor nodes can send data directly to other sensor nodes. Using the mesh topology the network can be extended beyond the range of the PAN Coordinator.

Figure 3: PAN topologies (IEEE 802.15.4 standard).

Using these topologies as basis larger networks can be built. The clustered tree topology is created by letting sensor nodes at the edges of one PAN become coordinators of new PAN. This creates a tree structure of PANs from the original coordinator and outwards.



25

Figure 4: Clustered tree network (IEEE 802.15.4 standard)

The coordinator of each PAN decides on a super frame format. Inside the super frame CSMA-CA4 is used to distribute 16 timeslots. It is also possible for the coordinator to reserve timeslots for specific senders, called guaranteed timeslots or GTS. Each super frame starts with a beacon message containing the settings for the PAN. The super frame might contain an idle period to save battery. During this period the devices can power down their radio, only to power up again when to receive the next beacon. Each device belongs to a single PAN, but it is possible to create a link to a second PAN.

Figure 5: Super frames in IEEE 802.15.4 (IEEE 802.15.4 standard).

4 Carrier Sense Multiple Access – Collision Avoidance. An algorithm to prevent collisions when multiple devices share the same medium.



26

4.1.1.1 Beacon frames

Beacon frames are used to announce the settings of the network and synchronize the devices. Beacon frames allow devices to save energy by turning off their radio receivers when they do not expect to receive any data. Beacon frames transfer the security settings used by the network. Beacon frames can be secured, but the initial frames are always sent unsecured. The beacon frame has the following format:

Octets 2 1 4/10 0/5/6/10/14 2 variable variable variable 2

Field

Frame control

Sequence number

Addressing fields

Security header

Super frame specification

GTS fields

Pending address

fields Beacon payload FCS

5

Type MAC header MAC payload MAC trailer

Figure 6: Beacon frame

The addressing field is used to identify the recipient of the frame. The sequence number is used to prevent replay of frames. The security header holds information about the security methods used to secure the MAC payload. Super frame specification gives details on how the frames in the network are built up. The GTS fields details the assignment of Guaranteed Time Slots to associated neighbours.

4.1.1.2 Command frame

Command frames are used to send commands for the management of the network. They are an integrated part of the IEEE 802.15.4 standard and simplify the network management. Command frames are most importantly used in the association and disassociation procedures. The command frames have the following format:

Octets 2 1 4/10 0/5/6/10/14 1 variable 2

Field Frame control

Sequence number

Addressing fields

Security header

Command frame identifier

Command payload FCS

Type MAC header MAC payload MAC Trailer

Figure 7: Command frame

The only payload of command frames are the identifier of the command and the payload of the command.

4.1.1.3 Data frames

The data frames carry the data being transferred. It is a simple frame and has the following format:

Octets 2 1 4/10 0/5/6/10/14 Variable 2

Field Frame control

Sequence number

Addressing fields

Security header Data payload FCS

Type MAC header MAC payload MAC Trailer

Figure 8: MAC layer data frame

The payload of the frame is the data being transferred.

5 FSC: Frame Check Sequence. Used to verify the correct transmission of the frame



27

4.1.1.4 Acknowledgement frames

The acknowledgement frame is used to provide reliable transport. It can be requested when sending a data frame.

Octets 2 1 2

Field Frame control Sequence number FCS

Type MAC header MAC Trailer

Figure 9: MAC layer acknowledgement frame

Notice the lack of a MAC payload field.

4.1.2 Security overview

A sensor node following the IEEE 802.15.4 standard can work in either unsecured or secured mode. Security is decided separately for each packet. When a packet is supposed to be sent over a link, a flag is used to signal if security is to be used. If this flag is set, the sensor node checks in the Access Control List (ACL) if there is an entry for the source-destination pair. The ACL entry contains the address, the security suit, and the security material to use. If there is such an entry the sensor node uses the material to secure and send the packet. If there is no entry the default entry in the ACL is used instead. The IEEE 802.15.4-2003 standard offers four basic security suits: None, AES-CTR, AES-CCM and AES-CBC-MAC.

When receiving a packet a flag in the header is used to signal if security has been used. If this flag is set the ACL is checked for an entry and the security material in the ACL is used to decrypt the packet.

Only the MAC payload part of the data is actually secured. The physical layer headers are not secured.

4.1.3 Advanced Encryption Standard (AES)

Rijndael was chosen 2001 by NIST (National Institute of Standards and Technology) as AES, replacing the older DES algorithm [9]. Today the American government uses the algorithm for information classified up to and including top secret [19]. AES with 128-bit keys is the encryption algorithm that is used as a basis for the security in IEEE 802.15.4 and used in all of the security suits. AES is today considered secure, as there is no known attack on the algorithm that is more efficient than exhaustive search of the key space. However, there are several well-known reduced round attacks on 128 bit AES up to 7 rounds out of 10 (see [20, 21]). There have also been successful side channel attacks on AES implementations [22]. Side channel attacks are not considered an issue in WSN design, at the lack of physical protection for the sensor nodes make other attacks, such as simply reading out the encryption keys over the debug interface, much easier. If the physical security of the devices is improved in the future side channel attacks might be deployed to get around the protection.

AES has been carefully examined and is as secure as we can expect a modern cipher to be. The algorithm is well suited to provide security on an IEEE 802.15.4 sensor node.

4.1.4 Security suits

IEEE 802.15.4 offers a set of security suits. Suits are set on links and together with the security material for the link used for all packets where security is requested. The suits define how to use the AES cipher to secure the packets and offer different security guarantees.



28

4.1.4.1 None

This is the basic security suit and it offers no security. It is the default if security has not been activated. It does not modify the packets in any way. There are no security guarantees and we will not discuss this mode further.

4.1.4.2 AES-CTR

AES-CTR uses AES in counter mode, which turns AES into a stream cipher. A counter (the nonce) is encrypted using the key associated with the link. This results in a set of blocks. These blocks are then used just like an encryption stream in a stream cipher and XORed6 with the message to be encrypted. Performing the same action again decrypts the data.

According to the standard AES-CTR offers encryption and freshness. However, the freshness protection is very limited No integrity checking of the messages is built into this mode. Without integrity checking this encryption mode is weak and might expose other weaknesses in the protocol.

It is trivial manipulate packets and bypass the freshness counter, creating a DoS situation. For example by flipping a high bit in the freshness counter and force the receiving node to discard following traffic. Sastry and Wagner recommend not implementing this mode. ZigBee does not use this mode.

Figure 10: Counter mode encryption (Public domain).

4.1.4.3 AES-CBC-MAC

AES-CBC-MAC offers integrity and authentication of messages. The MAC is calculated using cipher block chaining (CBC) and covers the whole packet, including headers. To calculate the MAC start with an initialization vector of 0, XOR the vector with the first message block and encrypt with the current key. The result of this operation is XORed with the second message block, a second encryption follows, and so on. The result of the final encryption is the MAC. The MAC is added to the end of the original message.

There is no confidentiality protection in this mode. There are three different variants defined, depending on if the MAC should be 32, 64, or 128 bits long. Truncating a full length MAC after the calculation creates a shortened MAC. MAC codes of 32 bits are not considered computationally secure and should not be used without extra protection against attacks [23]. ZigBee does not use this mode.

6 XOR is a binary primitive where A XOR B is true if and only if A or B but not both is true. Therefore:

(1 XOR B) XOR B = 1 and

(0 XOR B) XOR B = 0

letting us encrypt and decrypt using the same operation, as long as we know the value of B. B is often known as key stream. See chapter 6 of Handbook of applied cryptography.



29

Figure 11: Cipher block chaining MAC (Public domain).

4.1.4.4 AES-CCM

This mode comprises two-step process, first using a CBC-MAC to calculate the MAC of the message, then AES-CTR to encrypt the data and the MAC. The mode ensures confidentiality, integrity and freshness of the transferred packets. Just as with AES-CBC-MAC there are three different variants defined depending on the size of the MAC (32, 64, and 128 bits). So far no critical flaws have been found in CCM, even if the mode has been criticised [24] due to the complexity and unclear tradeoffs between performance and security. ZigBee uses a modified version of this cipher mode called CCM* (See 4.2.6 for a detailed analysis).

4.1.5 Initialization vectors

To use AES in counter mode initialization vectors are needed. A combination of initialization vector and key may never be reused, as this will result in a break of the confidentiality when two different clear texts are encrypted with the same stream. A simple XOR of the two encrypted messages will remove the encryption and return the messages XORed together. This is a well-known issue with stream ciphers and can be used in attacks [25].

Due to this fact the same key may not be reused in several ACL entries, as they might use the same initialization vector and break the confidentiality. To use the same key when communicating with several different partners the initialization vector has to be preserved, for example by using a single ACL entry.

A related problem is that the initialization vector must not be lost. If the sensor has a power failure or resets, it will possibly lose the initialization vector stored in volatile memory. This will result in a situation where the sensor will not know if it is reusing an old initialization vector or not. Therefore, the initialization vector has to be stored carefully and protected from power failures, or the keys have to be changed after the sensor recovers from an error where it is likely that the initialization vector has been lost.

Part of the initialization vectors is sent along with each frame as it is transferred in the form of the frame sequence number. The actual data used by the cipher is constructed by a concatenation of the senders 64-bit IEEE address, the sequence number and the security control field. It is a total of 104 bits, with a 32-bit frame counter.

Octets 4 1 variable 4/8/16

Field Frame counter Key sequence counter Encrypted payload Encrypted integrity code

Figure 12: MAC layer secure payload. Notice the addition of a Frame counter (IV).



30

4.1.6 Group keying in IEEE 802.15.4

Group keying is used when as set of sensors share a single key for communications. Typically any member of the group should be able to communicate securely with the group. This is very useful if the network is used for more than one task and not all members of the network are trusted. The only group key is used in IEEE 802.15.4 networks is the default key, which allows communication with all members of the network. All other keys have to be single link keys. An attempt to use group keys in IEEE 802.15.4 networks will run into a (non-obvious) security issue:

All encryption in based on the entries in the ACL. Therefore, to use a group key for several partners we would have to make multiple entries in the ACL. However, multiple ACL entries with the same key create a risk of reusing a nonce, because the nonce only depends on information about the sender (see 4.1.5) and not the receiver. Due to this fact group keying does not seem to be possible in pure IEEE 802.15.4 networks.

One possible workaround is to use a single ACL entry and change the destination in the ACL to match the current communication partner. It would work for sending the data, preserving the IV, but it would be very hard to predict which neighbour will send data next.

If group keying is to be used it has to be implemented at a higher layer where separate counters are kept for each sender. In this case it is possible to ensure the freshness of each partner the sensor node communicates with as well as having a single outgoing counter.

It is important to notice that there is no replay protection when using a network-shared key in IEEE 802.15.4. As there is only one ACL entry for each key it does not keep separate replay counters for different senders when receiving data secured with the network key. Therefore it is impossible to predict which value the replay counter of the partner should have and replay attacks cannot be prevented. This can be resolved at higher layers, but MAC layer messages cannot get this protection without changes to the standard.

4.1.7 Acknowledgement packets

The acknowledgement packets are sent in clear, with no integrity or confidentiality protection. This is because only the MAC payload is secured in IEEE 802.15.4 and acknowledgement messages have no MAC payload. The acknowledgement messages are therefore unsuitable for critical tasks. It is possible to observe a packet being sent, jam the transmission, and then create an acknowledgement packet to lure the sender into believing that the packet has been received. The acknowledgements can therefore not be relied on for critical tasks and instead acknowledgements have to be implemented on a higher layer where integrity and confidentiality protection can be guaranteed.

Figure 13: MAC layer acknowledgement, no MAC payload (IEEE 802.15.4 standard)



31

4.1.8 Beacon packets

IEEE 802.15.4 uses a beacon system to announce available networks. These beacons contain the global settings the network is using and are sent in clear text. A device wishing to join a network simply listens for a predefined period and uses some kind of internal mechanism to choose which of the announced networks to join.

During the initial parts of the join procedure the beacons are not secured. Therefore, a device cannot verify that the beacon is legitimate in anyway, and it has to apply the network settings in the beacon to join the network. These network settings include the level of encryption used and guaranteed time slots. It is therefore possible to turn off the encryption or denying it a timeslot.

Allowing the encryption of the beacon packet using the network key (in the case of preconfigured keys) would prevent this kind of attack, but there is no easy way to prevent replay attacks on the initial beacon.

Due to this issue it is critical to do sanity checking when joining a network, to ensure the device actually joins the right network and uses the right settings.

Figure 14: The IEEE 802.15.4 beacon frame (IEEE 802.15.4 standard)

4.1.9 Replay protection

There exists a simple system for reply protection, relying on the incoming frame counters. It is important to notice that on the MAC layer no replay protection exists when using the default key, as separate replay counters are not kept for all neighbours the sensor node is communicating with unless it has established link keys to those sensor nodes.

4.1.10 IEEE 802.15.4 –2006

Late in 2006 an updated version of the IEEE 802.15.4 standard was released with a number of corrections, clarifications, and changes to simplify the implementation of the standard. The following additions and enhancements can be found in the 2006 edition [26]:

• Support for a shared time base through the addition of a data time stamping mechanism.

• Extensions of the 2.4 GHz derivative modulation yielding higher data rates at the lower frequency bands.

• A mechanism for communicating the revision level on a frame-by-frame basis.

• Support for beacon scheduling.



32

• Synchronization of broadcast messages in beacon-enabled PANs.

• Improved usage of the security suite.

Also, a number of changes and simplifications can be found in the standard:

• Makes GTS (guaranteed time slots) support optional.

• Removes restrictions for manually enabling the receiver.

• Simplifies passive and active scan procedures.

• Allows higher flexibility in the CSMA-CA algorithm.

• Reduces association time in non beacon networks.

Only the changes done to the security suit have a clear impact on the security properties of the standard. Most importantly the AES-CTR and AES-CBC-MAC modes have been removed in favour of the CCM* cipher mode. This simplifies the implementation of ZigBee as the same cipher mode can be used on all layers in the stack. However the security problems with the AES-CTR and AES-CBC-MAC mode remain as CCM* can be configured to work in similar modes. There have been no changes to the acknowledgement messages, so they are still sent unsecured. For details on CCM* see section 4.2.6.

4.1.11 Conclusions

IEEE 802.15.4 offers basic security protection to data being transferred, but with several important limitations. These limitations will later influence the security of ZigBee.

The AES-CCM mode should be used, with a sufficiently long MAC to prevent attacks on the cipher. In the 2006 version CCM* is used, once again with a long enough MAC and confidentiality protection.

The joining sequence is insecure. It is not possible to authenticate a network until after the joining is complete, even if keys are shared with the network. Sanity checking can be used to partly avoid this problem.

It is important to monitor the usage of initialization vectors, as the standard has several points with significant risk of IV reuse. The same key must not be used in more than one ACL entry to prevent nonce reuse. Finally we cannot use the acknowledgements in any critical applications, as they are easy to spoof.



33

4.2 ZigBee 2006 ZigBee is an attempt to build a general purpose WSN on top of IEEE 802.15.4, including

multi hop routing, security, and API. It is the first commercial product of its kind.

The version of ZigBee standard [5] examined is a 564 page long document. This examination of the standard is not a complete security review, as it would not be possible in the time offered. In particular the routing and network control functions of ZigBee have not been examined. No previous security analysis of ZigBee has been found despite an extensive search of available public resources.

4.2.1 Introduction to ZigBee

While IEEE 802.15.4 provides a good foundation for a wireless network it lacks several things. There is no support in IEEE 802.15.4 routing and only limited options for network management. The security of IEEE 802.15.4 does not provide end-to-end security or any sort of key management. Applications built on top of IEEE 802.15.4 will have to interact directly with the MAC layer to function, which puts an extra burden on the programmer. To avoid these problems ZigBee introduces a network layer, providing end-to-end communication and security. A complete infrastructure for security management is introduced. In addition to this ZigBee supplies a number of tools to simplify the interaction with the WSN and provide clean interfaces to the hardware. While the application support framework and API are a critical part of the ZigBee standard it does not have direct impact on the security and therefore it will be left out of this thesis.

4.2.1.1 ZigBee sensor nodes

ZigBee defines three types of sensor nodes, namely coordinators, routers, and end devices. Any sensor node can run any sort of application, but the sensor nodes have special properties in the topology of the network.

• A ZigBee coordinator is the start of the network and responsible for the network wide settings. Typically this is also the trust centre of the network. A trust centre is an application running on a ZigBee node that acts as a trusted third party in a number of security functions.

• A ZigBee router is a sensor node that can act as a router and relay traffic through the network. Routers may also be able to act as coordinators if needed.

• A ZigBee end device is a simple sensor node that may only authenticate with a router or coordinator. It cannot route messages on its own, instead it relies on its parent to handle all the routing. End devices can be made considerably simpler than routers or coordinators, saving power.

4.2.1.2 Routing

ZigBee uses three different routing algorithms, depending on the topology of the network. A ZigBee network can never span over several IEEE 802.15.4 PAN.

• In a star network only a single router exists, the coordinator. All messages are routed through the coordinator.

• In a clustered tree network a form of structured tree routing is used. The routing algorithm relies on structured assignment of the addresses in the network. All routing is done up and down along the tree extending from the coordinator. No cross connections are allowed as this would break the tree structure of the network.



34

• In a mesh network a routing algorithm based on Ad-hoc On-demand Distance Vector Routing[27] is used. In this topology routers can form paths to any neighbour within range.

When building applications in ZigBee an application profile is used. The application profile defines interfaces for interacting with other members of the ZigBee network as well as many of the basic settings for the network. A few predefined application profiles exist to promote interoperability, but it is also possible to use a private profile for a specific application. These application profiles form a basis for the actual application. Many of the security settings are defined in the application profile.

4.2.2 Security basics

ZigBee uses the AES algorithm with 128-bit keys for all its security functions. It uses the CCM* cipher mode for encryption and integrity checking. This is a variation of the CCM algorithm as defined in RFC 3610 [28]. The main differences between CCM* and CCM are the confidentiality only and integrity only modes (see 4.2.6 for more information). There is no requirement or description of asymmetric cryptography in the standard.

4.2.3 Security assumptions

ZigBee makes several security assumptions. Most importantly the security model of ZigBee is based on trusting all sensor nodes that are part of the network. This is an unusual trust model for a WSN, where the sensor nodes are often not considered physically secure and can be captured. AES is assumed to be secure and all security critical functions are assumed to be correctly implemented.

4.2.4 Security model

For security purposes all logical parts of a ZigBee sensor node trust all other parts. There is no requirement of protected storage or similar for security material. Due to the limited storage and problems building a logical separation of different programs in a tightly constrained sensor node this makes sense, even if it does expose critical security material to flaws in other programs running on the sensor node.

This model also results in keys being bound to links between sensor nodes (unlike in IP style networks, where keys are usually bound to links between layers in the stack). Keys can be reused on several layers and the sensor node has only one ACL entry for each key.

A special key, the network key, is shared between all authenticated sensor nodes in the network. In secure mode this key is used to secure all frames where there is no link key available. All communication between authenticated sensor nodes uses the same security mode. If an application demands higher security than the network offers, it is expected to create a new network providing higher security.

Application keys are used for multi-hop communication between two sensor nodes. Only the two sensor nodes involved in the communication and (in some cases) the trust centre knows the application key for the link.

4.2.5 Trust centre

The trust centre is a program at a sensor node that all nodes in the network use for authentication and key setup. The trust centre is used as a basis for access control and key distribution in ZigBee. Usually, the trust centre is located on the network coordinator and, while it is theoretically possible to set it at another router, it does not seem practical to do so due to bootstrapping problems; to set up the initial trust between the coordinator and connected routers the coordinator needs to have access to a trust centre. The only other way is hard coding how the initial parts of the network are to be connected using direct joins or rejoins which breaks the idea of a self-organizing network.



35

Only one trust centre may exist in a network. The trust centre can be in either commercial mode or residential mode depending on the security required and memory available. The trust centre is used in all secure modes and is a single point of failure in the network. If the network is non-trivial in size the sensor node with the trust centre will most likely need a permanent power supply or it will fail due to power exhaustion before the other sensor nodes.

If a sensor node loses contact with the trust centre it has to leave the network and try to rejoin. This is to prevent network splits, but simplifies DoS attacks, as taking down the trust centre will take down the network.

4.2.5.1 Residential mode

In residential mode the trust centre may only hold the network key, saving considerable memory for the trust centre. In this mode all traffic from and to the trust centre is secured with the network key, but nodes might set up link keys for additional security in their communications.

4.2.5.2 Commercial mode

In commercial mode the trust centre stores the link keys and master keys in addition to the network keys. All secure communications to and from the trust centre are done with trust centre link keys. The trust centre needs significantly more memory in this mode.

4.2.6 CCM*

CCM* is a modification of the CCM [28] algorithm that allows to have a MAC length of 0 bits. The cipher mode can provide authentication, encryption or both. In authentication only mode CCM* has identical properties as AES-CBC-MAC in IEEE 802.15.4 and in encryption only mode it is identical to CTR mode.

The option to use MAC length of 0 bits introduces encryption without authentication. This is dangerous, especially when using a stream cipher, and should be avoided if possible.7 When CCM* is used in encryption only (mode 0x04) a DoS attack can easily be done by sending a packet with a high frame count, getting the receiver to discard following packets. Due to the stream nature of the cipher simply taking a captured packet and flipping some of the high bits in the frame counter creates such an attack.

Two of the security modes, 0x01 and 0x05 offer MAC of 32 bits. A 32-bit MAC cannot be considered computationally secure in general purpose networks as it is possible to launch brute force attacks on such a short MAC [23]. The limited bandwidth of IEEE 802.15.4 makes such attacks harder, but not impossible. Therefore extra protection has to be built into the network if a short MAC is used.

CCM has been heavily criticized by Rogaway and Wagner in [24] on several points. A summary of those are:

4.2.6.1 Efficiency

Compared to other cipher modes CCM is not especially efficient. There are several efficiency issues. The algorithm is not an online algorithm, which means it is not possible to process streaming data without knowing the full length of the data being processed. In addition to this the algorithm disrupts word alignment in the encrypted data and does not allow pre-computation of the key stream.

7 Encryption without authentication is sometimes used in stream protocols where throughput is more important than correctness and the algorithms are built to handle bit errors. This is common for the data channel in mobile phone networks, where losing whole chunks of data is unacceptable. It is important to notice that general-purpose protocols, such as ZigBee and applications running on ZigBee, are usually not built to handle such attacks.



36

4.2.6.2 Parameterization

One of the parameters that is set when employing CCM has strange effects. There is a parameter making tradeoffs between the maximum message length and the size of the nonce, two conceptually unrelated parameters, forcing shorter nonce when the maximum amount of data to be transferred grows. The user of a cipher mode should not have to make such a choice.

4.2.6.3 Complexity

The cipher mode has a very high complexity, which in itself is an issue when it increases the risk of faulty implementations. Some seemingly innocent changes to the input parameters are enough to break the security of CCM. For example, the encoding does not allow two byte tags. This is due to the fact that one of bit 3,4 or 5 in the first block must be non-zero or the security proof will not hold [24]. There is also a large amount of bit manipulation in the cipher mode, making it much harder to understand the mode.

4.2.6.4 Conclusions

The use of CCM* needs a careful review, but this is beyond the scope of this thesis. The changes done to CCM could be introducing even more security problems. CCM* is an integrated part of ZigBee and is unlikely to be replaced.

4.2.7 Key types in ZigBee

All keys in ZigBee are 128 bit and intended to be used with the AES-CCM* cipher. There are several types of keys defined in ZigBee to be used for secure communication.

4.2.7.1 Network key

A network key is a shared key that all sensor nodes in the network have access to. This key is used to secure broadcast messages, and the nature of the routing algorithm makes this key critical to secure routing. Frame counters are used to provide proper amounts of replay protection. There are several grades of network keys, residential, standard, and high-security, the only difference being how they may be transported. High-security keys may only be sent using trust centre link keys. Standard and residential keys may be sent using a previous network key. Only one network key can be active at any one time. Network keys can be updated and have associated sequence numbers. These keys are also used to authenticate sensor nodes in the joining phase.

Network keys offer confidentiality and authenticity only against attackers outside the network due to their shared nature. They can be used when no link keys are available. In a large network the frame counter quickly becomes a limiting factor. To provide replay protection separate frame counters have to be kept for each communicating member of the network.

Current revisions of the ZigBee standard are trying to resolve this issue by forcing localized use of the network key and re-encryption after each hop in the network.

4.2.7.2 Link keys

The second type of key is the link key. It is used to secure communication between two sensor nodes. In addition to this the link key is used to create two related keys, key-transport key and key-load key. These keys are simple hashes of the link key. The key-load key is used to protect the transfer of master keys and the key-transport key is used to protect the transfer of other keys.

There are two variations of link keys, the application link keys, for communication with other sensor nodes, and trust centre link key, for communication with the trust centre. Link keys can be established either by using a master key and SKKE, or transported directly from the trust centre.



37

4.2.7.3 Master keys

The standard also defines a “Master key” (pre-shared secret) that can be used in the link key establishment protocol. Two separate types of master keys exist, the first is the application master key and the second is the trust centre master key. Application master keys should be distinct for each pair of sensor nodes.

4.2.8 Stack layer security

ZigBee specifies that a packet can only be secured at a single layer, unlike the traditional IP model where each layer provides separate security guarantees for the packet. Security is provided at the layer that originates the packet. Depending on the originating layer different parts of the packet are secured. Reuse of keys for different purposes and layers is a breach of traditional security design principles. In addition, it is not always clear which security guarantees a packet actually has. A sender can request application layer security for a packet, but the packet will be sent using network key if no application link keys are available.

4.2.8.1 MAC layer

If a packet originates on the MAC layer the whole packet except for the physical layer headers is secured. This is the security provided directly by IEEE 802.15.4. Note that the acknowledgement frame is not secured even if MAC layer security is used.

The key used is a link key, if there is one available. If no link key is available the network key is used instead. No separate keys are kept for the MAC layer

Figure 15: Mac layer security (ZigBee standard).

4.2.8.2 Network layer

If a packet originates on the network layer the MAC headers are left unsecured. The network key is used, a key that is shared among all devices in the network. The device may also use link keys, which provide a higher grade of security, but this is not required. The network key does not provide protection against attacker that is already inside the network.

Figure 16: Network layer security (ZigBee standard).



38

4.2.8.3 Application layer

If a packet originates on the application layer the network headers are also left unsecured. Auxiliary headers are used to verify the network data. If no application layer keys are available the network key will be used instead, providing less security than would be expected from the end-to-end encryption provided by the application link key.

Figure 17: Application layer security (ZigBee standard).

4.2.9 Key transport

Keys can be sent over radio. Usually this should be done using already secured links. After reception of a key, the sensor node verifies that the correct keys and methods have been used in the transfer before accepting the key. Application link, master, trust centre link, and high security network keys may only be sent using the trust centre link key. If they are sent using any other type of key for security the transported key is discarded. Residential and standard network keys may, in addition to the trust centre link key, be sent with the active network key. A node can also initiate the transaction by requesting the key from another sensor node.

There is a system to broadcast key updates from the trust centre to all nodes, without forcing the trust centre to Unicast the key to each member of the network. This relies on each sensor node flooding the key to all of its children.

If the node lacks trust centre master key, network key, and trust centre link key one of them can be sent over radio without protection. There is no security in this mode, and none of the communication secured with this key can be assumed confidential or authenticated.

4.2.10 Key Agreement

ZigBee uses SKKE[5] for key agreement, i.e., a symmetric protocol based on a pre-shared secret (called master key in ZigBee). Key agreement can be initialized in several ways. It is used as a part of the authentication routine and two devices sharing a master key can use SKKE to setup link keys. Most of the time key agreement is started by key transport from the trust centre to the two devices involved.

In the following example a device wishes to initiate a secure connection to another device. It begins by sending a Request-Key message to the trust centre. The trust centre responds with the Transport-Key command, sending application master keys or application link keys to both the initiator and the responder. If the trust centre sent out master keys the devices then continues with the SKKE protocol to establish link keys. Finally the result is reported to the ZigBee Device Object (ZDO) that requested the connection.



39

Figure 18: Key establishment (ZigBee standard).

4.2.10.1 The Symmetric key key exchange

SKKE is based on the ANSI X9.63:2001[29] standard. With small variations it can be used both for key exchange and for authentication. It is a three or four pass protocol, depending on if unilateral authentication is needed or not, and uses symmetric methods. This is a description of the SKKE for key exchange.

U (Initiator) V (Responder)

QEU

QEV

MACMasterKey(0316||U||V||QEU||QEV||[Text2]) [Text2]

MACMasterKey (0216||V||U||QEV||QEU||[Text1]) [Text1]

Link key

Figure 19: The SKKE protocol.

4.2.10.2 Initiator message 1

The initiator (U) of the protocol generates the challenge QEU. This challenge can be a structured or strictly random number, as long as it is not reused. The length of the challenge is 80 bits in ZigBee.



40

4.2.10.3 Responder message 1

The responder (V) sends a challenge in return (QEV). This challenge is also 80 bits in length.

4.2.10.4 Initiator message 2

The initiator of the message responds with MACKey(0316|U|V|QEU|QEV|[Text2]),[Text2]. In this exchange U and V are the 64-bit identifiers of the sensor nodes. Text2 is an optional text that the initiator wishes to share with the responder. By computing the hash the initiator proves that he knows the key needed for the exchange.

4.2.10.5 Responder message 2

The responder then generates MACKey(0216|V|U|QEV|QEU|[Text1]), [Text1] in return, using the shared secret as the key. Text1 is optional if the responder wishes to share authenticated data with the initiator. By computing the hash the responder proves he has access to the key for the exchange.

4.2.10.6 Key generation

The key is finally generated by using the hash function again: MACKey(U|V|QEU|QEV). The key is therefore only dependant on the pre-shared secret (the hash key, known as master key), the identifiers and the two public values QEU and QEV. Both sides can verify that the other side has the shared secret and can compute the key.

4.2.10.7 Variations

It is possible to combine the two responder messages into one single message, sending QEV| MACKey(0216|V|U|QEV|QEU|[Text1]), [Text1] as a single message and thereby save one packet. The same amount of data has to be transferred but the overhead is lower. This variant allows an attacker to hash partially chosen data (as he can choose QEU freely) and might simplify attacks on the hash algorithm. However, I am not aware of any attacks on the CBC-MAC based on partially chosen plaintext.

4.2.10.8 Analysis

No cryptanalysis of SKKE has been found. What follows here is a limited analysis of the protocol.

SKKE relies on the strength of a keyed hash algorithm (in the case of ZigBee this hash is AES-CBC-MAC with 128 bits keys) and the confidentiality of the key used. An attacker monitoring the protocol will get the two public values QEU and QEV as well as the hashes. The identifiers U and V are known. If the attacker (at any point) compromises the MAC algorithm or the MAC key he will also get the encryption key and all messages secured with the key from this exchange will be compromised. This is a problem with all symmetric key exchange protocols, and therefore they do not offer perfect forward secrecy. If the MAC stays secure the protocol offers both authentication and integrity protection of the key exchange.

When the initial exchange is done between a joiner of the network and the trust centre the first router will encrypt the messages. While this prevents snooping in other parts of the network it opens the network to chosen plaintext-known cipher text attacks.

CCM* is a stream cipher. Therefore, encrypting the same message twice with the same key and counter will leave the clear text. If an attacker can reset the counters in a router somehow he will be able to decrypt arbitrary messages that have been secured from the router to the trust centre by feeding them into the SKKE protocol and letting the router encrypt them again for him (after waiting until the counters are in the same state as when the messages were first encrypted).

Beyond attacks such as physically resetting the device or exploiting software flaws the counters are reset by successful authentication or receiving a key transport message. It is not clear if this is a security problem, as normally both of these events should result in new keys, but it is easy to imagine implementation faults or replay attacks causing IV and key reuse scenarios.



41

4.2.11 Switching keys

For the network key, and only for the network key, a system to switch the key has been defined. This system is based on the transport of new key with a sequence number. After the key has been transferred, a special command can be broadcast to get all sensor nodes to switch to the new network key. This offers some additional freshness protection. Other keys can be replaced using key transport, but there is no protocol for the simultaneous switching to a new link key, which can lead to synchronization issues.

There is no protocol to remove keys from a device.

4.2.12 Joining the network

A sensor node can join the network at any time. Three types of joining exist: Unsecured joining (if the sensor node lacks the network key), secure joining (if the sensor node has the network key), and Orphan joining (if the sensor node has lost contact with the network). Authentication is normally done by the trust centre. The messages between the trust centre and the joiner are either forwarded by the router or sent directly. A router can decide not to allow joining if it lacks resources to handle more children.

Figure 20: Joining a network (ZigBee standard).



42

If the sensor joins without the network key it will be declared “unauthenticated” to the trust centre; if it used a network key when joining it will be declared “authenticated”.

A sensor that has joined a secure network in “unauthenticated” mode needs a network key to be able to fully join the network. If the sensor already has a trust centre master key it is used to generate a secure connection to the trust centre(using SKKE if the master key is available) and transfer the current network key. If no such key is available the key can be sent without security, which will compromise the network key for the whole network, as an attacker can easily break the SKKE exchange with access to the master key used.

A sensor node that has not authenticated should not be allowed to route data through the network, but the standard does not make this clear. According to the standard an unauthenticated device does have a network presence in the routing, but the setting UseParent is used to force the sensor node to send all packets through the parent router (unless it is the trust centre). This setting might be turned off for various reasons, such as if the setting nwkSecureAllFrames is not used. This exposes the network to attacks on the routing (for example memory exhaustion by using spoofed addresses to create virtual nodes) and leaves the device in an unclear state. If the authentication between the trust centre and the router is jammed, the device might be able to remain in the network without authentication for a long time, as no handling of this situation is defined.

4.2.13 Authentication

Authentication is done after a sensor node joins the network. Authentication is always done through the trust centre, either by direct communication between the sensor and the trust centre, or by communication using the router where the sensor is connected as a relay.

4.2.13.1 Residential authentication

Residential authentication is very simplistic due to the lack of shared keys between the trust centre and the device joining the network. The trust centre only knows the MAC address of the joiner, if he has a network key and which router he has joined at. It allows joining to be turned on or off, but little more.

Figure 21: Residential authentication (ZigBee standard).

4.2.13.2 Commercial Authentication

A protocol to authenticate other sensor nodes based on shared secrets (keys) exists, resembling the SKKE protocol. This is used as a part of the admission control after the sensor node has joined the network under the commercial security model. After verifying through authentication that a sensor node has a specific key it can be used to authenticate all communication with the sensor node,



43

preventing attacks. This protocol can be used by the trust centre when a sensor node joins the network. In the specification the network key is used for authentication.

Figure 22: Commercial Authentication (ZigBee standard).

4.2.13.3 Authentication problems

Authentication resets outgoing frame counters for the network key as well as all incoming frame counters, which leads to replay attack issues as well as lost traffic. If a sensor is part of a network, disconnects and later goes through the authentication routine an attacker can replay old traffic. As long as the attacker can block legitimate traffic with correct frame counters the sensor node will accept the traffic. Only when the sensor node gets a legitimate package will it update the incoming frame counter to the correct value.

It is also possible that the sensor node cannot communicate with a specific sensor node using the network key if the neighbour still keeps the previous replay counter for the joiner. It might be better not to reset the counters, but this is a breach of the standard.

If a sensor node has the network key it can, instead, use the network rejoin procedure. This way it bypasses the trust centre authentication and joins the network directly. This is possible even if joining has been turned off for the whole network.

4.2.14 Multicast

There is support for multicast and broadcast of packets, using flooding and a table of freshness counters to avoid implosions. It should be noted that authenticity and integrity might be hard to guarantee with multicast and that the multicast table has to be large enough to avoid DoS attacks. It is possible to disable multicast.

Due to the complexity and optional nature the multicast framework has not been examined more closely.



44

4.2.15 Revocation

A protocol exists to allow a sensor node (the trust canter) to request the removal of a node from the network. The responsibility of removing the sensor node lies on the parent router to the sensor node. The parent router is the router the sensor node used in the joining procedure. In a mesh network it is unclear how the other neighbours of the revoked sensor node are supposed to be informed of the revocation.

Nothing will stop the sensor node from trying to authenticate again, however the parent router is supposed to turn off rejoining after receiving the remove device request to prevent a rejoin.

After removal from the network the device will have to authenticate at the trust centre again if it tries to rejoin the network.

The request to remove a device has to come from the trust centre, but may be secured with the network key. As all devices share the network key any device that is part of the network can create a message, setting the trust centre as the source, and thereby remove another device from the network.

4.2.16 Conclusions

The ZigBee stack has a security framework offering a balance between security, complexity, usability, and performance. While some weaknesses exist in ZigBee it provides a basis for the deployment of secure WSN.

The ZigBee trust model does not include means to handle the capture of a single sensor node. Such an attack would give the attacker access to the network key, master keys, and link keys stored on the sensor node. In addition, the SKKE protocol does not provide forward secrecy, so that all link keys that have previously been created through the SKKE protocol and the master keys would be compromised.

The network keys, like all globally shared keys, are vulnerable. All nodes in the network share the network key, and it is used for authentication as well as encryption. There is a system for replacing the network key, but it creates a lot of traffic and might cause disruptions in the network or overload the trust centre.

The standard offers several functions that can have negative effects on the security. This includes the ability to send keys without any protection over radio and a cipher mode without integrity protection. These functions are not a critical part of the specification and can be avoided.

In IEEE 802.15.4 the acknowledgement packets are not secured, and therefore MAC layer acknowledgements lack protection. Higher layer acknowledgements do not suffer from this and end-to-end acknowledgements are secure.

In addition, there is no replay protection on the MAC layer when using network keys.

A security scheme built on the ZigBee will have to be based on pre-distributed keys between the trust centre and the nodes in some form. Transporting keys in clear over radio is not acceptable in a security critical application, unless it can be done in a secure environment such as a shielded room.

ZigBee is vulnerable to memory exhaustion attacks, especially against the counters in the security framework and the routing. Any device that is part of the network can launch effective memory exhaustion attacks.

ZigBee is vulnerable to computation and communication denial of service attacks by methods such as performing large numbers of authentication attempts at the edges of the network, forcing packets to be forwarded through the network to the trust centre allowing effective multiplying.

The confidentiality, integrity and authenticity are better protected when the application link keys are used.

There is no built-in support for public key cryptography.



45

4.2.17 Recommendations

The CCM* is a modified protocol and therefore it needs to be carefully analyzed in order to guarantee that none of the changes that have been applied to the CCM protocol impact the security properties. The effect of the MAC layer acknowledgement problems in ZigBee is not clear; especially to what extent ZigBee relies on MAC level acknowledgements. This seems to be implementation dependant.

The key distribution solution chosen for ZigBee is well suited for small networks, but does not scale very well on current hardware.

4.2.17.1 Security modes

Security mode 0x04 (encryption without integrity) should not be used. Mode 0x01 and 0x05 specify MAC codes of 32 bits, which is unusually short. Residential mode relies on a shared secret and is weak, but it can be used in a situation where node capture is unlikely and the extra cost of a capable trust centre is too high. Commercial mode is stronger and recommended from a security standpoint; however it requires more memory in the trust centre. The network should be set to secure all messages (nwkSecureAllFrames) to avoid attackers bypassing the authentication and attacking the routing.

4.2.17.2 Key initialization

The initial keys should not be transferred over radio, unless this can be done in a secure and shielded environment. Other methods, such as preloading the keys during production and entering them into the trust centre after buying a sensor or having a simple programmer could be used instead.

4.2.17.3 Network keys

The network keys are not reliable in an environment where a node might be subverted and should not be trusted in such an environment. The replay counter table has to be large enough to handle all possible senders, which will be an issue in large networks. An authenticated sensor node can disrupt any communication using the network key by spoofing a packet with a high replay value. From a security standpoint it is best to replace the network key every time a sensor node joins or leaves the network. This prevents non-authenticated sensors from listening to the traffic, and prevents accidental reuse of nonce by sensors that have rejoined the network after losing their counters. Link keys should be used when possible, as they offer better protection.

4.2.17.4 Link keys

Link keys should be established using master keys from the trust centre and the SKKE protocol instead of sending them out directly. In this way the sensor nodes can renegotiate the key if one of the sensor nodes has a power failure with less risk of reusing nonce.

4.2.17.5 Keys, counters and tables

A large number of counters and tables are used as a part of the security framework and the routing. The standard gives no guidance for how to manage the space in these tables. In many cases exhaustion of the tables will open the devices to attacks. An implementation has to carefully manage these tables and consider the impact of exhaustion of the table space. Strict sanity checking can also reduce the vulnerability to attacks.

Currently there is no way for a device to declare that it has removed keys. Once two devices have completed key setup they are assumed to have matching keys. This is an omission from the security framework and will have to be solved on a higher layer. Removing keys is very likely to cause synchronization problems.



46



47

5 Security Solutions ZigBee networks are intended to be used in a wide range of applications and have diverse

security requirements. Here we present some solutions to the security demands found in the

scenarios presented in Section 3 and analyzed in Section 3.7.

5.1.1 Initialization

During the deployment the sensor nodes need to receive initial keying material to establish secure links. This material is network specific. As the sensor nodes are built for a specific application the general programming of the nodes will most likely be done during production time.

5.1.1.1 Direct programming

One method to get the material to the sensor is to have an external interface on the sensor. Using this interface the sensor is connected to the trust centre, or a separate programmer, and the material needed to securely communicate with the network is loaded onto the sensor node. It is a quick and efficient method, but it requires extra hardware in the form of external interfaces on the sensors as well as programming hardware. This cost might not be acceptable in some applications. In addition it will require extra code in the trust centre.

5.1.1.2 Out of band transfer

To establish the initial secure link between the trust centre and the sensor, the transfer of a single key is needed. If the trust centre can allow entering of data (for example if the trust centre is connected to a computer) the sensor can be preloaded with a key for initialization. The key is printed on the outside of the sensor on a removable sticker. The sticker can be made tamper evident using a protective layer (so it is clear that the sticker has been read). If a sophisticated attacker has physical access to the sensor nodes before deployment, it would not be possible to trust the hardware and the sensor node has to be considered captured. If the trust centre has the appropriate hardware out of band transfer is a good alternative. I have chosen to implement this solution in an effort to offer an alternative solution to the initial key distribution. See 6.2.1 for details on the implementation.

5.1.1.3 Radio transfer

If no initial keys are available and programming and out of band transfer are unavailable, the keys have to be transferred over radio. In ZigBee there is a system to allow keys to be transferred in clear text, but if possible it should be avoided. From a security standpoint it is simply not acceptable to send unprotected keys over radio outside a trusted environment.

5.1.1.4 Public key cryptography

An alternative is to use public key cryptography and transfer keys over radio. In this case only a single public key needs to be transferred from the trust centre to the sensor node and a single encryption done on the sensor node. The sensor node then sends an encrypted key back to the trust centre to use for the initial link.

To verify the public keys, certificates can be used. Verification of public key-based certificates is expensive, but in some applications Merkle hash trees are suitable. Merkle trees allow cheaper verification of the validity of the certificates through the transfer of additional data [30].

This solution requires implementation of ECC cryptography and changes in the standard. It would use valuable memory and cause an initial investment of computing time on both the sensor and the trust centre for each link. It also increases the risk of DoS attacks. Still using public key cryptography is the



48

only way to establish secure links over an insecure medium with no shared secrets or out of band communication.

5.1.2 Authentication

Authentication is already built into ZigBee, using the trust centre as a centralized authentication server. As authentication is needed before a sensor node can communicate with the network, it is hard to replace or change the authentication routines without modifications of the standard. The authentication routine is described in 4.2.13.

5.1.3 Link key establishment

Once a sensor node has connected to the network it will need to establish link specific keys. Until these links have been established network keys are used to secure communications, which does not offer any protection against attackers that are a part of the network. ZigBee has a built-in system based on key transfer. This system uses the trust centre to establish link (or master) keys through key transport. The key establishment will put a lot of load on the trust centre and neighbouring nodes.

To avoid overloading the trust centre a small security application can be built. This application runs on top of ZigBee. When needed a normal application can request this application to insert keys into ZigBee instead of using the trust centre. First when the keys have been established and confirmed by this application, the original application sends the data.

This solution will not break the current ZigBee specification and allows easy fallback to the trust centre if the sensor in the other end does not support the protocol. It allows the network to scale considerably better as it minimizes traffic needed to distribute link keys.

5.1.3.1 Symmetric key pre-distribution

A number of key pre-distribution schemes for key establishment exist. These schemes can be of interest in networks of medium to large size where many different communication partners are used. I developed and tested a symmetric link key establishment protocol; the results are described in [1].

5.1.3.2 Asymmetric key solutions

If certificates have been preloaded during the initialisation asymmetric key exchanges can be done with authentication. This requires a number of packet exchanges between the sensor node and heavy calculations, but it scales in very large networks as long as the number of communication partners for each sensor node is kept small.

5.1.4 Removal of sensor nodes

Removal of a sensor node is supported in ZigBee. The trust centre requests the removal from the router to which the sensor node is associated. It is important to revoke all keys known to the removed sensor node. Due to this fact the network key has to be changed. If the trust centre is used to distribute the keys it can keep track of all connections the sensor node has and send updated keys to those sensor nodes that are still a part of the network. This is to prevent them from sending data with keys that might have been compromised. Under the commercial network model new keys are distributed using the trust centre link key, preventing snooping by other members of the network. Under the residential model recovery is not possible.

If the demands on security are less strict it might be acceptable to simply replace the network key and leave the other keys in the network. However, as the other sensors do not know the sensor have been revoked it might still be able to inject data in the network. It can also read any data sent to it.



49

A command to force a sensor node to remove specific keys would significantly simplify the removal of a sensor node from the network. If such a command existed the trust centre could signal to the network that all security material related to the removed sensor node should be revoked.


Implementation

50

6 Implementation What is easy to suggest is often much harder to implement. While there exist plenty of

suggestions for how to build secure sensor networks very few of them run on real hardware.

Therefore we try to actually get our ideas running. Code is king.

The purpose of the implementation is to examine the ideas for improvements and check the feasibility of implementing then on a commercial ZigBee stack. While a number of interesting issues were identified, only those that could be addressed without changing the actual ZigBee standard were implemented. This was both to ensure the solution stayed ZigBee compliant and due to the lack of access to parts of the source code for the stack used.

The goal of the implementation was to get a working ZigBee network with logging and debugging facilities, and then test the previous identified improvements. These include key predistribution (see 6.2.1), link key establishment (see 6.2.2) and revocation of sensor nodes (see 6.2.3).

6.1 The setup A Java application was the first part developed to simplify debugging and allow interaction with the limited hardware of the sensor node. The communication between the sensor node and the computer used a serial interface connected to a debugging board. Around 100 logging hooks were placed in the security framework running on the AquisGrain 2 to enable tracing. An application was developed to allow the sensors to constantly report basic information about their status. These status messages include Network address, IEEE address, Parent address and current network key. First when the debug setup was complete did the implementation of the actual improvements start. The debug application considerably simplified development compared to raw hex dumps in the IAR debugger.

Figure 23: The Java application


Implementation

51

6.1.1 Hardware

The hardware used is a mixture of the Philips developed AquisGrain 2 and original Texas Instruments (ChipCon) CC2430 equipment. For debugging and packet sniffing the CC2400EB and CC2430DB boards were used, but no development was done on these boards, due to compatibility problems. The development was done on a modified AquisGrain 1 programming board (providing a serial interface) and AquisGrain 2 programming boards.

6.1.2 AquisGrain 2

AquisGrain 2 is a fully integrated system, with the exception of external IO and power source. It is intended to become a general-purpose block to be used when constructing larger products and systems, but is still an experimental platform. The AquisGrain 2 is 16x24x4 mm in size. Each AquisGrain 2 contains a CC2430 Rev B SoC from Texas Instruments (ChipCon), supporting hardware, a radio antenna, two diodes, IO port, and power supply connector.

Figure 24: AquisGrain 2

6.1.2.1 CC2430-F128

The CC2430 [2] is a specially developed system on chip, minimizing the number of additional components needed. It is built by Texas Instruments (ChipCon) to be used for ZigBee and similar applications. It offers a 32 MHz 8051 MCU, built-in 2.4 GHz radio, 8 Kbyte SRAM, and 128 Kbyte flash memory. It includes a hardware AES engine to speed up encryption.

6.1.3 Software

To avoid re-implementing ZigBee the ZStack 1.4.0 from ChipCon was used. Later the code was ported to version 1.4.1. The ZStack is an implementation of ZigBee that runs on the AquisGrain 2. All critical security methods were present in the stack and could be used. Major parts of the stack were in binary format and could not easily be modified or debugged. IAR Workbench, from IAR Systems, was used as an IDE.


Implementation

52

6.2 Implemented changes To more closely examine the security properties of ZigBee the implementation was done. The goal was to implement a secure ZigBee network matching the long-term medical monitoring scenario (see 3.4) and examine how the security can be improved. After setting up the network and examining it three focus areas were chosen. These were key distribution for a commercial application, key pre-distribution and secure sensor node revocation.

6.2.1 Key initialization

The key setup methods offered by ZigBee are not suitable for a commercial product needing both security and simple deployment. Over the air transport is not acceptable outside a protected environment and the limited hardware of the sensor nodes does not allow easy programming of network unique keys.

6.2.1.1 Goal

Develop a solution that does not rely on programming of the sensor nodes after deployment or on key transfer over the radio. The solution has to be possible to deploy in a commercial situation. The sensors will not have suitable hardware for entering key material into them as they are likely to be embedded. The trust centre will either have access to a capable terminal such as a computer or an external network connection.

6.2.1.2 Implementation

During initialization the sensor is programmed with a unique trust centre master key. This key is printed, along with the sensor MAC address on a tamper evident sticker and secured to the sensor. After being started the sensor will try to connect to the trust centre, which does not have a corresponding master key. At this point the trust centre queries the user for the master key or connects to an external system to fetch the key. The key can be either the full 128-bit key or a smaller amount of key material that is used to generate the key through a secure hash function. The key is retrieved from the sticker and entered into the trust centre.

After receiving the master key the trust centre waits until the sensor node makes the next connection attempt. As the trust centre now has a key it starts SKKE with the sensor node and establishes the link keys needed to transfer the network key securely.

This solution takes advantage of how the authentication works without modifying any ZigBee functionality. It is fully transparent to the sensor node.

Figure 25: Update sensor window (Screenshot).

6.2.1.3 Results

The key setup method was successfully implemented. After an unknown sensor node tried to join the network the Java application queried the user for a correct key. After the correct key was entered the sensor node was allowed to join the network. It could easily be extended to fetch the key from an Internet system.


Implementation

53

Due to a bug in the ZStack an incorrect key could not be detected. Instead of simply failing SKKE the stack could no longer accept joiners and ended up in a loop inside the security framework.

6.2.2 Distributed key establishment

The trust centre is a single point of failure, which will have to handle most of the load in the key distribution and network management. In scenarios with large networks and dynamic communication, such as the disaster monitoring and the emergency medical monitoring, the trust centre can be especially vulnerable to overload from large amounts of key establishments.

6.2.2.1 Goal

Develop a ZigBee compliant solution using pre-distribution. This solution should allow sensors to establish link keys without the involvement of the trust centre.


A simple solution with pre-distribution was chosen, similar to the solutions described in [16]. The key material was distributed by the trust centre. In addition to this two new messages were defined “DirectEstablishKey” and “DirectEstablishKeyResponse”. A sensor starts the key establishment by sending a “DirectEstablishKey” message secured with the network key. The responder answers with “DirectEstablishKeyResponse”. These messages contain the IDs needed for the key distribution. After exchanging the IDs the two sensors examine their security material, calculates the link key to be used (though a simple XOR operation over the common security material), insert the master keys in their ZigBee stacks and finally run the SKKE protocol to setup link keys.

6.2.2.3 Results

The scheme was successfully implemented. It is fully ZigBee compliant and does not require modifications to the ZigBee stack itself. If the responder does not reply with the DirectEstablishKeyResponse, it is possible to fall back on trust centre distribution.

This protocol requires pre-distribution of the security material by the trust centre, but after that point the sensor node can set up master keys without the involvement of the trust centre.

It is possible to change the XOR solution for a public key or polynomial based solution.

6.2.3 Sensor node revocation

Revocation is important in all the scenarios. Outside strictly static networks there will be changes in the membership. When removing a sensor node it is important that this sensor node does not have access to any current security material in the network. It is always possible that the sensor node is removed due to an attack or that an attacker gets access to the discarded sensor node. If security material such as the network key is leaked it will make it trivial to attack the network.

6.2.3.1 Goal

Examine the revocation routines and see how secure revocation can be done while staying ZigBee compatible.


A simple revocation routine was implemented, using a revocation list. After removing a sensor node from the network a new network key is sent each remaining member of the network using the trust centre link keys. This ensures the removed sensor node does not have access to the current network key. It is also possible to replace link and master keys by sending key transport messages, but it was found unpractical due to the memory required to keep track of which pairs of sensors have a link key in a network of non-trivial size. Sending a key transport message when there is no established key already would use up memory on the sensor nodes.


Implementation

54

6.2.3.3 Results

While the implemented solution works, it has a number of limitations. ZigBee does not handle revocation well and there are no hooks in the framework to remove keys, only change them. Other sensor nodes in the network are not informed about the revocation. This can result in synchronization errors. Eventually sensors should time out their connections, or get a routing failure, but the removed sensor can still read the messages (as they are encrypted with a known key). It might also be possible to inject messages to the remaining members of the network.

Clearly, ZigBee needs the addition of some kind of revocation message, which forces all sensors to purge the security material they have for a specific ID. However, this is not possible to do within the ZigBee standard and stack available. This would be an addition to the standard.

It would also be good if a sensor could inform another sensor about the purging of security material.

6.3 Performance issues While the computational power did not cause any issues during the implementation of the solutions, the memory limitations of the AquisGrain 2 combined with the size of the ZStack where a challenge.

There are two types of memory available in the 8051: Flash and RAM. The flash memory provides long time storage, but is slow and has a limited number of write cycles. It is classified for 1000 write-erase cycles. Flash can be written byte-wise, but only erased in 2 Kbytes pages.

There is 8 Kbytes of RAM available. In power saving mode only 4 Kbytes of this RAM is available.

6.3.1 Flash memory

The memory model of the 8051 uses 4 banks. Of these, bank 0 is always available along with one of bank 1-3. Each bank is 32 Kbytes in size. The linker sorts the code into these banks, but cannot fill them completely. Due to the wasted space at the end of the banks the full 128Kbyte of flash is not available. In addition to this, the last 2Kbyte contains the 64-bit IEEE address, which should not be overwritten.

The ZStack also requires some flash to function correctly. If the compiled stack gets too large the linker will fail. A slightly smaller stack will crash randomly while running. The stack seems to still stay stable when using 122 Kbytes of flash.

6.3.2 RAM

A majority of the RAM is used for runtime variables. All variables that are not declared constant have to be stored in the ram. In addition to the runtime variables the ZStack has to have room for the runtime stack, which has a maximum size of 500 byte. The rest of the memory is used for the heap. If the ZStack uses up all stack or heap space it will crash or reset. Less than 800 bytes of heap caused problems.

6.3.3 Typical Stack sizes

Due to limitations of the debugger used actual stack usage when running could not be recorded. Instead the static size as reported by the linker was recorded. This does not include the size of the runtime stack or the heap memory. All sizes are in bytes. CODE is the data stored in flash (maximum of 128 Kbytes) while XDATA is stored in RAM memory (maximum of 8 Kbytes). Using more than 124 Kbyte CODE or 7.2 Kbyte RAM caused instability. Data was recorded for three different configurations: Coordinator/trust centre, Router and End device. The base size of the stack was recorded, along with how much memory each additional Network and Security entry took up. A


Implementation

55

network entry is needed for each routing partner (in practice, at least one for each connected sensor node). A security entry is needed for each secure connection.

6.3.3.1 No security

When turning off the security, additional security associations does not change the stack size.

Device Coordinator Router End device

Memory CODE XDATA CODE XDATA CODE XDATA

Network entry 0 14 0 14 0 0

Security entry 0 0 0 0 0 0

Base Size 104590 6463 101860 5445 82878 3827

Table 1: Stack size without security.

6.3.3.2 Residential security

When using residential security only a fixed number of keys need to be stored which ensures the stack has a fixed size.





Base Size 107574 6481 105234 5445 84363 3827

Table 2: Stack size with residential grade security.

6.3.3.3 Commercial security

When using commercial security additional information has to be stored for each security association. The coordinator has to store one security entry for each member of the network. This configuration leaves very little room on the coordinator for security associations (limiting the network size) and additional applications.





Base Size 119592 6483 115467 5461 96198 3785

Table 3: Stack size with commercial grade security.

6.3.3.4 Conclusions

Heavy space optimization is needed to fit the code within the limited amount of memory available. This optimization hampers debugging as the generated code gets much harder to read and trace. Due to this limitation, parts of the debugging had to be done in assembler, slowing down the development.

No extra memory is needed for routing at the end devices, as they use a default route to their parent and let it handle all the routing. The size of the stack leaves very little room for implementing applications on the coordinator and is a limiting factor in the growth of the network under the commercial grade security model. This specific stack version and hardware combination does not allow for large networks using the commercial security model.


Implementation

56

6.3.4 Bandwidth

The bandwidth was never a limiting factor in the development of the solutions. However the memory needed to store pending messages can be problematic as short bursts of messages easily fill up the available buffers before they can be processed.

6.3.5 CPU

The CPU was never heavily loaded by the new security framework. Because the power saving mode was not fully supported in the stack version 1.4.0 the CPU was always running at full speed.

6.3.6 Battery life

The batteries used are 3.7V Li-Ion batteries with a capacity of 980 mAh. These batteries lasted 2-4 days. Usage of external IO devices, such as the serial interface or LCD screens resulted in the shorter battery lifetimes.

A majority of the battery drain is most likely due to the lack of support for power saving mode in the stack used.


Conclusions

57

7 Conclusions ZigBee is the first commercially available wireless sensor network protocol with a security management infrastructure intended for omnipresent deployment. Building a security framework with tight constraints in memory, CPU and battery is not an easy task and ZigBee is not yet perfect.

While this thesis presents a number of possible weaknesses and attacks, it is not clear which of these attacks will actually be employed against ZigBee networks. Most of the attacks are of disruptive nature and not compromising nature, making them less valuable. ZigBee is still being developed and most of the issues are being addressed in the drafts for the next version of ZigBee.

7.1 Strengths of ZigBee The fundamental cryptographic functions in ZigBee are strong and well constructed. No cryptographic attacks similar to the attacks [25] on IEEE 802.11 (WEP) can be expected in the near term. The trust centre and standardized methods to handle key material and key setup work well. So far no similar security management solution for a commercial WSN has been deployed. The security framework in ZigBee can be made transparent to the users, which is useful in applications where the user will not be able to monitor or influence the settings of the device. Correctly deployed ZigBee networks can be configured to offer a good level of security. (See 4.1.3, 4.1.11 and 4.2.16)

7.2 Weaknesses of ZigBee Many variables and options exist in ZigBee, offering tradeoffs between security and performance. Some of the tradeoffs are not trivial to understand, while others are clearly dangerous. During the design of an application profile most of these variables will be fixed, providing a basic level of security. This helps if a predefined application profile is used, but companies might also develop their own application profiles.

There are issues with initialization vectors, MAC layer acknowledgements, cipher modes, key handling and security guarantees. Awareness of these issues makes it reasonably easy to work around them. (See 4.1.4, 4.1.7 and 4.2.8 for example)

The ZigBee networks are vulnerable to attacks involving capture of sensors node and during the authentication. These problems are not easy to solve. The reliance on the network key also complicates the creation of secure networks. These weaknesses have to be carefully considered in an application to avoid creating a network that is easy to break into. The trust centre is a single point of failure in the network. (See 4.2.13)

7.3 Changes to ZigBee ZigBee requires some form of distributed key setup and authentication to avoid overloading the trust centre. We have suggested using a simple key pre-distribution scheme to establish link keys between devices that are already part of the network without trust centre involvement. (See 6.2.2)

The unsecured joining phase is problematic and needs to be revised to avoid attacks where a sensor node is lured to join the wrong network.

One important security issue is the initial trust establishment. Without any support for public key cryptography the key establishment needs to be carefully considered. The two current methods are not suitable for all applications. (See 6.2.1)


Conclusions

58

Removal of keys is not supported in ZigBee. This makes management of the memory dedicated to keys harder and prevents efficient revocation of sensor nodes. The addition of a remove key command could easily solve this issue. (See 6.2.3)

7.4 Open questions This review of ZigBee has left out a number of important issues due to lack of time and resources. As ZigBee is still being developed, the following areas are interesting fields for future study.

7.4.1 Physical security and side channel attacks

This thesis has completely ignored the physical security of the sensor nodes. Currently the AquisGrain 2 does not have any protection against physical attacks. It would be interesting to examine how security material can be protected from physical attacks without significantly increasing the price of the hardware.

7.4.2 Routing

Routing is outside the scope of this thesis. Three different routing algorithms are used in ZigBee, and there is support for multicast. The routing algorithms need a careful examination, as routing often is a weak point for denial of service attacks.

7.4.3 Group keying

ZigBee includes support for group keying, but many of the security properties do not hold if group keys are used. In addition, the support for group keys in IEEE 802.15.4 is limited. This whole part of the framework needs a separate examination. Secure use of group keying would require changes in both ZigBee and IEEE 802.15.4. The tight memory constraints make implementing group keying with replay protection an interesting problem.

7.4.4 Scalability

It is clear that the ZStack version used does not scale up to the maximum theoretical size of a ZigBee network if security is activated. How far it actually scales and what optimizations can be used to improve the scalability of both the routing and security frameworks is still unclear.

7.4.5 Traffic analysis

On different layers different parts of the data is secured. It could be interesting to study how well traffic analysis can be done in low rate networks such as ZigBee networks when taking full advantage of the parts of the headers that are not encrypted.


References

59

Abbreviations • AES: The advanced encryption standard. Based on the Rijndael cipher.

• APL: The application layer in a stack, the layer where application specific code can be found. It simplifies application development and provides clean interfaces. The top layer of the stack in ZigBee.

• CBC-MAC: Cipher block chaining message authentication code. A form of MAC. Offers authenticity.

• CCM: Counter mode with CBC-MAC. A combined cipher mode. Offers confidentiality and integrity.

• CCM*: Extended counter mode with CBC-MAC. A version of CCM offering additional settings.

• CTR: Counter mode. Turns a block cipher into a stream cipher and offers confidentiality.

• DoS: Denial of service. A type of attack that tries to deny legitimate use of services.

• FFD: Full function device. A device with a full routing stack, capable of routing and relaying messages. It can act as a coordinator.

• LAN: Local area network.

• MAC (1): Medium access control layer in a stack, the layer controlling access to the shared medium. It lies between the network layer and the physical layer.

• MAC (2): Message authentication code. A cryptographic code added to a packet. It is used to verify the authenticity and integrity of the packet.

• NWK: The network layer in a stack. The layer is responsible for routing and multi-hop communication. It also handles reliable transport. It lies between the MAC layer and the APL layer.

• PAN: Personal area network.

• PHY: The physical layer in a stack. It specifies how the information is coded and transmitted. It is the lowest level in the stack.

• RFD: Reduced function device. A device not capable of routing or relaying of messages. It cannot act as coordinator.

• SKG: Secret key generation.

• SKKE: Symmetric key key establishment. A protocol to establish keys between two devices.

• WSN: Wireless sensor networks.

• XOR: Exclusive or, a logical operation on bits. The operation returns false if the bits have the same value (true-true or false-false). Otherwise the operation returns true.


References

60

Definitions Many of the definitions come from the IEEE 802.15.4-2006 standard and the ZigBee 2006 specifications.

• Access control list: A table containing the security material and security settings used to secure the communication with other devices.

• Active network key: The network key currently used to secure NWK layer frames.

• Alternative network key: A key that can replace the network key to handle NWK frames.

• Authenticity: Assurance about the source of transferred information.

• Block cipher: A cryptographic function operating on a string of bits with a fixed size.

• Block size: The fixed size of a string accepted by an algorithm. Also the smallest unit of data the algorithm will act upon.

• Broadcast: Transmission to all members of the network.

• Clustered tree network: A network where the routing is done according to a tree structure. Messages are only routed upwards and downwards in the tree.

• Cryptographic hash function: A hash function having the property that it is computationally hard to find a message matching a given output or to find two messages giving the same output.

• Confidentiality: Concealing information from non-trusted entities.

• Coordinator: A full function device capable of relaying messages. A coordinator starts the network and is called the PAN Coordinator.

• Device: Any entity with an implementation of the IEEE 802.15.4/ZigBee stack

• Encryption: Transforming a message so that it cannot be understood or transformed back without the use of shared secret information (key)

• End device: A device that is part of a ZigBee network but not acting as coordinator or router.

• Hash function: A fast, deterministic, function that maps an input value to a pseudorandom identifier of a specified length.

• Integrity: Assurance that the data has not been modified.

• Key (Symmetric): A shared secret string that can be used to protect the confidentiality or authenticity of information.

• Key (Public, Asymmetric): A shared string that can be used to protect the confidentiality of information when communicating with the holder of an associated private key. It can verify the authenticity secured with the associated private key.

• Key (Private, Asymmetric): A secret string that can be used to protect the integrity of information when communicating with the holder of an associated public key. It can also remove the confidentiality protection from messages secured with the associated public key.

• Key establishment: A mechanism where two or more parties establish a common secret key for communication.

• Key transport: A mechanism where a key is transferred from one device to another.

• Key-transport key: A special key used to secure key transport messages.


References

61

• Keying material: The material used to secure transferred messages. This includes key, nonce, and identifiers.

• Key management: The process of establishing keys and maintaining the security of the communications over the lifetime of the system.

• Key update: A mechanism used to replace an existing key with a new one in a number of devices.

• Link key: A key used to secure the communication between exactly two devices.

• Master key: A shared key used in the SKKE protocol. It is the basis for long time security between a pair of devices and used to generate link keys.

• Mesh network: A network where routing is done in a distributed manner according to the shortest path first principle.

• Multi hop network: A network that is not guaranteed to connect source and destination devices directly. It implies that routing is included.

• Network address: The address of the device, used as an identifier on the network. ZigBee uses two addresses: 64 bit IEEE addresses and 16 bit short addresses.

• Nonce: A context unique value, such as an increasing counter, long random string or time stamp. Used in cryptographic methods to prevent replay attacks.

• Octet: 8 bits of data. Identical to a byte.

• One-way function: A mathematical function that lacks an easy inverse function.

• Orphaned device: A device that has lost contact with its coordinator.

• Packet: The formatted information being transported over the physical layer

• Payload: The content of a packet being transported, once headers have been removed.

• PAN coordinator: The coordinator that controls the global settings in the PAN. Only one PAN coordinator may exist in each PAN.

• Plain text: Information without any confidentiality protection.

• Protection: The security level for information being transported. May include confidentiality, authenticity, and replay protection.

• Router: A device capable of forwarding messages between devices.

• Security level: A classification of the protection offered to information being transported over the network.

• SoC: System on Chip. Complete system in a single chip package.

• Star network: A network where all devices are connected to the coordinator and all routing is done in the coordinator.

• Trust centre: A trusted device in a ZigBee network. It is used for authentication and key distribution. Usually the same as the coordinator.

• Unicast: Transmission of a message to a single recipient.


References

62

References

1. Römer and Mattern, The Design Space of Wireless Sensor Networks. IEEE Wireless Communications, 2004.

2. CC2430: System-on-Chip Solution for 2.4 GHz IEEE 802.15.4 / ZigBee. 2007, ChipCon 2008-01-23 http://www.chipcon.com/files/CC2430_Data_Sheet_rev2p0.pdf.

3. 802.15.4-2003 Standard. 2003, IEEE Computer Society 2008-01-23 http://www.ieee802.org/15/pub/TG4.html.

4. FIPS, PUB 197: The AES standard. 2001 2008-01-23 http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf.

5. ZigBee 2006. 2006, ZigBee Alliance 2008-01-23 http://www.zigbee.org/.

6. Menezes, Oorschot, and Vanstone, Handbook of Applied Cryptography. 2001: CRC Press.

7. Shannon, Communication Theory of Secrecy Systems. Bell Systems Tech. J., 1949(4): pp. 656-715.

8. Schneier, Description of a New Variable-Length Key, 64-bit Block Cipher (Blowfish), in Fast

Software Encryption, Cambridge Security Workshop. 1994, Springer-Verlag. pp. 191-204.

9. FIPS, PUB 46-2: Data Encryption Standard. 1993 2008-01-23 http://www.itl.nist.gov/fipspubs/fip46-2.htm.

10. Koblitz, Elliptic curve cryptosystems. Mathematics of Computation, 1987: pp. 203-209.

11. Gupta, Millard, Fung, Zhu, Gura, Eberle, and Shantz. Sizzle: a standards-based end-to-end

security architecture for the embedded Internet. in Pervasive Computing and

Communications, 2005. PerCom 2005. Third IEEE International Conference on. 2005.

12. Gaubatz, Kaps, Ozturk, and Sunar, State of the Art in Ultra-Low Power Public Key

Cryptography for Wireless Sensor Networks, in Proceedings of the Third IEEE International

Conference on Pervasive Computing and Communications Workshops. 2005, IEEE Computer Society. pp. 146-150.

13. Douceur, The Sybil Attack, in Revised Papers from the First International Workshop on Peer-

to-Peer Systems. 2002, Springer-Verlag>. pp. 251-260.

14. Diffie, Oorschot, and Wiener, Authentication and authenticated key exchanges. Des. Codes Cryptography, 1992(2): pp. 107-125.

15. Messerges, Cukier, Kevenaar, Puhl, Struik, and Callaway, A security design for a general

purpose, self-organizing, multihop ad hoc wireless network, in Proceedings of the 1st ACM

workshop on Security of ad hoc and sensor networks. 2003, ACM Press: Fairfax, Virginia. pp. 1-11.


References

63

16. Camtepe and Yener, Combinatorial design of key distribution mechanisms for wireless sensor

networks. IEEE/ACM Trans. Netw., 2007(2): pp. 346-358.

17. Chan, Perrig, and Song, Random Key Predistribution Schemes for Sensor Networks, in Proceedings of the 2003 IEEE Symposium on Security and Privacy. 2003, IEEE Computer Society. pp. 197.

18. Sastry and Wagner, Security considerations for IEEE 802.15.4 networks, in Proceedings of

the 3rd ACM workshop on Wireless security. 2004, ACM Press: Philadelphia, PA, USA. pp. 32-42.

19. CNSS Policy No. 15, Fact Sheet No. 1, NIST 2008-01-23 http://csrc.nist.gov/cryptval/CNSS15FS.pdf.

20. Ferguson, Kelsey, Lucks, Schneier, Stay, Wagner, and Whiting, Improved Cryptanalysis of

Rijndael, in Proceedings of the 7th International Workshop on Fast Software Encryption. 2001, Springer-Verlag. pp. 213-230.

21. Gilbert and M. Minier, A collision attack on 7 rounds of rijndael. Proceedings of the 3rd Advanced Encryption Standard Candidate Conference, 2000: pp. 230-241.

22. Osvik, Shamir, and Tromer, Cache attacks and Countermeasures: the Case of AES. Cryptology ePrint Archive, 2005(Report 2005/271).

23. Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication

and Confidentiality, in Publication 800-38C. 2004, FIPS

24. Rogaway and Wagener, A Critique of CCM, 2008-01-23 http://www.cs.ucdavis.edu/~rogaway/papers/ccm.html.

25. Cam-Winget, Housley, Wagner, and Walker, Security flaws in 802.11 data link protocols. Commun. ACM, 2003(5): pp. 35-39.

26. 802.15.4-2006 Standard. 2006, IEEE Computer society 2008-01-23 http://www.ieee802.org/15/pub/TG4.html.

27. Perkins. Ad-hoc on-demand distance vector routing. in MILCOM '97 panel on Ad Hoc

Networks. 1997.

28. Counter with CBC-MAC, in RFC 3610. 2003, IETF 2008-01-23 http://www.ietf.org/rfc/rfc3610.txt.

29. ANSI, X9.63 Public Key Cryptography for the Financial Services Industry - Key Agreement

and Key Transport Using Elliptic Curve Cryptography. 2001

30. Merkle, A certified digital signature, in Proceedings on Advances in cryptology. 1989, Springer-Verlag New York, Inc.: Santa Barbara, California, United States. pp. 218-238.

TRITA-CSC-E 2008:036 ISRN-KTH/CSC/E--08/036--SE

ISSN-1653-5715

www.kth.se

an analysis of wsn security managemant - kth

Documents