Standard Security#
Overview#
Standard security, introduced in the Zigbee 2007 specification along with Zigbee PRO, is the security model being used in all Zigbee application profiles and in Zigbee 3.0. It is the only security model supported by the EmberZNet PRO stack libraries.
Standard security uses network keys and link keys to encrypt data at the network and application layers, respectively. The application support (APS) layer security allows the trust center to securely transport the network key to joining or rejoining nodes, and it optionally allows applications to add additional security to their messages. Network (NWK) layer security is used to secure all traffic sent on a Zigbee network, with the exception of basic MAC layer communication such as association, data requests (polling), and MAC ACKs. Dynamic Link Keys (DLKs), introduced in R23, allow for messages with no NWK layer security to be securely exchanged between a potential joining device and the trust center across a Zigbee 3.0 network using APS layer security.
Use of Keys in Standard Security#
Standard security defines different keys used for securing data in different ways. All keys are 128-bit symmetric and may or may not be used for encrypting/decrypting packets.
Network Key#
This is the network-wide key used to secure transmissions at the network layer. Standard security requires the use of a shared network key among all devices in the network. The trust center may periodically update and switch to a new network key. The trust center may use either a broadcast update or a unicast update. In the broadcast case, the trust center first broadcasts a new network key encrypted with the old network key. In the unicast case, the trust center sends a new network key to each device encrypted with that device’s corresponding Trust Center Link Key.
In both cases, the trust center later tells all devices to switch to using the new network key. The new network key has a sequence number that is one higher than the last sequence number.
Trust Center Link Key#
This key (known simply as the link key) is used for secure end-to-end communications between two nodes, one of which is the trust center. The trust center link key is used in these cases:
Encrypting the initial transfer of the network key to a joining node.
Encrypting an updated copy of the network key to a rejoining node that does not have the current network key.
Routers sending or receiving APS security messages to or from the trust center. These may be updates informing the trust center of a joining or rejoining node, or a command sent by the trust center to a router to perform some security function.
Application unicast messages that enable APS encryption, where either the sending or receiving device is the trust center.
The trust center has the option of deciding how to manage the trust center link keys. It may choose unique keys for each device in the network, keys derived from a common piece of shared data (the IEEE address of the device), or a global key that is the same for all devices in the network. Trust center link keys may also be negotiated at the application layer using a key establishment protocol like Certificate-Based Key Establishment (CBKE). As of R23, the trust center may also use DLKs, which use elliptic curve Diffie-Hellman key negotiation to establish keys and authenticate devices before joining the network.
Installation Code Keys#
Zigbee 3.0 now has installation code keys, which were previously only available to Smart Energy networks. All Zigbee 3.0 certified devices are required to have them, but use in the network is decided by the trust center. Smart Energy networks are required to always use them.
An installation code key is just a preconfigured trust center link key used to enter the Zigbee network and obtain the current network key. Because this unique key must be known to both the joining device and the trust center at the time of network entry, a piece of shareable data known as the "installation code" (sometimes also referred to as the "install code") is used to derive the key at both sides. The code can be any arbitrary value of 6, 8, 12, or 16 bytes, followed by a 16-bit CRC (least significant byte first) over those bytes.
This code is then used as the input to a Matyas-Meyer-Oseas (MMO) hash function (as specified in Zigbee Document 053474, the Zigbee Specification), with a digest size (hash length) equal to 128 bits. The 128-bit (16-byte) result of this AES-MMO hash function is used as the value for the preconfigured trust center link key for that device, and the trust center can then install a key table entry with that key and the EUI64 of the joining device, which then allows the authentication to take place successfully during joining, and the joining device can successfully receive and decrypt the network key delivery.
As part of this process, the installation code and the joining device’s EUI64 must be conveyed out-of-band (outside of the target Zigbee network, since the new node is not yet joined) to the network’s trust center to allow the proper link key table entry to be created. This communication may involve the device installer contacting the network administrator (the party responsible for the trust center, such as a utility company) by telephone or Internet to provide the necessary information.
Application Link Keys#
Standard security supports devices establishing application link keys with other devices. These keys are separate from the trust center link key and not required for normal operation. They are used for APS-level encryption between two devices in the network, neither of which is the trust center.
Application link keys must be established separately from the trust center link key. Devices may not establish an application link key with the trust center. However the trust center link key can be used to APS-encrypt application messages to the trust center, or from the trust center to a device on the network.
Application link keys can be established in one of two ways:
Manual configuration by the application specifying the key associated with a destination device.
Through a request that the trust center generate a key and send it to both devices.
The application can manually configure a key by calling into the stack and setting one up. The partner device must also configure the application link key and negotiate with the other device when they can start using that key.
Application link keys can also be established using the trust center. The EmberZNet PRO stack supports two methods for this. The first is the Zigbee standard method, discussed in Link Keys, where one device requests an application link key with another device by contacting the trust center. The trust center then immediately responds and sends a randomly generated application link key back to the requesting device and to the partner device. The drawback with having only one device request a key is that the other device may be asleep, offline, or have insufficient capacity to hold another key.
The second method, shown in the following figure, is not standardized in Zigbee and will be non-interoperable with other vendors’ devices. It also requires that all devices in the exchange are configured to use this method, including the trust center. It is more reliable in that it helps ensure that the partner device is online and able to receive an application link key. In this case, both devices must request an application link key from the trust center. The trust center stores the first request for an application link key for a period of time defined by the trust center application. During that time, the partner must send in its own application link key request with the first device as its partner. If that occurs, then the trust center generates a random application link key and sends it back to both devices. Requiring both devices to request an application link key greatly reduces the chance that a device or its partner will not receive the key.
EmberZNet PRO supports a configurable table for storing application link keys.
Joining a Network#
A device initiates the process of joining a Zigbee standard security network by first using MAC association to join to a suitable parent device. If the association is successful, the device is joined but unauthenticated, as it does not possess the network key. Before joining, the trust center may choose to delay sending the network key and 'interview' the device by sending arbitrary data requests to the joining device, to determine more about its capabilities and characteristics before deciding whether to authorize it.
After sending the success response to the MAC association request, the router sends the trust center an Update Device message indicating that a new node wishes to join a Zigbee network. The trust center can then decide whether or not to allow the device to join. If the device is not allowed to join, a Remove Device request is sent to the parent, as shown in the following figure. If the device is allowed to join, the trust center's behavior depends upon whether the device has a preconfigured link key.
Preconfigured Link Keys#
The trust center dictates the policy of how to handle new devices and determines whether a device should have a preconfigured link key. If a new device does not have a preconfigured link key, it will be unable to join the network.
The trust center has the option of choosing whether that key is the well-known default link key (ZigBeeAlliance09), a pre-shared installation code, or a dynamically-negotiated link key. The following figure illustrates the joining process with a preconfigured key.
To allow a device onto the network, the trust center transmits the network key encrypted with the device's preconfigured link key.
Zigbee 3.0 and all Zigbee application profiles require a preconfigured link key for joining.
Deciding What Key to Use#
The choice of whether the trust center will use a well-known key, an installation code, or a Dynamic Link Key (DLK) is based on a balance between ease of use and security.
Using a well-known key enables devices to join more easily without much user interaction. However, encrypting the network key with a well-known key provides a moment of vulnerability until that well-known key is replaced with a new key.
Using an installation code provides security for the initial exchange of the network key to the device, at the cost of added interaction between the user and the trust center. A user must somehow transfer the key from the device to the trust center. This is accomplished by a mechanism outside of the Zigbee network, such as typing in the code into the trust center GUI from a label listing the code on the joining device.
Using a DLK provides the most secure type of joining, as it allows the trust center to hold onto the network key for as long as possible before sharing it with joining device. It uses cryptographic techniques to negotiate unique link keys securely over an insecure channel.
The main application running on the network will help dictate whether ease of use versus better security is more important. The Zigbee standard allows either.
Requesting a New Link Key after Joining#
Zigbee 3.0, devices are required to request an updated trust center link key after successfully joining. This will replace their existing preconfigured key and be used as long as they are joined to that network. Even if the device joined used an installation code key, that key will be replaced. The following figure illustrates how Zigbee 3.0 devices update the Trust Center Link Key.
This replacement of the key is only possible if both the Trust Center and Joining Device support Zigbee 3.0. If one of them does not, then the original joining key will be kept.
Network Key Updates#
The network key encrypts all transmissions at the network layer. As a result, a local device constantly increases its local network key frame counter. Before any device in the network reaches a frame counter of all F's, the trust center should update the network key. Since it is not possible for the trust center to know the frame counter value of every device in the network at any given time, or even to inspect the frame counters of incoming messages, an approach that relies on specific frame counter thresholds is not practical. Thus, a preventative maintenance approach relying on periodic updates at long intervals, similar to what is described below, is recommended.
The recommended model is for the trust center to periodically update the network key to help minimize the risk associated with a particular instance of the network key being compromised. This helps to ensure that a device that has left a secured Zigbee Network is not able to rejoin later.
Key updates may either be broadcast or unicast. The trust center decides which mechanism it wants to use. Both mechanisms are described in the sections that follow.
Broadcast Network Key Update#
When the key update is broadcast the message is encrypted using the current network key. Devices that hear the broadcast do not immediately use the key, but simply store it. Later, a Key Switch is broadcast by the trust center to tell all nodes to start using the new key. At a minimum, the trust center should allow adequate time (approximately 9 seconds) for the broadcast of the new key to propagate throughout the network before switching. In addition, a trust center must keep in mind that sleeping end devices may miss the initial broadcast unless they poll frequently.
The broadcast mechanism is very simple because it does not require knowing the identity of all devices on the network. It also only involves sending two messages, an updated key message and a switch message.
Unicast Network Key Update#
For a unicast update the trust center will send an individual key update to each device on the network. The trust center must have been previously maintaining a list of all authorized devices on the network in order to do this.
The update message is unicast to each device with APS encryption using each device’s specific trust center link key. Later a key switch is broadcast by the trust center to tell all nodes to start using the new key.
Missing a Network Key Update#
It is possible that any device may miss a key update. This may happen because it was sleeping, was powered off, or dropped off the network for an extended period of time. If this occurs, a device may try to perform a trust center rejoin. The trust center can then decide whether to allow the node back on the network.
The EmberZNet PRO stack can detect the condition where an encrypted packet arrives secured with a newer network security key. It will automatically perform a trust center rejoin to its current network to attempt to acquire the latest network key.
Network Rejoin#
Rejoining is a way for a node to reconnect to a network of which it was previously part. Rejoining is necessary in two different circumstances:
Mobile or sleepy devices that may no longer be able to communicate with their parent.
Devices that have missed the network key update and need an updated copy of the network key.
Devices that have missed a PAN ID update and need to discover the network’s new PAN ID.
When a device tries to rejoin, it may or may not have the current network key. Without the correct network key, the device's request to rejoin is silently ignored by nearby routers.
Therefore, a device has two choices when rejoining: a secured rejoin or a trust center rejoin. Note that neither of these rejoin cases requires the MAC Permit Association (also known as "permit joining") flag to be set on any devices in the target network. A router/coordinator device will always provisionally accept a NWK layer Rejoin command that is either a trust center rejoin or a secured rejoin with the active network key. For the trust center rejoin case it is then the trust center’s responsibility to grant or deny access once it is notified of the rejoining device.
Secured Rejoining#
A secured rejoin is the simpler case and a device seeking to rejoin the network should try this method first. If it has the current network key, the device will be able to communicate on the network again very quickly. A secured rejoin is only necessary when a sleepy or mobile end device has lost its parent.
As illustrated in the following figure, the device sends its rejoin request encrypted with its copy of the network key. If a router is nearby and is using the same network key, the rejoin response is sent back to the device encrypted. The device is now joined and authenticated on the network again. The parent that answered the rejoin request informs the trust center that the device rejoined, but no further action must be taken by the trust center.
If the secured rejoin fails and the device is using standard security, the application can try an unsecured rejoin.
Trust Center Rejoin#
A trust center rejoin is necessary when neighboring devices have switched to a new network key and no longer use the same network key as the rejoining device. To succeed in the trust center rejoin, the device must have a trust center link key. The device sends the rejoin request unencrypted. A nearby router accepts the unencrypted rejoin request and responds to the device, allowing it to transition to the joined and unauthenticated state.
As illustrated in the following figure, the parent of the rejoining device sends an Update Device message to the trust center, informing it of the unsecured rejoin. The trust center has two choices: deny or accept the rejoin. If it accepts the rejoin, it must send an updated network key to the device. However, it secures this message using that device's trust center link key. The message is sent to the parent of the rejoining device encrypted at both the network and APS layers. The parent then relays this message without network encryption to the rejoining device. Once it has the network key, it will be in the joined and authenticated state and can communicate on the network again.
Important Note on allowing Trust Center Rejoins#
The decision by a Trust Center to allow a Trust Center Rejoin must consider whether or not a well-known link key is in use by the requesting device. If a Trust Center has only a well-known link key for the device (such as the ZigBeeAlliance09 key), it should silently ignore the rejoin request. The well-known link key is insecure and thus should not be used for transporting an important piece of data, namely the network key, during a rejoin. A well-known link key should only be used for initial joining and even then it should allowed only for a brief period of time.
Pre-Zigbee 3.0 networks did not update the Link Key after joining and thus it is highly recommended to reject any attempt to rejoin with the well-known link key. Smart Energy networks are not subject to this particular issue because they update their link key after joining. See Zigbee Smart Energy (ZSE) Security, for more details. Therefore, Smart Energy networks may accept Trust Center Rejoins.
The recommendation to silently reject the Trust Center Rejoin as opposed to explicitly reject the Trust Center rejoin is necessary to maintain compatibility with pre-Zigbee 3.0 devices. Pre-Zigbee 3.0 devices may try Trust Center Rejoins without considering whether an updated link key has been obtained previously. If an explicit rejection is done, the device may drop off the network entirely while a silent rejection would allow the device to try a Secure Rejoin later and succeed.
The Trust Center’s behavior will ultimately determine the security of the Trust Center Rejoin attempt. This can be controlled via the emberTrustCenterJoinHandler() callback on the SOC or via the ezspSetPolicy() API configuring the EZSP_TRUST_CENTER_POLICY for an NCP. To silently ignore the Trust Center Rejoin on an SOC device, the emberTrustCenterJoinHandler() must return EMBER_NO_ACTION. To silently ignore the Trust Center Rejoin on an NCP, the host must set the EZSP_TRUST_CENTER_POLICY to EZSP_IGNORE_TRUST_CENTER_REJOINS.
An End Device is advised to restrict itself to only performing Secure Rejoins if it has only a well-known link key. This is the default in the End Device Support component/plugin of the latest release of EmberZNet PRO. However, as noted above, it is the Trust Center’s behavior that ultimately guarantees the safety of the network.
Trust Center Decision Process Summary#
The following figure illustrates the decision tree for the trust center when a device joins the network. The parent of a joining or rejoining device sends an Update Device APS command to the trust center, indicating the event has taken place. The trust center application decides what to do based on that information. This figure describes the behavior for a Zigbee PRO device joining a Zigbee PRO network using standard security.
The trust center can decide whether or not to allow devices into a Zigbee network and whether or not to send the key in-the-clear. The trust center's decision can be made based on any number of additional factors, such as a user event (button press), a time-based condition, IEEE address of the joining device, or some other condition (such as, the network is being commissioned).
When new devices join, the trust center decides whether the device should have a preconfigured key. The joining devices have no ability to inform the trust center through the Zigbee protocol about whether or not they have a preconfigured key.
Distributed Trust Center Mode#
Normally a joining device is authenticated by the trust center through its parent. This is advantageous, as it allows one device to act as a gatekeeper and authenticate all devices that want to join the network. Security messages are relayed to the joining device through its parent until it becomes joined and authenticated.
However, this means that all routers must have a route to the trust center and vice versa. When applications are being developed or when commissioning a network, the trust center may not be reachable, and thus devices cannot join or perform a trust center rejoin.
The EmberZNet PRO stack allows a network to use standard security features without a trust center. This is known as distributed trust center mode. This mode is Zigbee-compliant as of Zigbee 3.0. This mode has the advantage of permitting devices to join without requiring the parent node to send information to the trust center and await the response. In this mode, all routers mimic the behavior of a trust center by sending the security data directly to the joining node. Each router individually decides whether or not to let the device onto the network. This mode is useful to allow commissioning of a complete network and then establishment of a trust center for security.
In this mode, all devices use a single trust center link key is preconfigured. All devices inherit the distributed trust center setting from their parent when they join and also operate in that mode. Thus, only the device that forms the network (the coordinator) needs to be set up to run in distributed trust center mode.
Additional Requirements for a Trust Center#
To function correctly in a Zigbee PRO network, a trust center also requires that:
The trust center application must act as a concentrator (either high or low RAM).
The trust center application must have support for source routing. It must record the source routes and properly handle requests by the stack for a particular source route.
The trust center application must use an address cache for security, in order to maintain a mapping of IEEE address to short ID.
Failure to satisfy all of the above requirements may result in failures when joining/rejoining devices to the network across multiple hops (through a target node that is neither the trust center nor one of its neighboring routers.)
Trust Center as a Concentrator#
The trust center must act as a concentrator because Zigbee PRO Security requires two-way routes to and from the trust center in order to transmit all the security messages necessary to transition a device to the joined and authenticated state.
Routers running the EmberZNet PRO stack automatically add a route to the trust center through their parent (the device they joined to) immediately after they become joined and authenticated. This route assumes that the trust center is acting as a low RAM concentrator.
The trust center should periodically broadcast the many-to-one route message, so that all routers update their routing tables and repair broken routes to the trust center. This also allows it to notify routers if it is acting as a high RAM concentrator, thereby updating the default route.
Trust Center and Source Routing#
The trust center must have support for source routing in the application. It should record the routes of incoming messages and store them in its own table. If the trust center is acting as a high RAM concentrator, it must keep track of all source routes. If the trust center is acting as a low RAM concentrator, then only the last couple of source routes must be recorded. The minimum number of entries in the source route table should be sized to support the maximum number of simultaneous security events that may occur at one time. These security events include rejoins, joins, and leaves.
In addition to storing the source routes, the trust center must also implement the proper hooks to respond to requests by the stack for a particular source route. Silicon Labs provides a source route library, which manages a source route table, and works with a trust center.
Note: For EZSP host-based designs, the source route table on the host cannot be used for routing security messages sent to devices joining or rejoining the network. This is because the APS security transactions must be handled by the stack (in the network coprocessor) without relying on application level interaction (at the host.)
Trust Center Address Cache#
In order to properly decrypt APS-encrypted messages, the trust center must maintain a mapping of IEEE address to short ID.
For a high RAM concentrator, the trust center must keep track of all devices in the network.
For a low RAM concentrator, the trust center need only keep track of a couple of entries at a time and may overwrite old entries as needed. The size of the cache should be equal to the maximum number of simultaneous security events that can occur at one time. These security events include rejoins, joins, and leaves.
Silicon Labs provides sample code for implementing the trust center address cache mechanism on SoC platforms (See app/util/security/security-address-cache.c). The EZSP network coprocessor binaries contain the security address cache feature as part of the firmware, but the host application must enable this feature by setting the Trust Center Address Cache Size to a value greater than 0. (Refer to document UG100: EZSP Reference Guide, for details on how to do this in your EZSP host implementation.)