01 · MQTT：发布/订阅模型的安全剖析
1.1 协议结构与安全机制
MQTT采用发布/订阅（Pub/Sub）解耦架构：客户端仅与Broker建立长连接，按Topic发布或订阅消息。控制报文仅14种（CONNECT、CONNACK、PUBLISH、SUBSCRIBE等），运行于TCP之上，IANA注册端口为1883（明文）与8883（TLS）。安全机制分层来看：传输层依赖TLS（3.1.1起规范定义TLS Profile；实践中TLS 1.2/1.3为基线，TLS 1.0/1.1已因RFC 8996（2021年3月）正式弃用）；会话层依赖CONNECT报文中的用户名/密码字段或证书双向认证（Client Certificate）；授权层完全由Broker实现（Mosquitto的acl_file、EMQX的ACL规则、云平台的Topic级IAM策略），协议本身不定义授权模型——这是MQTT安全的最大结构性事实：授权强度取决于部署方，而非协议。
1.2 MQTT 5.0相对3.1.1的安全相关增强
| 特性 | 安全意义 | 版本 |
|---|---|---|
| 原因码（Reason Code） | CONNACK/SUBACK等返回具体失败原因，使认证与授权失败可观测、可告警，替代3.1.1的单字节笼统拒绝 | 5.0 新增 |
| 会话过期（Session Expiry Interval） | 控制离线会话保留时长，限制会话劫持窗口与Broker资源消耗 | 5.0 新增 |
| 共享订阅（Shared Subscription） | $share/{Group}/{Topic}实现负载均衡消费，但要求Broker严格校验组内权限，防越权入组 | 5.0 新增 |
| 请求/响应模式（Request/Response） | 属性携带Correlation Data，使同步命令类通信无需自建主题约定，减少自定义鉴权旁路 | 5.0 新增 |
| 服务端保持活动（Keep Alive 协商） | SERVER Keep Alive允许Broker主动调整心跳预期，异常断连检测更精细 | 5.0 新增 |
| 增强认证（Enhanced Authentication） | 属性帧支持挑战-响应式多步认证（如SCRAM式流程），为令牌/OTP类认证提供协议载体 | 5.0 新增 |
1.3 MQTT高危误配置清单（基线强制项）
| 等级 | 误配置 | 危害与核查方法 |
|---|---|---|
| 高危 | 允许匿名CONNECT | 未设用户名/证书即可连接，随后可SUBSCRIBE "#"枚举全平台消息；核查：连接测试与授权审计（allow_anonymous参数） |
| 高危 | 通配符订阅无ACL限制 | "#"、"+/+"订阅可窃听跨租户/跨设备消息；核查：acl_file/主题权限最小化，按设备身份逐Topic授权 |
| 高危 | 1883明文端口对公网开放 | 凭证与消息内容明文可嗅探（尤其在共享介质网络）；核查：仅开放8883，1883限内网并配双向TLS |
| 中危 | 共享账号多设备复用 | 无法定位与吊销单台设备，一机失陷全网失陷；核查：账号-设备1:1映射与并发连接数限制 |
| 中危 | Retain消息与LWT滥用 | Retained消息可被恶意覆写注入虚假状态；LWT可被利用构造假离线告警；核查：retain权限收敛、LWT主题写权限隔离 |
| 中危 | QoS 0承载关键控制指令 | 至多一次投递，指令丢失无感知；核查：控制类消息强制QoS 1/2并配套应用层回执 |
重要事实：MQTT协议在TCP上设计，标准不定义UDP承载（MQTT-SN面向传感器网络，运行于UDP）。这使得MQTT自身不易被用作UDP反射放大攻击；而CoAP基于UDP，是反射放大的天然候选。协议选型本身就是DDoS面选型的一部分（与子课题06协同）。
02 · CoAP与LwM2M：受限环境下的安全现实
2.1 CoAP协议要点
CoAP（RFC 7252，2014年6月）是为受限节点与受限网络设计的类HTTP协议：采用UDP承载、二进制报文（4字节定长头）、REST模型（GET/POST/PUT/DELETE）、观察者模式（Observe）。安全依赖叠加层：DTLS（RFC 6347）为事实标准，RFC 8323（2018年2月）补充TCP与TLS承载。结构性安全现实是：RFC 7252规定"若使用UDP，则必须支持DTLS"，但"必须支持"不等于"部署方必须启用"——互联网上大量CoAP服务未启用DTLS，导致请求/响应可被伪造、监听与重放，并使CoAP服务被滥用为UDP反射放大攻击的反射源（安全厂商自2018年起多次公开报告CoAP反射滥用趋势）。
2.2 LwM2M：把"管理平面"纳入攻击面
LwM2M（OMA SpecWorks，1.0版2017年2月发布）运行于CoAP/DTLS之上，定义注册（Register）、设备管理（Object模型，如固件升级Object 5）与信息服务（Observe/Notify）。它把"远程管理"做成了标准功能——也意味着一旦DTLS密钥或设备凭据泄露，攻击者获得的是标准化的"全量控制权"（含固件升级下发），而非零散能力。LwM2M 1.1（2018年）及后续版本增加了对TCP/TLS、OSCORE（RFC 8613）对象级安全的支持，但存量部署以1.0+DTLS为主。
| 安全机制 | CoAP部署现状与风险 | 基线要求 |
|---|---|---|
| DTLS | 部署率低是主要短板；PSK模式下弱PSK（短口令、多设备共享）常见 | 强制DTLS 1.2+；PSK长度≥128比特且一机一密；优先证书模式 |
| 块传输（Block-Wise Transfer, RFC 7959） | 大报文分块传输若无完整性保护边界，存在重组攻击面 | 分块大小与超时收敛；跨块状态校验 |
| Observe | 长周期订阅若无最大通知计数与刷新机制，资源可被拖垮 | 设置Observe上限与定期重建观察关系 |
| 资源发现（/.well-known/core） | 默认暴露资源目录，便于攻击者枚举可控资源 | 生产环境关闭或限制发现端点访问 |
| 无连接性 | UDP无握手，伪造源地址成本低，放大滥用风险 | 出口过滤、上游限速、与运营商清洗联动 |
03 · 其他主流协议：AMQP、MQTT-SN、HTTP/2
| 协议 | 定位与现状 | 安全要点 |
|---|---|---|
| AMQP 1.0 | OASIS标准（2012年10月），ISO/IEC 19464:2014；面向企业消息中间件，Azure IoT Hub、RabbitMQ支持 | 内建SASL认证框架与TLS传输；安全焦点在SASL机制选型（PLAIN禁明文、SCRAM替代CRAM-MD5）与队列级授权 |
| MQTT-SN | 面向传感器网络的MQTT适配（UDP/蓝牙/Zigbee承载） | 网关集中转发模式使网关成为单点信任实体；主题注册表的网关侧鉴权是关键 |
| HTTP/2与HTTP/3 | 设备与App经REST API通信的主流通道；HTTP/2 Rapid Reset（CVE-2023-44487，2023年10月披露）引发API网关层防护升级 | TLS强制、请求限流、RST帧速率管控；HTTP/3(QUIC)引入UDP面，需同步评估反射滥用与连接迁移跟踪 |
| WebSocket | IoT App实时推送常用；MQTT over WebSocket（端口443/80）常见 | 同MQTT鉴权要求；反向代理需透传客户端证书或令牌；跨域与Origin校验 |
04 · 智能家居互联协议：Zigbee、Thread与Matter
智能家居短距与互联协议经历了"烟囱式生态"向"统一IP互联"的演进：Zigbee（CSA前身Zigbee联盟2002年发起）以应用 Profile 生态见长但跨厂商互通弱；Thread（Thread Group，基于IEEE 802.15.4与IPv6）提供自组织Mesh；Matter（CSA连接标准联盟，1.0版2022年10月4日发布，源自2019年12月由Amazon、Apple、Google等发起的Project CHIP）在Thread/Wi-Fi/以太网上运行统一应用层，并以"设备证明"重构信任链。
| 机制 | 安全设计 | 残留风险 |
|---|---|---|
| 设备证明（DAC） | 每台设备出厂内置由CSA PKI签发的设备证明证书（DAC），入网 commissioning 时经分布式合规账本（DCL）验证认证状态，仿冒设备无法加入Fabric | 证书密钥若出厂提取（固件侧问题，归子课题01），证明体系被绕过；DCL可用性成为新依赖 |
| 配网（Commissioning） | 经BLE辅助配网，使用Setup Code（约11位数字）建立PAKE加密通道，设备与管理员相互证明 | Setup Code熵有限且常印在机身，"开箱后未擦除+物理接触"场景存在本地接入风险 |
| 网络层加密 | Thread使用IEEE 802.15.4 AES-128 CCM链路加密；Matter节点间通信经AES-CCM-128加密、PASE/CASE会话密钥 | 链路加密不解决"恶意节点入网后合法访问"问题，仍需ACL与证书吊销支撑 |
| Wi-Fi承载（WPA3） | WPA3（Wi-Fi联盟2018年6月发布）强制PMF（受保护管理帧）、SAE替代PSK抗离线字典攻击；企业级支持192-bit CNSA套件 | 过渡模式（WPA2/WPA3混合）与Dragonblood研究（Vanhoef & Ronen，2019年）揭示的SAE侧信道/降级问题，需禁用过渡模式并修复实现 |
| Zigbee传统架构 | Trust Center集中分发网络密钥（AES-128），支持安装码（Install Code）增强入网 | 网络密钥单点管理、无内建公钥体系，跨网信任依赖厂商云端——这是Matter要解决的痛点 |
05 · 蜂窝接入：NB-IoT、LTE Cat.1与5G
蜂窝物联网由3GPP标准驱动：NB-IoT与LTE-M（eMTC）在R13（2016年6月冻结）标准化，LTE Cat.1为R8既有能力、Cat.1 bis在R13后广泛商用（中国市场自2020年起爆发式增长）；5G NB-IoT继续演进。安全特性上，蜂窝接入天然继承SIM/eSIM的双向认证（EPS-AKA，3GPP TS 33.401）与空口加密/完整性保护——这是相对Wi-Fi的结构性优势；但"网络侧可信"不等于"业务侧可信"：设备经运营商网络直达平台，平台侧的身份认证与授权仍是第一道真正由部署方控制的防线。
- 空口与核心网：信令面与用户面在LTE下默认加密（由运营商策略决定算法，国内网强制启用），伪基站与IMSI捕获在4G/5G下显著收敛（5G新增SUPI加密）；剩余风险集中在弱算法协商、遗留2G回落场景与SS7/Diameter信令交互（国际漫游场景，与本课题关联有限）。
- DNS与路由：物联网卡常配运营商DNS与NAT出口，设备真实源地址与平台日志的关联依赖卡实名信息——这也是第6页实名制治理的技术动因。
- 功耗与休眠：PSM/eDRX节能模式导致连接间歇，会话复用与凭据缓存窗口变长，离线期间的凭据保护（安全存储）更重要（与子课题01交叉）。
- 多APN与切片：行业客户常配专用APN或直接启用5G网络切片实现逻辑隔离；切片安全（切片间隔离、切片凭据管理）是5G物联网治理的新议题，相关标准化在3GPP SA3持续演进。
06 · 协议对比总表与选型安全指引
| 协议 | 标准化 | 典型承载 | 默认安全 | 主要风险面 |
|---|---|---|---|---|
| MQTT 3.1.1 | OASIS 2014 / ISO/IEC 20922:2016 | TCP | 无（TLS/认证靠部署） | 匿名访问、通配符越权订阅 |
| MQTT 5.0 | OASIS 2019 | TCP | 无（增强认证可用） | 旧特性兼容降级 |
| CoAP | RFC 7252（2014） | UDP | 无（DTLS叠加） | 明文通信、反射放大滥用 |
| LwM2M | OMA SpecWorks 1.0（2017） | CoAP/UDP或TCP | DTLS依赖部署 | 管理接口全量接管 |
| AMQP 1.0 | OASIS 2012 / ISO/IEC 19464:2014 | TCP | SASL框架内建 | 机制选型不当、授权粗粒度 |
| Matter | CSA 1.0（2022年10月） | Wi-Fi/Thread/以太网 | 设备证明+链路加密内建 | 配网码物理安全、DAC密钥保护 |
| NB-IoT/Cat.1（蜂窝） | 3GPP R13（2016） | 蜂窝空口 | 双向认证+空口加密内建 | 平台侧认证缺失、卡滥用 |
选型安全指引：①强交互控制场景（家电、门锁）优先Matter等内建证明体系；②大规模遥测场景用MQTT时把"双向TLS+Topic级ACL"列为验收强制项；③受限网络场景用CoAP/LwM2M时把"DTLS全覆盖+禁裸UDP出公网"列为网络准入条件；④蜂窝场景把"平台侧独立认证（独立于SIM）"列为强制项，防止"有卡即可信"的默认假设。
本节参考来源（第2页）
以下均为真实可查的权威来源（标准组织、监管机构、漏洞库、厂商安全公告与主流安全媒体报道），用于支撑本页事实性表述；涉统计数字均标注原始出处。
OASIS《MQTT Version 3.1.1 Plus Errata 01》与《MQTT Version 5.0》：mqtt.org（规范下载入口）；ISO/IEC 20922:2016：iso.org/standard/69466.html。
IETF RFC 7252（CoAP）、RFC 7959（Block-Wise Transfer）、RFC 8323（CoAP over TCP/TLS）、RFC 6347（DTLS 1.2）、RFC 8996（弃用TLS 1.0/1.1，2021年3月）：rfc-editor.org。
IETF RFC 8613《OSCORE: Object Security for Constrained RESTful Environments》：rfc-editor.org/rfc/rfc8613。
OMA SpecWorks Lightweight M2M（LwM2M）规范：openmobilealliance.org/release（LwM2M 1.0：OMA-TS-LightweightM2M_Core-V1_0-20170208-C）。
Connectivity Standards Alliance《Matter Specification》：csa-iot.org/developer-resource/specifications-download-request；Matter 1.0发布公告（2022年10月4日）：csa-iot.org/newsroom/matter-arrives。
Wi-Fi Alliance《WPA3 Specification》（2018年6月）：wi-fi.org/discover-wi-fi/security；Vanhoef & Ronen《Dragonblood: A Security Analysis of WPA3》（IEEE S&P 2020）：papers.mathyvanhoef.com/dragonblood.pdf。
3GPP TS 33.401（EPS安全架构）、TS 36.300/23.682（NB-IoT与蜂窝IoT）：3gpp.org（标准下载需注册）。
NVD CVE-2023-44487（HTTP/2 Rapid Reset）：nvd.nist.gov/vuln/detail/CVE-2023-44487。
终审增补 · 协议安全基线补充2026-09核验
B1. DTLS 1.3（RFC 9147，2022年4月）：CoAP/LwM2M通道加密的新基线
第2页基线以DTLS 1.2为强制项，现补充其继任版本的安全增益与部署注意事项：
| 特性 | 安全意义 | 部署注意 |
|---|---|---|
| 抗重放与0-RTT | 密钥建立与会话恢复机制重构，早期数据（0-RTT）默认不带前向安全性，需应用层防重放 | 承载控制指令的CoAP消息应禁用0-RTT或配应用层序列号 |
| 仅保留AEAD套件 | 废弃CBC类弱模式，仅支持AES-GCM/ChaCha20-Poly1305等带关联数据的认证加密 | 受限设备优先AES-128-GCM硬件加速路径 |
| 握手加密化 | ServerHello之后的扩展被加密，被动指纹暴露面收窄（与第7页JA3类指纹检测的演进相关） | 检测体系应迁移至流量统计与行为基线 |
| 与OSCORE组合 | RFC 9148（EST over CoAP）等将证书自动化流程引入受限网络 | 与第3页动态注册体系衔接 |
B2. Matter 1.5引入摄像头设备类型的信任边界变化
Matter 1.5（2025年11月）首次将摄像头/可视门铃纳入标准设备类型并引入TLS安全通信路径。其安全评估要点：①视频流凭证独立于设备证明（DAC）体系，摄像头类设备的隐私评估需覆盖视频流加密、存储与跨境路径（衔接子课题03）；②TLS路径的证书生命周期管理沿用第3页X.509治理框架；③Matter 1.4.2新增的证书吊销机制使DAC私钥泄露后的处置首次具备"可吊销"手段。
B3. CoAP反射放大的工程缓解基线
- 源侧：开启DTLS的CoAP服务不应直接对公网UDP开放；裸UDP 5683端口上线前须通过出口过滤与速率限制评估。
- 网侧：与运营商清洗中心联动，对5683/5684端口的入站放大流量做近源压制（呼应第6页运营商协同）。
- 协议侧：遵循RFC 7252对响应体大小的约束意识，避免将CoAP服务配置为大响应放大源。
增补来源
IETF RFC 9147《The Datagram Transport Layer Security (DTLS) Protocol Version 1.3》（2022年4月）：rfc-editor.org/rfc/rfc9147。
IETF RFC 9148《EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol》（2022年4月）：rfc-editor.org/rfc/rfc9148。
Connectivity Standards Alliance Matter版本发布存档：csa-iot.org/newsroom（含1.4/1.4.1/1.4.2/1.5/1.6发布公告）。