3、CoAP安全威胁分析：CoAP面临的安全风险、常见攻击类型、安全需求分析
好，咱们进入第3章。说实话，很多搞物联网的兄弟一开始都觉得CoAP协议轻量、好用，直接往产品上一怼就完事了。但我要泼盆冷水——CoAP跑在UDP上，默认不带任何安全机制。你想想看，这就好比你家大门没上锁，谁都能推门进来溜达一圈。
我在早期的一个智能照明项目里就吃过这个亏。当时为了赶工期，CoAP报文全是明文传输。结果上线第二天，客户反馈说灯半夜自己乱闪。一查日志，好家伙，有人在公网上伪造了控制指令。从那以后，我再也不敢忽视CoAP的安全问题了。
这一章，咱们就把CoAP面临的威胁掰开揉碎了讲清楚。只有知道敌人长什么样，才知道怎么防。
3.1 CoAP协议的安全短板
CoAP本身设计得很精巧，但它的几个核心特性，恰恰成了攻击者的突破口。
- 基于UDP传输：无连接、无状态，源IP地址可以随意伪造。攻击者很容易发起反射放大攻击。
- 默认无加密：URI路径、Payload、Token全是明文。抓个包就能看到你控制的是哪个设备、发了什么指令。
- 无内置认证：服务器无法确认请求来自合法设备，设备也无法确认响应来自真实服务器。
- 资源受限：很多CoAP终端是MCU，算力和内存都有限，跑不了复杂的加解密算法。
核心结论：CoAP的“轻量”是用“安全”换来的。在公网或不可信网络中部署CoAP，必须叠加安全层——DTLS是当前最成熟的选择。
3.2 常见攻击类型分析
我根据实际项目中的经验，把CoAP常见的攻击分成了四大类。咱们一个一个看。
3.2.1 嗅探与信息泄露
这个最简单，也最常见。CoAP报文在网络上明文传输，攻击者在同一网段抓包就能看到所有内容。
- URI泄露：比如
coap://server/light/on，攻击者一看就知道你在开灯。 - Payload泄露：传感器数据、控制指令一览无余。
- Token泄露：Token用于匹配请求和响应，泄露后攻击者可以伪造响应。
避坑指南：我曾经在一个智慧农业项目里，用Wireshark抓包测试。结果发现温湿度传感器的上报数据全是明文。客户当场就急了——这些数据要是被竞争对手截获，种植策略就全暴露了。所以，只要数据出了设备本地，就必须加密。
3.2.2 伪造与中间人攻击
UDP没有握手过程，攻击者可以轻松伪造源IP地址，冒充合法设备或服务器。
| 攻击类型 | 攻击方式 | 后果 |
|---|---|---|
| 伪造请求 | 攻击者伪造设备身份，向服务器发送控制指令 | 设备被非法控制，如远程开锁、关闭阀门 |
| 伪造响应 | 攻击者伪造服务器响应，欺骗设备执行错误动作 | 设备误判状态，如误报温度、误触发告警 |
| 中间人攻击 | 攻击者拦截并篡改CoAP报文 | 数据被篡改，指令被替换，双向欺骗 |
为什么会这样？因为CoAP的Token机制只能防重放，不能防伪造。攻击者只要猜出Token格式，就能伪造合法报文。
3.2.3 重放攻击
攻击者不需要解密报文，只需要把截获的合法报文重新发送一遍，就能达到目的。
- 场景举例：攻击者截获一条“开锁”指令。即使他不知道密钥，只要在合适时机重放这条报文，门就开了。
- CoAP的弱点：CoAP的Message ID只有16位，很容易被预测或暴力遍历。
注意：DTLS的序列号机制可以防重放，但前提是必须启用。我在一个项目中见过有人为了省资源，把DTLS的防重放窗口关了。结果测试时重放一条旧报文，设备直接执行了。嗯，这个坑大家千万别踩。
3.2.4 拒绝服务攻击
CoAP基于UDP，天生容易遭受DoS攻击。而且物联网设备资源有限，抗攻击能力更弱。
- 放大攻击：攻击者伪造源IP，向CoAP服务器发送小请求，服务器返回大响应。流量被放大数倍，打垮目标。
- 资源耗尽：攻击者发送大量CON消息，迫使服务器分配内存维护重传状态，直到内存耗尽。
- DTLS握手洪水：DTLS握手需要多次交互和计算，攻击者发起大量握手请求，耗尽服务器CPU。
3.3 CoAP安全需求分析
分析了这么多攻击，咱们来总结一下CoAP到底需要哪些安全能力。我个人习惯把需求分成四个维度，你可以对照着检查自己的项目。
3.3.1 机密性
说白了，就是防止别人偷看。所有CoAP的Payload、选项、甚至部分URI都应该加密。DTLS的AES加密可以满足这个需求。
3.3.2 完整性
防止数据在传输过程中被篡改。DTLS的MAC（消息认证码）机制可以保证：只要报文被改过一个比特，接收方就能发现并丢弃。
3.3.3 身份认证
确认对方是不是它声称的那个实体。DTLS支持两种方式：
- PSK（预共享密钥）：适合资源受限设备，双方预先配置相同的密钥。
- 证书认证：适合网关或服务器，基于PKI体系，安全性更高。
我的建议：如果你做的是传感器节点，用PSK就够了。证书认证的握手开销太大，有些MCU根本扛不住。我在一个水表项目里试过证书认证，结果握手花了3秒，电池直接报警。后来换成PSK，握手时间降到200毫秒以内。
3.3.4 可用性
保证服务在攻击下仍然可用。这不仅仅是DTLS能解决的，还需要配合网络层的限速、ACL、以及应用层的重传策略。
3.4 安全需求与DTLS的对应关系
最后，咱们把安全需求和DTLS的能力做个映射。这样你就能清楚地知道：DTLS到底解决了什么问题，还有哪些问题需要额外处理。
| 安全需求 | DTLS提供的机制 | 备注 |
|---|---|---|
| 机密性 | AES、CHACHA20加密 | 加密整个DTLS记录 |
| 完整性 | HMAC-SHA256等MAC算法 | 防篡改，防重放 |
| 身份认证 | PSK或证书双向认证 | 握手阶段完成 |
| 防重放 | 序列号+滑动窗口 | 需确保窗口大小合理 |
| 可用性 | 部分支持（握手限速） | 需配合网络层防护 |
嗯，看到这里你应该明白了。DTLS不是万能的，但它解决了CoAP最核心的四个安全问题中的三个。至于可用性，咱们后面讲实战配置的时候，我会分享一些抗DoS的配置技巧。