Simplelink (cc13x2_26x2_sdk_5_20_00_52) and ZStack2.5.1 network compatibility

Hi Wolfgang,

Have you made the recommended changes to the Z-Stack 2.5.1a project as it concerns zgPreConfigKeys/zgUseDefaultTCLK?  I cannot decrypt the packets from node 0x35CC which means it is using a different NWK key than what was transported by the ZC (0x01, 0x03, 0x05, 0x07, 0x09, 0x0B, 0x0D, 0x0F, 0x00, 0x02, 0x04, 0x06, 0x08, 0x0A, 0x0C, 0x0D).

Regards,
Ryan

Hi Ryan,

Yes, I made all recommended changes. Does the ZG_SECURE_DYNAMIC flag has any influence? It's 0 currently. 

The NWK key is transferred to the joining device by the APS Command after the Association Response, isn't it? In this case, the 0x35CC device seems to ignore the key that has been transferred. 

Which ZG_SECURITY_MODE would be the correct one? Currently, it's ZG_SECURITY_PRO_STANDARD. I'm not using the Smart Energy Profile. Thus chapter 10 of the Developer's guide isn't important, is it?

Kind regards,

Wolfgang

I not sure what effect ZG_SECURE_DYNAMIC would have on the v2.5.1a Z-Stack.  If the 0x35CC device has a pre-defined NWK key then it will use this instead of the key transported by the ZC.  ZG_SECURITY_PRO_STANDARD is the same as ZG_SECURITY_RESIDENTIAL (0x01) and is not the same as ZG_SECURITY_SE_STANDARD (0x04) as far as I am aware.

Regards,
Ryan

@pre-defined NWK key: I suppose you refer to DEFAULT_KEY that is defined in the f8wConfig.cfg file. Just undefining this value has no effect (see nwk_globals.c). Therefore, I changed all bytes to 0x0 but the joining device still seems to ignore the ZC's key. I cleaned the device before reprogramming to make sure that there is no key information in the NV-memory.   

Thanks for any hint,

Wolfgang

You could try setting the DEFAULT_KEY to 01:03:05:07:09:0B:0D:0F:00:02:04:06:08:0A:0C:0D since that's the NWK key being sent by the ZC in the sniffer log.  Otherwise please further debug your Z-Stack v2.5.1a ZR to further determine what NWK key it is trying to use.

Regards,
Ryan

I've already tried to use the default key without success.

Do you agree that ZDApp_ProcessSecEvent should be called in case of an incoming Transport Key Message, don't you? I would expect a ZDO_TRANSPORT_KEY_IND event. But this event never occurs.

What would be a better starting point?

Kind regards,

Wolfgang

It will not receive the ZDO_TRANSPORT_KEY_IND event if the global TC Link Key is not agreed upon.  I'm not familiar with how security is set up or the application flow on the deprecated Z-Stack.  It appears to be sending Link Statuses based on the frequency and data length, and attempting to send on the same PAN ID as the ZC.  Consider monitoring the join process and viewing NV contents.

Regards,
Ryan

I made a little progress. To my mind, calcChkF(...) defined in OSAL_Nv.c does not calculate len correctly. This is the reason why osal_nv_item_init fails for the various keys. Changing this got me a little further. But the transport key transmitted by the ZC seems still not to be accepted.

Am I right, that the TC Link Key is the only key that influences this behavior?  I cross-checked the TC Link Key (used by the joining device which is identical to the one used to encrypt the Transport Key message. Thus I'm stuck as there is no code of the security-related stuff available. Which NV items except ZCD_NV_TCLK_TABLE_START could be interesting, too?

The application link keys are of no interest yet, are they? ZStack 2.5.1 also uses MASTER_KEY_DATA which seems to be eliminated in the current stack. 

Regards,

Wolfgang

The global TC Link Key is the only key involved in APS layer messages like the Transport Key packet.  The global TCLK should be a defined value which is not stored in NV memory.  Application keys are not relevant and I have no recollection of MASTER_KEY_DATA usage as it is not used in Z-Stack HA 1.2.2a or Z-Stack 3.0.  You could try comparing the packets transferred between the joining of two Z-Stack 2.5.1 devices to identify the inconsistency.

Regards,
Ryan

I enabled the PACKET_FILTER_STATS flag to activate the nwk_UpdateStatistics function. Every time a Transport Key message is received a STAT_APS_SECURITY_FAILURE is reported which applies the theory that the transport key is not accepted. The call stack shows that nwk_UpdateStatistics is called from NLDE_DataIndication. Unfortunately, there is no source code available. At least an excerpt of the code related to the STAT_APS_SECURITY_FAILURE would help to identify the problem. Is the outdated code available somewhere?

I've sent you a private message containing the code you've requested.

Regards,
Ryan