I have mostly re-joined all my devices with no security (using factory reset and zwave replace). Getting down to some battery sensors and I know with no security it should even improve battery life, as less data needs to be sent and decoded. The two sensors I have grief over are a water leak sensor, which if some triggered would turn off the water. Not the end of the world I suppose. I have kept the actual water valve as S2 Auth paired. The other one is a open/close sensor. Right now it is not somewhere that needs security but I might move it to an exterior door.
I know the chances of someone actually trying to "hack" my zwave mesh and falsely trigger a water leak to shut my water off, or to trigger a door sensor to cause an alert to go off, is probably very close to 0%.
Whats everyone else been doing with these types of devices?
Funny thing is the ecolink tilt sensor on my garage door doesn't even have security, but again worst case it would tell me the door is open when it is not. Hmmm... technically someone could probably trigger that, I would think the door is open so I would try to close it remotely, which would actually open the door. I would quickly realize it was an error when it says it failed to close and close it again for real. Would be just enough time for someone to get in.
While the risk of someone hacking ZWave is real, it's functionality is exceptionally low. Who will be able to tell your home is vulnerable simply because ZWave frequencies emanate? Would they know that opening the garage door does or does not disable the alarm? Does or does not unlock the door into the house? Not knowing means a bat through the glass window is a more predictable (functional) pathway.
For devices that have ultra low traffic.. water sensors should be a good example, then the Security options are not much impact. Even imagine 3x the packets, but that's only 10 extra per YEAR.
When Jo Rhett was active on the Hubitat Community he would routinely posit that malicious actors were hacking z-wave networks to gain entry into homes for the purpose of theft. But could never produce evidence documenting the same.
Another good question is, how would they even know what all the random packets are. First they would have to sniff and analyze the packets to determine what a device might be. At that point they don't know where it is exactly or what it is named because that's not sent over zwave. So they could just start spoofing commands to random devices and hope something happens. Like you said, I am pretty sure by this point they would just kick in the back door and be done with it.
True, forgot to mention these little battery sensors seems to struggle a little. They are the worst RTT values. Was thinking without the S2 they would be better. Seems like everything else is a little more snappy without the S2.
Security is a 'wrapper' around the data... with words like 'nonce' and tech babble that unfortunately I understand. The point is, radio reception is independent of what is in the air. Your ZWave signals and your neighbor's are all duking it out to be above the noise level. Those that are above the noise get received. Those that get received get interpreted.. and THAT is where S-anything occurs.
Hacking concerns aside, when not using S0 or S2 (based on my reading of the docs) you only get CS-8 (simple 8-bit checksum) error detection on 9kbps and 40kbps data rate links (100kbps hops always use CRC16). An exception is metering devices which default to CRC16 encapsulation when included without security.
Though probability of an undetectable double bit error in a given transmission actually doing something harmful is low (since a corrupted non-payload part of the frame will probably just render it undeliverable), when you throw burst errors into the mix it's evidently probable enough that CS-8 isn't considered sufficient to protect metered data.
Maybe still not worth worrying about, but if you're doing something really important with your Z-Wave mesh network (like sequencing a rocket launch) and everything's not running at 100kbps, secure pairing might be worth the overhead to enhance data integrity.
I have a Schlage Z-wave lock on my front door. I use S2 access control security for the lock as a lot of data gets transmitted during the opening and closing of the lock and to verify whether the lock was opened manually or with specific lock codes.
I have everything else paired without security as data transmissions are so short and infrequent that it would be difficult to hack them
Sophisticated hacking, most likely by thieves trying to break in, would go after "most common" vectors like Wifi or garage door opener frequencies, not zwave. Far far more likely someone would wait for the house to be empty and break in thru a door or window. Unless you're protecting government secrets or a celebrity, but then using wireless sensors is a pretty dumb idea in the first place.
I personally use S2 for devices that support it because I'm lazy and like SmartStart. The extra error checking is a nice feature. I don't notice anything being slow vs non S2.
The biggest S2 con for me is the large increase in time that firmware upgrades of devices take. Its 10x sometimes.
Yes, trying to do a firmware update with security turned on takes forever. I had several Aeotec range extenders paired with security. I tried to do updates and never could get them to complete. I reset the devices to factory defaults, repaired them without security and then did the updates. That worked well. Since security is not really needed with range extenders/repeaters, I just left it off. I did end up with some ghosts in the process, but used a Z-wave stick to get rid of them. The support staff says you can get rid of ghosts using the hub, but since I updated several devices and had multiple ghosts, the USB stick was easier.
My thoughts are if you have physical control of the switch then security is not required. Keep in mind that Lutron uses unsecured telnet to communicate with its lighting, and as we know, Lutron is the number one in the business.
This is interesting because a new tool I am working on that sends and receives a bunch of data from the devices, I started to notice some invalid junk coming back, where the data is obviously scrambled. For example I will get data back saying it is for parameter 3956 when the device only has like 1-20 for parameters. Kind of makes me want to keep the sensors on S2 if it has better error checking so I don't get any bad data.
Encryption causes overhead regardless..Rule of thumb I have lived by is leave barrier entry devices encrypted and everything else unencrypted. That said...
If someone is close enough to sniff z-wave packets, that means they are parked outside your house or even on the porch. Encryption is useless at that point because they can simply look at what lights etc are being turned on/off. I mean what is the end use in the situation? Turn off your water and turn on random lights just to annoy you? Ok so you're not home. End use is still the same, except now you're getting messages on your phone the water turned off. Break in? Doubt it. Trying to hack the lock is stupid at that point when you have windows. It is far easier and most times safer to break a window with a towel over it to muffle the sound of breaking glass so the neighbors don't hear. (again this is assuming that lights aren't coming on outside do to motion sensing). If you're worried about home security, get a dedicated system that is purpose built. I honestly can't see a bad guy taking the time to go up to someone's house and sniff packets just to fark with their lights or any other part of their home automation. It's also not really a vector into someone's home network either. I wouldn't dwell too much on security for HA... Bad actors have easier/better ways of getting what they want then turning on the bathroom light when you're sleeping... (now friend's pranking you? That might be a different story)
I repaired all my Z-Wave devices that supported S2 and turned it off. All except for the door locks, the rest they want to hack, knock yourself out! Below is a post I made with more details and results.