HomeDaemon-MCP and Locks

Z-Wave has supported secure communication for quite some time, yet a known and documented risk in the "setup" process has recently come into focus as a potential means for an intruder to gain persistent access to your home control system, and potentially unlock your door!

The vulnerability was dubbed "Z-Shave" and arises due to the lack of adherence to best practices known since the first days of the Z-Wave protocol by multiple controller vendors.

When Z-Wave devices are added to a network they must be "included" through a one-time process. This involves placing the controller in a special mode, which must be done by the owner or administrator -- it cannot be done by an attacker without privileged access. The unit to be included then has a button pressed that causes it to exchange information with the controller and establish the link both between them and also to "mesh" itself with the any other devices in the Z-Wave network.

For encryption to work both ends of a communication must agree via some means on a "key". When you go to a secure web page the little lock shows up on your browser; this indicates that the server and your browser have both made agreement on a key that is used for that session. There are modern ways of reaching this agreement.

When the original Z-Wave security protocol, called "S0", was designed most controllers had no keypads and no good way to put a "starting key" (much like an initial "password") into them. Thus the decision was made to send that key, once, from the controller to the unit via trivially-discoverable means. It is technically encrypted but the key used to do so along with the rest of the initialization values used are known -- and thus can be intercepted and decoded. This was, at the time, not considered a material risk because "best practice" was to physically take the controller to the new device, which then exchanged that data using extremely low power. The range of that transmission was mere inches, and it only happened once. This was considered (and reasonably-so) an acceptable risk, just as we all accept the risk of being physically mugged to obtain our car or house key.

Contrary to some press reports this was not "hidden" or otherwise concealed -- in fact it was documented. It was considered an acceptable practice because when including a new unit is done at low power the potential range of interception is measured in inches; in other words to "steal the key" you must basically "kiss" the person doing the installation. It was assumed, reasonably-so, that the installer is personally trustworthy (since he or she presumably has the key in the first place since they set the system up originally!)

Unfortunately as "convenience" won out over security vendors implemented what is called "network-wide" inclusion. This option allows you to place the controller in the special "including" mode and then perform the including step from 100 or more feet away from the device. If that device includes security, even a new mode called "S2" that is immune from attack as it requires a "pairing key" be entered into it which would not be known, an attacker could jam (since this is a radio device) that transmission and the unit would then try to use the older S0 protocol.

Most existing controllers will then send that key at high power, exposing it to potential compromise by anyone within range -- which can be 100 or more feet of range. In an apartment or condo this could easily allow your neighbor to pick off your security key.

With that key they could then access any secure device at any time in the future including your door lock or garage door opener by commanding them to open and the command would be accepted as they would have the proper encryption key to talk to that device.

HomeDaemon-MCP by default completely eliminates this risk because it is coded to explicitly refuse, unless you specifically override it, to send S0 keying at all. Therefore even if someone was to jam a signal and attempt to intercept your security key the attempt will fail as the key is never sent by the controller; the request is logged but the key transmission itself is denied. In circumstances where you are certain you are safe from such interception you can override this with a specific instruction in the system configuration file but doing so is neither recommended or necessary.

To pair an "S0" secure device without this risk you simply remove the USB "stick" from the controller and physically take it to the device, doing the pairing while holding the stick a few inches away. This include is done at very low power, rendering the potential range of interception even with advanced equipment to under 10', and without advanced equipment the range of potential interception is inches.

HomeDaemon-MCP, unlike the other products on the market, not only has a detachable USB stick with a battery in it to make this sort of pairing easy (never mind compliant with long-standing best practice for Z-Wave networks!) it fully supports "hot-plugging" of the interface stick so you do not need to interrupt or restart the software to do so. Simply remove the stick, press the button when you are at the device so the stick's light flashes slowly, press the action button on the new unit and wait until the rapidly-flashing light on the stick returns to the slow flash, then press the button on the stick again to extinguish the light and reinsert the stick into the controller.

HomeDaemon-MCP will automatically detect the removal and re-insertion, finding the new device seamlessly and without the risk of a security breach.

S2 mode will be supported in a future release of the code, allowing network-wide include of S2-capable devices -- when they are commonly available. At present (June 2018) there are too few of these devices on the market to be confident with interoperability testing. When "S2" capability is available it will work network-wide without the risk of the "downgrade" attack working since the S0 key transmission will remain blocked, providing a nearly-complete mitigation of the so-called "Z-Shave" risk.