Secure and Energy-Efficient Join-Leave Operations in ZigBee Network

Abstract

Since security plays an important role in several ZigBee applications, such as Smart Energy and medical sensor applications, ZigBee Specification includes various security mechanisms to protect ZigBee frames and infrastructure. Among them, the Join and Leave operations of ZigBee are investigated in this paper. The current Join-Leave operation is protected by the network key (a kind of group key). We claim it is not adequate to employ the network key for such purpose, and propose a new Join-Leave operation protected by the application link key (a kind of pairwise key), which is based on a more efficient key management scheme than that of ZigBee. Hence, the original Join operation consists of a total of 12 command frames, while the new Join operation consists of only 6 command frames. In particular, the security of the proposed Join-Leave operation is equivalent to or better than that of the original Join-Leave operation. The new Join-Leave operation is extensively analyzed in terms of security and efficiency, and compared with the original Join-Leave operation of ZigBee.

1. Introduction

ZigBee is a low cost and low power consumption wireless personal area network standard, which can be used in many different wireless sensor network applications. The latest ZigBee standard, ZigBee Specification [1] defines Network and Application Support layers upon the IEEE 802.15.4 [2]. Since security plays an important role in several ZigBee applications, such as Smart Energy and medical sensor applications, ZigBee Specification includes various security mechanisms to protect ZigBee frames and infrastructure. Key management is an important primitive for building sensor network security. There are two types of key management schemes proposed for sensor network security. One is a distributed key management scheme, where each device interacts directly with neighboring devices, to establish pairwise keys, based on the pre-loaded keying materials. Random key pre-distribution schemes [3,4] and Transitory master key-based schemes [5,6,7] belong to this category. The other is a centralized key management scheme [1,8]; in this case, a base station plays the role of key server, to establish a pairwise key for any two devices. The key management scheme for ZigBee security is the centralized one. The Trust Center (TC) in ZigBee Coordinator is a kind of authentication and key server for other ZigBee devices. There are three kinds of keys used for ZigBee security: master key, link key, and network key. In particular, the link key can also be classified into TC link key and application link key. The network key, TC link key and application link key of ZigBee correspond to the global key, individual key and pairwise key of LEAP [5], respectively. However, the cluster key of LEAP is not defined in ZigBee. The Key Establishment protocol of ZigBee is for establishing a TC link key between TC and a ZigBee device, while the Key Distribution protocol is for establishing an application link key between any two devices through TC.

In this paper, we focus on the Join and Leave operations of ZigBee. When a new ZigBee device joins into a secured ZigBee network, two security protocols, Key Establishment and Authentication protocols, should be performed, to complete the Join operation. A total of 12 command frames are exchanged among TC, the joiner device and the parent router device. On the other hand, when a ZigBee device is to be removed from the network, the Leave operation is performed. Both Join and Leave operations are protected by the network key common to all the devices already joined into the network. Even though the network key plays an important role in securing the route maintenance at the network layer, we claim it is not adequate to employ the network key, at least for securing both Join and Leave operations, since it is a kind of group key. Instead of the network key, an application link key (a kind of pairwise key) established between the joiner device and the router device can be used to secure both the Join and Leave operations. [9] proposed a new Join operation consisting of a total of 9 command frames, using the pairwise key shared between them. However, how to establish the pairwise key between them was not proposed. [10] also proposed using the individual key for the Authentication protocol between the joiner device and TC, not between the joiner device and the parent router device, while there was no mention on how it could be integrated with the remaining part of the Join operation.

Contributions.

A main function of the Join operation is to establish a TC link key (individual key) between TC and the joiner device, and to securely transport the network key to the joiner device. Then, the network key (global key) is used for mutual authentication between the joiner device and its parent router device. In order to complete the Join operation of ZigBee, 12 command frames should be exchanged among the ZigBee devices, which is a source of a lot of energy consumption. First, a new Join operation consisting of only 6 command frames is proposed, while the security of the proposed Join operation is equivalent to or better than that of the original Join operation. Hence, the energy consumption of ZigBee devices during the Join operation can be greatly reduced. Second, an application link key (pairwise key) between the joiner device and its router device can also be derived, as a result of the new Join operation. In order to derive the application link key in ZigBee, another 3-way Key Distribution protocol should be separately executed between them, via TC. Third, the Leave operation can be protected using the application link key, instead of the network key, so that the security of the Leave operation can be more improved, in terms that the effect of compromising ZigBee devices can be localized.

