How important is Z-Wave security for switches?

Hi all,

I finally found a dimmer that ticks all the boxes for me - Leviton DW6HD. Paddle, separate dimming control, proper 3-way switch, etc. However, it adds with “Security: NONE”, which I assume means no encryption whatsoever.
Being a software engineer, anything unencrypted makes me uneasy, so I wonder how important it is specifically for Z-Wave switches, and should I try Leviton Zigbee dimmers instead while the return window is still open.

I don’t care about it. Realistically what’s someone going to do?

If it bothers you, then replace it with something that supports S2 Security.

1 Like

to ‘own’ a Zwave network, someone would have to be in range of your switch, connect to it somehow, exploit it, install their own firmware and then use that as a beachhead to… Where? Exploit another switch? They won’t be able to send direct zwave commands to anything but the controller unless a prior association existed on the device AND they didn’t hose the association installing compromised firmware.

I wouldn’t say it’s a NON issue - as there are a few known theoretical ZWave exploits in the wild since 2018 but most of these seem to be aimed at forcing an S2 device to pair S0 or no security at all so you can later arbitrarily send it unencrypted commands. (In the exploits I know about they’re targeting your lock at join time to later open the door, and these are fixed with current firmware on the device.)

What I would say is knowing the attack surface - you’re the only one who can make a determination if it’s important enough to worry about.

Personally, I pair all my S2 capable stuff as S2 by default and it’s MANDATORY for me if the device participates in a home security function such as alarm motion, exterior portal actuators, sensors or locks, sirens, etc.

…But, if a device is not a security device such as an interior light or fan controller or maybe a water sensor or something… AND it’s NOT S2 capable OR has to perform direct association with a Non S2 device, I join no security and I don’t fret about it. I only have 6 devices left in my system (besides my 3 Schlage locks) that don’t support S2. If a bad guy REALLY wants in my home that bad, he or she wont be hacking my lock to get in. My house isn’t that interesting. It’ll be a crowbar to the plate glass window next to my front door - and for that I have glass break sensors and good cameras.

4 Likes

Some of your decision is based on proximity. For example, if you live in a high rise or dense urban community with hundreds of people within range of your zwave network, then there is opportunity for a kid on his laptop to spend time trying to break into your network. The same is true for your WiFi, Bluetooth, etc. On the other hand if your house is in the middle of nowhere, it’s very unlikely someone would be in proximity to spend the time breaking into your network. They would however, spend time breaking into your house, first they would cut your internet cable if possible and use an RF jammer.

It seems like this is detectable in the zwave controller stats?

1 Like

Is there any good public docoumentation about exactly what attack vectors do exist without encryption ? I would imagine that an attacker in a neighboring apartment could be able to observe unencrypted
packets and then perform replay attacks. So, unless i have it on good authority, that simple observer based replay attacks are NOT possible, i would not run Z-Wave nodes unencrypted unless i really don’t care when this happens.

Right now almost all my Z-Wave is lighting, and i don’t care, so its unencrypted. My room heaters don’t even support S2, so no option. My door lock of course uses S0 (can’t do better). I should really start to enable S2 for the plug-in switches that allow power cycling of some of my electronics.

If you’re miing and matching lighting products, you may want to stay without encryption because it is quite nice to set those up as direct groups without requiring the controller to run, and some of the products only do S2 authenticated, others only do S2 unauthenticated, so you can’t put them in one group with encryption (stupid S2 design in Z-Wave IMHO).

Here’s a start. Worse than I expected.

I’m not so worried about S2 security on the newer devices, but it is a bonus. I’m more concerned about speed and reliability of the mesh. I have about 10 of my 76 devices that are still standard Z-Wave (not Plus), so 300 series. Eventually I’ll replace them all with newer devices to improve my mesh, so if I’m going to that effort, I might as well make sure they are S2 enabled just for peace of mind. it certainly doesn’t hurt.

1 Like

What’s the recommendation between s2_unauthenticated and no security for lights?

My lights and non-alarm sensors have always been set up with no security, but when setting up some newer switches I noticed the s2_unauthenticated option and now I’m curious if that should be used. Most of the info I’ve found so far focuses on the s2_authenticated classification. Can anyone provide any insight on this? Thanks.

So you have 4 different security keys. Different devices use different keys. I think I read that the idea is that if one key gets compromised it prevents hackers from accessing the other devices.

When you include a device with security (2) things happen.

  1. You have to verify that the device you have is the device that is trying to join the network. You do this by entering in your DSK pin.
  2. The security keys get copied to the device

When you include a device with the s2_unauthenticated option you don’t have to enter the DSK. Thats what the unauthenticated means. Your device is still encrypted with S2 Security.