3、通信安全基线：TLS/DTLS协议配置、证书管理、双向认证、加密套件选择
通信安全，说白了就是解决两个问题：数据在传输过程中有没有被偷看？有没有被篡改？ 在物联网场景下，设备资源受限、网络环境复杂，这两个问题尤其棘手。
我刚开始做物联网安全那会儿，总觉得给设备加上TLS就万事大吉了。后来在一次车联网项目里，发现某款T-Box虽然启用了TLS，但用的是自签名证书，而且没做证书校验。结果呢？中间人攻击一打一个准。嗯，从那以后我再也不敢轻视通信基线的每一个细节了。
核心原则：物联网通信安全不是"有"或"没有"的问题，而是"配置是否正确"的问题。一个配置不当的TLS，比裸奔更危险——因为它给你一种虚假的安全感。
3.1 协议选型：TLS vs DTLS
先解决一个基础问题：用TLS还是DTLS？
TCP场景下用TLS，UDP场景下用DTLS。这个选择本身不难，难的是很多人不知道DTLS的存在，或者觉得"反正都是加密，用TLS准没错"。你想想看，一个基于CoAP/UDP的设备，硬要跑TLS，那得额外维护TCP连接，功耗和内存都扛不住。
| 对比维度 | TLS 1.2/1.3 | DTLS 1.2/1.3 |
|---|---|---|
| 传输层依赖 | TCP（可靠传输） | UDP（不可靠传输） |
| 握手开销 | 2-RTT（TLS 1.3为1-RTT） | 3-RTT（DTLS 1.3为2-RTT） |
| 适用协议 | HTTP/MQTT/AMQP | CoAP/DDS/一些自定义UDP协议 |
| 资源消耗 | 较高（需维护TCP状态） | 较低（无连接状态） |
| 丢包处理 | TCP重传机制 | 应用层自行处理重传 |
我的建议：如果设备支持TCP且对时延不敏感，优先选TLS 1.3。如果必须走UDP（比如低功耗传感器、音视频流），选DTLS 1.2以上版本。DTLS 1.3虽然草案已定，但生态还不够成熟，我建议再等一等。
3.2 加密套件选择：别再用那些"过时货"了
加密套件这东西，很多人直接复制网上的示例代码，或者用OpenSSL默认配置。我见过一个智能门锁项目，用的竟然是TLS_RSA_WITH_RC4_128_SHA——RC4啊，2003年就被标记为不安全了。
为什么会这样？因为很多芯片厂商提供的SDK里，默认配置就是这些老古董。他们图兼容性，但安全就顾不上了。
我个人习惯，在物联网设备上只推荐以下加密套件：
- TLS 1.3场景：TLS_AES_128_GCM_SHA256（首选）、TLS_AES_256_GCM_SHA384（资源允许时）
- TLS 1.2场景：TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256（首选）、TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- DTLS场景：与TLS 1.2保持一致，优先使用ECDHE密钥交换
避坑指南：我曾经在一个NB-IoT项目中，为了省流量选了TLS_PSK_WITH_AES_128_CCM_8。结果发现某些运营商的网络网关不支持这个套件，导致大量设备连接失败。所以，加密套件的选择不仅要考虑安全性，还要考虑平台兼容性。建议在选型阶段就与云平台、模组厂商确认支持的套件列表。
另外，绝对不要碰的套件列表：
- 所有使用RC4、DES、3DES的套件
- 所有使用CBC模式（如AES_128_CBC）的套件——除非你确定能处理好Padding Oracle攻击
- 所有使用RSA密钥交换的套件（不支持前向安全性）
- 所有使用SHA-1的套件
3.3 证书管理：从签发到吊销的全生命周期
证书管理是物联网通信安全里最容易被忽视的环节。很多团队把证书当成"一次性用品"——烧录进去就不管了。但证书是有生命周期的，而且物联网设备的证书管理比Web场景复杂得多。
我参与过一个智慧城市项目，涉及10万+个路灯控制器。每台设备出厂时烧录了有效期5年的证书。结果第3年发现证书私钥被提取了——因为用的是软件密钥存储。你想想看，10万台设备，要全部召回更新证书，那成本...嗯，不提了。
3.3.1 证书层级结构
物联网场景下，我建议采用三级证书体系：
- 根CA（Root CA）：离线存储，只用于签发中间CA。私钥必须放在硬件安全模块（HSM）里。
- 中间CA（Intermediate CA）：用于签发设备证书和平台证书。可以按业务线、产品线、区域拆分多个中间CA。
- 终端实体证书（End-Entity Certificate）：设备证书、平台证书、服务证书。
关键点：千万不要直接用根CA签发设备证书。一旦根CA私钥泄露，整个信任体系就崩塌了。用中间CA做隔离，即使某个中间CA出问题，也只影响它签发的那个子集。
3.3.2 证书存储与保护
设备端的私钥存储，我按安全等级排序：
| 安全等级 | 存储方式 | 适用场景 | 成本 |
|---|---|---|---|
| 高 | 独立SE（安全芯片）或TEE | 车联网、金融支付、医疗设备 | 高 |
| 中 | SoC内置安全区（如ARM TrustZone） | 智能家居、工业网关 | 中 |
| 低 | 文件系统+加密存储 | 低价值传感器、一次性设备 | 低 |
我的经验：如果预算允许，尽量用独立SE。我在一个智能门锁项目里用了TrustZone方案，结果发现某个芯片厂商的TEE实现有漏洞，私钥还是能被读出来。后来换了SE芯片，虽然成本多了2块钱，但再也没出过问题。这2块钱，买的是整个产品线的信誉。
3.3.3 证书吊销
证书吊销是物联网的"老大难"问题。Web场景可以用CRL或OCSP，但物联网设备可能几个月才上线一次，OCSP的实时性根本保证不了。
我推荐的做法是：
- 短有效期证书：把证书有效期设为30天或更短，设备每次上线时通过OTA更新证书。这样即使私钥泄露，影响范围也有限。
- 黑名单机制：在平台侧维护设备黑名单，设备连接时先检查是否在黑名单中。这个比证书吊销快得多。
- 混合方案：短有效期证书+黑名单+CRL（作为兜底）。
3.4 双向认证：不只是"验设备"
很多人理解的TLS认证是"客户端验证服务器证书"，这在Web场景下够用了。但在物联网场景下，服务器也必须验证客户端证书——这就是双向认证（mTLS）。
为什么？因为物联网设备数量巨大，攻击者很容易拿到一台设备，然后冒充它接入平台。如果没有双向认证，攻击者可以伪造任意设备ID，把整个平台的数据搅得一团糟。
我记得有个智能电表项目，初期只做了单向认证。结果测试阶段就发现，有人用树莓派模拟电表往平台发假数据。后来改成双向认证，这个问题才彻底解决。
3.4.1 双向认证的握手流程
我画了一张图，把双向认证的流程梳理了一下：
3.4.2 双向认证的配置要点
在代码层面，双向认证的配置并不复杂，但有几个容易踩的坑：
- 证书链验证：不仅要验证设备证书本身，还要验证整条证书链直到根CA。我见过有人只验证了设备证书，没验证中间CA，结果攻击者用自己签的证书也能通过。
- CN/SAN校验：设备证书的Common Name或Subject Alternative Name必须与设备ID绑定。平台侧要校验这个绑定关系，防止证书被复用。
- 会话复用：物联网设备频繁重连时，会话复用能大幅减少握手开销。但要注意，会话复用期间不会重新验证证书。如果设备证书被吊销了，会话复用期间平台可能还不知道。建议设置较短的会话超时时间。
避坑指南：我曾经在一个项目中，设备端用了mbedTLS，平台端用了OpenSSL。结果发现mbedTLS默认不发送CertificateRequest的响应——它以为服务端没要求证书。折腾了两天才发现，是mbedTLS的配置项MBEDTLS_SSL_VERIFY_REQUIRED没开。所以，不同TLS库的默认行为差异很大，一定要在集成测试中验证双向认证的全流程。
3.5 协议配置的"硬指标"
最后，我整理了一份通信安全基线的检查清单。每次做项目评审时，我都会拿这份清单过一遍：
| 检查项 | 要求 | 备注 |
|---|---|---|
| TLS版本 | TLS 1.2 或 TLS 1.3 | 禁止TLS 1.0/1.1、SSL全系列 |
| 加密套件 | ECDHE + AES-GCM + SHA256 | 禁止RSA密钥交换、CBC模式、RC4/DES |
| 证书有效期 | 设备证书≤1年，平台证书≤3年 | 建议设备证书30天轮换 |
| 密钥长度 | RSA≥2048位，ECC≥256位 | 推荐ECC，性能更好 |
| 双向认证 | 必须启用 | 平台必须验证设备证书 |
| 证书吊销 | 支持CRL或黑名单 | 短有效期证书可降低吊销压力 |
| 私钥保护 | 硬件安全模块或TEE | 至少使用加密文件系统 |
| 会话超时 | ≤24小时 | 防止会话劫持 |
最后说一句：通信安全基线不是"配完就完"的事。我建议每个季度做一次TLS配置审计，用工具（比如testssl.sh）扫描一下设备和服务端的TLS配置。很多问题都是在版本升级、配置迁移时引入的。保持警惕，比什么都重要。