4.4 DTLS安全与受限节点落地
4.4 DTLS 安全与受限节点落地
本节摘要：CoAP 跑在 UDP 上，TLS 套不上，于是有了 DTLS——把 TLS 的握手搬到数据报的加密裸子。本节讲 DTLS 与 TLS 的差别、四飞握手、受限节点上的安全取舍（证书太重？用 PSK/OSCORE），最后落到传感器网络、智能楼宇等真实场景。
给 MQTT 套锁用 TLS 就行，但 CoAP 坐的是 UDP——TLS 假定有可信流式传输，没法直接套。于是 CoAP 的安全底座叫 DTLS（数据报传输层安全），标准端口是 5684（coaps）；明文端口 5683（coap）。
DTLS 与 TLS 差在哪
迪递的本质，是把 TLS 那套面向字节流的握手，改造成能在"丢包、乱序的数据报"上工作的版本。最直观的三点差异：
- 防重放：DTLS 给每条记录加序号（epoch + sequence），把 TLS 的报文序号防线延伸到无连接世界。
- 显式长度：每条 DTLS 记录自带长度字段，解决 UDP 分片后接收端不知道"一条多长"的问题。
- 可重传的握手：握手阶段的每个 flight 都能重发，因为 UDP 不保证送达。
DTLS 四飞握手
DTLS 握手持恒四飞（四个 flight），把"换密钥"与"确认密钥"来回一次谈妥：
相比 TLS 的连接流式握手，DTLS 每一步都可独立重传，代价是握手报文多、延迟略高——受限节点上通常只在"建立会话"和"重配"时才走，日常通信复用已协商的密钥。
受限节点上的安全取舍
全量 DTLS 证书 + 双向认证在 8-Bit 单片机上是奢侈品：证书解析、非对称加密都要内存。于是工程上按设备能力分三档：
| 安全档位 | 机制 | 适用设备 |
|---|---|---|
| 轻量子集 | PSK 预共享密钥（对称，无证书） | 极小内存传感器 |
| 标准 DTLS | 证书 + 双向认证 | 网关、能力较强的节点 |
| 端到端对象安全 | OSCORE（应用层逐对象加密） | 需端到端、中继不可信 |
PSK 走的就是**"别上证书、用共享密钥"**的路子，很多受限网络选它换来极低开销。真正的安全根本在于：密钥别硬编码、要便于轮换、设备要有唯一身份。
⚠️ 常见坑：把证书方案硬塞进小内存设备，很容易在握手阶段就把内存打爆、或功耗烧穿电池。先按设备内存分档选机制，再谈加密深度，别一步到位全上最强。
DTLS 为什么顺手要起 cookie 机制
DTLS 的握手里藏着一步 TLS 没有的"反射防护"：因为 UDP 无连接且好伪造源地址，攻击者可以拿别人的 IP 连续播 ClientHello 把服务器 CPU 打满（放大攻击）。DTLS 用 HelloVerify 的 cookie 交换回敬：服务器先发一个 cookie 给客户端，客户端必须原样带回才继续握手，从而确认"发起者真的能收到回包"、无法完全伪造。这一设计在公网 CoAP 部署里极其关键，也是 DTLS 相比"硬套 TLS"必须多出的一环。
从 PSK 到 OCSORE 的取舍再拆一层
受限节点的安全档位，实质是"内存预算 vs 信任模型"的对赌。补一张更细的对照帮你实际选：
| 方案 | 额外开销 | 信任边界 | 最怕的失败模式 |
|---|---|---|---|
| PSK 预共享密钥 | 最低（对称加密） | 两端共享同一把钥匙 | 密钥泄露/难轮换 |
| 证书 DTLS | 较高（解析 + 非对称） | 以证书链背书身份 | 内存/握手功耗超负载 |
| OSCORE 端到端 | 应用层逐对象 | 中继可见密文仍是对象加密 | 需双方都支持对象加密 |
实际落地时，很多"看着能力够"的设备最终仍选 PSK，往往不是因为算力不够，而是证书生命周期（到期、吊销、轮换）在离线设备上太难维护——这与 3.5 里 MQTT 证书轮换是同一种现实负担。所以决策时要同时问：内存够不够、证书能不能方便轮换、中继可不可信。三者交叉，答案往往自然浮现。
用一次"coaps 接入"做最小验收
不确定 DTLS 到底配没配对，用带 coaps 的客户端连一次即知。方向上是"证书校验 + 握手 + 一次安全 GET"：
# 设备端接入示意（聚焦安全链路，细节依库而定） coaps://[fd00::6]/temperature # 走 5684 coaps 端口 # 握手成功后再发一次受保护的 GET 应能拿到 2.05 Content # 若返回握手失败/证书错误, 优先查 CA 信任、凭证是否匹配
能完成"coaps 握手 + 安全 GET"，说明加密链路已通；此时再看抓包，载荷应是密文而非可读 JSON。把"明文能读、coaps 后读不懂"作为验收信号，最容易确认 DTLS 是否真正生效。
落地场景：CoAP 不辜负哪里
CoAP + DTLS 的组合最常见于"有 IP、但设备很省电"的世界：
- 传感器网络：墙上的温湿度、空气质量传感器，让网关以 GET/Observe 拉取，不常设长连接。
- 智能楼宇：灯、开关、HVAC 端点以资源方式暴露，控制面板用统一接口一并管理。
- 低功耗设备通信：需要 REST 化的设备直连，又不愿背 MQTT Broker 的登记成本。
一座楼宇的例子最能说明组合拳：灯光控制器暴露 coap://floor3/lights/07/state，业主运维面板用 Observe 订阅亮度变化、用 PUT 调亮度，DTLS 保证这条链路不被邻居稀听——CoAP 的省电与 DTLS 的机密性正好互补。
选型提醒
DTLS 虽强，但它在受限节点上不等于"免费"。若设备内存真的小到撑不住 DTLS 完整握手，退一步用 PSK 或改 OSCORE 往往更合理。安全设计要在"机密性 "与"装得下、耗得起"之间做工程平衡，而不是无脑堆最强。
💡 关键直觉：CoAP 的安全核心是"给 UDP 世界补一块能让双方信任的踏板"——DTLS/PSK/OSCORE 三选一，本质上是在内存预算里给"信任"定价。
本节要点回顾
- 要点一：DTLS = 给 UDP 版 TLS，标准端口 5684（coaps），抗重放、握手可重传。
- 要点二：DTLS 四飞握手，端到端协商会话密钥，日常复用不重走。
- 要点三：受限节点按内存分档——PSK 最轻、证书 DTLS、端到端用 OSCORE。
- 要点四：CoAP 场景以传感、楼宇、低功耗直连为主，省电与机密性互补。
- 要点五：在"机密性"与"装得下耗得起"之间做主动取舍，不无脑拉满。
CoAP 四节讲完，第 5 章跳向一个完全不同次元：没有 IP 的 LoRaWAN 广域低功耗世界。