OpenThread项目中密钥轮换机制的安全隐患分析

背景介绍

在物联网通信协议OpenThread的实现中，密钥轮换是一个重要的安全机制。它允许网络定期更换加密密钥，以增强通信安全性。然而，在RCP(Radio Co-Processor)架构下，当前的密钥轮换实现存在一个潜在的安全隐患，可能导致帧计数器使用错误，进而影响通信可靠性。

问题本质

在RCP架构中，密钥轮换过程分为两个独立步骤：

1. 首先更新密钥数据和索引(通过SPINEL_PROP_RCP_MAC_KEY属性)
2. 然后更新帧计数器(通过SPINEL_PROP_RCP_MAC_FRAME_COUNTER属性)

这种两步操作存在一个时间窗口，在此期间如果RCP需要发送帧或增强确认(enhanced ACK)，可能会出现以下情况：

• 密钥ID已更新为新值
• 但帧计数器尚未重置
• 导致发送的帧使用新密钥ID但旧帧计数器值

这种不一致性会导致后续使用新帧计数器发送的帧被接收方拒绝，因为它们的帧计数器值比之前收到的帧更小，违反了安全协议中帧计数器必须单调递增的原则。

技术影响

这种问题不仅存在于RCP架构中，在支持OT_RADIO_CAPS_TRANSMIT_SEC功能的无线电设备上也可能出现类似情况。当密钥ID更新后，在帧计数器被清除前，如果无线电从中断服务程序(ISR)上下文接收并准备发送增强ACK，同样可能产生不一致的密钥ID和帧计数器组合。

解决方案分析

针对这一问题，技术专家提出了几种可能的解决方案：

1. 无线电平台强制重置方案：

   • 要求otPlatRadioSetMacKey()调用时自动重置安全帧计数器
   • 优点：逻辑清晰，从根本上解决问题
   • 缺点：需要所有无线电平台厂商更新实现

2. 调用顺序调整方案：

   • 在SubMac::SetMacKey()中先显式调用重置帧计数器的API
   • 再调用otPlatRadioSetMacKey()
   • 优点：实现简单
   • 缺点：可能存在极短时间窗口

3. 原子操作方案：

   • 创建新的spinel命令同时更新密钥和帧计数器
   • 优点：最安全可靠
   • 缺点：实现复杂，缺乏向后兼容性

最佳实践建议

经过技术评估，推荐采用组合方案：

1. 修改SubMac::SetMacKey()实现，在更新密钥ID前先重置帧计数器
2. 同时要求无线电平台在otPlatRadioSetMacKey()实现中自动重置帧计数器

这种双重保障机制可以最大限度地降低风险，即使无线电平台未及时更新，也能通过上层调用的顺序调整保证安全性。对于新开发的无线电平台，应严格遵循在密钥更新时自动重置帧计数器的规范。

总结

OpenThread项目中的这一发现提醒我们，在安全协议实现中，即使是看似简单的两步操作也可能引入安全隐患。密钥管理和帧计数器的同步是无线通信安全的基础，需要特别关注其原子性和一致性。通过这次问题的分析和解决，OpenThread的安全机制得到了进一步加固，为物联网设备提供了更可靠的通信保障。