Z-Wave Security

Introduction

This whitepaper provides an overview of the Z-Wave Security ecosystem.

Whether one is providing remote access to, or securing communication between, Z-Wave (PAN) nodes from the Internet (WAN) via a home network (LAN), there are a number of challenges to consider. These include security attack threats, available cryptographic computation power, available network bandwidth, available code space, firewall policies, efficient battery operation and more.

S2 Security introduces best-in-class security in the PAN while maintaining the user friendliness and power efficiency, that Z-Wave is so well-known for. Consumer product manufacturers will appreciate that the S2 Security solution only requires a small code footprint in embedded devices while installers benefit from the simple installation procedure. S2 complements similar optimized mechanisms for IP domains that allow Z-Wave services to operate securely in an end-to-end fashion.

S2 Security may be considered as the first true smart home security solution. It enables secure communication for sensor devices that run for years on a single battery. At the same time it enables secure multicast addressing of lights, window coverings and similar devices.

Z-Wave nodes are added to the Z-Wave network (PAN) with Out-of-Band (OOB) authentication to ensure that they can be trusted. A strong temporary key is used to assign keys for one or more security classes. This allows for segmentation of safety critical devices in the “S2 Access Control” class and sensors in the “S2 Authenticated” class, while the most constrained devices without authentication support are only allowed access to the “S2 Unauthenticated” class.

The Z/IP Gateway controls access to the Z-Wave network by only forwarding commands from trusted LAN clients or from a trusted Internet host such as a service provider portal. It must be expected that a typical home network (LAN) is compromised by malware or bots. DTLS is used to secure communication between LAN hosts and Z-Wave nodes. LAN hosts and Z-Wave nodes communicate via a Z/IP Gateway which terminates the DTLS encryption and strips Z/IP and IP headers before forwarding Z-Wave commands securely in the Z-Wave network.

Users do not want to mess with firewalls. Therefore, the Z/IP Gateway punches a hole from the LAN side of the firewall by creating a secure TLS-based tunnel to a service provider portal in the Internet (WAN). The portal only accepts trusted gateways and the gateway only accepts trusted internet hosts.

Security Challenges in Connected Home Control

It is attractive to connect directly to the home control gateway via the LAN when the user is at home as the latency is lower and the system works even when the Internet connection is down. Just as the WAN, the LAN has also evolved to be a very hostile place in most homes. Kids click on links on compromised web pages or download games with viruses, trojans and other malware. Adults are tricked to open attachments in apparently trustworthy phishing mails. Thus, LAN hosts cannot rely on the LAN being safe today. In home control terms, this means that LAN clients such as tablets and smart phones must use secure and trusted communication when accessing home control resources via the home control gateway. It is also required that the administration web interface of the home control gateway complies with best design practices for non-default user passwords and passwords as well as rejection of brute-force login attempts via exponential delay ramp-up in case of wrong credentials. Additional guidelines may be found in [HC SECURITY].

PAN networks like Z-Wave may also be attacked. The simplest attack is radio jamming. Wi-Fi networks can also be jammed. Jamming may be used to obstruct PAN-based alarm systems. It is therefore critical that the Z-Wave gateway monitors periodical heartbeat signals from all nodes in the Z-Wave network so that jamming can be detected within minutes after the attack is initiated. Another threat is the unintended inclusion of a rogue node. Neighbors may inadvertently add nodes to each other’s (wrong) networks or, more critically, an attacker may succeed in including a debugging node and subsequently extract the network keys from that node. Out-of-Band (OOB) authentication must be required for joining nodes in order to prevent the inclusion of rogue nodes. An attacker may use a wireless sniffer to capture transmissions over the air and replay such transmissions at later time. Encrypted commands may also be replayed. This type of attack is prevented by making each transmission unique and ignoring earlier transmissions in the receiver.

Z-Wave S2 Security – Under the Hood

Many Z-Wave building blocks serve multiple purposes. For instance, an acknowledgement mechanism may at the same time ensure secure delivery of a command, maintain secure multicast state information, assist in saving power and minimize the use of the radio spectrum. 

This chapter provides a detailed walk-through of the mechanisms provided by Z-Wave S2 nodes.

Security classes and network keys

