Advanced
Secure and Energy-Efficient Join-Leave Operations in ZigBee Network
Secure and Energy-Efficient Join-Leave Operations in ZigBee Network
KSII Transactions on Internet and Information Systems (TIIS). 2013. Nov, 7(11): 2874-2892
Copyright © 2013, Korean Society For Internet Information
  • Received : June 22, 2013
  • Accepted : October 23, 2013
  • Published : November 30, 2013
Download
PDF
e-PUB
PubReader
PPT
Export by style
Share
Article
Author
Metrics
Cited by
TagCloud
About the Authors
Bong-Whan Kim
Information Security Lab, Department of Computer Science, Dankook University Cheonan, Republic of Korea
Chang-Seop Park
Information Security Lab, Department of Computer Science, Dankook University Cheonan, Republic of Korea

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.
Keywords
1. Introduction
Z igBee 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 (Z TC ), ZigBee Router and ZigBee End Devices, where ZigBee Routers and End Devices are denoted as Z X (X = A, B, C, …). A ZigBee device (ZigBee Router or ZigBee End Device) can join the network through the parent router device. Z A becomes a parent of Z B , when Z B joins the network through Z A . 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 Z TC , since it is a part of Z TC .
PPT Slide
Lager Image
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 Z X ’s extended 64-bit MAC (Medium Access Control) address and 16-bit network address, respectively, and FC X denotes a frame counter managed by Z X 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 of Notations
PPT Slide
Lager Image
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 Z TC and a ZigBee device Z A , and the application master key MK AB ) and application link key ( LK AB ) are shared for end-to-end security between any two ZigBee devices, Z A and Z B . When requested by Z A or Z B , the application master or link key ( MK AB or LK AB ) is distributed to both Z A and Z B by Z TC , through the Key Distribution protocol. In this case, Z TC plays the role of a key server for Z A and Z B . The keying material can be pre-installed before deployment, or transported by Z TC 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 (Z B ) communicates with a router device (Z A ), to join a secured ZigBee network. The main point of the Join operation is for Z B to obtain the network key from Z TC , and to perform a successful authentication protocol with Z A based on the network key. It is assumed that the TC link key LK A has already been established between Z TC and Z A . When receiving a periodic Beacon {A} command broadcasted by the router device Z A , Z B starts the Join operation by sending an Association-Request {B} command to Z A . If an entry is available in Z A ’s neighbor table, Z A allocates Z B ’s network address B* , and makes an entry for Z B consisting of B, B* , and its state “ joined and unauthenticated ” in its neighbor table. Then, an Association Response { B*, Status } command is sent to Z B , where Status is “ association successful ”. No security mechanism is employed at this phase, since there is no pre-established security association between them. Then, Z A reports the joiner device’s address ( B, B* ) to Z TC through the Update-Device command, which is protected by LK A .
PPT Slide
Lager Image
Join Operation in ZigBee [1]
Z B ’s MAC address B and the TC master key MK B have already been pre-installed in the TC’s device table. Since Z B has joined and the Key Establishment protocol is subsequently performed, to establish the TC link key LK B between Z TC and Z B , the device table of Z TC is updated as follows: ( B, MK B , B*, LK B , parent ), where parent is the network address of Z A .
This is a 4-way handshake protocol, through which two random numbers R TC and R B generated by Z TC and Z B , respectively, are exchanged, and LK B = kdf ( MK B , TC, B , R TC , R B ) is computed. The successful verifications on HMAC TC ( LK B ) and HMAC B ( LK B ) guarantee both the entity authentication and key confirmation on LK B between them, where HMAC is a HMAC function [14] . Z TC then transports a current network key NK with its sequence number NKSeq to Z B , through the Transport-Key command. The network key is protected by LK B . Whenever NK is updated, NKSeq is incremented by one.
PPT Slide
Lager Image
Authentication Protocol and Leave Operation in ZigBee [1]
Based on NK , another 4-way Authentication protocol between Z A and Z B is performed, as in Fig. 3 (a). It is a kind of challenge-response mutual authentication protocol using two random numbers R A and R B . If it is successful, Z B ’s state in Z A ’s neighbor table is changed to “ joined and authenticated ”, and Z B is authorized to send and receive data or command frames. When the joiner device Z B directly joins the network through Z TC , the Update-Device command is not needed and the 4-way Authentication Protocol is performed directly between Z TC and Z B .
- 2.3 Leaving a Secured ZigBee Network
Z TC can remove a ZigBee device from the network, as in Fig. 3 (b). For example, if Z B fails to authenticate properly during the 4-way Authentication Protocol, Z TC requests the router device (Z A ) to remove its child device (Z B ). When receiving a Remove-Device command from Z TC , the router device (Z A ) sends a Leave command, to notify the ZigBee device (Z B ) of its removal from the network. On the other hand, a ZigBee device (Z B ) can remove itself from the network, by sending a Leave command to its parent router (Z A ). The ZigBee device (Z B ) can select the parent router (Z A ) since Z B stores its parent router information in the neighbor table during the association phase. Z TC will also be informed of the device that leaves the network, through the Update-Device command. In either case, Z TC shall delete the device from its device table. If Z TC and the router share a TC link key LK A , then the Remove-Device command between the two will be secured with the TC link key LK A . 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 LK B between Z TC and Z B based on the pre-shared TC master key MK B . The TC link key is used to protect the network key to be delivered to Z B . Based on the network key, mutual authentication is performed between Z A and Z B 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 Z TC , Z A , and Z B . In this Section, a new Join operation consisting of only 6 command frames is proposed, which also allows an application link key LK AB to be established between Z A and Z B . 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 LK A between Z TC and Z A , and Z B ’s TC master key MK B is pre-installed in Z TC ’s device table during ZigBee commissioning time. Second, the 4-byte frame counter FC X 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 TS X (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 LK B and application link keys LK AB , unlike in Fig. 2 , where random numbers are used to derive them. Fourth, an application link key LK AB can also be established between Z A and Z B , as well as the TC link key LK B , 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, Z A sends the network key to Z B , when the Authentication protocol is performed successfully.
PPT Slide
Lager Image
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 Z B computes h ( MK B , TS B ) based on its current timestamp TS B , and sends an Association Request { TS B , B, h ( MK B , TS B )} command to Z A , where h ( MK B , TS B ) is used to authenticate Z B by Z TC . If entry is available in Z A ’s neighbor table, Z A allocates Z B ’s network address B* , and makes an entry for Z B in its neighbor table, as follows:
  • Update ZB’s entry in Neighbor Table
  • •(B, network_addr, stored_TSB, Application_link_key, state)
  • •network_addr←B*;
  • •stored_TSB←TSB;
  • •state← “joined and unauthenticated”;
(Step 2) A router device Z A sends to Z TC an Update-Device { TS A , B* , L, MIC ( LK A )} command, where L = TS B || B || h ( MK B , TS B ). The freshness of the command is guaranteed by both the timestamp TS A generated by Z A , and MIC ( LK A ).
When receiving the Update-Device command, Z TC first verifies if it is authentic command sent from Z A . If the verification of MIC ( LK A ) fails or TS A is not fresh, then Z TC discards the command frame, and stops processing. Second, by checking L , Z TC verifies if B in L is authorized to join. If Z B ’s entry is not found in the device table, or the received h ( MK B , TS B ) in L is not valid, Z TC notifies Z A that the Update-Device command cannot be processed, by replying with Update-Result { TS TC , B* , “ Update Unsuccessful ”, _, _, MIC ( LK A ) } command, where “_” denotes an empty field, namely Y and LK AB are not computed. When all of the above tests are passed, the device table is updated, as follows:
  • Update ZB’s entry in Device Table
  • (B, MKB, network_addr, stored_TSB, TC_link_key, parent)
  • •network_addr←B*;
  • •stored_TSB←TSB;
  • •TC_link_key←LKB;
  • •parent←A*;
(Step 3) Z TC computes Y , LK AB , and LK B as in Fig. 4 , where Y = h ( MK B , TS B , TS A , TS TC ), LK AB = kdf ( MK B , B, A , TS B , TS A ), and LK B = kdf ( MK B , B, TC , TS B , TS TC ). Then, an Update-Result { TS TC , B* , Result, Y , [ LK AB ] LK A , MIC ( LK A )}command is sent to Z A , where Result = “Update Successful” .
When receiving the Update-Result command with valid MIC ( LK A ), Z A first checks if Result is “ Update Successful ”. If not, Z A deletes Z B ’s entry in the neighbor table, and stops processing. Otherwise, the encrypted LK AB is decrypted from the command, and its neighbor table is updated, as follows:
  • (B, B*, TSB,Application_link_key =LKAB, “joined and unauthenticated”)
(Step 4) Z A sends to Z B an Association-Response { TS TC , TS A , Y, B *, Status } command, where Status = “Successful Association” . When receiving it, Z B first verifies if Y is valid, since TS TC and TS A are used to compute the link keys. If the verification is successful, Z B computes and shares the application link key LK AB and the TC link key LK B with Z A and Z TC , respectively. Both TS A and TS TC are also stored. Now, Z B performs a 2-way Authentication protocol. If it is done successfully, Z B ’s state in Z A ’s neighbor table is changed from “ joined and unauthenticated ” to “ joined and authenticated ”, and Z B is authorized to send and receive data or command frames.
When the joiner device Z B directly joins the network through Z TC , the Update-Device and Update-Result commands are not needed and the 2-way Authentication Protocol is performed directly between Z TC and Z B .
- 3.3 A 2-Way Authentication Protocol
The Authentication protocol in Fig. 2 is a 4-way handshake protocol for mutual authentication between Z A and Z B 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 LK AB already shared between Z A and Z B .
PPT Slide
Lager Image
A Proposed 2-Way Authentication Protocol
Z B computes HMAC B ( LK AB ) = HMAC ( LK AB , TS B *, B, A ) based on the current timestamp TS B *, and sends to Z A a command frame { TS B *, B, A , HMAC B ( LK AB )}. When receiving it, Z A checks if the stored TS B is less than the received TS B *, and if the computed HMAC is the same as the received HMAC . If both verifications are successful, Z A computes W = [ NKSeq, NK ] LK AB and HMACA ( LK AB ) = HMAC ( LK AB , TS A *, A, B ), and sends to Z B a command frame { TS B *, A, B, W, HMAC A ( LK AB )}. Then Z B performs the verification on the timestamp and HMAC A ( LK AB ), 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 LK AB is shared between Z A and Z B , 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:
  • ZTC→ ZA:Remove-Device{FCTC,B*,MIC(LKA)}
  • ZA→ ZB:Leave{FCA,Request, MIC(LKAB)}
  • ZA← ZB:Leave{FCB,Request, MIC(LKAB)}
  • ZTC← ZA:Remove-Device{FCA,B, B*,MIC(LKA)}
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 (Z A and Z B in Fig. 2 and Fig. 4 ) by physical capture. One exception is the ZigBee Coordinator (Z TC ), 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 R A and R B are employed to compute and verify the HMAC value.
PPT Slide
Lager Image
Comparison of 4-Way and 2-Way Authentication Protocols
In Fig. 6 (a), Z A and Z B 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, TS A * and TS B *, are used to provide frame freshness, since Z A and Z B store the previous timestamps, TS A and TS B , 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.
PPT Slide
Lager Image
Attack Scenarios for the Leave Operation of ZigBee
First, suppose an adversary (Adv) disguising Z B knows the network key, and sends a bogus Leave command to Z A (Type-1 Attack). If this occurs, the entry for Z B is deleted from the neighbor table of Z A , which means it is detached from the ZigBee network, so that frames destined for Z B are discarded by Z A . Second, if Adv disguising Z A sends a bogus Leave frame to Z B (Type-2 Attack), Z B think Z A is no longer its router, and tries to find another neighboring router. Third, suppose Adv knows the TC link key LK A of the router device Z A (Type-3 Attack), and forges and sends the Remove-Device { FC TC , B* , MIC ( LK A )} command to Z A . Then, Z B is also removed from the network, when receiving the Leave command from Z A . 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 LK AB is shared between Z A and Z B , and it can be employed to secure the Leave command, instead of the network key. However, if the application link key LK AB is also exposed to Adv, we encounter the same security problem for the Leave operation. In such a case, only Z B 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 Z U without the current network key tries to join the network through Z A . In the case of the Join operation in Fig. 2 , after exchanging the Association commands between Z A and Z U , Z A sends the Update-Device command to Z TC . However, since the information about Z U is not pre-installed in the device table of Z TC , the Remove-Device command is sent back to Z A , so that the temporary entry for Z U is deleted from the neighbor table of Z A , 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 Z U is not pre-installed in the device table of Z TC . Hence, if Zu is proven to be unauthorized, the temporary entry for Z U is also deleted from the neighbor table of Z A , so that the unauthorized join attempt is blocked.
On the other hand, suppose an adversary (Adv) can access the keying materials ( NK or LK A ) of the router device Z A , and aid an unauthorized device Z U to join the network through Z A , as in Fig. 8 . Initially, Adv installs NK or ( U, MK U ) into Z U . In the case of Fig. 8 (a), after the Association commands are exchanged with Z A and Z U , Adv blocks the Update-Device command sent from Z A . Then, Z U initiates the Authenticaion protocol with Z A , based on NK . Eventually, Z U 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 Z TC .
PPT Slide
Lager Image
Attack Scenarios for Join Operation
In the case of Fig. 8 (b), Z U should first compute h ( MK U , TS U ). Even if the Association-Request { TS U , U, h ( MK U , TS U )} command is sent to Z A and the subsequent Update-Device { TS A , U *, L, MIC ( LK A )} command is sent to Z TC , the verification on h ( MK U , TS U ) by Z TC will fail, since ( U, MK U ) is not pre-installed in the device table of Z TC . However, suppose Adv blocks the Update-Device command, and responds with the following forged Update-Result command to Z A , where TS TC # , LK AU # , and Y # are fabricated by Adv.
PPT Slide
Lager Image
Then, both commands can be normally processed, and finally the application link key LK AU # is shared between Z A and Z U . Namely, Z U is also successfully attached to the network. However, in both cases ((a) and (b) in Fig. 8 ), Z U joins the network incompletely , since its information is not pre-installed into the device table of Z TC . So, Z U cannot perform a normal communication with another device in the network. In order for Z U to communicate with it, Z U should first contact with Z TC , 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 Z TC and the router device Z A . There are two cases: the first is for Adv to send the Association Request command to Z A with a bogus MAC address that is not pre-installed into the device table of Z TC . In this case, after making an entry in its neighbor table, Z A responds with the corresponding Association Response command to Adv, and then sends the Update-Device command to Z TC . Since the bogus MAC address is not pre-installed in the device table, Z TC sends a Remove-Device command to Z A , 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 Z B to send the Association Request command to Z A with a Z B ’s MAC address that is pre-installed into the device table of Z TC . In this case (Case 2 in Fig. 9 ), the Z TC 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.
PPT Slide
Lager Image
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.
Security Comparisons of ZigBee and The Proposed One
PPT Slide
Lager Image
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 LK B between Z TC and Z B , based on the pre-shared TC master key MK B . The TC link key is used to protect the network key to be delivered to Z B . Based on the network key, mutual authentication is performed between Z A and Z B 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 Z A of the result of processing the Update-Device command frame, and the second is to convey the keying material, namely < [ LK AB ] LK A > to Z A and < TS A , TS TC , Y > to Z B , where the integrity of TS A and TS TC is guaranteed by Y = h ( MK B , TS B , TS A , TS TC ). Based on the keying material, the TC link key LK B = kdf ( MK B , B, TC, TS B , TS TC ) can be shared between Z TC and Z B , and the application link key LKA B = kdf ( MK B , B, A , TS B , TS A ) can also be shared between Z A and Z B . 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 LK AB 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 Z A , Z B , and Z TC 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 NK new encrypted with the old network key NK old , through the Transport-Key frame.
  • •Transport-Key{FCTC, [NKnew]NKold,MIC(NKold)}
  • •Switch-Key{FCTC,MIC(NKold)}
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.
PPT Slide
Lager Image
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 .
PPT Slide
Lager Image
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.
Frame Length in Bytes for Each Command in ZigBee and the Proposed One
PPT Slide
Lager Image
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.
PPT Slide
Lager Image
Energy Consumption of ZigBee Devices during the Join/Leave Operation
As shown in Fig. 12 (a), the energy consumptions in Z TC and Z B 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 (Z TC , Z A , Z B ) 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 Z A 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.
BIO
Chang-Seop Park has been with the Department of Computer Science at Dankook University, Republic of Korea, since 1990. He has a Ph.D. and a M.Sc. from Lehigh University (1990 and 1987), as well as a B.A. from Yonsei University (1983). He has been working on the wireless mobile network security during the last 5 years. His research interests include network security, cryptographic protocols, and coding theory.
Bong-Hwan Kim has received his B.Sc. in computer science from Dankook University in 2012 and has been completing his M.Sc. in computer science. His research interests include network security, wireless security, and wireless body area network.
References
2008 ZigBee-2007, ZigBee-2007 Specification. ZigBee Alliance USA Article (CrossRef Link)
2006 IEEE 802.15.4-2006 Wireless Medium Access Control and Physical Layer Specifications for Low-Rate Wireless Personal Area Networks. IEEE USA Article (CrossRef Link)
Eschenauer L. , Gligor V. “A Key Management Scheme for Distributed Sensor Networks” in Proc. of Computer and Communications Security Nov. 2002. Article (CrossRef Link) 22 - 31
Chan H. , Perrig A. , Song D. 2003 “Random Key Pre-distribution Schemes for Sensor Networks”. in Proc. of IEEE Symposium on Security and Privacy May Article (CrossRef Link) 112 - 120
Zhu S , Setia S , Jajodia S 2006 “LEAP+: Efficient Security Mechanisms for Large-scale Distributed Sensor Networks,” ACM Transactions on Sensor Networks Article (CrossRef Link) 2 (4) 500 - 528    DOI : 10.1145/1218556.1218559
Deng J. , Hartung C. , Han R. , Mishra S. 2005 “A Practical Study of Transitory Master Key Establishment for Wireless Sensor Networks,” in Proc. of First International Conference on Security and Privacy for Emerging Areas in Communications Networks 5-9 Sept. Article (CrossRef Link) PMid:20369924 289 - 302
Zhang X. , He J. , Wei Q. 2011 “EDDK: Energy-Efficient Distributed Deterministic Key Management for Wireless Sensor Networks” EURASIP Journal on Wireless Communications and Networking Article (CrossRef Link) 2011 (12)
Perrig A. , Szewczyk R. , Wen V. , Culler D. E. , Tygar J. D. 2001 “SPINS: Security Protocols for Sensor Networks” in Proc. of ACM Mobile Computing and Networking Article (CrossRef Link) 189 - 199
Lee S. , Kim J. 2009 “Design of Authentication Protocol for LR-WPAN using Pre-Authentication Mechanism” in Proc. of The Sixth IEEE Consumer Communications and Networking Conference 10-13 Jan. Article (CrossRef Link) 1 - 5
Tian B. , Han S. , Liu L. , Khadem S. , Parvin S. 2012 “Towards Enhanced Key Management in Multi-phase ZigBee Network Architecture” Computer Communications Article (CrossRef Link) 35 579 - 588    DOI : 10.1016/j.comcom.2011.12.004
Yüksel E. , Nielson H. R. , Nielson F. 2011 “A Secure Key Establishment Protocol for ZigBee Wireless Sensor Networks,” The Computer Journal Article (CrossRef Link) 54 (4) 589 - 601    DOI : 10.1093/comjnl/bxq036
Dini G. , Tiloca M. 2010 “Considerations on Security in ZigBee Networks,” in Proc. of 2010 IEEE International Conference on Sensor Networks, Ubiquitous, and Trustworthy Computing 7-9 June Article (CrossRef Link) 58 - 65
Whiting D. , Housley R. , Ferguson N. 2003 “Counter with CBC-MAC (CCM)” RFC 3610. Article (CrossRef Link)
Krawczyk H. , Bellare M. , Canetti R. 1997 “HMAC: Keyed-Hashing for Message Authentication,” RFC 2104 Article (CrossRef Link)
Wallner D. , Harder E. , Agee R. 1999 “Key Management for Multicast: Issues and Architectures,” IETF, RFC 2627 Article (CrossRef Link)
McGrew D. , David A. , Alan T. , Sherman A. 2003 “Key Establishment in Large Dynamic Groups using One-way Function Trees” IEEE Transactions on Software Engineering Article (CrossRef Link) 29 (5) 444 - 458    DOI : 10.1109/TSE.2003.1199073
Hill J. , Szewczyk R. , Woo A. , Hollar S. , Culler D. , Pister K. 2000 “System Architecture Directions for Networked Sensors,” in Proc. of the Ninth International Conference on Architectural Support for Programming Languages and Operating Systems Dec. vol. 35, Article (CrossRef Link) 93 - 104
Simek M. , Moravek P. 2011 "Modeling of Energy Consumption of ZigBee Devices in Matlab Tool," Elektrorevue Article (CrossRef Link) 2 (3) 41 - 46
Yüksel E. , Nielson H. R. , Nielson F. 2012 “Key Update Strategies for Wireless Sensor Networks” International Journal of Information and Electronics Engineering Article (CrossRef Link) 2 (2) 141 - 145
Chen L. 2008 “Recommendation for Key Derivation using Pseudorandom Functions” Revised NIST Special Publication 800-108 Article (CrossRef Link)