4、数据加密传输：TLS/SSL协议原理、在DTU中配置TLS、证书链验证、加密套件选择
4.1 为什么DTU必须上TLS？
说实话，我见过太多DTU项目出事了。数据在公网上裸奔，就像把银行卡密码写在纸上贴脑门上。你想想看，DTU采集的可是工业现场的核心数据——PLC指令、仪表读数、甚至远程控制命令。一旦被中间人截获或篡改，后果不堪设想。
我2018年做过一个水厂项目。客户说“我们内网安全，不用加密”。结果呢？运维人员用手机APP远程查看水位数据，数据包在公网绕了一圈，被黑客篡改了水位值，差点导致水泵空转烧毁。从那以后，我所有DTU项目必上TLS。
核心结论：DTU作为工业物联网的“最后一公里”设备，数据加密不是可选项，是必选项。TLS/SSL是目前最成熟、最可靠的传输层加密方案。
4.2 TLS/SSL协议原理——别被术语吓到
说白了，TLS就是给数据通信加了一把“锁”和一把“钥匙”。握手阶段交换密钥，传输阶段加密数据。我习惯把TLS握手分成三步：
- 打招呼：客户端（DTU）告诉服务器“我想建立安全连接，我支持这些加密算法”
- 验明正身：服务器出示数字证书，DTU验证证书是否合法
- 协商密钥：双方用非对称加密交换对称密钥，后续用对称加密传输数据
为什么这么设计？非对称加密慢但安全，对称加密快但不安全。取长补短，先用非对称加密交换对称密钥，再用对称加密传输海量数据。嗯，这个思路在工业通信里很常见。
我的经验：DTU资源有限，握手阶段尽量选择计算量小的加密套件。我曾经在老旧DTU上配了4096位RSA证书，结果每次握手耗时3秒多，现场设备直接超时报警。后来换成ECC证书，握手时间降到200毫秒以内。
4.3 在DTU中配置TLS——手把手教你
不同厂家的DTU配置方式略有差异，但核心步骤一致。我以最常见的基于OpenSSL的DTU为例：
4.3.1 生成证书和密钥
我个人习惯用自签名证书做测试，生产环境必须用CA签发的证书。生成命令如下：
# 生成CA根证书（仅测试用）
openssl req -x509 -newkey rsa:2048 -keyout ca.key -out ca.crt -days 3650 -nodes
# 生成DTU设备证书
openssl req -newkey rsa:2048 -keyout dtu.key -out dtu.csr -nodes
openssl x509 -req -in dtu.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out dtu.crt -days 365注意：生产环境千万别用自签名证书！我曾经有个客户图省事，所有DTU用同一个自签名证书。后来一台DTU被攻破，私钥泄露，整个系统都得重新换证书。教训深刻啊。
4.3.2 DTU端配置示例
以某主流DTU为例，通过AT指令配置TLS：
AT+SSLCFG="cacert",0,"/mnt/flash/ca.crt" // 设置CA证书
AT+SSLCFG="clientcert",0,"/mnt/flash/dtu.crt" // 设置设备证书
AT+SSLCFG="clientkey",0,"/mnt/flash/dtu.key" // 设置私钥
AT+SSLCFG="ciphersuite",0,"0x009C" // 设置加密套件（TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256）
AT+SSLCFG="seclevel",0,2 // 设置安全等级
AT+SSLOPEN=0,"tcp","192.168.1.100",443 // 建立TLS连接你可能会问：为什么加密套件选0x009C？因为这是目前工业场景下安全性和性能平衡最好的选择。后面我会详细讲。
4.4 证书链验证——别跳过这步
证书链验证，说白了就是“查户口”。服务器出示证书，DTU要一路追查到根证书，确认每个环节都合法。
我见过太多人只验证服务器证书，不验证中间CA证书。结果呢？攻击者伪造一个中间CA证书，照样能骗过DTU。2019年某知名工控厂商的漏洞就是这么来的。
正确的验证流程：
- 检查证书有效期（过期证书直接拒绝）
- 验证证书签名（用上级CA的公钥解密签名）
- 检查证书吊销状态（CRL或OCSP）
- 验证证书用途（Extended Key Usage）
避坑指南：我曾经在DTU上只做了第1步和第2步，结果一台被吊销证书的设备依然能连接服务器。后来加上CRL检查才彻底解决。记住：证书吊销检查不能省！
4.5 加密套件选择——别盲目追求最强
加密套件就是一组加密算法的组合。DTU资源有限，选错了要么不安全，要么跑不动。我整理了一个对照表：
| 加密套件 | 密钥交换 | 认证 | 加密 | MAC | 推荐场景 |
|---|---|---|---|---|---|
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | ECDHE | ECDSA | AES-128-GCM | SHA256 | 首选（性能与安全平衡） |
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | ECDHE | RSA | AES-128-GCM | SHA256 | 兼容旧设备 |
| TLS_RSA_WITH_AES_128_CBC_SHA | RSA | RSA | AES-128-CBC | SHA1 | 不推荐（有已知漏洞） |
我个人习惯：新项目一律用第一行。为什么？ECDHE提供前向安全性，ECDSA比RSA计算量小，AES-128-GCM是认证加密模式，SHA256足够安全。你想想看，DTU的CPU主频往往只有几百兆赫兹，选个计算量大的套件，数据采集周期都受影响。
小技巧：如果DTU支持硬件加密引擎，一定要开启。我测试过，开启硬件AES加速后，加密传输速度能提升5-10倍。具体配置看DTU手册，一般通过AT+SSLCFG="hwaccel",1开启。
4.6 实战中的几个坑
最后分享几个我踩过的坑：
- 时间同步问题：证书验证依赖系统时间。DTU刚上电时时间不对，证书验证必失败。解决方案：上电后先NTP同步，再建立TLS连接。
- 内存不足：TLS握手需要分配缓冲区。有些DTU默认缓冲区太小，大证书链会握手失败。我遇到过证书链超过4KB就崩溃的情况，后来手动调整了SSL缓冲区大小。
- 重连机制：TLS会话会超时。DTU断线重连时，别每次都重新握手，用Session Resumption能省不少时间。
好了，这一章就到这里。记住：TLS不是万能药，但不加密的DTU就是裸奔。下一章我们讲数据完整性校验，看看怎么防止数据在传输过程中被篡改。