Like Wi-Fi, S2 security [S2] also operates with the concept of a network key. All nodes may use this key to communicate to each other. S2, however, divides the logical Z-Wave network into three dedicated security classes, which each have a unique network key. A given S2 security class not only identifies the network key to use but also dictates the rules applying to authentication of a new node during inclusion. The “S2 Access Control” class is the most trusted class, intended for access control devices like door locks and garage doors. The “S2 Authenticated” class is used for all normal household devices such as sensors and light dimmers. The “S2 Unauthenticated” class is the least trusted class and is only intended for the most constrained controllers that, due to a limited user interface, are not capable of authenticating a node joining the network. An example is a key fob used to control a few lamps in a country cabin. Finally, a dedicated S0 key may be handed out to S2 enabled nodes for interoperability with S0-only nodes. S2 nodes transfer the S0 key just as the “S2 Unauthenticated” class key; using the temporary ECDH key for the key exchange, rather than using the S0 key exchange which has a known vulnerability. 

S0 and all three S2 classes use AES-128 [AES] encryption. The US Government considers AES-128 safe enough for classified information up to the SECRET level [NSA_AES]. Combined with S2 authentication and Nonce scrambling, there is no known way to break this protection – even with the aid of a super computer. 

A node may request and be granted access to several security classes during inclusion but it only accepts incoming commands in the most trusted of the granted classes. This means that a light bulb being a member of both the “S2 Authenticated” and “S2 Unauthenticated” classes only accepts commands encrypted with the “S2 Authenticated” class key. A controlling node that is member of all security classes may control a door lock via the “S2 Access Control” class key and a lamp via the “S2 Authenticated” class key. A node may be granted a subset of the requested classes. For instance, a light bulb may request membership of both the “S2 Authenticated”, “S2 Unauthenticated” and “S0” classes but be granted only the “S0” class by a constrained S2 controller.

Device Authentication 

In a wireless environment, there is a real risk that a foreign node is included accidentally or due to evil intent. The S2 authentication process allows an including controller to verify that a joining node is indeed the physical device that it claims to be. Depending on the UI, an including controller may allow the installer to enter a Device-Specific Key (DSK) string of decimal digits that can be read visually or scanned as a QR code. The DSK is the first 16 bytes of the 32-byte long ECDH public key of the joining node.

If a joining node is granted membership of the “S2 Access Control” or “S2 Authenticated” class by an including controller, the joining node advertises a garbled ECDH public key where the first 16 bits have been set to zero. This may sound like a vulnerability. An including controller could quickly scan through the 65536 possibilities to reverse engineer the garbled bits of the ECDH public key and then include the joining node without waiting for the installer. However, the ECDH public key is not a secret. The purpose is solely to force the installer to confirm that this is indeed the node that should be included. If a joining node is only granted membership of the “S2 Unauthenticated” class, the node advertises the complete ECDH public key so that the authentication step can be skipped.

Key Exchange

Key Integrity

Dettering Lost Devices

It may be impossible to physically reset the network key of a lost device, e.g. if a key fob is stolen from a car. The situation may be noticed by the user or the central gateway may detect that a device has gone missing because the periodic keep-alive notifications stop. 

One response would be to start distributing a new network key to all other nodes in the network. This would, however, require that all nodes could run with both the old and new keys – and corresponding old and new singlecast and multicast Nonces – for a longer period before the new key was completely phased in as many sensors only wake up rarely to report their presence to the gateway. The central gateway would even have to remember all previous keys since the user may have bundled (preconfigured) products lying around for months or years before they are unpacked and installed. Updating a key via an older old key makes no sense if there is no trust in the old key. Having an online enabled method for re-enabling the secure ECDH key exchange would open for a new possible attack vector. 

The lost key fob of the above example may be blacklisted in the gateway, thereby preventing the key fob from triggering gateway rules. If the key fob is later found under the driver's seat in the car, the rules can quickly be re-enabled by removing the key fob from the gateway blacklist again. 

If a lost device directly controls other Z-Wave nodes, it is necessary to mark these nodes as failing and re-include them with new NodeIDs.

Secure multicast with no addressing overhead

Native Z-Wave multicast uses a bit-indexed address field to identify receivers of a particular transmission. This has the attractive property that receivers do not have to keep any state on memberships of multicast groups. 

S2 receivers need to be aware of their S2 Multicast memberships. S2 makes a virtue of necessity and uses plain Z-Wave Broadcast frames for S2 Multicast transmissions, thereby avoiding the 30-byte overhead associated with Z-Wave Multicast transmissions. The length of an S2 Multicast frame is therefore comparable to the S2 Singlecast follow-up frame. S2 Multicast receivers recognize S2 Multicast transmissions from the S2 Multicast group owner’s NodeID and a one-byte S2 Multicast group ID carried in the S2 Multicast frame header. 

