• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 56 subscribers
  • Views 654 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC1352P: User Specified Trust Center Link Key

Bill Kuckuk
Expert 1305 points
Part Number: CC1352P


I'm trying to find a way to override the defaultTCLinkKey in the coordinator.  

I'm using Zstackapi_bdbSetActiveCentralizedLinkKeyReq() as follows:

LinkKeyRequest.zstack_CentralizedLinkKeyModes = zstack_UseAPSKey;
LinkKeyRequest.pKey = UserSpecificKey;
Zstackapi_bdbSetActiveCentralizedLinkKeyReq(H8Interface_ZstackId, &LinkKeyRequest);

Where the UserSpecificKey[] can be specified by a user.  I realize this is non-interoperable, but that's what we want.

I do this before I call Zstackapi_bdbStartCommissioningReq();

This seems to work for a Router because it no longer recognizes the TRANSPORT_KEY message, but the coordinator keeps using "ZigbeeAlliance09"  in the TRANSPORT_KEY  message.

Is there a way to get the coordinator to use a different TCLinkKey?

Thanks,

- Bill

  

  • 0
    TI__Guru**** 219527 points

    Did you modify DEFAULT_TC_LINK_KEY in nwk_globals.h?  Have you considered using install codes?  Please also refer to the Zigbee Security SLA: http://dev.ti.com/tirex/explore/node?node=AES5VdxyX-.OXxWoIFsyPg__pTTHBmu__LATEST

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Expert 1305 points

    Hi Ryan

    The problem with modifying the DEFAULT_TC_LINK_KEY is that it's a constant that would be used across all PANs.  We want a unique TCLK per PanID.

    We also considered using Install Codes, but it requires unique codes for each device (and label/QR/BarCode that needs to be created in manufacturing) and requires a UI or some other means to enter the codes into the trust center.  These are added costs during manufacturing and added labor during install.

    I did find a way around this by modifying ZDSecMgrReadKeyFromNv().  

      else if(keyNvId == ZCD_NV_TCLK_DEFAULT)
  {  
    // JCI Patch
   GetPriviteKey(keyinfo);
    
    //OsalPort_memcpy(keyinfo,defaultTCLinkKey,SEC_KEY_LEN);
    // JCI Patch
    return ZSuccess;
  }


    GetPriviteKey(keyinfo) is also called to fill in the key for the bdb call before forming/joining a network..

    ...
  zstack_bdbSetActiveCentralizedLinkKeyReq_t LinkKeyRequest;
  uint8_t PANSpecificKey[SEC_KEY_LEN];
  GetPriviteKey(PANSpecificKey);
  LinkKeyRequest.zstack_CentralizedLinkKeyModes = zstack_UseAPSKey;
  LinkKeyRequest.pKey = PANSpecificKey;
  Zstackapi_bdbSetActiveCentralizedLinkKeyReq(H8Interface_ZstackId, &LinkKeyRequest);
...

    I think there is a hole in the stack where the bdb call with CentralizedLinkKeyModes = zstack_UseAPSKey works for Routers, but does not change the behavior of the Coordinator as it continues to use the "ZigbeeAlliance09" default to transport the key.

  • 0 in reply to Bill Kuckuk
    TI__Guru**** 219527 points

    Hi Bill,

    Before further evaluating the ZDSecMgrReadKeyFromNv function, would it be possible for you to modify defaultTCLinkKey during run-time (you will also need to write the ZCD_NV_TCLK_DEFAULT NV item)?

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Expert 1305 points

    I did try that first.  I needed to change the defaultTCLinkKey from a "CONST uint8_t " to just a "uint8_t" in both the .c and .h files.  Then I copied the PAN specific key into it before forming/joining the network.  I thought it should work but for some reason the coordinator kept using "ZigbeeAlliance09".   I did see that ZDSecMgrReadKeyFromNv() was getting called from some location (ROM?) that I have no source for.  It might have been getting called before I updated defaultTCLinkKey.  

    I did not write this to NV.  Could that be the problem?  Is the NV being read without calling ZDSecMgrReadKeyFromNv()?

    I may have been doing something else wrong, but I didn't dig into it any further before I came up with a fix that worked. 

  • 0 in reply to Bill Kuckuk
    TI__Guru**** 219527 points

    ZDSecMgrReadKeyFromNv is called from the source libraries for processing frame security but this involves ZCD_NV_PRECFGKEY.  However, ZCD_NV_TCLK_DEFAULT is used by the security manager.  bdb_setActiveCentralizedLinkKey is only to be used for joining type devices, not the coordinator.