4、通信安全协议：TLS/DTLS在IoT中的应用、MQTT安全最佳实践、CoAP与DTLS、Zigbee/Z-Wave安全机制

通信安全，说白了就是解决两个问题：数据在传输过程中有没有被偷看？有没有被篡改？ 在IoT里，这个问题尤其棘手。你想想看，一个传感器可能只有几KB的内存，跑个完整的TLS握手都费劲。但安全又不能不做。

我这些年经手过的IoT项目，因为通信协议没选对或者配置不当导致的安全事故，少说也有七八起。有的设备被远程控制成了肉鸡，有的传感器数据被中间人篡改导致整个生产线停摆。嗯，这一章咱们就把这些坑一个个填上。

4.1 TLS/DTLS：IoT的传输层保镖

TLS（传输层安全协议）是互联网上最成熟的安全协议之一。HTTPS就是基于它。但在IoT里，TLS有个天生的短板——它依赖TCP。而很多IoT设备用的是UDP，因为省电、延迟低。

这时候DTLS就派上用场了。DTLS是TLS的UDP版本。我个人的习惯是：能用TCP的场景优先用TLS 1.3，必须用UDP的场景才考虑DTLS。为什么？因为DTLS的实现复杂度其实比TLS高，而且很多嵌入式TLS库对DTLS的支持不够完善。

TLS 1.3 vs TLS 1.2：IoT场景下的选择

特性	TLS 1.2	TLS 1.3
握手轮次	2-RTT（完整握手）	1-RTT（完整握手），0-RTT（恢复）
密码套件	支持多种，含不安全算法	仅支持AEAD，强制前向安全
内存占用	较高（状态机复杂）	较低（简化握手）
0-RTT数据	不支持	支持（需防重放）
IoT推荐度	兼容性优先时使用	强烈推荐

我个人强烈建议新项目直接上TLS 1.3。少一次握手，在IoT里可能就是节省了几百毫秒的唤醒时间，对电池寿命影响很大。但要注意0-RTT的重放攻击问题——我见过有人直接把0-RTT用在开关锁指令上，结果攻击者重放了几次，门锁反复开关。嗯，0-RTT只适合幂等操作，比如上报传感器数据。

4.2 MQTT安全最佳实践

MQTT是IoT里最流行的发布/订阅协议。轻量、双向、支持QoS。但它的安全配置，说实话，很多项目做得太糙了。

我审计过不下20个MQTT项目，发现最常见的问题有三个：没有认证、没有加密、权限控制太粗。有的项目甚至直接用默认的mosquitto配置，用户名密码都是空的——这等于把家门钥匙挂在门把手上。

MQTT安全配置清单

1. 强制TLS加密：MQTT over TLS（默认端口8883），不要用1883明文端口。证书双向认证最好，至少也要服务端证书验证。
2. 客户端认证：使用用户名/密码 + TLS客户端证书，或者OAuth2/Token认证。我习惯用证书认证，因为密码容易被硬编码在固件里。
3. 细粒度ACL：每个设备只能发布/订阅自己的主题。比如设备ID为sensor_001，只能发布到devices/sensor_001/data，不能订阅其他设备的话题。
4. Payload加密：即使TLS加密了传输层，我仍然建议对敏感payload做应用层加密。防止Broker被攻破后数据泄露。
5. 限制Last Will和Testament：LWT消息可能被恶意客户端利用来伪造设备离线状态。建议对LWT主题也做ACL控制。

MQTT 5.0的新安全特性

MQTT 5.0相比3.1.1，增加了一些有用的安全特性。比如增强认证（支持SCRAM、Kerberos等）、用户属性（可以携带额外的安全上下文）、会话过期（防止会话劫持）。如果你的Broker和客户端都支持5.0，我建议升级。

4.3 CoAP与DTLS

CoAP（受限应用协议）是HTTP的UDP版本，专为资源受限设备设计。它本身不提供安全机制，安全全靠DTLS。

CoAP的安全模式有四种：

安全模式	描述	适用场景
NoSec	无安全保护，明文传输	内网非敏感数据，测试环境
PreSharedKey	使用预共享密钥的DTLS	资源极度受限设备，一对一通信
RawPublicKey	使用非对称密钥对的DTLS	中等资源设备，需要身份认证
Certificate	使用X.509证书的DTLS	高安全需求，支持PKI的场景

我个人在项目里用得最多的是PreSharedKey模式。为什么？因为很多MCU跑不动证书验证的DTLS握手。但PSK有个问题——密钥分发和管理。你想想看，几千个设备，每个设备一个不同的PSK，怎么安全地烧录进去？

CoAP的Observe模式安全

CoAP支持Observe模式，让客户端订阅资源变化。这个模式下的DTLS会话管理要特别注意。我见过一个案例：设备进入深度睡眠后DTLS会话超时，醒来后重新握手，但Observe订阅关系丢失了。解决方案是在应用层维护一个订阅状态表，设备醒来后主动重新订阅。

4.4 Zigbee/Z-Wave安全机制

Zigbee和Z-Wave是智能家居领域的两大短距离无线协议。它们的安全机制是协议栈内置的，但配置不当照样出问题。

Zigbee安全架构

Zigbee的安全分两层：网络层安全（NWK）和应用层安全（APS）。NWK层负责帧加密和完整性校验，APS层负责端到端加密和密钥建立。

• NWK加密：使用AES-CCM*，密钥长度128位。所有网络帧都加密，包括路由发现和信标。
• APS加密：使用AES-CCM*，提供端到端安全。两个设备之间的通信，中间节点无法解密。
• Trust Center：Zigbee网络的核心安全节点，负责设备入网认证和密钥分发。

Zigbee 3.0引入了Install Code机制。设备出厂时带有一个唯一的安装码，用户通过扫描二维码或输入字符串的方式把安装码告诉协调器。协调器用安装码派生出Link Key，设备入网时用这个Link Key进行安全认证。

Z-Wave安全机制

Z-Wave的安全机制经历了几个版本。S0（Security 0）已经被证明不安全，S2（Security 2）是目前推荐的标准。

安全版本	加密算法	认证方式	状态
S0	AES-128-ECB（有缺陷）	单次握手	不推荐，已弃用
S2	AES-128-CCM	双向认证（Elliptic Curve Diffie-Hellman）	推荐使用

S2最大的改进是引入了基于椭圆曲线的密钥协商（ECDH）。设备入网时，通过ECDH协商出一个会话密钥，即使通信被监听，攻击者也无法推导出密钥。而且S2支持多种认证方式：

• DSK（Device Specific Key）：设备上贴有一个5位数字的DSK，用户入网时输入前5位，设备验证后5位。这是最常见的S2认证方式。
• Out-of-Band（OOB）：通过NFC、二维码等方式传输DSK，用户体验更好。

我个人的建议是：新项目一律使用Z-Wave S2。S0的ECB模式加密已经被证明可以被破解，而且S0没有双向认证，攻击者可以伪造设备入网。

Zigbee vs Z-Wave：安全对比

维度	Zigbee 3.0	Z-Wave S2
加密算法	AES-CCM* 128位	AES-CCM 128位
密钥协商	基于Trust Center分发	ECDH（椭圆曲线）
入网认证	Install Code / Touchlink	DSK / OOB
端到端加密	支持（APS层）	支持（S2端到端模式）
防重放	帧计数器（32位）	帧计数器（32位）
已知漏洞	极少（3.0版本）	极少（S2版本）

说实话，这两个协议在安全层面已经做得相当不错了。真正出问题的，往往是实现层面的错误——比如密钥存储不安全、固件更新不验证签名、或者像我前面说的，所有设备用同一个密钥。