If I pair the Aeotec Smart Switch 6 with a single button press it pairs successfully with a green light (insecure mode). All functions like on/off/power utilized/etc work fine.
If I remove the device and then repair with two button presses it pairs successfully with a blue light (secure mode). None of the functions nor status appear to work.
Removing and repairing with insecure mode works fine. This suggests that the driver isn't storing the secure connection details during pairing, and is trying to use insecure mode after it was paired as a secure device...
Do you have the hub set to allow pairing of all devices securely? The default is only locks and perimeter security devices. This can be changed in the zwave settings.
Note, though, that pairing it securely just makes a lot more traffic (3x per command/event) for almost zero additional security. So I'm not really sure why you would want to pair it securely to begin with...
If "zwaveSecurePairingComplete: true" is in the data section then it works with security.
If that's not there then the driver doesn't know it's joined securely and won't encapsulate the commands.
Like @JasonJoel said, if you want to pair a device secure, you have to change that setting, but there's really no benefit to doing that.
If that setting was already set to all devices when you joined it then inclusion might have just messed up and joining the device again using double click might fix it.
Wow, that screen isn't easy to find. Perhaps Zwave settings should be an option under uh... Settings? Not under the different menu of triple dots?
But yes, I had apparently already found that setting and enabled it. It shows "All Secure Z-Wave" but still doesn't work. I've tried disconnecting and reconnecting several more times, and secure pairing never shows up in the data. However it seems to fall back to insecure pairing.
I live far too close to neighbors I can't trust. I want secure pairing, and I'd force it on all devices if I could.
Thanks for this. I've had an issue with one of mine, and I must have included it in secure mode. My 5 others were fine, and must have been included insecurely. I've been dealing with aeotec, but rejoining it insecurely worked, at least for the auto reports. Thanks!
Do you have the device really close to the hub during inclusion? I think if it's going through a non secure repeater during inclusion it will fall back to insecure pairing, but I don't know that for sure...
They are about 5 feet apart with no repeaters within 25 feet of the plug. Not to say that the repeater can't be involved... seen that happen before. I'll try moving it really really close, but that's not always an option.
With all due respect - feel free to do your own research and cite your own sources ... I've read the zwave spec, including the S2 sections - that would be a good place for you to start.
S2 is great if you are doing Z/IP... Which we aren't... It is also great if you think someone is going to sniff you out DURING pairing (which lasts what - 5 seconds one time?). I don't see that as a big problem in the home environment, you may have a different opinion.
While S2 has some advantages, I just don't think they are real, proven problems we have in the home environment. More FUD / scare tactics of the boogey man.
And there is a serious bandwidth messaging overhead hit that is definitely non-trivial once you have a lot of S2 devices on your network. Feel free to pair something w/S2 and watch the packet difference on a zwave sniffer...
Now Zwave 700 fixes a lot of the problems with S2 in terms of bandwidth, etc. Once you get to Zwave 700 there isn't really any downside to the 'extra security', so in that environment - why not (even if it isn't needed)?
S0 Security exposes the encryption key during inclusion so if someone happened to be monitoring traffic at that moment they'd be able to decrypt all future traffic from that device.
S2 doesn't expose the key during encryption, but I believe they both generate the same amount of extra traffic so I personally don't think it's worth using either except for locks and door openers.
Yes, S2 is now required by z-wave alliance for certification.
I believe Hubitat only supports S0 Security, but the packet difference you're referring to would still be the same as S2 if you watch it with a sniffer.
Wow, I'm a bit shocked by that response. If someone asked me for details about a statement for a subject I am willing to express my opinions as an expert on, I wouldn't tell them to go read for themselves with no other context. Comes across as an STFU, especially with similar other unreferenced claims here.
Unsubstantiated statement with a false dichotomy. This claim has neither any basis nor any substantiation.
For those who don't know, Z/IP is a way to gateway between IP and Z-Wave communications: essentially, allowing off-network or cross-network communications with Z-Wave devices. You can find a lot more detail in the Z/IP forum: https://forum.z-wavepublic.com/c/z-ip
Yes, high security should be used with this (as with everything) but there's no reason S2 is only for this. I don't feel that this either/or statement is relevant. These aren't comparable, they are both independently valid use cases.
The power switch in question controls important infrastructure that could be used to impact the operation.
It is also a relay device that could be/is-already used by the locks.
It's been shown repeatedly that someone within radio range can gain control of every non-S2-secure Z-Wave device on the network through forged packet insertion.
First, you are tossing this kind of response in a reply to my own statement that I had determined that security was important to me and necessary in my own environment.
Second, the security community (see papers quoted above) and the Z-Wave Alliance completely disagree with you, which is why S2 is required now for certification of both Plus (500) and upcoming 700 devices.
If you want to express your opinion why it's FUD, I think you should back up your statements with some supporting... anything, to show why your expertise is more significant and relevant than all the papers demonstrating cracks, the toolkits you can download and use yourself, and the Z-Wave Alliance's own judgment of the risks here.
There's a cost to TLS encryption of my login to both my bank and this community forum. I believe that the cost is negligible compared to the risk. (and I've had to deal with the consequences professionally of people who made the other choice and their organizations paid dearly for that). I consider my home security needs on the same level as I consider my bank transactions.
I can't find anything in the Z-Wave 700 changes which relates to this. Everything I've read just involves the chipset upgrade. The only protocol changes I can find involve more defaults/expectations--including mandatory S2. The S2 implementation is not just backwards compatible, it doesn't appear to be changed at all. Can you show references to back up your claim of improvements?
Further, there are no products shipping with 700 chips that I can find, so this is hardly on topic for this thread.
Interesting, so do I, albeit in the industrial space... I spend 90% of my time at the packet and protocol side of things. That means little in the context of this discussion, though.
What I find with most security experts is that they are so amped up on the possibilities of insecurity that all reasonableness of likelihood or impact go out the window. Which drives things to an alarmist or very conservative outcome that isn't always practical.
Again, I come from the industrial space, but in my OPINION anyone that would consider using ZWave for "important infrastructure" is out of their mind. ZWave is, at best, commodity grade and as such not suitable for "important infrastructure".
But whatever.
Back to facts, instead of opinion. Hubitat doesn't support S2, and falls back to S0 when pairing securely. So if full S2 compatibility is truly a requirement in your application, you can't use Hubitat anyway.
And I spend a lot of time consulting companies who say "how likely is it that we'd be targeted?" until they face the consequences of that choice. It disregards the wide availability of toolkits that do everything for the user, and the risks of disgruntled neighbors/employees/etc.
When it comes to simply using encryption/validation or not it's hard to validate your statement that you work in security when you downplay it so hard.
I've heard the same about IP, "the cloud", and every other networked technology over the decades of my career. Given the value of the benefits (remote lock control, etc blah blah why we're all here) the security benefits outweigh the compromises. I don't do it blindly, and I test my assumptions.
You're a very black/white thinker for someone who claims to be a security expert.
My Schlage locks likewise only support S0. But I have tested and they can't be forced into pairing mode remotely, nor by forged insertion. But I don't see S2 in my bug report here--you brought that up, and I responded to you but that's not the point. S0 is better than nothing, and is all my Schlage locks can use anyway.
And I'm not certain that the Aeotec 6 can do S2 either So... can we get back on topic?
I want to use the secure connect ability of the Aeotec 6
I want the benefit of securing relay communications from the hub via the Aeotec
The Aeotec does not work with Hubitat in secure mode, as confirmed by others
... I've read the zwave spec, including the S2 sections - that would be a good place for you to start.
So... can we get back on topic?