Organization.

In Section 2, ZigBee security architecture is introduced, together with the Join and Leave operations of ZigBee. After pointing out the weaknesses of the Join and Leave operations of ZigBee, a new security mechanism for the Join and Leave operations is proposed in Section 3. This is extensively analyzed, and compared with that of ZigBee in terms of security and efficiency in Section 4. Finally, performance analysis is given in Section 5.

 

2. ZigBee Security Architecture

Fig. 1 presents a typical ZigBee network topology, consisting of three types of devices: ZigBee Coordinator (ZTC), ZigBee Router and ZigBee End Devices, where ZigBee Routers and End Devices are denoted as ZX (X = A, B, C, …). A ZigBee device (ZigBee Router or ZigBee End Device) can join the network through the parent router device. ZA becomes a parent of ZB, when ZB joins the network through ZA. The Trust Center (TC) in the ZigBee Coordinator is a key component in ZigBee security. It generates various cryptographic keys and distributes them to ZigBee devices, and updates them on a regular basis, or on request from ZigBee devices. Furthermore, the TC maintains a list of ZigBee devices (device table) currently joined into the ZigBee network. From now on, the TC is also denoted as ZTC, since it is a part of ZTC.

Fig. 1.ZigBee Network Topology and Types of ZigBee Keys [1]

In the following, [m]K is a symmetric encryption of m using a secret key K. kdf(.) and h(.) are a key derivation function and a one-way hash function, respectively. MIC(K) is the message integrity code computed over all preceding fields of a message, using the secret key K.

X and X* denote ZX’s extended 64-bit MAC (Medium Access Control) address and 16-bit network address, respectively, and FCX denotes a frame counter managed by ZX to guarantee frame freshness. Each protocol frame has several inherent fields, described in [1,2]. However, since most of them are not related to security, for the sake of simplicity they are excluded from the explanation. Instead, only the security-related fields are shown in each frame. The notations used in this paper are shown in Table 1.

Table 1.Table of Notations

2.1 Types of ZigBee Keys

Three types of keys are employed for ZigBee security, as in Fig. 1: master key, link key, and network key. The network key (NK) is a kind of group key used for protecting ZigBee frames at the network layer, while the link key derived from the master key is for protecting ZigBee frames at the application layer. When deriving the link key from the master key, the 4-way Key Establishment protocol is performed between two ZigBee devices. There are two kinds of master and link keys: TC master key (MKA) and TC link key (LKA) are shared between ZTC and a ZigBee device ZA, and the application master key MKAB) and application link key (LKAB) are shared for end-to-end security between any two ZigBee devices, ZA and ZB. When requested by ZA or ZB, the application master or link key (MKAB or LKAB) is distributed to both ZA and ZB by ZTC, through the Key Distribution protocol. In this case, ZTC plays the role of a key server for ZA and ZB. The keying material can be pre-installed before deployment, or transported by ZTC after deployment. The confidentiality and integrity of ZigBee frames are provided by the CCM* cryptographic algorithm, which is a minor variant of CCM [13], based on 128-bit AES.

2.2 Joining a Secured ZigBee Network

There are two options to install the keying materials into the ZigBee devices [1]. The one is pre-installation during ZigBee commissioning time, and the other is key transport after deployment. Since the key transport is performed in the air, the secure installation of the keying materials cannot be guaranteed. Therefore, throughout this paper, it is assumed that a set of ZigBee devices authorized to join the network are predefined, which means that each authorized ZigBee device’s MAC address and its TC master key are pre-installed in the TC’s device table. Fig. 2 shows a message sequence chart ensuing from when a joiner device (ZB) communicates with a router device (ZA), to join a secured ZigBee network. The main point of the Join operation is for ZB to obtain the network key from ZTC, and to perform a successful authentication protocol with ZA based on the network key. It is assumed that the TC link key LKA has already been established between ZTC and ZA. When receiving a periodic Beacon {A} command broadcasted by the router device ZA, ZB starts the Join operation by sending an Association-Request {B} command to ZA. If an entry is available in ZA’s neighbor table, ZA allocates ZB’s network address B*, and makes an entry for ZB consisting of B, B*, and its state “joined and unauthenticated” in its neighbor table. Then, an Association Response {B*, Status} command is sent to ZB, where Status is “association successful”. No security mechanism is employed at this phase, since there is no pre-established security association between them. Then, ZA reports the joiner device’s address (B, B*) to ZTC through the Update-Device command, which is protected by LKA.

