4. 加密传输通道：TLS/DTLS协议、证书管理、密钥协商、安全通道建立

好，咱们进入第四章节。前面聊了固件签名和哈希校验，那都是针对固件包本身的保护。但还有个关键问题：固件在传输过程中，会不会被窃听、篡改？

说白了，你从云端拉固件，中间要经过多少跳板？CDN、运营商、路由器……任何一个环节都可能出问题。我早年做智能门锁OTA时，就遇到过固件在运营商链路上被注入广告脚本的案例——虽然没改固件逻辑，但设备多了个弹窗，用户体验直接崩了。

所以，加密传输通道是OTA安全的基石。今天咱们就聊聊TLS/DTLS、证书管理、密钥协商这些硬核内容。

4.1 为什么需要加密通道？

你想想看，如果固件明文传输，攻击者可以：

• 窃听：拿到固件内容，分析漏洞、提取密钥。
• 篡改：在传输过程中修改固件，植入后门。
• 重放：截获旧固件，让设备降级到有漏洞的版本。

加密通道能同时解决这三个问题。它提供：

• 机密性：数据加密，窃听者看不懂。
• 完整性：数据签名，篡改会被发现。
• 身份认证：确认你连接的是真正的OTA服务器，不是钓鱼站点。

4.2 TLS vs DTLS：选哪个？

这里有个常见困惑：TLS和DTLS到底啥区别？我简单解释下。

特性	TLS	DTLS
传输层	TCP（可靠、有序）	UDP（不可靠、无序）
延迟	握手延迟较高（2-RTT）	握手延迟较低（1-RTT）
适用场景	Wi-Fi设备、网关、云端	低功耗蓝牙、Zigbee、LoRa
重传机制	依赖TCP	自带超时重传
资源消耗	较高（内存、CPU）	较低（适合MCU）

我个人习惯：能跑TCP的设备，优先用TLS。因为TLS生态成熟，库多，调试工具也多。但如果你做的是电池供电的传感器节点，用UDP更省电，那就得上DTLS。

4.3 证书管理：你的信任锚点

加密通道的核心是证书。没有证书，你没法验证对方身份。我见过太多设备因为证书管理混乱，导致中间人攻击成功。

4.3.1 证书链结构

典型的OTA场景，证书链长这样：

根证书（自签名，预置在设备中）
  └── 中间证书（由根证书签发）
        └── 设备证书（由中间证书签发，用于TLS握手）

设备里只存根证书。服务器发来证书链，设备用根证书验证中间证书，再用中间证书验证设备证书。这样即使设备证书泄露，也不会影响整个PKI体系。

4.3.2 证书格式与存储

嵌入式设备上，证书通常用DER或PEM格式。我建议：

• DER：二进制，体积小，适合存储空间有限的MCU。
• PEM：Base64文本，可读性好，适合调试阶段。

存储位置也很关键：

• 安全元件（SE）：最安全，硬件隔离，防物理攻击。
• 加密Flash：次选，需要配合安全启动和加密存储。
• 普通Flash：不推荐，容易被读取。

4.4 密钥协商：如何安全地交换密钥？

TLS握手过程中，最关键的一步是密钥协商。常用的算法有：

• RSA密钥交换：客户端用服务器公钥加密预主密钥，服务器用私钥解密。简单，但不提供前向安全性。
• ECDHE（椭圆曲线Diffie-Hellman Ephemeral）：双方各自生成临时密钥对，通过椭圆曲线计算共享密钥。提供前向安全性，即使服务器私钥泄露，历史会话也不受影响。

我强烈建议：OTA场景必须用ECDHE。为什么？因为固件升级涉及长期有效的设备，如果私钥泄露，RSA会暴露所有历史固件传输内容。而ECDHE每次握手都用临时密钥，私钥泄露只影响未来会话。

握手流程大致如下：

1. ClientHello：设备发送支持的密码套件、随机数。
2. ServerHello：服务器选择密码套件，发送证书和ECDHE公钥。
3. 证书验证：设备验证服务器证书链。
4. 密钥计算：双方用ECDHE算出共享密钥，再派生会话密钥。
5. Finished：双方确认握手完成，开始加密通信。

4.5 安全通道建立：从握手到数据传输

握手完成后，安全通道就建立了。但这里有个容易被忽略的细节：会话恢复。

OTA升级通常需要多次传输（比如分块下载）。如果每次都要完整握手，延迟和资源消耗都很大。TLS/DTLS支持会话恢复机制：

• Session ID：服务器保存会话状态，客户端在后续连接中带上Session ID，直接恢复。
• Session Ticket：服务器把会话状态加密后发给客户端，客户端在后续连接中出示Ticket，无需服务器保存状态。

我个人更倾向Session Ticket。因为服务器不需要维护会话表，适合大规模OTA场景。但要注意：Ticket的加密密钥必须妥善保管，否则攻击者可以解密Ticket，恢复会话。

下面这张图展示了完整的TLS握手与数据传输流程：

4.6 实战建议：嵌入式TLS/DTLS优化

嵌入式设备资源有限，跑TLS/DTLS需要一些优化技巧：

• 密码套件选择：优先用TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256。椭圆曲线用P-256，平衡安全性和性能。
• 证书压缩：去掉证书链中不必要的中间证书，或者用证书压缩扩展（如Cached Information Extension）。
• 握手缓存：把握手过程中的中间状态缓存到外部Flash，减少内存占用。
• 硬件加速：如果MCU有硬件加密引擎（如AES、SHA、ECC），一定要用。我在一个项目里，启用硬件加速后，TLS握手时间从3秒降到0.5秒。

4.7 常见问题与避坑

最后，分享几个我踩过的坑：

• 时间同步问题：TLS证书验证依赖系统时间。如果设备没有RTC，或者时间不准，证书验证会失败。解决方案：在设备出厂时写入一个近似时间，或者用NTP同步后再握手。
• MTU问题：DTLS基于UDP，如果证书链太大，可能超过UDP的MTU（1500字节），导致分片和重组问题。我建议把证书链控制在1200字节以内。
• 重连风暴：大量设备同时OTA，服务器可能扛不住TLS握手。可以用预共享密钥（PSK）模式，或者错峰升级。