ZigBee & Z-Wave Security Brief

We have performed in-depth evaluations of many products built on ZigBee and Z-Wave for clients, and we are often helping clients understand vulnerabilities in IoT products built on standard protocols such as these. We believe that it will benefit the overall community to share a brief summary of our comparisons between these two popular protocols based on the recent ZigBee 3.0 and Z-Wave S2 specifications which both aimed in-part to update the protocols to an increased level of security.

This is the first of two blog posts where we will share a high-level summary of the differences.

The ZigBee and Z-Wave protocols have both undergone numerous revisions and support many different security modes and edge cases. In this discussion, we will try to focus on core design decisions and features, and leave out discussion or investigation of edge cases for brevity. We will use the following shorthand: ZigBee (ZB)’s HA 1.2 spec as ZBHA1.2, the ZigBee 3.0 core protocol as ZB3.0, Z-Wave’s PHY and main protocol as ZW, and Z-Wave’s Security 2 specification as S2.

Physical Layer (PHY)

In terms of the physical layer (PHY), ZW uses a lower frequency compared to ZB¹, which typically has longer range through materials. Also, as ZW has a narrower bandwidth it is sometimes considered easier to jam by injecting noise. It is beyond the scope of this blog post to detail the PHY layer considerations and anti-jamming techniques here, although we may post a later blog discussing our experiences with these considerations over a broad range of PHYs.

Key Management

Both of the protocols support multiple keying modes. Here is a brief summary of the main modes of each:

We will now discuss the three main considerations for these protocols: key exchange, key management, and key usage.

Key agreement in ZBHA1.2 is done by sending the unique per-network key to the newly joined device protected under a fixed key called the “default global trust center link key” (which is well known).⁴ ZigBee can also support per-link keys (each two devices that can talk have a different key), but this is not in widespread use at this time. This transfer method means that an attacker can observe the transport of the network key in ZBHA1.2 networks, if they are sniffing at the time a device is added (or in other edge cases, such as insecure rejoins).

The ZigBee SKKE protocol is a key exchange protocol available in ZigBee PRO for exchanging a link key to then transport the network key. However, we are unable to determine if it is commercially used, and it requires a shared master secret (basically another key) that if not pre-installed must be sent over the air (insecurely).⁵ We have not deeply investigated the security of this exchange.

In the ZB3.0 standard, the install code method for deriving trust-center link keys⁶ must be supported by all devices. This derived key is used to transfer the network key to the end node over, instead of the default global key. However, by default the setting still allows a device to use the old method, which if done by one device can compromise the shared network key used by all devices. Devices may require the use of install codes to join if the devices are something like a gas meter, which is not meant for a consumer to install. Consumer devices may default to a mode requiring an install code, but they must be able to be switched to an “all networks” mode. The ZB3.0 install code is 18 bytes, such as “83FE D340 7A93 9723 A5C6 39B2 6916 D505 C3B5,” and is used with a Matyas-Meyer-Oseas hash to derive the link key. It must always be fully entered on both the trust center and the node (usually handled at the factory for a node).

Whereas this install code method isn’t fully “embraced” by the ZB standards, modes with a similar concept are standard in the ZW S2 standard. In this mode, each device has a public and private key programmed in by the manufacturer. The standard states that the private key should not be able to be extracted by common methods. We would prefer to see this as a firm requirement, but it is further than we have observed in ZB specification requirements.

When a device joins in an authenticated S2 mode, the device sends its public key⁷, but omits the first 2 bytes. These bytes must be entered by the user into the “includer” (e.g., coordinator) by either a 5-digit PIN code, or by scanning a QR code that consists of the first 16-bytes of the key that the includer will use – in both cases, this provides an out-of-band authentication that the user has explicitly given to say “this is the device I want you to allow to join.” This prevents masquerading of a fake device as a legitimate one during pairing. The devices then participated in an authenticated elliptic curve Diffie Hellman (AuthECDH) key agreement, creating a shared secret value that is then used (with other information) to derive temporary keys used to transfer the real network key (PNK).⁸ In ZB, this is typically just one key for the network, however S2 supports different groups with different PNKs (“class keys”) to separate out types of devices. Once the PNK is exchanged, messages are protected with AES128-CCM (using a 64-bit MAC, like most ZB devices) which offers confidentiality and integrity of the messages. Nonces are carefully managed but if they repeat could weaken the cryptography (same as in ZB). However, in S2, the nonces are longer than in ZB, lengthening the time that it would take to have repeat.

There are devices, such as lighting controls which are not part of a home security system, which do not require the user to enter the PIN or QR code for authenticated pairing. These still benefit from most of the S2 protections, but don’t protect against an attacker masquerading as one during a join to the network.

Learn More

We later posted a second blog post discussing the encryption algorithms and other mitigations utilized by these protocols. We also encourage you to contact us if you have any questions or comments based on this post, as we value your feedback and would be happy to discuss your specific questions.