All - how does the Zigbee insecure rejoin function impact automations and smartapps? For example, if I have the disable insecure rejoin, then Zigbee devices that disconnect will need to be manually re-added rather than automatically reconnecting. If that happens, do those devices need to be manually re-added to all automations and smartapps (such as Webcore) that use them? Or when I re-add the Zigbee devices, they will step into their old IDs and automations and smartapps all work unimpeded?
Thanks for the attention, I saw the FAQ but it wasn’t helpful. What I wanted to know is upon re-registering (as shown in the FAQ), do all automations and smartapps that use that device need to be re-linked to the new device, or does the re-registration allow the device to “step in” to the old device handler.
For example, I think I had an issue where a door sensor at the fringe of my network dropped off while i had insecure rejoin disabled, so when I re-registered it, it was no longer registered in smart home monitor. I am not sure the two were connected however, as I had a lot of other issues going on at the same time.
I’m interested in impact on automation, smart lightings SmartApp, and webcore.
Hi @rlin5741, you do not need to re-link anything. When your zigbee device rejoins it will get the same ID and continue to work like it did before in ST.
I think something else is going on because I’ve never seen any of my zigbee devices do that with the Classic app’s SHM, or the new app’s STHM; or any automation, Scene, etc; and I have a little over 260 zigbee devices
Thank you, that was helpful. So I guess the only downside of turning off insecure rejoin (or turning the secure mode on in the new app) is the hassle of manually re-registering if a device drops from the network - and if I am away or device is in an inaccessible place, this can’t be done easily.
I wonder when SmartThings is going to fix this, hasn’t the Zigbee standard come up with a solution already?
How big of an issue is this really? In order to spoof a Zigbee device, would someone need to have physical access to it to discover its network key, or is the whole issue that network keys are broadcast in the open and unencrypted (negating the whole point of having a network key).
The network key is sent to the insecure rejoining device encrypted with the public Zigbee HA key so it’s effectively not secured and anyone listening can get the key. This also happens any time you join a Zigbee HA device to the network, but the difference is an insecure rejoin can happen at any time while the join only happens when you are actively joining a device to the network which makes it much harder to exploit. Zigbee 3 introduced the concept of installation codes which the hub uses to encrypt the network key with a device specific key that only the device you’re joining will be able to decrypt.
The “secure mode” flag is intended to give users control over security vs ease of use. We also make sure that devices use secure rejoin during WWST certification, although some older devices got the certification before that test was in place.
Thanks Tom, I appreciate the answer. One follow-up - this statement implies that WWST certified devices should be able to drop off the network and then rejoin securely (e.g. rejoin regardless of whether insecure rejoin is activated or not), and be able to do this without manually taking the device down and putting it in join mode. Is this correct, or did I read too much into it?
This should be true for WWST devices certified in the last year or so that are running the latest firmware. There are some devices that were certified before we started testing the secure rejoin behavior that may not always secure rejoin. For example, it used to be common for devices to attempt secure rejoin a couple of times and then only attempt unsecure rejoins after that. We now check for that and ask manufacturers to update the firmware if we find that behavior.