4.5.1 ZigBee Network Topologies and Types of Keys
As depicted in Figure4.3, the ZigBee network supports Star, Tree, and Mesh topolo- gies. ZigBee network may comprise three types of devices: Coordinator, Router, and end device. In particular, a ZigBee network must have a Trust Center. The Trust Center is usually the Coordinator, which provides key management and other security services. In the Star topology, the network is controlled by the Coordina- tor, which is responsible for initiating and maintaining the devices on the network, while the end devices communicate with the Coordinator [124]. In Mesh and Tree topologies, the Coordinator is responsible for starting the network and for choosing certain key network parameters, but the network may also be extended through the use of ZigBee Routers [118]. Nowadays, the most important and promising ZigBee application profiles seem to be Home Automation [125] and Smart Energy [126]. Our research focuses on the latter since it considers security as a major issue and includes precise mechanisms for secure communications.
In terms of key types, ZigBee uses Master key, Link key, and Network key for authentication and encryption.
• Master key. The Master key is not used to encrypt data. Instead, it is used to authenticate the node when the node joins the network and as an initial shared secret between two devices when they generate Link keys.
• Link key. The Link key is unique for a pair of devices and is used for end-to- end encryption. In particular, the key shared by a device and the Trust Center is called Trust Center Link (TCL) key. The TCL key is established during
Figure 4.3: The topologies of ZigBee networks
the join procedure and is used to protect application level messages and stack commands.
• Network key. The Network key is shared by all devices and is used for broad- cast management and to control communications. A high security Network key must always be sent encrypted over the air [127].
4.5.2 Security Problems of ZigBee Key Management
Two basic security requirements of network communication are forward secrecy which prevents a departing or expelled device from having continued access to fur- ther communication, and backward secrecy which prevents a newly joined device from accessing the previous communication. Usually, these two requirements are achieved by a timely key revocation and rekeying mechanism. Rekeying a group before the addition of a new member is simple, while rekeying the group after a member leaves is far more complicated [128]. The ZigBee specification provides a backward secrecy mechanism but leaves the issue of forward secrecy unresolved.
The ZigBee specification dictates that the Trust Center should refresh the Net- work key periodically, but it does not specify either the refresh period or any event that triggers the Network key refresh. It says nothing about key refreshment upon
a device’s departure. No effective measure is adopted to safeguard Network key and Link key on membership change. All the same, the revoked devices can access all communications encrypted by these keys. The adversary may compromise the device and exploit the Network key to spoof and inject bogus routing information. More seriously, the adversary may launch highly disruptive routing attacks such as sinkhole attack and selective forwarding attack [118].
As far as the two ways to refresh the Network key are concerned, none of them is effective. The overdue Network key is used to refresh the new Network key in the broadcast-based refresh method. While in the unicast-based refresh method, the new Network key is encrypted with each device’s Transport key and delivered to each device in a one-to-one fashion. This solution is secure but has scalability limitations.
As to the Link between two devices, the ZigBee specification does specify how to deal with it when one of the two device leaves the network or how to inform its neighbors when a device leaves the network.
4.5.3 The Enhanced Key Management of the ZigBee Specifica-
tion
The proposed solution can be directly used to enhance the key management ser- vices of the ZigBee tree architecture (As shown in Figure4.3). We assume that the Coordinator has the function of the Trust Center and the Routers have cluster man- agement function. The corresponding relationship of the entities in the proposed solution and the ZigBee specification is shown in the Table4.2.
Table 4.2: The corresponding relationship of the entities in the proposed solution and the ZigBee specification
Entities in the proposed solution Entities in the ZigBee specification The BS The Coordinator
Routers Cluster heads Ordinary sensor nodes End devices
We mentioned that ZigBee uses three types of keys for authentication and en- cryption. The corresponding relationship of the keys in the proposed solution and the ZigBee specification is shown in the Table4.3.
Table 4.3: The corresponding relationship of the keys in the proposed solution and the ZigBee specification
Keys in the proposed solution Keys in the ZigBee specification Master key Master key
Link key Pairwise key TCL key Individual key Network key Network key
4.5.4 Authentication for Node Admission Control in ZigBee Spec-
ification
Secure node admission avoids the situation where unauthorized nodes join the net- work. In the ZigBee specification, the Coordinator controls the policy of node ad- mission. Each authorized node is preloaded with a common network security key prior to deployment. The Coordinator checks the validity of the common Network key. Only those nodes possessing the correct Network key should be permitted to join the network. This authentication method does not take the Network key updating into consideration. What this means, firstly, is that the Network key is re- newed over the generations while the nodes still request admission with the original Network key in later generations. Secondly, the authentication is not secure if the Network key is disclosed.
In the enhanced key management services, we use the TCL key for authentica- tion as it is the unique key shared by each node and the Coordinator. The Master key Km is stored by the Coordinator and does not change over time. Suppose a node u is requesting for admission, the authentication process can be displayed as follows:
The Coordinator generates the TCL key Km
u = fKm(IDu) and uses it to check
the correctness of the MAC value. If the MAC value is correct, node u passes the authentication and joins the network. Otherwise, node u is rejected from joining the network.