Fig. 2.Join Operation in ZigBee [1]

ZB’s MAC address B and the TC master key MKB have already been pre-installed in the TC’s device table. Since ZB has joined and the Key Establishment protocol is subsequently performed, to establish the TC link key LKB between ZTC and ZB, the device table of ZTC is updated as follows: (B, MKB, B*, LKB, parent), where parent is the network address of ZA.

This is a 4-way handshake protocol, through which two random numbers RTC and RB generated by ZTC and ZB, respectively, are exchanged, and LKB = kdf (MKB, TC, B, RTC, RB) is computed. The successful verifications on HMACTC(LKB) and HMACB(LKB) guarantee both the entity authentication and key confirmation on LKB between them, where HMAC is a HMAC function [14]. ZTC then transports a current network key NK with its sequence number NKSeq to ZB, through the Transport-Key command. The network key is protected by LKB. Whenever NK is updated, NKSeq is incremented by one.

Fig. 3.Authentication Protocol and Leave Operation in ZigBee [1]

Based on NK, another 4-way Authentication protocol between ZA and ZB is performed, as in Fig. 3 (a). It is a kind of challenge-response mutual authentication protocol using two random numbers RA and R B. If it is successful, ZB’s state in ZA’s neighbor table is changed to “joined and authenticated”, and ZB is authorized to send and receive data or command frames. When the joiner device ZB directly joins the network through ZTC, the Update-Device command is not needed and the 4-way Authentication Protocol is performed directly between ZTC and ZB.

2.3 Leaving a Secured ZigBee Network

ZTC can remove a ZigBee device from the network, as in Fig. 3 (b). For example, if ZB fails to authenticate properly during the 4-way Authentication Protocol, ZTC requests the router device (ZA) to remove its child device (ZB). When receiving a Remove-Device command from ZTC, the router device (ZA) sends a Leave command, to notify the ZigBee device (ZB) of its removal from the network. On the other hand, a ZigBee device (ZB) can remove itself from the network, by sending a Leave command to its parent router (ZA). The ZigBee device (ZB) can select the parent router (ZA) since ZB stores its parent router information in the neighbor table during the association phase. ZTC will also be informed of the device that leaves the network, through the Update-Device command. In either case, ZTC shall delete the device from its device table. If ZTC and the router share a TC link key LKA, then the Remove-Device command between the two will be secured with the TC link key LKA. The Leave command is protected by the network key known to all ZigBee devices.

 

3. An Enhanced Security Mechanism for ZigBee

A purpose of the Key Establishment protocol in Fig. 2 is to establish the TC link key LKB between ZTC and ZB based on the pre-shared TC master key MKB. The TC link key is used to protect the network key to be delivered to ZB. Based on the network key, mutual authentication is performed between ZA and ZB through the Authentication protocol, which is a final step of the Join operation. In order for a joiner device to join a secured ZigBee network, a total of 12 command frames should be exchanged among ZTC, ZA, and ZB. In this Section, a new Join operation consisting of only 6 command frames is proposed, which also allows an application link key LKAB to be established between ZA and ZB. So, the application link key can be employed to secure the Authentication protocol and the Leave operation, instead of the network key.

3.1 Assumptions and Design Principles

