这里有个疑问,通过自定义网关,小米设备能够直接加入。那么米家设备和网关是否预定义network key,如果有那么他还怎么能够加入我们自定义的网关。如果没有,那又是怎么保证网络安全的?
[zigbee Specification Revision 22 1.0]() ->4.2.1.2.1 Security Keys
详细介绍了zigbee 密钥类型,包含用以两个设备应用层(apl)单播的link key和用以所有设备其它层(network、mac)、以及应用层广播的network key。
通常地,network key 通过设备加入网络后密钥交互流程获取,而link key 则通过密钥交换和可能的出厂预定义安装。类似bdb install code已经实现应用预配置tc link key。
link key 区分全局(global)和唯一(unique)的,zigbee 联盟默认约定了一个全局的tc link key 5A 69 67 42 65 65 41 6C 6C 69 61 6E 63 65 30 39 (ZigBeeAlliance09)。
network key
用以网络层和应用层广播的数据帧加密,所有设备之间都共享该唯一密钥,可以程序固定也可以随机生成。
tc link key
用以两个设备之间应用层单播加密,具有唯一性,两个不同设备之间不一致,zigbee 联盟预定义了一个全局的link key用以初次获取network key。
提示:区分于不同网络安全模式,在分布式安全网络中没有tc link key,从而network key 实现应用层、网络层,单播、组播所有的加密。
通过tc(trust center 信任中心)统一为新加入的设备分发唯一的tc link key,该key作为新加入设备同其他设备应用层单播通信的密钥。
提示:详细参考,[Z-Stack 3.0 Developer's Guide.pdf]()->
10.3 Centralized security network
&10.6 Unsecure join to a network
提示:如上交互流程,区分两次 Transport Key,第一次为通过zigbee 联盟预设的全局 link key获取network key过程,第二次 Transport Key 则为通过network key 获取 唯一的tc link key。
如下图,通过抓包理解交换network key流程。
提示:random_key_succeed_packet_join_toggle.cubx ->
id.15
Transport Key
过程
对于成功交换的network key 支持程序预定义为固定值,如果默认为0x00,那么将会随机生成。
//ZGlobals.c line 840 function zgPreconfigKeyInit
if(ZG_DEVICE_RTR_TYPE) {
if(osal_memcmp(defaultKey, zgPreConfigKey,SEC_KEY_LEN)) {
ZDSecMgrGenerateRndKey(zgPreConfigKey);
} else {
// Initialize the Pre-Configured Key to the default key
osal_memcpy( zgPreConfigKey, defaultKey, SEC_KEY_LEN );
}
}
对于 交换 network key 的Transport Key
过程也是加密的,这里也需要解密,所以收发双方需要默认约定全局的link key 用以第一次的network key 获取,也就是如上zigbee 联盟约定的全局 tc link key。
提示:先前以为这里的network key 是双方程序提前固话好的,看来也是及时获取的,所以对于需要加入网络的双方设备都不需要提前知道任何密钥,都是通过加入网络后及时获取的。那么zigbee 安全不是保护的设备加入网络而是加入网络后设备的数据行为。这是zigbee3.0 设备能够互通的前提。
tc link key 交换过程,和network key 不一样,区分Request Key
和Transport key
过程。
提示:random_key_succeed_packet_join_toggle.cubx ->
id.40
Request Key
和id.44
Transport Key` 过程。
所有支持路由的设备(路由、协调器)直接为关联加入的设备分发预定义的全局 network key,该密钥固定。
提示:详细参考,[Z-Stack 3.0 Developer's Guide.pdf]()->
10.4 Distributed security network
&10.6 Unsecure join to a network
提示:如上交互流程,只有一次Transport key 过程,该过程则为通过zigbee 联盟预设的全局 link key获取 network key 过程。试想如果获取了分布式网络中的network key,那么所有设备的加密行为将会保留。
默认地,tc link key获取都是通过新加入网络设备发起数据请求。现在可以通过设备出厂的install code 携带一个随机128bit tc link key和16bit的crc,加入网络前tc通过一些物理接口(key/lcd、serial)获取该install code,从而直接允许新设备的加入。
提示:详细参考,[Z-Stack 3.0 Developer's Guide.pdf]()->
10.5.2 Install Code Derived Trust Center Link Key
以及[Base-Device-Behavior-Specification-2.pdf]()->10.1 Install codes
。
综上,zigbee 3.0 安全机制保证的是加入网络后设备数据通信链路,同时为了实现真正意义的万物互联,所以对于密钥的设置上面并且预先设置私有密钥。这样极大程度上保证了不同厂商的设备可以互联。当然这里还有一些其他策略用以网络安全。
mac permit join
mac 层beacon指示的允许设备加入标志位,通过cordinator在网络中广播zdp 同步该选项。
tc permit join
trust center 允许设备加入标志位,如果禁止允许设备加入,那么joined not
authornized` 设备将会被剔除网络。
暂时地,可以通过抓包分析一次还是两次 Transportkey 行为来区分。