ZigBee 3.0理论教程-通用-1-05:安全加密


【配套源码文档软件硬件等资源,请移步技术交流群:拿破仑ZigBee(263671349)】
【所有相关IDESDK均可从群文件免费获取,也全都是免安装的,解压出来直接就能开始开发】

持续更新中,欢迎关注!

一、安全威胁

由于ZigBee是一种无线技术,因此安全性非常重要,因为黑客可以通过无线检测到这些数据包。想象您有一个智能门锁。如果黑客捕获了打开您的门的数据包,那么他可以重发该文件以打开您的门。这是很危险的。

在ZigBee的网络里面,面临的两种最为典型的安全威胁:

  • 第一种是伪造。比如黑客捕获到无线报文,进行篡改之后,伪造一个假的报文,再发送到这个ZigBee网络中,从而去控制网络里的设备;
  • 第二种是重播。捕获到这个报文后,不进行编辑,直接重新播放一下,

为了防止这种情况发生,ZigBee定义了许多安全功能。下面将会做简要介绍。

二、ZigBee安全

2.1 加密流程

APS层和网络层的加密流程,如下图所示:

它显示了如何在网络层中保护不安全的网络帧:首先,网络有效负载将被加密。之后,将在加密的有效负载之前添加安全标头。然后根据网络标头,安全标头和加密的有效负载来计算哈希值。最后,将32位哈希值附加到帧的末尾。如果更改了网络标头,安全标头和加密的有效负载中的任何字节,则哈希值将不同。我们将此值称为MIC(mandatory integrity control),是消息完整性检查的缩写。

2.2 加密算法

APS层和网络层的两个加密环节使用的都是AES128对称加密算法,这意味着需要使用相同的密钥进行加密和解密。

2.3 完整性检查

2.4 重播攻击保护

添加了帧计数器以防止重发攻击。让我们看看它是如何工作的。

在发送方

  • 每发送一次Frame Counter的值都需要增加1;
  • Frame Counter的值需要保存在non-volatile memory中,便于重启后恢复Frame Counter。

在接收方

  • 首先,将记录接收到帧的节点的Eui64和Frame Counter的值;
  • 来自同一节点的下一条消息的Frame Counter必须大于记录的Frame Counter值。如果此次的Frame Counter比上一次的小或者相等,该消息都将被视为重发并将被丢弃;
  • 由于资源有限,接收方只保存所有邻居的Frame Counter。

由于Frame Counter是一个32位值,因此如果设备长时间保持运行状态,它可能会自动溢出。显然,如果帧计数器被覆盖,可能会出现问题。为防止这种情况发生,必须在溢出之前更新Network Key。如果更新了Network Key,帧计数器则可以再次从零开始。

对于End Device来说,它通常只需要保存其父节点的Frame Counter即可。

三、APS层安全

3.1 总览

在APS层用来加密的密钥被称为Link key。在ZigBee网络中,虽然APS层和网络层都有加密,但是绝大部分通信都只是在网络层的加密。
一般来说,只有在传输Network Key的时候需要在应用层被加密,并且这仅在Trust Center和新设备之间发生。因此,在这种情况下,我们也将其称为Trust Center Link key。

新设备和Trust Center之间必须要在组网之前就使用哪一个Link Key达成共识,所以新设备和Trust Center之间是不需要一个Link Key的传输过程的。

网络中的设备可以使用相同的Link key或不同的Link key,只要新设备和Trust Center之间达成共识即可。

一般来说有四种Link Key,但是我们以前两种为主。后两种目前可能用得很少了,这里仅作简要描述,不做深入探讨。

又被称为the well-known link key,其内容如下:

Default global Trust Center link key (0:15) = 0x5a 0x69 0x67 0x42 0x65 0x65 0x41 0x6c 0x6c 0x69 0x61 0x6e 0x63 0x65 0x30 0x39

其实就是字符串“ ZigBeeAlliance09 ”。这个是在ZigBee 3.0之前就一直在广泛使用的一个相同的默认的密钥,如今得以保留主要是为了保持向后的兼容性。

所有的ZigBee设备都会有这个Default Global Trust Center Link Key。如果没有指定其他的link key的话,Default Global Trust Center Link Key就是设备在入网过程中第一个被尝试使用的密钥。

如果希望能保证和其他的ZigBee 3.0的设备之间互联互通的话,这个密钥时不能改变的。

Install Code并不是一个Key,而是一个Key的输入。Install Code是16字节多项式+ 2字节CRC,再通过固定的算法,计算可以得出Link Key。这种Link Key的传输是由人工来完成的,Install Code的实际应用场景如下图所示:

  • 首先,在产品生产的时候,由厂家在产线随机生成一个Install Code;
  • 然后将这个Install Code烧录到产品里面;
  • 然后把这个Install Code和Eui64打到标签上面,贴在这个产品表面;
  • 在安装的时候,安装人员利用手持设备的扫描功能,从产品标签上扫描获取Install Code和Eui64;
  • 将获取到的Install Code和Eui64告诉Trust Center(一般是协调器);
  • 然后在Trust Center上通过这个Install Code得到Link Ley,让Trust Center知道IEEE地址为Eui64的这个新设备必须使用这个Link Key进行组网;
  • 待入网的新设备这边,从flash中读取出预先烧录的Install Code,然后使用相同的算法得出Link key。

