• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 3 answers
  • Subscribers 56 subscribers
  • Views 598 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: Why coordinator send a NWK Key secured Leave command to End-Device when it Unsecured-Rejoin?

Aries Lord
Genius 5370 points
Part Number: CC2652R
Other Parts Discussed in Thread: Z-STACK, SIMPLELINK-CC13X2-26X2-SDK

Tool/software: TI-RTOS

My coordinator has rebuild a new network with new NWK Key, but an old joined end-device will scan the parent, and try to rejoin into it. If End-device rejoin failed, it will try to rejoin with unsecured-rejoin. But the coordinator will send a NLME-Leave command to the end-device with new NWK key secured.The end device can't decrypt  it.

  • 0
    Guru 735625 points

    As I know, unsecured rejoin is deprecated in Zigbee 3.0 due to security issue.

  • 0 in reply to YiKai Chen
    Genius 5370 points

    But some HA 1.2 devices need to be compatible.

  • 0
    TI__Guru**** 211327 points

    The Zigbee HA 1.2 End Device will need to recognize a failed unsecure rejoin, timeout, and perform an unsecure join.  Please refer to Section 4.7.3 of the 2017 (R22) Zigbee Spec.

    Note that backwards compatibility is still intact, with the exception of corner cases including options for joining a new network formed by the original Coordinator acting as the Trust Center.  As YK mentioned this presents a security risk.  http://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_3_10_00_53/docs/zigbee/html/zigbee/z-stack-overview.html#security 

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Genius 5370 points

    I have update my SDK to 3.10.01.11, does it supports R22?

    If a HA 1.2 End-Device failed rejoin into a z-stack 3.10.01.11 parent, it many change to unsecured-rejoin mode. But  z-stack 3.10 parent will refuse any unsecured-rejoin by sending Leave-Req.

  • 0 in reply to Aries Lord
    TI__Guru**** 211327 points

    The SIMPLELINK-CC13X2-26X2-SDK is a Zigbee r22 Compliant Platform: https://www.zigbee.org/zigbee-compliant-platforms/#zcp/productdetails5/5c8bee17be7b565362682524/

    Yes, this is the behavior described in the R22 Zigbee Specification.  The HA 1.2 End Device application must change join methods after the unsecured rejoin fails.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Genius 5370 points

    I want my coordinator to accept unsecured-rejoin device and re-transport new NKW key. How can I do to force my coordinator to stop sending Leave-Command to unsecured-rejoin device?

  • 0 in reply to Aries Lord
    Guru 735625 points

    As I know, you cannot do this in Zigbee 3.0 Coordinator acting as trust center.

  • 0 in reply to YiKai Chen
    Genius 5370 points

    I have provided that set "zgAllowRejoins" to "TRUE", coordinator and router will not send leave-command to unsecured-rejoin child-node. But Trust Center will transport NWK key with Default-Link-Key encrypted. I think that it is better for Trust Center to transport NWK-Key to a unsecured-rejoin node with Verified-Link-Key encrypted.

  • 0
    Genius 5370 points

    Part Number: CC2652R

    Tool/software: TI-RTOS

    In zigbee 3.0 network, a joined Node could get a new Link-Key that is called "verified link key" from trust center. So when the end-device try to rejoin the network by unsecured-rejoin mode, if trust-center had stored its unique Link-key( generated by trust-center). This end device should be accepted by this network.

    1, set "zgAllowRejoins" into "TRUE" on router and coordinator, the parent node will not send NLME_Leave command to a unsecured-rejoin end-device.

    2, function "ZDSecMgrDeviceJoinDirect" in "zd_sec_mgr.c", there is some issue in it, fix it like this.

    ZStatus_t ZDSecMgrDeviceJoinDirect( ZDSecMgrDevice_t* device )
{
  ZStatus_t status;
  
  if(device->secure == FALSE)
  {  
     //........
  }

  status = ZDSecMgrDeviceJoin( device );

  if ( status == ZSuccess )
  {
   //.....
    
  #if (ZG_BUILD_COORDINATOR_TYPE)    
    //Add the device as joining device, if it did join unsecured
    if( (device->secure == FALSE) && !(device->devStatus & DEV_SEC_AUTH_TC_REJOIN_STATUS) )//fixed by luoyiming 2019-07-11
    {
      bdb_TCAddJoiningDevice(NLME_GetShortAddr(),device->extAddr);//don't waiting verify link key for unsecured-rejoin
    }
  #endif
  }

  //.....
}

  • 0
    Genius 5370 points

    This is the correct trust-center processing of my idea.