First, as in Fig. 2, it is assumed there is a pre-established TC link key LKA between ZTC and ZA, and ZB’s TC master key MKB is pre-installed in ZTC’s device table during ZigBee commissioning time. Second, the 4-byte frame counter FCX is used to guarantee the freshness of the command frames in ZigBee. Due to the security problems of the frame counter of ZigBee pointed out in [11], the 8-byte timestamp TSX (X = TC, A, B) is instead employed in the proposed Join and Leave operations. Nonetheless, strict time synchronization between two ZigBee devices is not required for security, since the timestamp is more like a sequence number in the proposed Join and Leave operations. Third, the timestamps are also used to derive the TC link key LKB and application link keys LKAB, unlike in Fig. 2, where random numbers are used to derive them. Fourth, an application link key LKAB can also be established between ZA and ZB, as well as the TC link key LKB, without the Key Establishment protocol. Namely, the Key Establishment protocol and the Transport-Key command are omitted in the proposed Join operation, while a newly-defined Update-Result command is employed. The application link key is used to protect the network key, and to perform both an Authentication protocol and the Leave operations. In particular, ZA sends the network key to ZB, when the Authentication protocol is performed successfully.

Fig. 4.A New Join Operation in ZigBee

3.2 Proposed Join Operation

Fig. 4 shows a message sequence chart for a new Join operation proposed for ZigBee. A main difference between Fig. 2 and Fig. 4 is that both the Key Establishment protocol and the Transport-Key command are replaced by a new Update-Result command.

(Step 1) A joiner device ZB computes h(MKB, TSB) based on its current timestamp TSB, and sends an Association Request {TSB, B, h(MKB, TSB)} command to ZA, where h(MKB, TSB) is used to authenticate ZB by ZTC. If entry is available in ZA’s neighbor table, ZA allocates ZB’s network address B*, and makes an entry for ZB in its neighbor table, as follows:

(Step 2) A router device ZA sends to ZTC an Update-Device {TSA, B*, L, MIC(LKA)} command, where L = TSB || B || h(MKB, TSB). The freshness of the command is guaranteed by both the timestamp TSA generated by ZA, and MIC(LKA).

When receiving the Update-Device command, ZTC first verifies if it is authentic command sent from ZA. If the verification of MIC(LKA) fails or TSA is not fresh, then ZTC discards the command frame, and stops processing. Second, by checking L, ZTC verifies if B in L is authorized to join. If ZB’s entry is not found in the device table, or the received h(MKB, TSB) in L is not valid, ZTC notifies ZA that the Update-Device command cannot be processed, by replying with Update-Result { TSTC, B*, “Update Unsuccessful”, _, _, MIC(LKA) } command, where “_” denotes an empty field, namely Y and LKAB are not computed. When all of the above tests are passed, the device table is updated, as follows:

(Step 3) ZTC computes Y, LKAB, and LKB as in Fig. 4, where Y = h (MKB, TSB, TSA, TSTC), LKAB = kdf (MKB, B, A, TSB, TSA), and LKB = kdf (MKB, B, TC, TSB, TSTC). Then, an Update-Result {TSTC, B*, Result, Y, [LKAB]LKA, MIC(LKA)}command is sent to ZA, where Result = “Update Successful”.

When receiving the Update-Result command with valid MIC(LKA), ZA first checks if Result is “Update Successful”. If not, ZA deletes ZB’s entry in the neighbor table, and stops processing. Otherwise, the encrypted LKAB is decrypted from the command, and its neighbor table is updated, as follows:

(Step 4) ZA sends to ZB an Association-Response {TSTC, TSA, Y, B*, Status} command, where Status = “Successful Association”. When receiving it, ZB first verifies if Y is valid, since TSTC and TSA are used to compute the link keys. If the verification is successful, ZB computes and shares the application link key LKAB and the TC link key LKB with ZA and ZTC, respectively. Both TSA and TSTC are also stored. Now, ZB performs a 2-way Authentication protocol. If it is done successfully, ZB’s state in ZA’s neighbor table is changed from “joined and unauthenticated” to “joined and authenticated”, and ZB is authorized to send and receive data or command frames.

When the joiner device ZB directly joins the network through ZTC, the Update-Device and Update-Result commands are not needed and the 2-way Authentication Protocol is performed directly between ZTC and ZB.

3.3 A 2-Way Authentication Protocol

The Authentication protocol in Fig. 2 is a 4-way handshake protocol for mutual authentication between ZA and ZB based on the network key NK. However, the proposed Authentication protocol shown in Fig. 4 is a 2-way handshake protocol based on the application link key LKAB already shared between ZA and ZB.

Fig. 5.A Proposed 2-Way Authentication Protocol

