This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/CC2652R: Some issue about unsecured rejoin in z-stack.

Part Number: CC2652R
Other Parts Discussed in Thread: Z-STACK,

Tool/software: TI-RTOS

In current version of z-stack that support R21, when a joined end-device lost parent it will find and rejoin a new parent node by secured rejoining. But when secured rejoining is failed, it will delete the network Key and try to rejoin by unsecured-rejoin. So the trust center would accept unsecured-rejoin whenever. If there is a malice device try to attack a zigbee network with unsecured-rejoin, it can be accept by  trust center. How does  trust center denied this malice device?

  • As I know, Zigbee 3.0 disallow insecure rejoin.

  • flowing zigbee 3.0, both in TI's and in silabs's stack SDK, device will get new link key from coordinate instead of default-key("ZigbeeAlliance09"). Once device rejoin failed by secured-rejoin, the network key may be changed by trust center. So the end-device will remove old network key and try to rejoin by unsecured-rejoin. After receiving unsecured-rejoin-rsp, the end-device will get new network key.
  • As I know, TI Z-Stack and EmberZNet disable unsecure rejoin by default.
  • Part Number: CC2652R

    Tool/software: TI-RTOS

    As I know, in z-stack,  trust center supports unsecured-rejoin. If a end-device lost it parent and the network key has changed, it can't recover by secured-rejoin, so the end device should try to rejoin by unsecured-rejoin and get new network key from trust center. But I find that there is no-way for end device to change to unsecured-rejoin when it rejoin fail in z-stack version which support zigbee 3.0.