CC2538: Communication between two platform end devices cannot be encrypted with an application-layer link key

The compressed file is a packet grabbing file when communicating.

Hi Susan,

I understand that all of the devices involved in the packet sniffer log are TI products.  Are you aware which version of Z-Stack is being used on each?  Z-Stack 3.0.2, HA 1.2.2a, Lighting, Mesh, etc.  as from Z-STACK and Z-STACK-ARCHIVE are possible.  It appears that Z-Stack 3.0 is not being used since TC Link Key updates are not initiated.  I'm not entirely sure what is attempting to be accomplished.  Both devices A & B are Zigbee End Devices since they announce as Reduce-Function Devices, send Data Requests, and do not send Link Status messages.  As such they should only communicate with their parent device (the Zigbee Coordinator in this instance) and not with other child devices.

Regards,
Ryan

Hi Ryan,

Customer uses the z-stack mesh version of the protocol stack. First, end devices don't just communicate with their parent devices. In the packet capture file, it can be clearly seen that the two terminal devices communicate directly without going through the parent device. And the protocol specification mentions that the app link key (this key is not the TC link key) is used to encrypt end-to-end communication. Why is the end-to-end communication between the two end devices not encrypted with the link key? What is the role of applying to the trust center for an end-to-end link key without link key encryption?

Thanks,

Annie

If the Zigbee end devices are going to be "always on" and communicate with other end devices then they should be configured as Zigbee router nodes instead.  That way they can perform mesh routing capabilities.  The customer can debug ZDSecMgrTransportKeyInd to further determine the reason why ZDSecMgrLinkKeySet is not executed or does not take effect.  One common reason could be that the correct security definition is not established.

Regards,
Ryan

Hi Ryan,

As can be seen from the packet capture file, the two terminal devices have obtained the app link key from the trust center, but they did not use the app link key encryption when they interacted with the data. What does it mean to say that the correct security definition has not been established, and how to set it up? Thank you!

Regards,

Susan

End Devices operate differently from Routers and as such Z-Stack settings will vary.  Debug ZDSecMgrTransportKeyInd and figure out why ZDSecMgrLinkKeySet is not executed or does not take effect, and evaluate operation with the End Devices changed to Router node configurations.

Regards,
Ryan

Okay thanks, I'll try it first.

Ryan Brown1 said:

One common reason could be that the correct security definition is not established.

I would like to ask what it means have not to get  the correct security definition established?

If you're going to implement end-to-end communication encrypted with a link key.

How do you illustrate it in your code? Thank you

ZG_CHECK_SECURITY_MODE must be ZG_SECURITY_SE_STANDARD for the KEY_TYPE_APP_LINK to be processed in ZDSecMgrTransportKeyInd.  ZG_SECURITY_MODE should be defined by the ZGlobals.h file.

The Zigbee Security Features SimpleLink Academy Lab briefly covers parts of this for a different device.  You can also review the Z-Stack Mesh Developer's Guide.pdf detailing APS Links Keys.

Regards,
Ryan

Hi Ryan,

says he knows this. The problem is: the two end devices have received the app link key, but cannot use it to encrypt the communication data.

Thanks,

Annie

I understand the issue, this is why I have asked that the user debug ZDSecMgrTransportKeyInd and figure out why ZDSecMgrLinkKeySet is not executed or does not take effect, and evaluate operation with the End Devices changed to Router node configurations.

Regards,
Ryan