ZB computes HMACB(LKAB) = HMAC (LKAB, TSB*, B, A) based on the current timestamp TSB*, and sends to ZA a command frame {TSB*, B, A, HMACB(LKAB)}. When receiving it, ZA checks if the stored TSB is less than the received TSB*, and if the computed HMAC is the same as the received HMAC. If both verifications are successful, ZA computes W = [NKSeq, NK]LKAB and HMACA(LKAB) = HMAC (LKAB, TSA*, A, B), and sends to ZB a command frame {TSB*, A, B, W, HMACA(LKAB)}. Then ZB performs the verification on the timestamp and HMACA(LKAB), and decrypts W and gets the network key NK.

3.4 Proposed Leave Operation

During the Leave operation of ZigBee in Fig. 3 (b), the Leave command is protected by the network key known to all ZigBee devices. However, if the network key is compromised, an adversary can send a bogus Leave command to any ZigBee device in the network for the purpose of removing a victim device from the network. On the other hand, as a result of successful completion of the proposed Join operation in Fig. 4, the application link key LKAB is shared between ZA and ZB, and it can be employed to secure the Leave command, instead of the network key. Therefore, the newly proposed Leave operation is the same as that in Fig. 3 (b) except the Leave command as follows:

The network key is a kind of group key, while the application link key is a kind of pair-wise key. The security of the proposed Leave operation will be more detailed in Section 4.3.

 

4. Security Analysis and Comparisons

In this Section, the ZigBee Join-Leave and the proposed Join-Leave operations are compared and analyzed, in terms of security and efficiency.

4.1 Security Assumptions and Threat Model

The level of security provided by the ZigBee security architecture depends on the safekeeping of the symmetric keys, and on the protection mechanisms employed. So, trust in the ZigBee Join and Leave operations ultimately reduces to trust in the secure installation, processing and storage of keying material. The ZigBee specification assumes that the keying material, such as TC master key, is securely installed at each ZigBee device during the ZigBee commissioning time before deployment. However, due to the low-cost nature of ad hoc network devices, one cannot generally assume the availability of tamper-resistant hardware, which means that physical access to a device may yield access to secret keying material and other privileged information [1]. Therefore, it is assumed that an adversary is able to eavesdrop and manipulate the ZigBee commands exchanged, and access the keying materials in ZigBee devices (ZA and ZB in Fig. 2 and Fig. 4) by physical capture. One exception is the ZigBee Coordinator (ZTC), with the device table maintaining TC master keys of authorized ZigBee devices. So, it is assumed that the ZigBee Coordinator is physically protected, so that physical capture and compromise by an adversary are not feasible. Finally, the internal functioning of the devices in the network cannot be arbitrary controlled by an adversary.

4.2 Nonces and Replay Attacks

The freshness of the command frames in the Join and Leave operation of ZigBee (Fig. 2) is guaranteed by the 4-byte frame counter. For this purpose, each device maintains two kinds of frame counter: outgoing frame counter (OutgoingFrameCounter), and a set of incoming frame counters (IncomingFrameCounter). When a frame is sent, the frame counter field of the frame is set to OutgoingFrameCounter, and it is increased by one. When a frame is received, IncomingFrameCounter corresponding to the sender address is compared with the frame counter value in the received frame. On the other hand, in the proposed Join and Leave operation (Fig. 4), 8-byte timestamps are employed, instead of the frame counters. Nonetheless, strict time synchronization between two devices is not required for security, since the timestamp is more like a sequence number in the proposed Join and Leave operations. Therefore, replay attacks against both schemes (Fig. 2 and Fig. 4) are not feasible without the secret keying materials. Besides the security problems of the frame counter in ZigBee pointed out in [11], there is another advantageous reason to employ timestamps for the Authentication protocol. The Authentication protocol of ZigBee is a 4-way handshake protocol for mutual authentication, based on the network key. Two random numbers RA and RB are employed to compute and verify the HMAC value.

Fig. 6.Comparison of 4-Way and 2-Way Authentication Protocols

