When I add a dimmer, this is how Hubitat wants me to include it:
But because I dont want to take off plates to find the DSK, I uncheck everything. What am I losing/gaining by doing this?
1 Like
The DSK is also on the small square card that shipped with the switch.
Based on your Christmas came early post, they’re on your bed:
7 Likes
3 Likes
I have a stack of DSKs in a box. Make sure you label them so you don’t have to try every one to find the right one.
What am I losing by unchecking S2 and S0? By unchecking those I don’t have to enter in any numbers.
Security for that device. Avoid using S0 if you can. Its inefficient and triples the data on the network that that device sends. If you are going to add security use S2.
Some devices however don’t give you an option. I think locks and garage door openers are examples of devices that force you to use the security that they implement.
For my other devices I just leave them all off. I’ve seen many debates in the forums about what people should be doing. Its all up to you.
Whoa, is this fact? I heard S2 added slightly MORE data to be transferred but it wasn’t that much different…
I’m moving everything from ST to HA and will be executing in the next few days. This is super important to me.
I was talking about S0. S2 is recommended if you will be using the security.
Ah, thanks! So IF using security at all, go straight to S2. Got it.
1 Like
What does the security add though? Is Z wave easily hackable without security?
1 Like
“Easily hackable” doesn’t go far enough IMHO. If you turn security off, I’d be hard-pressed to argue that letting anyone do whatever they want with your network isn’t intended behavior. That’s not specific to Z-Wave either— anything that lacks security is basically screaming “hey, come play with me!”
Here’s a rough summary of what the different security levels provide:
- None (All Unchecked): Completely open. Anyone in range can read every message sent between these devices on your network, send messages to these devices on your network, and send messages to other devices on your network pretending to be these devices. I would recommend against allowing these devices to trigger any sort of automation and avoid if at all possible. No Trust
- S0: Encrypted communication; Once a device joins the network, its messages are protected from someone just casually walking in range, but it can still be passively compromised during pairing without you knowing. If compromised, same as No security. Low Trust
- S2 Unauthenticated: Encrypted communication + pairing; Like S0, but using the newer / more efficient protocol. Cannot be passively compromised, but could be actively compromised during pairing with a MITM attack without you knowing*. Low Trust
- S2 Authenticated: Like S2 Unauthenticated, but device and hub verify that they were not compromised during pairing. Medium Trust
- S2 Access Control: Functionally the same as S2 Authenticated, but expected to only be used by other highly secure devices, such as door locks and garage doors. High Trust
* Some hubs, like Hubitat, allow you to manually verify that S2 Unauthenticated devices were not compromised during pairing, but that does not stop the keys from being compromised— just lets you know if it happened.
A device can be in multiple groups, and each encrypted security group (S0/S2 Unauthenticated/S2 Authenticated/S2 Access Control) functions as it’s own mini sub-network. Devices can only see/communicate with other devices that share a common security group with each other. If a group is compromised, all devices in that group are considered compromised.
Ideally you want your access control devices (door locks, garage doors, etc.) in only S2 Access Control, and everything else in only S2 Authenticated.
If you can’t physically secure a device (i.e., an exterior light switch or bulb), you’d want to use S2 Unauthenticated, and then move only the devices that need to communicate with that device directly (i.e., associations) to S2 Unauthenticated + S2 Authenticated groups.
If you have a legacy device that only supports S0, then similarly you’d need to move any other devices that have to communicate directly with it to S0 + S2 Authenticated groups.
S0 and S2 Unauthenticated are “Low Trust” because while the window for encryption keys to be stolen is small, it’s hard to prove that nobody in range of your network is running a device that’s just constantly waiting for a Z-Wave pairing and stealing the keys. Maybe if you’re in a cabin in the woods, but for most people it will not be realistic to secure the entire area from which someone might be able to sniff or transmit a Z-Wave signal.
S2 Authenticated is “Medium Trust” because pairing will fail if someone tries to steal the keys, but most devices will use this and if there are non-zwave security vulnerabilities in any one of those devices, it could allow the entire security group to be compromised.
S2 Access Control is “High Trust” because not only will pairing fail if someone tries to steal the keys, but there should be very few devices in this security group and those devices should undergo more rigorous security design and testing than normal devices (smaller surface area for non-zwave attacks).
13 Likes
For completeness sake, Silicon Lab’s documentation about S2 can be found here: https://www.silabs.com/documents/public/presentations/PMP13827-2.pdf
1 Like
Thanks for all the info!
Without reading through all of the actual documentation, are you saying that every device that uses security needs to have a pathway of securely added devices all the way back to the hub?
I was under the understanding that every mains powered device in the whole network can repeat any message from hub to endpoint…?
No, thankfully! My understanding is any repeater device can repeat messages from any security group— An S0 device can repeat a message from S2 Access Control device, since it doesn’t need to see anything about the message itself— just rebroadcast the message as-is. But it will not be able to see the contents of the messages it is relaying from other security groups (which is why you can’t build associations that cross between security groups).
TL;DR: Your understanding matches mine, but I’ve not tested it.