Sorry if this has been asked before, but I could not find the answer. Are there plans for a version of Hubitat that will fully support Z-Wave S2 security?
4 Likes
I am also curious and pretty sure I asked this question also and didn’t get a reply.
Zooz makes an S2 Z-Wave stick so I wonder if it would work in the older HE that uses the Z-Wave sticks?
S2 depends on software implementation so Hubitat will need to incorporate it into the platform. S2 has been required by the Z-Wave Alliance for a while now so if they ever want to certify the product, it will need to be implemented.
I am surprised that this has gone unanswered. S2 capability would be a great option to have. So if the new hardware in the USA with the integrated radios were to already have a S2 capable Z-Wave chip, and the software component will be added in the future, I would definitely buy now.
And why you need S2 so badly? Because most of the actual devices in the market are non S2 and the S2 must fall back to the older specs. Any particular reason?
1 Like
That's always my 1st question... I've read the S2 tech docs (more than once) with cybersecurity work I'm doing outside of Hubitat and I don't find it that interesting.
But I acquiesce that security, and how much is "good enough", is subjective.
I'm just not stressing out about MitM attacks on my zwave network so the new key handling is a "so what", I have no need to tunnel zwave over IP (another big S2 feature), and the changes to the secure pairing process isn't really interesting to me either in a home environment.
The only thing kind of nice in S2 is reducing needed commands from 3 to 1, thus reducing overhead/traffic/latency when communicating with those devices.
3 Likes
I did not intend to state that I "needed S2 badly". It is more of a "it would be nice to have for the future" feature. True there are few S2 devices now, but that will change, and since I am fairly new to Z-Wave, most of my devices are compatible.
I agree with most that the chances of someone hacking my Z-Wave network to gain access to my home is very slim, they could just break a window. But it sure would be nice to be able to turn this on if I wanted to.
Changing hubs will take a lot of work, so I'm evaluating if it will be worth it. Gaining S2 capability would be a positive, that I will probably never get with my current hub. And having a hub that could possibly act as a security system would be a benefit as well.
I get that. I just think it is a lot of development work and testing for not that much benefit. It isn't like there isn't encryption in S0... And all S2 devices have to fail back for compatibility reasons.
Or I suppose one could always go zigbee that is always encrypted.
1 Like
The silence on this topic is deafening. But you can see places with the employees have dismissed secure pairing, so they are clearly uninterested. Hubitat will be left to the 2017-and-before Z-Wave devices only.
Can you provide references for this "S1" security and how Hubitat uses it? 
Even better, please do explain how a Z-Wave user has to do development work... for features built into the chips they use. I'm looking at the libraries, and there were zero changes for S2 support. It was entirely a firmware update.
Where are you coming up with these ideas?
I don't think that downplaying an active risk scenario is good for users who might have different needs or environment. Your risk is not their risk and vice versa.
So let's be clear for people reading this: Z-Wave uses a single network key for the entire network, and during pairing it communicates it with a shared key of all zeros. So if anyone is in RF range they can just passively wait until you pair a new device, reboot a device, replace a battery, or any other thing which causes the network key to be shared again, and then they'll have control of EVERYTHING. Your previously paired locks on your door for instance.
Each person should make their own choices about whether or not they trust everyone who can get within 30-40 meters of their devices. That's 100ft in every direction, unless you have cement or metal-lined walls (aka nobody with a house built in the last 50 years)
Edit: the post I'm replying back to isn't there any more, but the accusation was that I'm intentionally misleading people.
No, we're not misleading anyone. We just have a different opinion on how big of a deal (or not, in this case) that pairing key issue is.
And I'll ask you to keep your slanderous accusations to yourself in the future. You know neither my background nor my motives.
S2 devices are required by the spec to fall back for compatibility, so Hubitat isn't leaving any devices behind at this time. 
We are moving forward with S2 implementation. It is non-trivial, and more than just a firmware change done at the chip level. We don't have a date yet for its availability.
9 Likes
Shouldn't be much longer I wouldn't think for the new 700 series chips to start rolling out, I would think that would be a good starting point......but I'm a noob.
Does "more than just a firmware change" imply that the hardware I currently have (Hubitat Elevation US) isn't going to be S2 capable? Because I specifically bought it with that intention after confirming that S2 was "mandatory" in current hardware when I made the purchase.
The fallback, of course, enables downgrade attacks like Z-Shave.
The Z-Shave authors talk about leaving a drop box in order to implement the attack without having to hang around waiting, but I got curious about the possibility of subverting an existing node to implement the attack instead, using the firmware update mechanism.
While the standard recommends that the user be expected to trigger a firmware upgrade by physically interacting with the device they want to upgrade, none of the instructions I could find actually require it, and they all seem to be able to initiate updates by radio without any physical interaction. I tried skimming over the specs but that seemed to imply that firmware updates and encryption were mutually exclusive (a packet sizing disparity) so I clearly wasn't understanding that.
Even so, it seems like if you can get control of the firmware of an unsecured device, or even an S0 device if you have the time, then you might be able to use that to launch downgrade attacks, and if you can do that then you own the whole network.
I mean... I don't know, but I've struggled to figure out how all this is prevented. Certainly a careful, downgrade-resistant S2 implementation seems like an important first step.
And it's not exactly fair to say that breaking a window is easier. Depending on what your motives are there can be a lot of value in entering a property without evidence of forced entry. Keeping an alarm silenced is the most obvious; making the authorities take it less seriously is a factor (does the homeowner even have evidence without anything being broken?); keeping the homeowner ignorant of what's been done; and in the worst possible case keeping the homeowner ignorant of the fact that someone is still in there waiting for them.
Everyone has to make their own risk assessments, but people are pretty bad at that even for themselves, let alone when it comes to considering how their designs affect more vulnerable people.
I could see this a possible concern for those who live in houses very close to each other or say apartments, but I have zero concern for anyone getting within around 100ft (the distance away from my farthest away repeater to be within range of connecting to my devices network) without me being alerted (from my personal security measures) that someone is there first.
The convention is to do it by drone. They tend to be a bit noisy, but they can usually stay out of view of cameras and motion sensors.
I have that area covered as well, but I spent a good bit of time beefing up my personal security measures. Not only that but yes for a drone to be within the RF range of my devices, it would be EXTREMELY noisy