In Fig. 6 (a), ZA and ZB do not have each other’s IncomingFrameCounter in advance, since they exchange frames for the first time. In Fig. 2, since security is not enabled on both Association Request and Response commands, the frame counters are not included. Even though the command frames ③ and ④ include the frame counter, it is not for frame freshness, but for creating each other’s frame counter for the first time. Therefore, frame freshness is guaranteed by two random numbers. That is why the Authentication protocol in the Join operation of ZigBee consists of 4 command frames. On the other hand, in Fig. 6 (b), instead of random numbers, the timestamps, TSA* and TSB*, are used to provide frame freshness, since ZA and ZB store the previous timestamps, TSA and TSB, received from each other through the Association Request and Response commands.

4.3 Forgery Attacks for Unauthorized Leave

Since the network key is known to all the devices joined into the ZigBee network, we claim it is not adequate to use it, at least for securing the Leave operation. In this section, three types of attack scenarios for the Leave operation of ZigBee are investigated.

Fig. 7.Attack Scenarios for the Leave Operation of ZigBee

First, suppose an adversary (Adv) disguising ZB knows the network key, and sends a bogus Leave command to ZA (Type-1 Attack). If this occurs, the entry for ZB is deleted from the neighbor table of ZA, which means it is detached from the ZigBee network, so that frames destined for ZB are discarded by ZA. Second, if Adv disguising ZA sends a bogus Leave frame to ZB (Type-2 Attack), ZB think ZA is no longer its router, and tries to find another neighboring router. Third, suppose Adv knows the TC link key LKA of the router device ZA (Type-3 Attack), and forges and sends the Remove-Device {FCTC, B*, MIC(LKA)} command to ZA. Then, ZB is also removed from the network, when receiving the Leave command from ZA. For Type-1 and Type-2 attacks, if a device from Group A in Fig. 7 is physically captured and the network key is extracted from it, Adv can remove any device in Group A, as well as any device in Group B. Namely, many random ZigBee devices can be out of the network.

On the other hand, as a result of successful completion of the proposed Join operation, the application link key LKAB is shared between ZA and ZB, and it can be employed to secure the Leave command, instead of the network key. However, if the application link key LKAB is also exposed to Adv, we encounter the same security problem for the Leave operation. In such a case, only ZB is out of the network. Namely, the above three types of attacks can be localized to the group (Group A in Fig. 7) to which the victim device belongs, while the remaining devices in the other group (Group B in Fig. 7) can remain unaffected.

4.4 Man-In-The-Middle Attacks for Unauthorized Join

Suppose an unauthorized device ZU without the current network key tries to join the network through ZA. In the case of the Join operation in Fig. 2, after exchanging the Association commands between ZA and ZU, ZA sends the Update-Device command to ZTC. However, since the information about ZU is not pre-installed in the device table of ZTC, the Remove-Device command is sent back to ZA, so that the temporary entry for ZU is deleted from the neighbor table of ZA, and the subsequent authentication procedure cannot be initiated. In the case of the proposed Join operation in Fig. 4, the Update-Result command plays the same role of the Remove-Device command, when the information about ZU is not pre-installed in the device table of ZTC. Hence, if Zu is proven to be unauthorized, the temporary entry for ZU is also deleted from the neighbor table of ZA, so that the unauthorized join attempt is blocked.

On the other hand, suppose an adversary (Adv) can access the keying materials (NK or LKA) of the router device ZA, and aid an unauthorized device ZU to join the network through ZA, as in Fig. 8. Initially, Adv installs NK or (U, MKU) into ZU. In the case of Fig. 8 (a), after the Association commands are exchanged with ZA and ZU, Adv blocks the Update-Device command sent from ZA. Then, ZU initiates the Authenticaion protocol with ZA, based on NK. Eventually, ZU is successfully attached to the network, and can send and receive the broadcasted frames protected by NK, even though its information is not in the device table of ZTC.

Fig. 8.Attack Scenarios for Join Operation

In the case of Fig. 8 (b), ZU should first compute h(MKU, TSU). Even if the Association-Request {TSU, U, h(MKU, TSU)} command is sent to ZA and the subsequent Update-Device {TSA, U*, L, MIC(LKA)} command is sent to ZTC, the verification on h(MKU, TSU) by ZTC will fail, since (U, MKU) is not pre-installed in the device table of ZTC. However, suppose Adv blocks the Update-Device command, and responds with the following forged Update-Result command to ZA, where TSTC#, LKAU#, and Y# are fabricated by Adv.

