Infosecurity杂志上的ZigBee的文章

Infosecurity Volume 4, Issue 3, April 2007, Pages 32–35

The need to accommodate resource and energy constrained nodes has resulted in a number of vulnerabilities and adversaries .... Hopefully, these shortcomings will be addressed in future versions of 802.15.4 and ZigBee standards.

ZigBee: A long way to go? The introduction of IEEE 802.15.4 low rate wireless personal area network (LR-WPAN) standard [1] was implemented for three reasons: the need for low-cost, low-power and short-range communication. While the 802.15.4 standard goes into great detail when describing the functionality of the physical (PHY) and medium access control (MAC) layer, security related issues received much less attention. Jelena Mišic explains… The standard outlines some basic security services at the MAC (or, more precisely, data link) layer that can be combined with advanced techniques from upper layers to implement a comprehensive security solution. For example, the recent ZigBee specification 【10】 implements a number of protocols— including security reated ones—that can be deployed in an 802.15.4 network.

The 802.15.4 specification In an IEEE 802.15.4 compliant WPAN, a central controller device (commonly referred to as the PAN coordinator) builds a WPAN with other devices within the personal operating space. The standard allows two topologies. The first is the peer-to-peer topology in which nodes can directly communicate with one another. The second is star topology, in which all communications, even those between the devices themselves, must go through the PAN coordinator. While the former topology may appear better suited to sensing tasks, it was recently shown that such networks with identical devices are not optimal in terms of power consumption 【4】. Therefore, we consider only sensor clusters that use the star topology in this analysis.

How does it work? The 802.15.4 networks with star topology operate in beacon enabled mode - channel time is divided into super-frames, bounded by beacon transmissions from the PAN coordinator 【1】. All communications in the cluster take place during the active portion of the superframe; the inactive portion may be used to switch to conserve power by switching devices to a low power mode. The active portion of each superframe is divided into equal slots which are further subdivided into backoff periods. Channel access is regulated through the CSMA-CA mechanism similar to 802.11 【1】. Since both packet transmissions and clear channel access (CCA) checks must be synchronized to the slot boundaries of backoff periods, this mechanism is designated as slotted CSMA-CA Data transfers in the downlink direction, from the coordinator to a node, must first be announced by the coordinator. The beacon frame contains the list of nodes that have pending downlink packets (Fig. 1b). When the node learns there is a data packet to be received, it transmits a request. The coordinator acknowledges the successful reception of the request and the coordinator then sends the packet using the slotted CSMA-CA. The recipient node will listen for the data packet for the period of a maximum frame response time, during which the coordinator must send the data frame.. The services listed in the box are typically implemented in hardware for performance reasons. Their use is optional. Individual security services may be combined into the so-called security suites, as a ‗set of operations to perform on MAC frames that provide security services‘ 【1】.

Figure 1. Data transfers in 802.15.4 PAN in beacon enabled mode. How does it operate? A device can choose to operate in unsecured mode, secured mode, and ACL mode. In unsecured mode, none of the services mentioned are available. In secured mode, the device may use one of the security suites supported by the standard 【1】, all of which use the Data Encryption service. A device operating in ACL mode can maintain a list of trusted devices from which it expects to receive packets. The access control service enables the receiver to filter received frames according to the source address listed in the frame. Without encryption, it is not possible to authenticate the true source of the data packet or to ascertain that the packet payload has not been modified in any way. While these services are useful, they are by no means sufficient. In particular, procedures for key management, device authentication, and freshness protection are not specified by the 802.15.4 standard. Hence, they must be implemented by the applications, or perhaps by another layer of network protocols running on top of 802.15.4 itself. A viable alternative for this task is the ZigBee protocol suite 【10】 developed by the ZigBee Alliance, an industry consortium working on developing network and Application Programming Interfaces (API) for wireless ad hoc and sensor networks. The ZigBee APIs include security extensions at different networking layers, using both symmetric and asymmetric key exchange protocols. Asymmetric key exchange protocol, which mainly rely on public key cryptography, are computationally intensive and their application in wireless sensor networks is only possible with devices that are resource rich in computation and power and connected through high bandwidth links. As many wireless sensor networks require extended low power operations which favor the use of simple, resource-constrained nodes, the protocols that rely on symmetric key exchange (which is computationally much simpler) are preferred. One such protocol is known as the Symmetric-Key Key Establishment (SKKE) protocol. In this protocol, the application support sublayer of the ZigBee specification defines the mechanism by which a ZigBee device may derive a shared secret key (link key) with another ZigBee device. Key establishment involves two entities, an initiator device and a responder device, and should be prefaced by a trust provisioning step in which trust information (a master key) provides a starting point for establishing a link key. The master key may be preinstalled during manufacturing, it may be installed by a trust center, or it may be based on user-entered data (e.g., PIN or password). In the following example, we assume that all the devices, including the PAN coordinator, have pre-installed master keys.