4、传输层安全：TLS 1.3协议、双向认证(mTLS)、证书链验证、加密套件选择

设备注册时，数据要过网。过网就得加密，这是底线。

很多物联网项目早期只关注业务功能，传输层安全往往被当成「后面再补」的事。结果呢？设备上线第一天就被抓包分析，密钥直接裸奔。我见过不止一次。

这一章我们聚焦传输层。说白了，就是解决两个问题：通信是不是加密的？对方是不是可信的？

4.1 为什么是TLS 1.3？

TLS 1.3 是当前最主流的传输层安全协议版本。相比 1.2，它做了几件狠事：

• 握手次数减少：1-RTT（一次往返）就能完成握手，之前 1.2 要 2-RTT。对于低功耗设备，少一次交互就是省电。
• 移除不安全算法：RSA 密钥交换、CBC 模式、RC4、3DES 等全被砍掉。你没法再配出弱安全组合。
• 前向安全性成为强制：所有密钥交换必须用 (EC)DHE，即使服务器私钥泄露，历史会话也无法被解密。

4.2 双向认证（mTLS）——不只是服务器验你

常规 HTTPS 是客户端验证服务器证书。但在物联网场景里，服务器也需要确认「你是谁」。这就是 mTLS：双方都出示证书，互相验证。

我在一个智能门锁项目里遇到过这种情况：设备注册时只用了单向认证，结果攻击者伪造了一个设备 ID 成功注册，后台以为是合法锁，下发了解锁指令。嗯，从那以后，所有涉及控制指令的设备注册，我都强制上 mTLS。

mTLS 的流程大致如下：

1. 客户端发起连接，请求服务器证书。
2. 服务器发送证书链，客户端验证。
3. 服务器请求客户端证书（CertificateRequest）。
4. 客户端发送自己的证书链，服务器验证。
5. 双方完成密钥协商，建立加密通道。

4.3 证书链验证——别只验叶子证书

很多开发者验证证书时只检查设备证书本身，忽略了证书链。这是大坑。

证书链的结构通常是：根CA → 中间CA → 设备证书。验证时要做三件事：

• 签名验证：每一级证书的签名都由上一级私钥签发，逐级验证直到信任锚。
• 有效期检查：每个证书的当前时间必须在有效期内。
• 吊销状态检查：通过 CRL 或 OCSP 确认证书未被吊销。

我习惯在设备注册阶段做一次完整的证书链验证，并把验证结果（包括证书指纹、颁发者、有效期）记录到注册日志中。这样后续审计时能追溯。

4.4 加密套件选择——不是越多越好

加密套件决定了用什么算法做密钥交换、身份验证、对称加密和消息认证。TLS 1.3 的套件格式简化了，只有 5 个标准套件，但实际部署时你只需要关注其中几个。

套件名称	密钥交换	对称加密	认证	推荐场景
TLS_AES_128_GCM_SHA256	(EC)DHE	AES-128-GCM	SHA-256	通用物联网设备
TLS_AES_256_GCM_SHA384	(EC)DHE	AES-256-GCM	SHA-384	高安全要求设备
TLS_CHACHA20_POLY1305_SHA256	(EC)DHE	ChaCha20-Poly1305	SHA-256	无AES硬件加速的设备

我个人习惯：优先选 TLS_AES_128_GCM_SHA256。性能和安全平衡得好。如果设备有 AES 硬件加速，128 位密钥足够。如果合规要求更高（比如金融级），再上 256 位。

对于没有 AES 硬件加速的低端 MCU，ChaCha20-Poly1305 是更好的选择。它在软件实现上更快，而且抗侧信道攻击能力更强。

4.5 整体架构图

下面这张图展示了设备注册时传输层安全的完整流程，从连接建立到证书验证再到加密通信：

4.6 实践建议

最后，我总结几条在项目中反复验证过的经验：

• 证书有效期别太长：设备证书建议 1-2 年，根CA 5-10 年。太长的有效期意味着吊销困难。
• 使用独立中间CA：根CA离线存储，中间CA用于日常签发。这样即使中间CA泄露，根CA还在，可以吊销并重新签发。
• 注册时做全量验证：不要只验证证书，还要验证设备身份与证书中的 CN/SAN 是否匹配。
• 日志记录要完整：记录 TLS 握手版本、加密套件、证书指纹、验证结果。这些是合规审计的关键证据。