MCU上的硬件AES CCM加密，是否采用硬件防止重放攻击？

[物联网神教]

Zigbee采用AES加密，我把一帧空中抓到的控制命令，再次发给目标设备，目标设备有MAC层的ACK，说明目标设备收到控制包了，但是没有执行对应动作，说明目标设备具有防止重放攻击的功能。

但是AES防止重放攻击的原理是什么？我只看到SDK里面的AES CCM的加密/解密接口是这样的：
AESCCM_Encrypt( uint8_t *key, uint8_t *input, uint16_t inputLen, uint8_t *outPut, uint8_t *nonce, uint8_t nonceLen, uint8_t *MIC, uint8_t MIC_len);

AESCCM_Decrypt( uint8_t *key, uint8_t *input, uint16_t inputLen, uint8_t *outPut, uint8_t *nonce, uint8_t nonceLen, uint8_t *MIC, uint8_t MIC_len);

我对协议栈仿真，看到协议栈每次加密的时候都填入了13字节的nonce, nonce由Zigbee的8字节IEEE地址，4字节的counter，1字节的常数组成。加密后除了密文，还会产生4字节的MIC。加密后的无线数据帧，空中数据包除了有密文，还会带上nonce和MIC。

请问这个MIC可以用于防重放攻击么？组成Nonce中的counter是每发一帧就会累加的。而且Zigbee设备每次掉电时的counter必须小于下次上电时的counter，也就是说Zigbee设备每次上电的时候，counter的值要初始化成一个比上次掉电时较大的值，否则就会出现发出去的报文，对方不能识别，但是对方也复位一次就好了。

但是如果Zigbee设备是靠记录counter来判断重放，那么一个Zigbee设备要开辟多大的空间来保存已经失效的counter，而且每个counter还要对应一个IEEE地址。

[weixin_43964245]

MIC是AES加密里面的东西，由AES-32，64，128对应不同的MIC长度，你不用研究它。 重放攻击的防护就是依靠这个Counter判断，开启NV_restore与加密之后，每次上电都会在上一次的基础上对这个Counter增加一点； 存储空间应该是在设备的neighborTable里，其中包括周边设备的长短地址和linkInfo，linkInfo里面包含密钥序列号和上一次的Counter；每个设备实际上只需要确认传到自己的数据是网络中的合法数据就足够了，不需要保存网络中所有节点的信息。

[物联网神教]

引用 1 楼 月月鸟， 的回复:

MIC是AES加密里面的东西，由AES-32，64，128对应不同的MIC长度，你不用研究它。 重放攻击的防护就是依靠这个Counter判断，开启NV_restore与加密之后，每次上电都会在上一次的基础上对这个Counter增加一点； 存储空间应该是在设备的neighborTable里，其中包括周边设备的长短地址和linkInfo，linkInfo里面包含密钥序列号和上一次的Counter；每个设备实际上只需要确认传到自己的数据是网络中的合法数据就足够了，不需要保存网络中所有节点的信息。

neighborTable，router table长期不通信的设备，应该会被清理掉。而且可能是记录MAC地址+counter。我之前怀疑过由counter+MAC地址组成的nonce会在硬件寄存器中生成特殊的校验值，nonce被重复使用的话校验值会出错。

[物联网神教]

引用 3 楼 月月鸟， 的回复:

只有在长期不通信，且表被占满了之后才会替换，而且之后还可以重新由nwkLink建立连接； 要不你试试在运行过程中直接修改neighborTable里面linkInfo的Counter，看看还能否进行通信？

好几个表里面都有linkInfo_t，里面有个uin32的inFrmCntr，看来就是这个counter

[物联网神教]

引用 3 楼 月月鸟， 的回复:

只有在长期不通信，且表被占满了之后才会替换，而且之后还可以重新由nwkLink建立连接； 要不你试试在运行过程中直接修改neighborTable里面linkInfo的Counter，看看还能否进行通信？

想明白了，一个设备只需要记录associate list和neighbor table的MAC地址和counter就够了，NWK Key的解密只是对能够直接通信的设备进行解密。

[物联网神教]

引用 3 楼 月月鸟， 的回复:

只有在长期不通信，且表被占满了之后才会替换，而且之后还可以重新由nwkLink建立连接； 要不你试试在运行过程中直接修改neighborTable里面linkInfo的Counter，看看还能否进行通信？

如果是door lock和door lock controlor这样的关系，还有应该在应用层加上非对称加密才行。Zigbee 3.0的安全机制可能会不够用。我的想法是door lock会在不同时间随机产生不同的nonce，door lock controlor每次开锁前需要获取door lock的nonce，而AES-Key只有door lock和door lock controlor知道，网关都不知道，采用物理接触的方式让door lock和door lock controlor拥有相同的key

[weixin_43964245]

只有在长期不通信，且表被占满了之后才会替换，而且之后还可以重新由nwkLink建立连接； 要不你试试在运行过程中直接修改neighborTable里面linkInfo的Counter，看看还能否进行通信？

[weixin_43964245]

引用 6 楼 物联网神教 的回复:

[quote=引用 3 楼 月月鸟， 的回复:] 只有在长期不通信，且表被占满了之后才会替换，而且之后还可以重新由nwkLink建立连接； 要不你试试在运行过程中直接修改neighborTable里面linkInfo的Counter，看看还能否进行通信？

如果是door lock和door lock controlor这样的关系，还有应该在应用层加上非对称加密才行。Zigbee 3.0的安全机制可能会不够用。我的想法是door lock会在不同时间随机产生不同的nonce，door lock controlor每次开锁前需要获取door lock的nonce，而AES-Key只有door lock和door lock controlor知道，网关都不知道，采用物理接触的方式让door lock和door lock controlor拥有相同的key[/quote] 这个在应用层生成一段随机序列号，然后做比对不是就可以实现了吗，

[物联网神教]

引用 7 楼 月月鸟， 的回复:

[quote=引用 6 楼 物联网神教 的回复:] [quote=引用 3 楼 月月鸟， 的回复:] 只有在长期不通信，且表被占满了之后才会替换，而且之后还可以重新由nwkLink建立连接； 要不你试试在运行过程中直接修改neighborTable里面linkInfo的Counter，看看还能否进行通信？

如果是door lock和door lock controlor这样的关系，还有应该在应用层加上非对称加密才行。Zigbee 3.0的安全机制可能会不够用。我的想法是door lock会在不同时间随机产生不同的nonce，door lock controlor每次开锁前需要获取door lock的nonce，而AES-Key只有door lock和door lock controlor知道，网关都不知道，采用物理接触的方式让door lock和door lock controlor拥有相同的key[/quote] 这个在应用层生成一段随机序列号，然后做比对不是就可以实现了吗，[/quote] 这个是肯定需要的，但是还是要对序列号进行加密才行啊。 另外还有zigbee自动售货柜的，格子太多，每个格子一个Endpoint不显示，可以每个格子一个Attribute（cluster为独立的manufacturer code使能型）。格子的Attribute可以是一个随机系列号，每次补货的时候更新随机序列号。应用层的加密协议才能知道随机序号对应的开锁密钥。这种设计还有一个好处就是防止重复扣费。中途有消息丢包导致无法开格子，那么原先的随机序号就一直存在。