Security and backwards compatibility, and how we designed Z-Wave to maintain both
October 04, 2018
Blog
Z-Wave Security 2 ensures all new Z-Wave products come with the best security level. Together with security, backwards compatibility is a core value and a celebrated engineering principle.
At Silicon Labs, we take security of IoT devices very seriously. Z-Wave Security 2 ensures that all new Z-Wave products come with a best-in-class security level. Together with security, backwards compatibility is a core value and a celebrated engineering principle of the Z-Wave ecosystem. To maintain backwards compatibility and interoperability with older versions of Z-Wave devices, there is a system security tradeoff that must be accounted for. In this article, we will share insights on how we maintain the balance, talk about when and how we evolved the security framework, and describe how we assess potential security incidents.
Z-Wave has been in the market for more than 15 years, with over 100 million products deployed. This impressive market adoption is due to Z-Wave’s interoperability and backwards compatibility, meaning that a home owner can continue to use previously installed smart home devices, together with newly installed devices. This is ensured through the rigorous certification process that all Z-Wave devices are required to pass.
Z-Wave has a first-generation security framework called Security 0 or S0, dating back to 2008. It uses AES-128 for authenticated symmetric encryption (AES CBC-MAC and AES-OFB) for access control devices and was secure enough to enable the first wireless door locks in the smart home market. In 2013, a vulnerability was found in S0 during the inclusion process of installing an S0 device [1]. This led to the second-generation Security 2 framework or S2 released in 2016 [2], offering several significant improvements over S0.
Z-Wave Security S2 is embedded inside the protocol, so product developers automatically get the benefit of S2 and do not need to be security experts. It is done for them. Many exploits are the result of improper implementations of otherwise sound security solutions. Even small, innocent-seeming modifications to the source code of a security system can break the system in very hard-to-detect ways. By embedding S2 in the Z-Wave protocol, this failure mode is completely eliminated.
The Z-Wave Alliance mandated S2 for all new Z-Wave products in April 2017. Since then, hundreds of Z-Wave products with S2 have entered the market. Because there is a large base of installed devices without S2, it is key to the Z-Wave ecosystem that the S2 devices are compatible with Z-Wave devices without S2. This backwards compatibility enables an S2 device to interoperate with an S0 device, meaning that the security level of an S2 device can be downgraded to S0. This intended downgrade functionality can however be forced by a nefarious perpetrator if they are within physical range of the device during inclusion (when the device is installed), and then the known theoretical inclusion vulnerability from 2013 of S0 can be exploited. This is called an S2 downgrade attack, which we have mitigated as explained in the following section.
Maintaining security and backwards compatibility
Because backwards compatibility is such a crucial part of the Z-Wave ecosystem, removing S0 support altogether is not a feasible solution. We believe in protecting consumers’ investment in their smart homes and in protecting manufacturers’ investment in their product lifecycle. Instead, we’ve opted for two other mitigation techniques:
- User notification. Inclusions are locally initiated by the home owner, and Z-Wave controllers always inform that user of the inclusion result, so an advanced user will realize that something is wrong when an S2 node suddenly includes as S0. This notification, for both S0 and S2 nodes, has always been verified during Z-Wave certification of a device.
- Opt-in backwards compatibility. We already allow our partners to make their UIs in such a way that the default way to include a node is to allow S2 only. This prevents a downgrade attack. A user will specifically have to allow backwards compatible inclusions if so desired. This opt-in feature will become mandatory in all controllers in the future.
Vulnerability assessment of a downgrade attack
The risk of an exploit can be modeled as the product of a probability and a consequence. We want to minimize that product every time. A Z-Wave S2 to S0 downgrade attack has a high consequence but also a very low probability of being carried out, and very low probability of not being acknowledged by the home user. The low probability is closely related to the difficulty of the attack, which arises from these factors:
- S0 proven track record. Z-Wave’s original Security 0 has a proven 10-year track record of successfully securing door locks and other trusted access control devices in the field. To our knowledge, no exploits have taken place in the real world despite the well-known limitations.
- A forced downgrade requires special interception equipment. An attacker needs to custom build the equipment.
- Need to be in physical proximity. A downgrade cannot be performed over the internet. It requires physical proximity within maximum 100 meters.
- Need to be present during installation. A battery or main-powered interception device can be left outside the home waiting for an inclusion to happen. But even with that kind of equipment, an attacker would have to wait for an inclusion event that only happens a few times in the life of a Z-Wave device, when it is installed or moved.
Compared to a downgrade attack that requires waiting for years and then detected by the home owner through the smart home UI, the cheaper and easier option is lock bumping, a brick through the window or a crowbar to the door.
S2 Improvements
“If Security 0 is good enough, why even go to the trouble of developing Security S2?” you might ask. Even with the low probability of being exploited, we knew we could make it better. We turned to the cyber security community to work with experts that could help us develop S2 for the highest levels of security in any situation [2]. With S2 we bring a number of benefits to the market [3]:
Out of band inclusion and Elliptic Curve Diffie Hellman. When a new device is added to the Z-Wave network, a QR code or PIN is used together with the industry wide recognized Elliptic Curve Diffie Hellmann key exchange method. This prevents deciphering of networks keys and inclusion of rogue nodes.
Jamming detection. If a jamming signal is blocking the communication between Z-Wave devices it will be detected by this functionality.
Multiple network keys. S2 supports up to three network keys. This improves security because keys are compartmentalized. E.g. physically exposed nodes in the garden can use a less trusted key. This way a physical key extraction will not compromise the door lock key.
Battery efficiency. S2 sends fewer frames than S0 to transfer encrypted messages, this translates into better battery efficiency and lower network latency.
Z-Wave never compromises on backwards compatibility. We want existing devices to interoperate smoothly with new controllers. If you come across a 10-year-old Z?Wave device, you will find that it includes and operates seamlessly with even the newest controllers on the market. We believe that the chosen security solution follows that tradition and strikes the best possible balance between security and interoperability. We have a clear path forward for evolving security across the entire ecosystem to become even more robust without sacrificing convenience and interoperability.
Z-Wave Welcomes Responsible Disclosure
At Silicon Labs, we are acutely aware that improving security involves listening and learning from security disclosures. Therefore, we welcome responsible disclosure reports from security researchers and have a formal contact point for such incident reports [4]
We look forward to working with the security community and make Z-Wave better and even more secure than it has already proven to be.
References
[3] https://www.silabs.com/documents/login/white-papers/INS13474-Z-Wave-Security-Whitepaper.pdf