待入网的新设备这边计算得出的Link Key应与Trust Center端的派生Link Key相同。这样,即使消息已加密,他们也可以在应用程序层进行通信。接下来就开始组网的过程了。

An Install Code is a sequence of 16 bytes followed by 2 bytes of CRC. A complete 18 bytes sequence is needed to generate a unique TCLK. The usage of install codes defined in Z3.0 was added to allow a generalized out-of-band key delivery method for network commissioning. It works as follows:

  1. TC gets the install code and the 64-bit IEEE address of the device that will use this install code to join, via any user interface (serial, display and switches, etc.). The install code must be physically provided with the joining device.
  2. TC validates the CRC of the install code introduced. If this is valid then a TCLK entry is added into the TC with the derived key and the address of the corresponding device.
  3. The joining device is instructed to use its install code to generate the corresponding TCLK.
  4. The network is open by any means.
  5. The joining device performs association and the Trust Center delivers the network key encrypted in APS layer with the install code derived key.
  6. After this, the joining device must perform the update of its TCLK as BDB specification requires.

For further details on how to generate the install codes, see the Base Device Specification [7]. This is supported only by R21 or later revisions, so to allow backwards compatibility the application must have a way to attempt joining networks without the usage of Install Codes.

在Distributed Security Network中,没有Trust Center,每个Router都可以分发 network key。

由Router父节点向新入网设备分发的network key,在APS层是使用Distributed Security Global Link Key进行加密的。

如果希望能保证和其他的ZigBee 3.0的设备之间互联互通的话,这个密钥时不能改变的。

Distributed Security Global Link Key (0:15) = 0xd0 0xd1 0xd2 0xd3 0xd4 0xd5 0xd6 0xd7 0xd8 0xd9 0xda 0xdb 0xdc 0xdd 0xde 0xdf

如果新设备是要通过touchlink的方式进行组网的话,就需要使用Touchlink Preconfigured Link Key。

Touchlink Preconfigured Link Key (0:15) = 0xc0 0xc1 0xc2 0xc3 0xc4 0xc5 0xc6 0xc7 0xc8 0xc9 0xca 0xcb 0xcc 0xcd 0xce 0xcf

四、网络层安全

4.1 总览

该密钥称为Network Key。由于它是一种对称加密算法,因此同一ZigBee网络中的所有设备都将使用相同的Network Key。

在网络安全标头中,添加了“帧计数器”的字段和加密信息节点的源Eui64,以防止重发攻击。还添加了密钥序列号以支持Network Key更新。

4.2 逐跳安全

APS层的安全性,是端到端安全性。在APS层,是节点A加密好了之后一直得等到达目的地(节点C)之后才去解密。这中间的加密/解密密钥(Link Key)只要A和C两个知道,B不知道这个密钥,不能去进行加密解密,所以B不关心通信的内容。在这种情况下,我们可以有很多的Link Key,只要通信的双方知道即可。

网络层的安全性,是逐跳安全性。A加密好了在发给C的过程中要经过B,B收到这个报文后要先解密再加密,加密完了之后再发给下一跳。由于所有的中间节点都要参与解密和重新加密的过程,所以所有的节点都必须使用相同的Network Key。

路由器节点需要解密该消息,然后对其进行加密,然后替换安全标头中的信息,再将其发送出去。如果解密失败,该消息将立即被丢弃。

这样的好处是可以尽快丢弃攻击消息。

4.3 Network Key

Network Key是一个16字节的八位位组。通常,它是在网络创建时由协调器随机生成的。当新设备加入网络时,它们必须获得Network Key的副本。

在ZigBee网络中,将Network Key分发给新设备的角色称为Trust Center。有两种典型的安全模型,即集中式安全网络和分布式安全网络。

在集中式安全网络中,只有一个Trust Center,通常是协调器。所有新设备将从协调器获取Network Key。
在分布式安全网络中,没有一个固定的Truster Center,也就是说每个路由器都是一个Trust Center。新设备可以从每个路由器父节点那里获取Network Key。

Distributed Security Model目前主要就是在飞利浦的Touch Link上在使用。ZigBee 3.0中最主要的还是Centralized Security Model的模式。

由于需要将Network Key从一个设备传输到另一台设备,因此在传输过程中需要对密钥值进行加密。此加密在应用程序层中完成。我们稍后再讨论。

 

持续更新中,欢迎关注!

 

【所有相关IDESDK均可从群文件免费获取,也全都是免安装的,解压出来直接就能开始开发】
【配套源码文档软件硬件等资源,请移步技术交流群:拿破仑ZigBee(263671349)】

文章作者: 拿破仑940911
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 拿破仑940911 !
评论
  目录