一、先搞懂CoAP多播到底是啥

很多做物联网或者智能家居的开发者，都听过CoAP协议，它就像物联网版的HTTP，专门给低功耗、小带宽的设备设计的。那多播又是什么？简单说就是“一对多”的发送，发一次，同一个局域网里所有符合条件的设备都能收到。比如你家里有10个智能灯，要同时让它们全亮，要是用单播，得给每个灯发一遍命令，不仅费时间，还占带宽；用CoAP多播，只需要发一次，所有灯同时收到，特别适合这种需要同步操作的场景。 常见的应用场景有三个：第一个是智能家居里的设备发现，新的智能音箱加入WiFi后，发个多播包问“有没有其他设备？”，其他设备回应，不用逐个扫描；第二个是应急照明系统，断电后，控制中心发多播命令，所有应急灯同时亮起，比单播快得多；第三个是工业传感器组网，十几个温度传感器定期同步数据，用多播一次就能把所有数据请求发出去，省能耗。

二、CoAP多播的安全性“坑”到底有哪些

别看CoAP多播方便，它的安全问题藏得很深，主要有四个致命的坑：

2.1 身份验证缺失

这是最严重的问题之一，默认的CoAP多播没有任何身份校验，任何人只要在同一个局域网里，用随便一个工具就能发命令。比如你用手机跑个简单的脚本，就能给所有智能灯发“全关”的命令，根本不用管你是不是合法的控制端，恶意攻击者很容易利用这一点搞破坏。

2.2 消息被篡改

多播包在传输的时候，可能会被中间的节点（比如路由器）或者恶意设备拦截、修改。比如本来要发“全亮”的命令，中途被改成“全灭”，所有灯瞬间关掉，造成不必要的损失，而且很难查到是谁改的。

2.3 重放攻击

比如之前某合法的控制端发过“全关”的命令，被攻击者用工具抓下来，过几个小时再重新发一遍，所有灯又会被关掉，这种旧命令重复发送的攻击，很难靠基础的防护挡住。

2.4 明文传输窃听

默认的CoAP多播都是明文传输的，命令内容（比如“action:turn_on”）会被局域网里的任何人抓到，要是涉及到工业机密，比如传感器的位置、设备的运行状态，就会泄露给竞争对手，造成损失。

三、针对这些坑的实际防护方案

既然知道了坑，那怎么补？这些方案都是专门为低功耗物联网设备设计的，不会太复杂，适合算力弱的设备。

3.1 预共享密钥（PSK）做身份验证

最常用也最省资源的方案，就是让所有可信的设备共享一个秘密密钥，只有用这个密钥发的多播命令，接收端才会执行。这个方案不用复杂的公钥体系，特别适合中小规模的局域网。 我们用Python的aiocoap库来写代码，这个库专门处理CoAP通信，运行之前先安装：

pip install aiocoap

先看一个没防护的恶意发送端，谁都能跑：

# 技术栈：Python + aiocoap库
from aiocoap import Context, Message, POST
import asyncio

async def malicious_send():
    # 目标是局域网所有CoAP设备的多播地址：FF02::1
    multi_addr = "ff02::1"
    # 构造恶意命令：让所有灯全关
    payload = b"action:turn_off_all"
    # 构造CoAP请求，指定灯的控制路径
    req = Message(code=POST, payload=payload, uri=f"coap://[{multi_addr}]/lamp/control")
    # 创建客户端上下文，直接发送，没有任何校验
    protocol = await Context.create_client_context()
    try:
        resp = await protocol.request(req).response
        print(f"恶意命令发送成功，响应状态：{resp.code}")
    except Exception as e:
        print(f"发送失败：{str(e)}")

if __name__ == "__main__":
    asyncio.run(malicious_send())

这个代码任何人复制就能跑，只要在同一个局域网，就能搞破坏。再看带PSK防护的合法发送端，必须有正确的密钥才能发：

# 技术栈：Python + aiocoap库
from aiocoap import Context, Message, POST
import asyncio
from aiocoap.psk import CredentialsMap