S2 uses an auto-updating 13-byte multicast Nonce (MPAN) that all members of an S2 Multicast group must know. Acknowledged S2 Multicast is a two-stage process consisting of one unacknowledged S2 Multicast frame which reaches all group members within range followed by a S2 Singlecast follow-up transmission to each group member. Out-of-sync MPANs are automatically updated during the follow-up singlecast session between the transmitter and a multicast group member. 

Application status polling not needed

Z-Wave’s bandwidth is limited. Yet, a number of control applications have a need for precise status information. One example includes a door lock control panel, which needs to know if the door was really locked after sending a “Lock” command. It may take several seconds for that operation to complete. 

The classic approach would be to use polling but Z-Wave Plus puts restrictions on the use of polling as it affects the performance of the entire network and may further violate regional spectrum legislation. With S2, there is no need for polling. All S2 capable devices support the Supervision Command Class [Supervision CC] as it also serves to acknowledge the secure delivery of an S2 encrypted command. The Supervision Report allows a destination node to advertise its current and future operational state. A receiving door lock may immediately advertise its current Supervision state as “Working” with an expected duration of three seconds, and later, its updated Supervision state “Success”.

This makes it possible for a control application to update its UI in a more responsive way as it is notified as soon as the state changes rather than having to poll until a certain state is reached.

Expedited Delivery

The Supervision Report allows the transmitter to go on sending commands to other nodes immediately without waiting for an S2 out-of-sync Nonce error message.

Energy Efficiency

Low-power radios often use almost the same power when listening as when actively transmitting. Further, the total power consumption of a device depends significantly on the actual application. A battery powered door lock may spend the majority of its battery on driving motors rather than on listening for commands over the radio. 

On the other hand, a temperature sensor may be sensitive to the time spent sending or receiving. Consider a sensor based on the Silicon Labs Z-Wave 500 series chip that reports the temperature every five minutes and queries a mailbox for pending commands every 30 minutes. Without security, such a sensor draws an average current of 2.2µA. The S0 challenge-response overhead leads to an average current of 5.9µA. A similar S2 sensor uses only 30% more energy than the non-secure sensor (2.9µA). 

Individual frame delivery confirmation may not always be needed. One such example is an over the air (OTA) firmware update which employs its own retransmission state machine. S2 encryption can be used in one-frame-mode. This mode only has a small overhead compared to the non-secure variant. A node can receive an S2 protected OTA firmware update at virtually the same time and battery cost as a nonsecure node. A node running S0 would need 200% more bandwidth and energy for the same task.

Active protection against attacks via Nonces

S2 network keys are secret among trusted nodes and should not be revealed to others via predictable patterns in the payload. Therefore, any frame is scrambled by a long Nonce before encryption. The 13-byte singlecast Nonce (SPAN) is auto-updated before each new transmission. This prevents an attacker from recording a command and replaying it later. 

An advanced variant of the replay attack is the delay attack: An attacker may 1) at the same time, record a command at the transmitter and jam reception at receiver end, and 2) when the command is retransmitted, record the retransmitted command at the transmitter, jam reception at receiver end and then replay the first recorded command. Most cars are vulnerable to this attack. A sending S2 node uses the Supervision Command Class to request a delivery acknowledgement for the command. The attacker cannot construct a valid response for the second command; only return an old response or none at all. The sending S2 node can therefore warn the user of suspicious network activities. 

Thus, this attack is not only very difficult to accomplish; it can also be detected by the sending S2 node.

Secure gateway communication

The Z/IP Gateway controls access to the Z-Wave network by only forwarding commands from trusted LAN clients or from a trusted Internet host such as a service provider portal. An AES-based pre-shared key [TLS PSK] is used by all LAN hosts communicating to Z-Wave nodes via the Z/IP gateway. Two Z/IP Gateways may also interconnect two PANs securely using the open standard DTLS [DTLS]. UDP is used for low latency and to provide support for communication to battery devices in the PAN. UDP is unfortunately problematic in the Internet as it may be used for aggressive DoS attacks. Therefore, firewalls often block UDP. 

Therefore, The Z/IP Gateway creates a dedicated tunnel from the inside (the LAN side) of the firewall to a service provider portal. This is known as firewall penetration. The Z/IP Tunnel uses the open standard TLS [TLS]. TLS is a secure overlay to TCP. RSA-1024 standard certificates [RSA] are incorporated in both ends to ensure two-way authentication so that a portal only accepts trusted gateways and a Z/IP Gateway only accepts communication from trusted internet hosts.