Then, both commands can be normally processed, and finally the application link key LKAU# is shared between ZA and ZU. Namely, ZU is also successfully attached to the network. However, in both cases ((a) and (b) in Fig. 8), ZU joins the network incompletely, since its information is not pre-installed into the device table of ZTC. So, ZU cannot perform a normal communication with another device in the network. In order for ZU to communicate with it, ZU should first contact with ZTC, to request the application link key to be shared with it.

4.5 DoS Attacks against Join Operation

During the Join operation, a DoS attack inducing unnecessary energy consumption can be mounted against ZTC and the router device ZA. There are two cases: the first is for Adv to send the Association Request command to ZA with a bogus MAC address that is not pre-installed into the device table of ZTC. In this case, after making an entry in its neighbor table, ZA responds with the corresponding Association Response command to Adv, and then sends the Update-Device command to ZTC. Since the bogus MAC address is not pre-installed in the device table, ZTC sends a Remove-Device command to ZA, to delete the entry in the neighbor table. In this case (Case 1 in Fig. 9), the bogus Association Request command induces three unnecessary command frames. The second is for Adv disguising ZB to send the Association Request command to ZA with a ZB’s MAC address that is pre-installed into the device table of ZTC. In this case (Case 2 in Fig. 9), the ZTC performs the unnecessary Key Establishment protocol with it, which eventually fails, after exchanging two command frames. So, the bogus Association Request command induces five unnecessary command frames. On the other hand, in the proposed Join operation, the bogus Association Request command induces only two unnecessary command frames.

Fig. 9.Comparison of Induced Unnecessary Command Frames

4.6 Security Comparisons of ZigBee and The Proposed One

The security of Join-Leave operation of ZigBee and the proposed one has been investigated in Section 2, 3, 4 and 5, and is summarized in Table 2. As indicated in Table 2, the security level of the proposed one is equivalent to or better than that of ZigBee, while the performance efficiency of the proposed one is much better than that of ZigBee, which will be shown in Section 5.

Table 2.Security Comparisons of ZigBee and The Proposed One

Additionally, in this Section, we compare the key management for the secure Join-Leave operation of ZigBee and the proposed one. A purpose of the Key Establishment protocol in Fig. 2 is to establish the TC link key LKB between ZTC and ZB, based on the pre-shared TC master key MKB. The TC link key is used to protect the network key to be delivered to ZB. Based on the network key, mutual authentication is performed between ZA and ZB through the Authentication protocol, which is a final step of the Join operation.

In the proposed Join operation of Fig. 4, both the 4-way Key Establishment protocol and Transport-Key command frame are omitted. Instead, a new Update-Result command frame is defined, and additional fields associated with the key establishment are embedded into the 4 command frames, Association-Request, Update-Device, Update-Result, and Association-Response. In particular, the role of the Update-Result command frame is two-fold: the first is to notify ZA of the result of processing the Update-Device command frame, and the second is to convey the keying material, namely < [LKAB]LKA > to ZA and < TSA, TSTC, Y > to ZB, where the integrity of TSA and TSTC is guaranteed by Y = h (MKB, TSB, TSA, TSTC). Based on the keying material, the TC link key LKB = kdf (MKB, B, TC, TSB, TSTC) can be shared between ZTC and ZB, and the application link key LKAB = kdf (MKB, B, A, TSB, TSA) can also be shared between ZA and ZB. Eventually, the subsequent Authentication protocol and the Leave operation can be secured, using the application link key, instead of the network key.

It is possible to use the application link key LKAB for the Authentication protocol of Fig. 2, and the Leave operation of Fig. 3. However, in order to do so, an additional 3-way Key Distribution protocol defined in the ZigBee specification [1] should be performed among ZA, ZB, and ZTC beforehand, which induces a long delay, and consumes more energy in the participating ZigBee devices.

4.7 Rekeying Issue in ZigBee

Even though the network key is not employed for the new Join and Leave operations, the network key plays an important role in securing the broadcast frames for route maintenance at the network layer. In addition to use the network key for the Join-Leave operation, the ZigBee specification [1] defines how to update the network key. The TC broadcasts a new network key NKnew encrypted with the old network key NKold, through the Transport-Key frame.

