ZigBee & Z-Wave Security Brief: Part 2

This is the second of two blog posts where we will share a summary of the differences. We encourage you to read the first post for background on the purpose of this post and discussion of security levels and keying techniques.

The ZigBee and ZWave 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.

Encryption Algorithms

The encryption used by ZBHA1.2 and ZB3.0 is AES-CCM* operating with a 128-bit key and block size. When used in the authenticated and encrypted mode AES-CCM-128, this offers adequate security for the use case. A brute-force attack is generally estimated to take 2^127 operations on average, which would take a very very long time even on the fastest computers. S2’s encryption is also AES-CCM-128, but does not allow less secure modes as ZB does with AES-CCM*. S2 requires an 8-byte authentication tag, whereas ZB allows a 4, 8, or 16-byte authentication tag. If it were used, ZB’s 16-byte authentication tag would theoretically offer a higher strength of authentication on the message contents then S2’s 8-byte tag.

Additionally, for the purpose of key agreement, S2 uses the asymmetric Elliptic Curve Curve25519. This curve is generally considered well-reviewed and offers 128-bits of equivalent symmetric security.

Other Mitigations

The S2 specification acknowledges a jam-and-capture (e.g., “ROLLJAM”) type of attack against nonces, as timestamps aren’t used, and states that the Supervision Command class should be used to mitigate this. However, this is not required. ZB faces a similar issue but we are not aware of it recommending a mitigation.

In contrast, the older ZW standards only required security on items like door locks, and left them optional for items like alarm conditions. It utilized proximity pairing which is similar to the ZB Touchlink which has had reported issues in the past. ZW now has 5 different security levels, which can’t talk directly, and thus there are compatibility translations that must occur, typically in the “primary controller.”

Summary

Requirements of interoperability between vendors, desire to simplify the pairing experience for users, limited interfaces, and the notion of constrained resources are challenges that both standards face when designing security. As the Z-Wave specification states, “security is a challenging area in any wireless home control solution, since conflicting requirements are colliding especially strong… User interfaces of many home control devices are extremely limited, not allowing entering keys and/or PIN numbers into devices.”¹ However, in the S2 specification the Z-Wave team appears to have changed course and decided that the user interfaces can allow PIN or QR code entry, and have moved to make such behavior a requirement for many systems. The ZigBee specification has not yet taken the step to embrace such a requirement, and where such options are supported, they generally do not support the same strength of security (key agreement, etc).

We are interested to see if recent consolidation in the industry with the acquisition of Sigma Designs Z-Wave business unit (who owned Z-Wave’s IP) by Silicon Labs (a major player in the IEEE 802.15.4/ZigBee standard) leads to the standards becoming more similar or not from a security perspective.

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.