ZigBee 3.0 Z-Stack 2.1 Centralized security network
2018-03-15 16:23
435 查看
(配套源码、软件、开发板等资源,可移步博客同名QQ群:拿破仑940911)
1、Definition
This network type is formed by coordinator devices, in which the coordinator assumes the role of TC. In this type of network only the TC can deliver the network key to joining and allow them to be part of the network.
The coordinator can configure different sets of TC policies that allow control of the security level of the network.
2、Association/Join and validations
Case 1: When a device performs an association directly to the TC, the TC will evaluate the TC policies and validate if the device is allowed to join the network or not.
[b]Case 2: When a device joins through a router device[/b], the parent device notifies the TC via an APS Update Device command, and then the joining device will go through the same TC policy validations.
3、Key delivery
Case 1: If a device passes the validations, the TC will deliver the network key to the joining device through either a direct APS Transport Key command or an APS Tunnel: Transport Key command, depending on the devices joining topology.
Case 2: If the joining device does not pass the TC policy validations, it will be kicked out of the network with a network leave command.
4、Trust center policies
4.1 zgAllowRemoteTCPolicyChange
If this policy is set to TRUE, other devices in the network may modify the permit joining policy of the trust center, which could allow other devices to join the network.
If set to FALSE, remote devices will not be able to change the permit joining policy on the coordinator, which will cause the TC to not deliver the network key and kick out any devices attempting to join the network through an intermediate router which may have locally enabled permit join.
4.2 bdbJoinUsesInstallCodeKey
If bdbJoinUsesInstallCodeKey is set to TRUE, then the network key will be delivered only to those joining devices that do have an install code associated.
If bdbJoinUsesInstallCodeKey is set to FALSE, joining devices may use install codes. The usage of install codes is described in section 10.5.2.
4.3 bdbTrustCenterRequireKeyExchange
If this policy is set to TRUE (set to this value by default in bdb_interface.h), all the joining devices are mandated to performthe TCLK exchange procedure. Devices that do not perform this procedure will be kicked out of the network after bdbTrustCenterNodeJoinTimeout seconds (15 by default). It is important to note that legacy devices (implementing R20 or before) will not be able to perform the TCLK exchange process, so if this policy is set to TRUE, legacy devices will not be able to join this network.
If this policy set to FALSE, joining devices will not be required to perform a TCLK update, but they will be allowed to do so. The TCLK exchange procedure is described in section 10.6.1.
5、Key Updates
The Trust Center can update the common Network key at its discretion. An example policy would be to update the Network key at regular periodic intervals. Another would be to update the NWK key upon user input (like a button-press). The ZDO Security Manager ZDSecMgr.c API provides this functionality via ZDSecMgrUpdateNwkKey() and ZDSecMgrSwitchNwkKey().
Step 1 :
ZDSecMgrUpdateNwkKey() allows the Trust Center to send a new Network key to the dstAddr on the network. At this point the new Network key is stored as an alternate key in the destination device or devices if dstAddr was not a unicast address.
Step 2 :
Once the Trust Center calls ZDSecMgrSwitchNwkKey(), with the dstAddr of the device or devices, all destination devices will use their alternate key.
In R21 revision of the ZigBee specification, the network frame counter is mandated to be persistent across factory new resets, but it can be reset to 0 under the following condition: if the network frame counter is larger than half of its max value (0x8000000), prior to performing a network key update, performing the update will reset the frame counter to 0.6、Note
It is also important to note that if the TC is not available (power cycled or not in the network), new devices will not be able to join the network since no other device is allowed to deliver the network key or validate TC policies.
(配套源码、软件、开发板等资源,可移步博客同名QQ群:拿破仑940911)
1、Definition
This network type is formed by coordinator devices, in which the coordinator assumes the role of TC. In this type of network only the TC can deliver the network key to joining and allow them to be part of the network.
The coordinator can configure different sets of TC policies that allow control of the security level of the network.
2、Association/Join and validations
Case 1: When a device performs an association directly to the TC, the TC will evaluate the TC policies and validate if the device is allowed to join the network or not.
[b]Case 2: When a device joins through a router device[/b], the parent device notifies the TC via an APS Update Device command, and then the joining device will go through the same TC policy validations.
3、Key delivery
Case 1: If a device passes the validations, the TC will deliver the network key to the joining device through either a direct APS Transport Key command or an APS Tunnel: Transport Key command, depending on the devices joining topology.
Case 2: If the joining device does not pass the TC policy validations, it will be kicked out of the network with a network leave command.
4、Trust center policies
4.1 zgAllowRemoteTCPolicyChange
If this policy is set to TRUE, other devices in the network may modify the permit joining policy of the trust center, which could allow other devices to join the network.
If set to FALSE, remote devices will not be able to change the permit joining policy on the coordinator, which will cause the TC to not deliver the network key and kick out any devices attempting to join the network through an intermediate router which may have locally enabled permit join.
4.2 bdbJoinUsesInstallCodeKey
If bdbJoinUsesInstallCodeKey is set to TRUE, then the network key will be delivered only to those joining devices that do have an install code associated.
If bdbJoinUsesInstallCodeKey is set to FALSE, joining devices may use install codes. The usage of install codes is described in section 10.5.2.
4.3 bdbTrustCenterRequireKeyExchange
If this policy is set to TRUE (set to this value by default in bdb_interface.h), all the joining devices are mandated to performthe TCLK exchange procedure. Devices that do not perform this procedure will be kicked out of the network after bdbTrustCenterNodeJoinTimeout seconds (15 by default). It is important to note that legacy devices (implementing R20 or before) will not be able to perform the TCLK exchange process, so if this policy is set to TRUE, legacy devices will not be able to join this network.
If this policy set to FALSE, joining devices will not be required to perform a TCLK update, but they will be allowed to do so. The TCLK exchange procedure is described in section 10.6.1.
5、Key Updates
The Trust Center can update the common Network key at its discretion. An example policy would be to update the Network key at regular periodic intervals. Another would be to update the NWK key upon user input (like a button-press). The ZDO Security Manager ZDSecMgr.c API provides this functionality via ZDSecMgrUpdateNwkKey() and ZDSecMgrSwitchNwkKey().
Step 1 :
ZDSecMgrUpdateNwkKey() allows the Trust Center to send a new Network key to the dstAddr on the network. At this point the new Network key is stored as an alternate key in the destination device or devices if dstAddr was not a unicast address.
Step 2 :
Once the Trust Center calls ZDSecMgrSwitchNwkKey(), with the dstAddr of the device or devices, all destination devices will use their alternate key.
In R21 revision of the ZigBee specification, the network frame counter is mandated to be persistent across factory new resets, but it can be reset to 0 under the following condition: if the network frame counter is larger than half of its max value (0x8000000), prior to performing a network key update, performing the update will reset the frame counter to 0.6、Note
It is also important to note that if the TC is not available (power cycled or not in the network), new devices will not be able to join the network since no other device is allowed to deliver the network key or validate TC policies.
(配套源码、软件、开发板等资源,可移步博客同名QQ群:拿破仑940911)
相关文章推荐
- ZigBee 3.0 Z-Stack 2.5 Unsecure join to a centralized network
- ZigBee 3.0 Z-Stack 2.6 Unsecure join to a distributed network
- ZigBee 3.0 Z-Stack 2.4 Unsecure join to a network
- ZigBee 3.0 Z-Stack 2.8 Security for joining devices
- ZigBee 3.0 Z-Stack 2.3 Link Key types
- ZigBee 3.0 Z-Stack 2.10 Backwards Interoperability
- ZigBee TI ZStack CC2530 2.1 如何学习ZigBee
- 「2014-5-31」Z-Stack - Modification of Zigbee Device Object for better network access management
- ZigBee 3.0 Z-Stack 5.1 抓包工具:Packet Sniffer/Ubiqua
- [置顶] ZigBee 3.0 Z-Stack 1.1 总体框架
- Z-Stack Developer's Guide - Zigbee & Addressing
- zigbee z-stack实现按键的长按
- 研究 Z-Stack 中ZigBee 设备的 IEEE 地址
- 揭开ZigBee 2006协议栈Z-Stack的”开源“面纱 以及其它的开源协议
- Hack the Stack: Using Snort and Ethereal to Master the 8 Layers of an Insecure Network [ILLUSTRATED]
- AAA and Network Security for Mobile Access: Radius, Diameter, EAP, PKI and IP Mobility
- coco2dx 3.0使用sqlite3和network时出现无法解析的外部符号的解决方案
- 权限控制:spring 3.0 security配置例子
- spring-security 3.0.X, 让ajax login和普通login共存
- Linux网络协议栈导读 Linux Network Stack Walkthrough (2.4.20)