Zigbee Coordinator Cloning

[saratk90]

As the title indicates, this question is regarding a scenario in which a coordinator needs to be replaced on an already established network. Is it possible to clone a coordinator on a new chip and resume network operation completely uninterrupted (i.e. without the need to recommission end devices)? Assume the trust center resides in this coordinator, this network has standard security enabled (NWK & TCLK), and there are bindings and reports configured on the joined end devices.

I've read numerous posts on various development forums indicating this is theoretically possible by saving network parameters in NVRAM and reloading them onto the new coordinator. However, it doesn't seem like there is consistent success (if at all) in getting this done. 

Is this possible? If so, what are the high level steps involved using the ZBOSS stack, and what caveats/gotchas/limitations/ should one be mindful of when implementing this at a production scale? My understanding is, a new coordinator can restart the same network configured on the old coordinator with the same PANID, NWK, and TCLKs & short IDs of joined devices. With this information, the coordinator should be able to send packets to end devices (e.g. turning on/off a switch). Where I'm confused is how end device to coordinator communication is restored. For example, you physically toggle a switch, and it's configured to report that state change back to the coordinator. The application and NW layers will package the frames correctly to address the coordinator with the correct PAN ID, address (0x0000), NWK, etc. But what happens at the MAC layer? The new coordinator will have a new MAC address. How will the end device know of this change so that it addresses the coordinator correctly at the MAC layer? Assume this end device is a 3rd party device, for which we have no control over its firmware.

[AHaug]

Hi,

Unfortunately there exists no option to replace the coordinator in the case where you have a centralized security network (coordinator is the trust center), as (among other things) authentication of new devices and generation of new keys are done by the coordinator. And as far as I know you can not provision a new coordinator, move the trust center to the new coordinator and remove the old coordinator from the network either.

One option is to design a network with a distributed security model instead of a centralized model. Here, the routers issues keys and authenticates new devices to the network, which should allow you to swap the coordinator if needed.  As I've answered in another case asking a similar question, you must be aware that there are some potential security problems with the transport key in distributed network. All routers and end-devices in a distributed network must be pre-configured with a link key, used to encrypt the network key when it is passed to a new device. There has been cases where it has been exploited that the keys were hard coded on the devices. 

If you could supply the resources you've found stating that it might be possible to clone/swap the coordinator, I can have a look at them to see if I've missed anything in my understanding on how the coordinator/trust center is working. Also be sure that if you share any docs that they are otherwise publicly available as this is a public ticket (so we can avoid sharing pirated docs). I am fairly certain that this should not be possible, as if you could clone a coordinator of a network with relative ease (read out keys, bindings, devices, IDs etc), that would be a large potential security issue. 

Let me know if you have any follow up questions or if this answers your question at all! 

Kind regards,
Andreas

[saratk90]

Hi Andreas,

Thank you for providing clarity on this topic. So theoretically speaking, even if the network parameters such as the network key, pan id, ext pan ID, preconfigured keys, app EPs, cluster info, and TC keys of joined devices are saved and then copied to new hardware, this would not work?

[AHaug]

Glad to help,

I will have to take a closer look into that, but as far as I know there are certain keys that are encrypted in a fashion that only the ZBOSS stack producer knows how is encrypted that are stored somewhere in the flash and are not possible to read out and store, so I don't think that you will be able to pull out everything you need to do a full clone and replace the device.In addition, if you (and potentially other users) are able to fetch all of the keys from a device and feed them to a new device that will replace the network center of security, that would be a large potential point of entry for malicious use of the devices in the network. 

I see however that there are some forum posts on for instance the Home Assistant community where they have procedures for doing this, but it is not supported by all types of coordinators. So if you have found a procedure for how to do this elsewhere online, you are always open to try them. But be aware that if you intend to certify the device at some point in time for production, you might have to cross examine the Connectivity Standars Alliances requirements for Zigbee device certification to see if you meet the requirement w.r.t. security

Kind regards,
Andreas