Mitigating Risks From A to Z-Wave

A wireless standard delivers interoperability but could create vulnerability

Zigbee and Z-Wave are wireless standards that enable home and building automation devices to communicate with each other without using Wi-Fi or Bluetooth. Z-Wave is lower power than Wi-Fi and has a longer range than Bluetooth. This article will examine the complexities and vulnerabilities introduced by the Internet of Things (IoT) in physical spaces.

In any product development life cycle, it is more cost effective to perform threat modeling and security testing early in the development cycle, but with IoT, that issue gets magnified.

Z-Wave is a wireless networking technology designed for home automation. It transmits data in small chunks and uses minimal power. There are more than 50 million Z-Wave devices worldwide, and more than 200 companies manufacture Z-Wave compatible hardware.

The Z-Wave Alliance and certification process ensures that devices from different manufacturers can interoperate and that they work correctly in a mixed-vendor environment. These devices include, for example, electronic door locks, HVAC systems, lamp dimmers, swimming pool pumps, and garage door openers.

Z-Wave uses radio frequency communication in a mesh network to monitor, control and read the status of devices. Each of the devices can relay data packets through the network, obviating the need for a router. Home automation systems can be controlled either via a remote control or through an online connection. For Internet connectivity, a gateway needs to be installed that can be configured to control the home automation network via Wi-Fi or, for some products, an Ethernet wired connection.

Z-Wave protocol has the following layers:

• Physical Layer – The physical layer specifications for radio communications
• Data Layer – Where MAC address is stored and encryption occurs, if enabled
• Transport Layer – Responsible for packet transmission and retransmission; devices with limited power supply, such as door locks, are often designed to reduce power consumption by entering a sleep mode and periodically checking for incoming data; this layer wakes up the device when necessary
• Network Layer – Z-Wave uses mesh networking that enables any node to communicate directly with another node or through relays; there can be 232 devices and one controller device on a network; this layer contains a unique 32-bit ID for the home controller and an 8-bit node ID for each accessory, which is assigned when a new device is paired with the system
• Application Layer – This layer parses network packets to decode the Z-Wave command payloads which define functionality for the devices, such as door locks and thermostats; each command class can contain multiple commands that can be actions or data collection (i.e., lock the door or get information if it is in a locked state)

For transmission to occur between a device and the central controller of the home, both must share a network key that allows for communication. When a new device is paired via Z-Wave, a specific syncing protocol is executed in order to share this network key with the device. First, a “preamble” packet is sent between the receiver and transmitter, containing a specific series of bits, the home ID and node ID of the device to pair.

Critical Security Issue in Wireless Door Locks

Behrang Fouladi and Sahand Ghanoun, in their presentation at Black Hat 2013 titled Honey, I’m Home! – Hacking Z-Wave Home Automation Systems, explained the security implications of a particular lock that used Z-Wave.

They found that the first time the lock was paired with a controller, the devices exchanged encryption keys using custom key establishment protocols AES-OFB and AES-CBCMAC, and a 64- bit nonce value, a random value that can only be used once, as well as a 128-bit random number key to encrypt transmission of the network key. The keys were generated using a hardware-based pseudorandom number generator on the Z-Wave chip and encrypted using a hard-coded temporary default key of all zeroes in the chips’s firmware.

“The word ‘custom’ in cryptography rings off alarms,” Fouladi said in the Black Hat presentation. They went further, even without documentation, to crack the key establishment protocol and carry out attacks. The protocol begins with the controller sending an initialization packet to the device, which responds with a ready packet. The controller replies with a nonce value and the lock returns it to confirm that communication has successfully been initialized. Next, the controller generates a random network key and temporary encryption key, and sends it with the actual network key to the device. The device then constructs a secure packet using this information to prove that it has properly decrypted the securely transferred network key.

Now, both the controller and the device have the same network key and can use it for further communication when the homeowner wants to lock or unlock the front door.

The team also described a severe vulnerability: “Key Reset Attack,” which takes advantage of the fact that the pairing protocol can be run multiple times for a single device. Using the home ID of the controller, which is easily retrieved from any intercepted packet, the team could pretend to be the controller and run the key establishment protocol with the door lock again.

The security issue here is that once the lock has paired with a controller, it should check its current key and load the existing key from its electrically erasable, programmable, read-only memory. The lack of this basic validation step is what allows the door lock to be compromised and not perform its basic function. Another important result is that, once the lock has been compromised, events such as “door open” will be rejected by the controller, since it will now only accept packets from the new pairing and will therefore reject the valid payload, worsening the situation since no warnings will be issued that the door is open or unlocked.

This illustrates how a simple design flaw can have major repercussions on multiple levels – for the owner of the device, the device manufacturer, implementers of firmware and radio protocols.

Even though the owners of Z-Wave responded quickly to Fouladi and Ghanoun to validate their findings and remediate the vulnerability, the issue of applying firmware updates still stands. Managers of physical facilities and homes do not normally have a process that involves checking for firmware updates and applying them to their door locks and controllers. What’s more, the 6-year-old flaw lies in software that has been shipped to more than 100 million home automation and security installations. Doorbells, bulbs and house alarms are among the countless products from 2,400 different vendors that contain the flawed code. Tens of millions of smart home devices are, as a result, vulnerable to hacks that could lead to breakins or a digital haunting.

In 2018, a white hat hacking group found a vulnerability in an underlying standard used by a Z-Wave lock in the communications between the lock and the paired device that controls the system. The flaw meant that communications could be intercepted and manipulated to make it easy for someone in the local area to steal keys and unlock the door. So the problem continues and is not going to be eliminated any time soon.

Moving Forward

IoT device manufacturers and platform service providers have a responsibility to make sure their devices can be patched remotely so they are resilient to attacks. In June 2017, we saw the first state attorney general action, in New York, against a wireless security company for failing to implement adequate security in IoT devices.

Manufacturers must ensure that their engineers and architects fully understand the threat model of their products and that the proposed architecture is fully assessed and inspected by an independent, qualified third party. A clearly defined process should exist for communicating and reporting security vulnerabilities that are discovered outside the company, such as by security researchers. There are a range of upcoming applicable regulations globally that include sanctions for non-compliance, which could have serious financial and reputational implications for corporations and staff.

Pamela Gupta (pamela.gupta@outsecure.com) is president of OutSecure.

This article originally appeared in the spring 2019 edition of SIA Technology Insights.