TC在Z-Stack3.0上面的使用以及ZDSECMGR_TC_DEVICE_MAX

什么是TC（Trust Center） 以及ZDSECMGR_TC_DEVICE_MAX

Enhanced security for Centralized Networks (Networks with a Coordinator/Trust Center)

R21 TC Link Key update procedure

Trust Center Link Key (TC Link Key) update

• R21 devices joining a Zigbee 3.0 centralized network must initiate a TC Link Key update procedure upon joining the network.
  • Node Descriptor packet sent during network association procedure indicates the joining device's Zigbee version (0x00 for legacy devices, 0x15 for new devices), and the R21 coordinator/trust center can be configured to accept or reject legacy devices that do not initiate the TC Link Key update procedure.
• This unique TC Link Key will be used for all encrypted APS-layer communication instead of the well-known TC Link Key
• Note: mandatory unique TC Link Keys for each capable device leads to an increased flash requirement on the coordinator
• By default, the initial network key is transported to joining devices using the well-known TC Link Key. However, you now have the option of using pre-configured keys and install codes to enhance security even further.

Defines the maximum number of Unique TC Link Key entries that the ZC can handle. The Zigbee 3.0 specification mandates that every Zigbee 3.0 certified device must perform TC Link Key update during network association and use a unique TC Link Key with the network Trust Center (ZC). This is to say,  ZDSECMGR_TC_DEVICE_MAX defines the maximum number of Zigbee 3.0 devices that are allowed in the network. Legacy devices (HA 1.2 profile, R20) will not affect this value.

实验：

我定义ZDSECMGR_TC_DEVICE_MAX=2，然后使用3个节点入网看一下实验现象。

0x2714入网：

0x33bd入网：

0xba01入网：

0xba01 leave：

可以发现0x2714以及0x33bd都可以入网并且request key会有transport key，以及最后的confirm key。

但是发现0xba01发出了request key，但是一直没有transport key以及Verify key，直到time out 以及最后的leave。

可以得出结论上面的：

The Zigbee 3.0 specification mandates that every Zigbee 3.0 certified device must perform TC Link Key update during network association and use a unique TC Link Key with the network Trust Center (ZC). 

Susan Yang：

谢谢分享！学习一下！

user4958201：

设置的MTO宏，ZC信任中心机制，两次设置ZDSECMGR_TC_DEVICE_MAX宏都一样，但是BDB_DEFAULT_JOIN_USES_INSTALL_CODE_KEY这个宏分别设置了true和false，其中有一个现象和 你的完全一样，完全一样的那次BDB_DEFAULT_JOIN_USES_INSTALL_CODE_KEY= FALSE。

官方开发文档10.3.1.3章节对此宏做了说明大致意思为：

TRUE=  所有加入设备都被强制执行TCLK交换程序，如果没有完成/执行这一程序的加入设备在bdbTrustCenterNodeJoinTimeout时间（默认       15秒）后会被踢出网络。  我做实验时如果ZDSECMGR_TC_DEVICE_MAX=2，第三个加入的节点会收到ZC发来的leave指令。

FALSE= 连接设备不是强制必须执行TCLK交换程序，但是也运行TCLK交换。

主要是这个等于FALSE时我不太明白说的什么意思，能解释下  “连接设备不是强制执行TCLK交换程序，但是也运行TCLK交换”  ？

我做实验的真实结果是：前提还是ZDSECMGR_TC_DEVICE_MAX=4，前4个顺利入网，都执行了TCLK，第5个入网开始由于没有TCLK交换过程，在发出beacon后30~40秒直接自己发送leave广播后重启，这个过程一直在循环，应该和你上面截图分析的一致。

我换了另外一个节点入网，刚开始现象同上，但是过一会竟然加进去了，收发报文正常，看了下入网过程，没有任何密钥交换，不过异常点在于这个节点入网每次ZC给他分的16位短地址都是一个。我觉得这可能是个偶发现象。

我的最终目的其实想在3.0协议栈和MTO机制基础上入网越简单越好，所以如果密钥能取消或者优化流程是最好的。

Alvin Chen：

回复 user4958201:

processors.wiki.ti.com/…/What's_New_in_ZigBee_3.0

user4958201：

回复 Alvin Chen:

您好，还是这个ZDSECMGR_TC_DEVICE_MAX值的问题，协议栈默认设置ZC 为40，我改成100，编译可以通过（编译官方注释超过NV_id分配的条目0xFF-0x11=238会报错，说明该值受限于NV大小的），但是一个节点都不能入网，ZC回复的association response报文中提示unsuccessful，我看了map文件，该值不仅受NV大小限制，还影响RAM运行空间。
我用的2538_512芯片，下面是设置ZDSECMGR_TC_DEVICE_MAX=100编译后map文件。看着也不超过32K啊。134 892 bytes of readonlycode memory1 420 bytes of readonlydata memory14 603 bytes of readwrite data memory (+ 12 288 absolute)

我将ZDSECMGR_TC_DEVICE_MAX=45也可以正常运行，但是想找到改为100时的限制原因，请给与指点，谢谢。

Alvin Chen：

回复 user4958201:

本帖子仅作为分享帖，不做回复。
你可以参照这个帖子e2echina.ti.com/…/156759