After receiving a Switch-Key frame subsequently broadcasted from the TC, all ZigBee devices begin using the new network key. The ZigBee specification uses the word "periodically" when the network key update issue is referred, but gives no further guidelines. It should also be updated in case of both Join and Leave events [19] and device compromise event [10].There are two security weaknesses in the network key update of ZigBee. First, perfect forward security is not guaranteed, since the compromise of the old network key leads to that of the new network key. Second, if the network key is exposed, an adversary disguising TC can broadcast the bogus network keys, so that the network keys are not synchronized among the TC and ZigBee devices. The network key update should be triggered by TC only. Regarding these security weaknesses, the ZigBee specification also mentions that the new network key can be individually encrypted by the TC link key shared with each device, and sent (unicast) to each ZigBee device. However, if the ZigBee network consists of too many devices, a scalability problem occurs. In this case, key management schemes in multicast dynamic groups, such as LKH (Logical Key Hierarchy) rekeying [15] and OFT (One-way Function Tree) rekeying [16], might be solutions to solve the scalability problem.

 

5. Performance Analysis

Fig. 10 shows a frame format for the Leave, Update-Device and Authentication commands, while Fig. 11 shows that of Association-Request and Response commands. The length of each field in the command is in bytes, and depends on the type of the command.

Fig. 10.Frame Format for Leave / Update-Device / Authentication Commands [1]

The newly defined Update-Result command can have the same frame format as that of Fig. 10. The security-related parameters of the 2-way Authentication commands, Update-Device and Update-Result commands, can be put into the “Command Payload” field in Fig. 10, whose length is variable. On the other hand, for the new security-related parameters of the Association-Request and Response commands introduced in Section 3, two new fields can be added into the dotted boxes in Fig. 11.

Fig. 11.Frame Format for Association-Request / Response Commands [2]

Table 3 shows the number of bytes of each command frame used in ZigBee and the proposed one, where both the Authentication and Key Establishment protocols of ZigBee are 4-way handshake protocols consisting of 4 command frames each. On the other hand, the 2-way Authentication protocol of the proposed one consists of only 2 command frames.

Table 3.Frame Length in Bytes for Each Command in ZigBee and the Proposed One

In order to evaluate energy consumption, only the number of bytes sent and received by the devices is taken into consideration. We did not include the relatively insignificant levels of energy consumed, since 1 bit transmitted in a sensor network consumes as much power as 800 -1000 instructions [17]. Assuming the energy consumption during transmission or reception of a 1-byte message equals 0.13 mJ [18], Fig. 12 (a) shows the energy consumption (mJ) of each device, when sending and receiving the frames in Table 3 during the Join and Leave operations, assuming no security attack is mounted.

Fig. 12.Energy Consumption of ZigBee Devices during the Join/Leave Operation

As shown in Fig. 12 (a), the energy consumptions in ZTC and ZB of the proposed Join operation are much less than those of the ZigBee Join operation. Fig. 12 (b) shows the cumulative energy consumption in 3 devices (ZTC, ZA, ZB) as the number of joining / leaving devices increases. The main difference of energy consumption between the ZigBee and the proposed one is due to whether the 4-way Key Establishment protocol is included, or not, in the Join operation. The reason that the energy consumption in ZA of the proposed one is a little higher than that of ZigBee in Fig. 12 (a) is due to the additional fields embedded into the command frames associated with the key establishment and association. In particular, there is no difference between the ZigBee Leave operation and the proposed one in terms of the frame length of the commands in them, which means that the energy consumptions for both Leave operations remains the same. In conclusion, the proposed Join and Leave operations are more efficient than the original ZigBee ones, as shown in Fig. 12 (b).

 

6. Concluding Remarks

Since security plays an important role in several ZigBee applications, various security mechanisms are employed to protect ZigBee frames and infrastructure. In this paper, Join and Leave operations of ZigBee have been investigated. A couple of weaknesses of ZigBee have been pointed out in terms of security and efficiency, and a new security mechanism has been proposed to address them. The proposed Join operation is more energy-efficient than that of ZigBee since the number of command frames involved in the Join operation has been reduced in half. In particular, the application link key can be derived as a result of the proposed Join operation, and it can be used to secure both Authentication protocol and Leave operation, instead of the network key. It has been shown that it is more secure and efficient than that of the original Join and Leave operations of ZigBee.