async def secure_send(pre_key):
    multi_addr = "ff02::1"
    payload = b"action:turn_on_all"
    req = Message(code=POST, payload=payload, uri=f"coap://[{multi_addr}]/lamp/control")
    # 配置PSK凭据：只有持有相同密钥的设备才能通过校验
    creds = CredentialsMap()
    # 这里的密钥是16字节，必须和接收端的密钥完全一致
    creds.add_psk("lamp_controller".encode(), pre_key)
    # 创建带密钥的客户端上下文
    protocol = await Context.create_client_context(client_credentials=creds)
    try:
        resp = await protocol.request(req).response
        print(f"安全命令发送成功，响应状态：{resp.code}")
    except Exception as e:
        print(f"发送失败（可能密钥错误）：{str(e)}")

if __name__ == "__main__":
    # 这个密钥要预先在所有合法设备里配置好，比如控制端和智能灯都存这个
    valid_key = b"my_safe_coap_psk_16byte"
    asyncio.run(secure_send(valid_key))

要是用错误的密钥发，接收端会直接拒绝，这样就挡住了恶意发送。

3.2 消息完整性校验

光有身份验证还不够，还要确保消息没被改。我们可以在命令后面加一个哈希值，比如用SHA-256，把命令内容和密钥一起算哈希，接收端再算一遍，要是和收到的哈希不一样，就说明消息被改了，直接丢弃。这个方案也不费算力，适合低功耗设备。

3.3 多播来源过滤

要是你知道合法的控制端只有一个固定的IP，那可以在局域网的网关或者路由器里设置，只允许这个IP发CoAP多播包，其他IP发的直接拦截，这样就算攻击者拿到了密钥，不是合法IP也发不出去。不过这个方案只适合控制端IP固定的场景，要是动态IP的话就不行了。

3.4 时间戳防重放攻击

每个多播命令都加一个当前时间戳，接收端记录最近10秒内收到的所有时间戳，超过10秒的命令直接丢弃。这样就算攻击者把旧命令抓下来重发，因为时间戳超过了，也会被拒收，完美解决重放问题。不过要注意，所有设备的时间要同步，不然会因为时间差误删合法命令，比如用NTP同步时间就行，NTP也很轻量。

四、技术优缺点和注意事项

4.1 优点

  • 所有防护方案都是轻量级的，不会占太多CPU和内存，适合智能灯、传感器这类低功耗设备，比如PSK的计算量只有公钥加密的几十分之一。
  • 部署简单，不用搞复杂的PKI（公钥基础设施），也不用给每个设备发证书，只要统一配个密钥就行，特别适合中小规模的智能家居或者小工厂的传感器网络。

4.2 缺点

  • PSK的密钥管理麻烦，要是有100个设备，换密钥的话得改100次，规模大了维护起来很累。
  • 来源过滤和时间戳的场景受限，比如设备IP经常变的话，来源过滤就没用；时间戳需要同步时间，要是设备没网络，时间不准就会出问题。

4.3 注意事项

  • 多播地址要用链路本地的，也就是FF02开头的，不能用全局多播，不然路由器会把包转发到互联网，不仅不安全，还会浪费带宽。
  • 防护方案不要贪多，低功耗设备用PSK加时间戳就够了，不用加太多复杂的加密，不然设备电池撑不了多久。
  • 一定要测试，比如写完防护方案后，用之前的恶意发送脚本测一下，看能不能拦截，要是没拦住，就说明防护有漏洞，得调整。

五、总结

CoAP多播是物联网里非常实用的技术，但是安全问题不能忽视，核心的防护思路就是“让只有可信设备能发命令，并且命令不能被改、不能被重复发”。我们用Python的代码示例，讲了最常用的PSK防护方案，还有其他辅助的防护手段。开发者在实际用的时候，要根据自己的场景选方案，中小规模的用PSK足够，大规模的可以结合更复杂的DTLS会话密钥，总之平衡好安全和功耗，才能做出稳定的物联网产品。