«Carles Gómez Josep Paradells José E. Caballero Edita: Fundación Vodafone España Autores: Carles Gómez Montenegro* Universitat Politècnica de ...»
9.3.1. ZigBee security architecture 184.108.40.206. ZigBee security design guidelines The ZigBee security architecture is based on an open trust model for each device: the layers and all applications that run in a device can trust each other. This model allows key material23 to be reused at several layers of the same device and makes end-to-end security possible between devices.
This approach leads to the following ZigBee security principles:
• The layer that originates a frame is responsible for securing the frame.
• Only source and destination have access to a key shared by them.
• All devices of a network will use the same security level.
220.127.116.11. Security keys
Security between devices of a ZigBee network is based on link keys and a network key. Unicast communication between two APL entities is secured by means of a 128-bit link key shared by both devices, while broadcast communications are secured by means of a 128-bit network key shared by all devices of the network. A receiver always knows which key has been used to protect a frame.
For instance, the active network key is used to secure APS layer broadcast frames or NWK layer frames. Reuse of keys contributes to reducing storage requirements.
A device may obtain link keys via key transport service, key establishment service or pre-installation. The first two mechanisms are APL layer mechanisms (see 9.3.4). The link key establishment technique is based on the use of a master key. A device obtains the master key through the use of key transport or pre-installation. A device may obtain the network key via key transport service or pre-installation.
As a precautionary measure, the reuse of a key by different security services is avoided. For this reason, different services use different keys obtained with a one-way function from the link keys. The network key may be used by MAC, NWK and APL layers. The link and master keys may be used solely by the APL layer. Subsection 9.3.5 provides more details about key management in a ZigBee network.
A device may store two network keys: the active key (the one which is being used at a given moment) and the alternative key, which may become the active key in certain situations.
18.104.22.168. Security architecture
The ZigBee architecture includes security mechanisms in three layers of the ZigBee protocol stack: MAC, NWK and the APS sublayer, all of which are responsible for the secure transport of their respective frames. In addition, the APS sublayer provides services for establishment and maintenance of secure end-to-end communications. The ZigBee Device Object (ZDO)24 manages the security policies and configuration in a device.
22.214.171.124. Security levels
MAC, NWK and APS each comply with eight security levels. These security levels are equivalent to those shown in Table 9.1, that is, no security, cipher only, authentication/integrity only (with 32-, 64- and 128-bit MAC25 options) and cipher plus authentication/integrity (with 32-, 64- and 128-bit MAC options).
See Chapter 11 Here, MAC stands for Message Authentication Code.
9.3.2. MAC layer security When a MAC frame requiring security is generated, ZigBee uses the MAC layer security specified in IEEE 802.15.4-2006, complemented with additional mechanisms26. The use of CCM* in ZigBee allows the reuse of the same key material by MAC, NWK and APS layers. The MAC frame is responsible for its own security, but upper layers specify which security level must be used by the MAC layer.
Fig. 9.1 shows the fields involved in the use of MAC layer security in a ZigBee frame.
Fig. 9.1. Payload of the ZigBee frame (MAC payload), when MAC layer security is used. The last field, denoted by MAC, is the Message Authentication Code. The size of each field is expressed in bytes 9.3.3. NWK layer security When a frame generated at the NWK layer requires security, or when a frame is generated by an upper layer and requires NWK security, ZigBee uses the AES and CCM* algorithms. Upper layers determine the key and the security level to be used.
Fig. 9.2 shows the fields involved in the use of security at NWK layer in a ZigBee frame. The NWK header may have a size of 8, 16 or 17 bytes, which correspond to the following situations: i) absence of source and destination IEEE addresses; ii) presence of such addresses, and iii) use of multicast. When NWK layer security is used, a 14-byte auxiliary header is employed.
See clause 4.3 of ZigBee specification 
Fig. 9.2. Payload of the ZigBee frame (MAC payload), when NWK layer security is used. The last field, denoted by MAC, is the Message Authentication Code. The size of each field is expressed in bytes 9.3.4. APL security When a frame generated by the APL layer requires security, the APS sublayer manages the security mechanisms needed. The APS sublayer provides frame security based on link keys or network keys. This sublayer is also responsible for offering functionality such as key establishment, key transport and device management services to the ZDO and applications. In order to do this, the APS sublayer uses special data units called commands.
Fig. 9.3 shows the fields involved in the use of an APS sublayer security in a ZigBee frame. The APS header may be composed of 8 or 9 bytes, depending on whether the destination corresponds to a single destination endpoint or a group address (that is, an address that identifies the members of a group). When an APS sublayer security is used, a 5- or 6-byte auxiliary header is employed. This size depends on the use of an optional parameter.
Fig. 9.3. Payload of a ZigBee frame (MAC layer payload), when APS security is used. The last field, denoted by MAC, is the Message Authentication Code. The size of each field is expressed in bytes
126.96.36.199. Key establishment The APS sublayer provides the mechanism by which a ZigBee device can establish the link key, which is a shared secret key, with another ZigBee device. The Symmetric-Key-Key Establishment (SKKE) protocol is used for that purpose and requires the use of a master key. Recall that link keys may also be pre-installed.
188.8.131.52. Key transport
The key transport service provides both secure and insecure mechanisms to transport a key from one device to one or more different devices.
• The secure key transport mechanism is used to transport a master key, a link key or a network key from a key source to other devices.
• The insecure key transport mechanism is based on the use of out-ofband channels (which are beyond the scope of the ZigBee specification) that guarantee secrecy and authentication. In this case, security is provided by non cryptographic methods.
184.108.40.206. Device update
The device update service provides a secure method to inform the trust center (which is an entity that all ZigBee devices trust, see 220.127.116.11) that a third device has changed its status (e.g. it has joined/left the network or does not fulfil the security requirements of the trust center). This is the mechanism by which the trust center maintains an accurate list of the number of active devices.
18.104.22.168. Key recovery and key update
The key recovery service provides the devices with a secure way of soliciting the current network key or an end-to-end master key to another device (e.g. the trust center). On the other hand, the key update service offers the devices a secure way to inform another device that it should switch to using a different network key.
9.3.5. Functional description This subsection offers a functional description of the security services in a ZigBee network. First, the security tasks of three network entities are presented. These elements are the ZigBee coordinator, the trust center and routers. Secondly, the following procedures are described: secure network join, authentication, network key update, network key recovery, end-to-end key establishment and leaving a network.
22.214.171.124. Security tasks of ZigBee coordinator, trust center and router
First, the ZigBee coordinator configures the network security level. It also configures the trust center address, which is by default the ZigBee coordinator itself or a device designated by the ZigBee coordinator.
The trust center is a device that all ZigBee network devices trust and is in charge of network key management as well as end-to-end communications management. The trust center can help to establish end-to-end application keys by sending link keys or master keys. The keys must be randomly
generated. It may operate in two modes, the commercial mode and the residential mode:
• The commercial mode has been developed for high security commercial applications. In this mode, the trust centre maintains a list of devices, master keys, link keys and network keys that are needed for network admission control and key update policies.
• The residential mode is targeted to low security residential applications. In this mode, the trust centre maintains the network key and controls the network admission control, but the device list and key maintenance are relaxed.
Finally, in the ZigBee security context, a router is a ZigBee device that, in addition to carrying out routing tasks, accepts network join requests sent by other devices.
126.96.36.199. Secure network join Fig. 9.4 shows the messages involved in the procedure by which a device communicates with a router to join a secure ZigBee network.
The device that aims at joining the network may start the join procedure by transmitting a non-secure beacon request. This same device receives beacons from the surrounding neighbours, which include information about the security level of the network. In accordance with these parameters, the device decides which WSN intends to join by sending an association request command to the corresponding router. If the device already has a network key for a specific WSN, the association request includes parameters that allow the router to discover this fact. At this point, the router knows the device address and the network key used to generate the association request.
The router then transmits an association response command. When this command is received, the device is declared as joined, but not authenticated.
Subsequently, the authentication phase follows (see 188.8.131.52) except for
when the device is not a router. In this situation, the device is immediately declared as joined and authenticated.
184.108.40.206. Authentication If the router that securely joins the new device) is not the trust centre it initiates the authentication procedure by transmitting the update device command (see 220.127.116.11) to the trust center.
In the residential mode, the trust center sends the network key to the joined device. This is done by means of the insecure key transport mechanism from the router to the device (see Section 18.104.22.168).
Fig. 9.5. Message chart for the authentication of a new device in a secure ZigBee network, in residential mode In commercial mode, if the trust center does not share a master key with the joined device, it sends a master key to the device through the router. The transmission of this key from the router to the device is done by means of an insecure key transport mechanism (see 22.214.171.124). The trust center then starts the establishment of a link key between the trust center and the device using the SKKE protocol. Once the link key has been established, the
trust center sends the network key to the new device by means of the secure key transport mechanism. Fig. 9.6 illustrates the sequence of messages described.
Fig. 9.6. Message exchange for the authentication of a new device in a secure ZigBee network, in commercial mode 126.96.36.199. Network key update In residential mode, the trust center may update the network key for all the devices of the network. To do so, the trust center sends the network key through a transport-key command in broadcast mode.
In commercial mode, the trust center maintains a list of all the devices of the network. To update the network key, the trust center transmits the new network key to each device of the list and then requests that each device uses this new key through the switch-key command. Fig. 9.7 presents an example showing the related message exchange.
188.8.131.52. Network key recovery A device may request the network key from the trust center by sending the request-key command.
In residential mode, after reception of this command, the trust center assumes that the device belongs to the network.
In commercial mode, the trust center checks that the device is on the list of network devices. In this case, the trust center transmits the network key by using the transport-key command, and indicates that the device should use this key by means of the switch-key command, as shown in Fig. 9.8.
184.108.40.206. End-to-end key establishment The device that intends to establish a link key with another device sends a request-key to the trust center indicating that it requests a link key and the remote device with which this link key should be shared.
Depending on the configuration of the trust center, it can provide link keys or master keys by offering the corresponding key to the two devices for which an end-to-end key is going to be established. If the trust center provides a master key, the initiator starts the key establishment procedure by transmitting the SKKE-1 command of the SKKE protocol. If the remote device accepts this command, the protocol is run with the transmission of SKKE-2, SKKE-3 and SKKE-4 commands. Fig. 9.9 illustrates the sequence of messages described.
220.127.116.11. Secure network leave A device may leave a network by its own decision or by decision of the