2　MQTT 协议安全加固方案

2.1　TLS

2.2　增强的口令认证密钥交换协议

2.3　基于主题的加密方案

3　MQTT 协议安全加固框架

3.1　对比与小结

3.2　框　架

近年来物联网（Internet of Things，IoT）飞速发展，随着其应用范围越来越广泛，物联网面临的安全威胁也逐渐呈现出大规模、多样化、高频次等特点。根据国家计算机网络应急技术处理协调中心的监测数据，仅 2022 年 7 月，共捕获物联网恶意样本 471 158 个，发现物联网恶意程序传播 IP 地址55 163 个， 发 现 活 跃 的 僵 尸 网 络 命 令 和 控 制（Command and Control，C&C）服务器地址 2 021 个，其地址位置主要分布在美国（33.6%）、中国（8.5%）、俄罗斯（6.7%）等国家。其中，来自美国的 680 个C&C 服务器控制了中国境内的 373 080 个设备。因此，IoT 面临的安全威胁不容忽视。

消息队列遥测传输（Message Queuing Telemetry Transport，MQTT） 协 议 是 一 个 超 轻 量 级 的 发 布（publish）/ 订阅（subscribe）消息传输协议，是专为受限设备和低带宽、高延迟或不可靠的网络而设计的。该协议第 1 个版本由 IBM 公司在 1999 年发布，版本 v3.1.1 于 2014 年成为结构化信息标准促进组织（Organization for the Advancement of StructuredInformation Standards，OASIS）的标准，其最新版本为 MQTT v5.0。

MQTT 协议非常适用于需要代码占用较小空间或网络带宽非常宝贵的远程连接。这些特性也使该协议成为新兴的机器到机器（Machine to Machine，M2M）或 IoT 世界的连接设备，以及带宽和电池功率非常高的移动应用的理想选择。MQTT 协议的常见应用场景有大规模传感器网络数据采集、智慧家居互联、移动及时消息推送等。

1.1　 MQTT 协议简介

MQTT 协议中只有客户端（Client）和 MQTT 代理服务器（Broker）两个角色，以及一个关键概念：主题（Topic）。

客户端（Client）：使用 MQTT 的程序或设备，具有消息发送和接收能力。客户端之间不能直接通信，所有客户端需与代理服务器（简称代理）连接，彼此间的通信全都要经过 Broker 的转发。

代理服务器（Broker）：为 MQTT 服务端，是一个代理中介，主要实现主题管理、消息接收、消息路由和消息存储等业务。

主题（Topic）：为附着于应用消息的标签，可以被客户端订阅。客户端发布消息时指明该消息属于的主题，代理将该条消息推送给所有订阅了这个主题的客户端。

可见，MQTT 通信是标准的异步通信模式，各个客户端是对等关系。

如图 1 所示，MQTT 的报文由固定头、可变头和有效荷载 3 部分组成。其中固定头为必选项，长度为 2 字节；可变头和有效荷载是可选项，载荷部分最大支持 256 MB 的数据。

图 1 MQTT 协议报文数据格式

MQTT 报文第 1 字节的前 4 个比特为 MQTT 控制报文类型，除 0 与 15 为 Reserved 保留外，还规定了剩下的 14 种控制报文类型，如表 1 所示。MQTT 协议的通信模型如图 2 所示。客户端使用 subscribe（SUB）向代理订阅主题，代理和客户端之间使用 publish（PUB）发布消息。

表 1　 MQTT 报文类型

图 2　MQTT 协议通信模型

1.2　MQTT 协议安全分析

MQTT 协议面临的安全风险主要是由认证、鉴权、数据传输，以及代理的可信性的安全缺陷带来的，这也对应着其安全需求。

1.2.1　认  证

MQTT 协议的 CONNECT 报文中提供了可选的用户名（UserName）+ 口令（PassWord）的认证方式。其中 UserName 字段为一个字符串，PassWord 字段为二进制类型，最大支持 65 535 Byte 的长度。该认证方式简单，且口令在传输过程中是明文。此外，若不设置认证机制，可以有无限多客户端连接到代理，对代理造成很大的连接冲击。

1.2.2　鉴  权

MQTT 协议中规定按照层级划分主题，并规定了两个特殊字符“＃”和“／”，这两个特殊字符导致订阅者在不知道主题的情况下就能够对该主题进行订阅，而 MQTT 协议本身并没有给出访问控制相关的说明。

1.2.3　数据传输

MQTT 协议数据本身都是明文传输的，数据传输过程中面临着机密性与完整性被破坏的风险。

1.2.4　代理的可信性

代理是整个 MQTT 协议的核心，客户端间发送的数据均会在代理处落地。若代理不可信，则整个MQTT 通信网络毫无安全可言。

2.1　TLS

安全传输层协议（Transport Layer Security，TLS）是多数 MQTT 协议使用者首选的安全通信方案，也是业界使用最广泛的 MQTT 安全解决方案。该方案在传输层解决了认证与数据安全的问题，但也有如下弊端：

（1）TLS 占用 CPU 与硬件存储，对资源受限的物联网设备而言开销较大。

（2）所有加密数据在经过代理时必须先解密，再加密给接收方，带来了大量加解密运算开销。同时，代理是整个通信网络的性能瓶颈，也面临着可信性的问题。

（3）物联网设备中节点状态动态变化迅速，对节点安全凭证的管理难度大。

2.2　增强的口令认证密钥交换协议

相较于 TLS 协议需花费大量字节用于认证和密钥协商，增强的口令认证密钥交换（Augmented Password Authenticated Key Exchange，AugPAKE）协议利用口令完成了客户端接入代理时的双向认证，同时基于 D-H（Diffee-Hellman）密钥交换，协商了后续通信过程中使用的对称密钥（一般是AES 密钥）。

2.2.1　AugPAKE 协议简介

令 p 和 q 是两个大素数，且 q 是 (p-1)/2 的因子，同时 (p-1)/2 的每个因子都是与 q 大小相当的素数。使用模 p 的整数群来表示有限域 GF(p) 上的q 阶乘法子群，令是子群 G 的生成元，即AugPAKE 协议可在群 G 中实现。表 2 给出了 AugPAKE 协议涉及的符号说明。

表 2  符号说明

初始化时，用户 U 计算其中 w' 是有效口令，并将 W 发送给 S，作为向 S 的注册口令。

协议执行流程如图 3 所示。

图 3 AugPAKE 协议流程

AugPAKE 协议具体的执行流程描述如下：

（1）用户 U 从中选择随机数 x，计算 DH公开值并将 (U,X) 发送给服务端 S。

（2） 若 S 收 到 的 X 等 于 0,1,1mod p，则 S 终止 协 议。否 则，S 从中选择随机数 y，计算其中S将 (S,Y) 发送给 U。

（3）若 U 收到的 Y 等于 0,1,1mod p，则 U 终止协议。否则，U 计算其中U 计算认证码U 将发送给 S。

（4）若 S 收到的不等于其中则 S 终止协议。否则 S 生成验证码并将发送给 U。服务端生成会话密钥

（5）若 U 收到的 不等于则终止协议。否则，U 生成会话密钥

至此，U 和 S 间基于口令完成了双向身份认证，并产生了后续加密消息的会话密钥 SK。

2.2.2　基于 AugPAKE 的 MQTT

设发方客户端 ClientA 与收方客户端 ClientB 分别通过 AugPAKE 协议与代理建立了会话密钥 SKa与 SKb。图 4 给出了基于 AugPAKE 协议的 MQTT通信流程。

图 4　基于 AugPAKE 的 MQTT

基于 AugPAKE 协议的 MQTT 通信流程如下：

（1）ClientA 使用 SKa 加密该主题下待发布的消息，并将消息密文发送给代理。

（2）Broker 使用 SKa 解密消息，然后分别使用订阅了该主题的所有客户端的会话密钥加密明文消息，将密文推送给收方客户端，如使用同 ClientB共享的 SKb 再次加密消息。

（3）ClientB 使用 SKb 解密消息。

综上，AugPAKE 可视作较轻量的 TLS，它也可以被其他认证密钥交换协议替换。

2.3　基于主题的加密方案

由于 MQTT 的消息推送是与主题相关的，因此容易想到基于主题对消息进行加密。相较于 TLS 与AugPAKE 方案，基于主题的加密方案可以避免密文消息在 Broker 处的解密与重新加密。

2.3.1 　非对称主题密钥分发与消息加解密

2016 年，Mektoubi 等人提出了一种基于主题的加密方案 。该方案需使用配套的公钥基础设施，为客户端与主题生成证书，并将主题证书与其对应的私钥手动地公开给通过认证的客户端，用于消息的安全传输。

新加入主题的客户端请求主题证书的流程如图5所示，首次请求主题私钥的流程如图 6 所示。图 5和图 6 省略了 Broker 的转发过程。

图 5 新加入主题的客户端请求主题证书

图 6 首次请求主题私钥

新加入主题的客户端请求主题证书的具体流程描述如下：

（1）当新加入主题的客户端 Client1 要加密消息时，它首先需请求主题的证书，发布 Requset Topic 消息。

（2）某个已订阅该主题的客户端 Client2 监听到请求，检查自己是否拥有主题的证书，若有，则返回 Response Topic 消息，里面包含主题的证书。

（3）Client1 收到主题证书，验证其有效性（CA签名等）。

首次请求主题私钥的具体流程如下：

（1）首次解密消息时，Client1 需请求主题的私钥，发送 Request Privatekey 消息，其中包含用主题证书公钥加密的 Client1 的证书。

（2）某个已订阅该主题的客户端 Client3 监听到请求，检查主题私钥是否可用。若可用，则使用主题私钥解密得 Client1 证书。

（3）Client3 验 证 Client1 证 书 的 有 效 性， 并用 Client1 证 书 公 钥 加 密 主 题 私 钥， 构 造 并 返 回Response Privatekey 消息。

（4）Client1 收到 Response Privatekey 消息后，使用自己证书对应的私钥进行解密，获得主题私钥。

至此，Mektoubi 等人的方案完成了主题证书与私钥的分发，Client1 可用其对 MQTT 通信消息进行加解密。实际上，还可利用数字信封技术实现会话加密，如图 7 所示。

图 7 基于主题加密的 MQTT——数字信封

利用数字信封实现基于主题加密的 MQTT 流程如下：

（1）发方客户端 Client1 产生会话密钥 key，用 key 加密某个主题下的消息。

（2）Client1 使用主题证书的公钥加密 key，并将 key 的密文写入 MQTT 载荷。

（3）Client1 将 消 息 发 给 Broker，Broker 将 之推送给所有订阅了相关主题的客户端，如 Client4。

（4）Client4 先使用主题私钥解密 key，再使用key 解密消息。

2.3.2　对称主题密钥分发与消息加解密

为不同主题生成相应的主题密钥（对称密钥），在客户端订阅主题时获取主题密钥，使用主题密钥来加密该主题下的所有消息。

如图 8 所示为客户端注册流程。客户端注册时需提交加密公钥、证书、身份标识等，用于主题密钥的分发。主题密钥的生成与分发流程如图 9 所示。

图 8 客户端注册

图 9 主题密钥的生成与分发

主题密钥的生成与分发的具体流程描述如下：

（1）Broker 为每个主题生成的主题密钥，可根据主题层级利用密钥衍生算法产生。

（2）客户端订阅主题时，从 Broker 处安全获取主题密钥，主题密钥可使用客户端提交的公钥、证书、身份标识等加密。

基于主题的加密流程如图 10 所示。

图 10 基于主题的加密

基于主题的加密流程具体描述如下：

（1）发方客户端 Client1 使用主题密钥加密该主题下待发布的消息；

（2）Broker 将该密文消息推送给所有订阅了该主题的客户端；

（3）收方客户端收到密文消息，使用对应的主题密钥解密。

由于主题密钥是预先生成的，故 Broker 需维护与主题等量的主题密钥。当主题密钥采用层级衍生时，Broker 可只维护最顶层密钥，要用时实时生成，以减少密钥存储量。

2.4 　基于属性的加密方案

相较于传统的公钥密码算法，基于属性的加密（Attribute-Based Encryption，ABE）能较好地满足一对多的通信场景，同时还能对数据的访问进行细粒度的控制，非常适合 MQTT 协议的订阅—推送机制。典型的基于属性加密构造的 MQTT 安全通信解决方案有安全消息队列遥测传输协议（Secure Message Queuing Telemetry Transport，SMQTT）。

2.4.1 　属性加密简介

所谓属性是指某个对象所具备的性质，如性别、年龄、学历等组成该对象的属性集。访问策略（简称策略）指由属性及它们间的关系所组成的一个逻辑表达式，一般用树形结构表示。若属性集合使得策略的逻辑表达式为真，称属性与策略匹配，允许用户执行相关操作。

在基于属性的加密中，根据设计者将属性集合与策略嵌入到用户私钥还是密文中，可分为密钥策略属性加密（Key Policy-Attribute-Based Ecryption，KP-ABE）与密文策略属性加密（Ciphertext Policy Attribute-Based Ecryption，CP-ABE）两个方案，二者是等价的。

KP-ABE 的访问策略由服务端产生，作为产生用户私钥的输入。消息发布方在加密消息时，需用属性集合生成密文索引。解密时要求密文索引满足密钥访问策略，用户才能正确解密。由于访问策略是服务端制定的，因此该方案适用于静态场景，如付费点播等。

CP-ABE 的访问策略由消息发布方产生，加密消息时作为输入，生成密文索引。用户私钥的生成需输入用户属性，只有属性满足密文访问策略的用户才能正确解密。该方案中数据拥有者可以通过设定策略来决定拥有哪些属性的人能够访问这份密文，一般应用于公有云上的数据加密存储与基于属性的细粒度共享。

2.4.2 　与属性加密结合的 MQTT

文献 [5] 中考虑到用户对发布消息的细粒度访问控制，采用的是基于 CP-ABE 的加密方式。考虑到适配 MQTT 订阅—推送的机制，结合基于主题加密的思想，本文采用 KP-ABE 的加密方式，为订阅了不同主题的用户生成访问策略。

KP-ABE 的初始化流程如图 11 所示。

图 11 KP-ABE 初始化

KP-ABE 的初始化流程具体描述如下：

（1）向 Broker 提供属性、证书等信息进行注册。

（2）Broker 生 成 系 统 主 密 钥（Main Secret Key，MSK）、公开参数（Public Key，PK），并将全体用户的属性集公开。

（3）Broker 针对不同的主题，根据订阅的用户生成访问策略，并以此为输入生成用户的私钥。

（4）Broker 将 与相关的私钥集安全返回给它（如使用证书中的公钥加密）。

（5）对于自己订阅的每个主题，都拥有一个对应的私钥。KP-ABE 加解密流程如图 12 所示。

图 12　KP-ABE 加解密

KP-ABE 的加解密流程具体描述如下：

（1）消息发布方 使用公开参数 PK 与加密属性集（该消息所属主题）加密待发布的消息，将密文消息推送给 Broker。

（2）Broker 将该消息推送给订阅了相关主题的客户端。

（3）某个客户端收到消息后，验证密文属性是否符合自己所拥有的密钥的访问策略，若符合，则使用对应的私钥解密消息。上述过程同样也可利用数字信封技术实现。

2.5　基于代理重加密技术

代 理 重 加 密（Proxy Re-Enceyption，PRE） 技术可以在代理不解密的情况下，将发送方公钥加密的密文转化为可被接收方私钥解密的密文，能较好地解决 MQTT 中 Broker 的可信性问题。

2.5.1　代理重加密技术简介

代理重加密系统模型如图 13 所示。

图 13　代理重加密系统模型

代理重加密的流程具体为：

（1）初始化时，各通信客户端需向密钥生成中心（Key Generation Center，KGC）请求自己的加密公私钥对 (PK,SK)。

（2）KGC 使用消息发送方客户端的私钥与接收方的公钥作为输入，生成代理重加密密钥并将之安全地传输给代理服务端。

（3）发送方使用自己的公钥加密明文消息 m，得密文并将之上传到代理服务端。

（4）代理服务端使用重加密密钥重加密密文将发送给接收方。

（5）接收方使用自己的私钥解密得消息明文 m。

常规的 PRE 方案中，代理方重加密次数与接收者人数成正比，消耗较多的网络资源，并且发送者不能对云端的重加密对象做细粒度控制。

2.5.2　基于代理重加密技术的 MQTT

文献 [6] 给出了一种基于代理重加密技术实现MQTT 通信中发布者与订阅者间端到端数据安全传输的解决方案，如图 14 所示。该方案中，KGC 根据设备注册的属性（发布 / 订阅）和主题进行匹配，为每对的发布者—订阅者对等方预生成重加密密钥，并将生成的重加密密钥通过安全的方式发送给Broker。

图 14 基于代理重加密的 MQTT

初始化时，客户端需向 KGC 申请自己的加密公私钥对与签名公私钥，分别用于会话密钥的分发消息与签名。其中，签名公钥为客户端的唯一身份标识，实际加密消息的密钥为会话密钥。

基于代理重加密技术的 MQTT 的具体实现流程如下：

（1）发方客户端产生会话密钥 key，使用自己的加密公钥 PKEnci 加 密 key，得密文Ckeyi。

（2）使用自己的签名私钥对待发布的消息 m 进行签名，得并用 key 加密

（3）将密文消息、Ckeyi 和自己的唯一身份标识 UUIDi（签名公钥）发送到 Broker。

（4）Broker 查询订阅了该条消息所属主题的客户端有哪些，并使用相应的重加密密钥重加密得会话密钥密文

（5）Broker 使用 keyi 重加密会话密钥密文 1，得会话密钥密文 2。

（6）Broker 将密文消息、Ckeyj 和发方 UUIDi推送给相应收方客户端

（7）首先使用自己的私钥 SKDecj 解密 Ckeyj，得会话密钥 key，其次使用 key 解密消息，得

（8） 使用 UUIDi 验证的有效性。

3.1　对比与小结

设想一个 MQTT 通信网络中有 1 个消息发送方与 n 个消息订阅方。用 E 表示加密、D 表示解密、T 表示密钥分发 / 密钥转保护（对密钥解密并加密1 次为 1 个完整的 T）。本文使用上述操作出现的次数来直观地衡量各方案的开销，对比结果见表 3。

如表 3 所示，TLS 协议为成熟的网络层安全通信方案，对应用层 MQTT 协议透明；但传统的TLS 协议在物联网环境中应用的开销较大。虽然AugPAKE 协议在一定程度上降低了认证过程的开销，但当认证完成后，方案 1 与方案 2 的数据传输保护方式是一样的。

表 3 中后面 3 种方案的认证过程都是提前完成的，只有通过认证的客户端才能获得消息解密密钥，进而解密消息。

表 3　5 种方案对比

基于主题的加密方案中，Mektoubi 等人的方案是基于非对称算法的，需要对私钥进行分发，且非对称加解密的效率并不高。本文给出了基于对称算法的主题加密与密钥衍生，维护的密钥量并不比Mektoubi 等人的方案多，且加解密效率更高。

基于属性的加密能很好地实现一对多的数据分发，且可以对数据的访问进行控制，这是方案 4 相较于其他方案最大的优势。本文给出的是基于 KPABE 的属性加密方案，相较于文献 [4] 推荐的 CPABE，虽然不能由数据拥有者对数据的访问进行控制，但更适合 MQTT 协议的订阅—推送机制，然而其本质仍是控制对主题密钥的访问。

方案 5 相较于其他方案的优势在于代理重加密技术可以较好地解决 Broker 的可信性问题。加密消息的密钥由数据拥有者产生，Broker 不能获取数据明文。但方案 5 仍是一对一的方案，针对不同用户的分享要生成不同的重加密密钥。

3.2　框　架

基于上文的分析，给出 MQTT 协议安全加固框架如图 15 所示。

图 15 MQTT 协议安全加固框架

安全的协议需要底层密码算法与基础设施支撑，而所有基于公钥加密的方案都可以转化为使用数字信封技术实现的对称加密的方案。因此针对消息自身的加密，主要使用适合嵌入式设备的轻量级分组密码算法，如国际标准化组织（International Organization for Standardization，ISO）、 国 际 电 工委 员 会（International Electrotechnical Commission，IEC）轻量级分组密码标准：PRESENT、CLEFIA[8]与 LEA[9] 等。而分组密码的工作模式可采用伽罗瓦计数器模式（Galois Counter Mode，GCM）或使用分组密码链接消息认证码的计数器模式（Counter withCBC-MAC，CCM），来同时实现通信数据的机密性与完整性。

公 钥 密 码 算 法 主 要 用 作 密 钥 的 分 发， 椭 圆曲 线 密 码（Elliptic Curve Cryptography，ECC） 算法 相 较 于 RSA 等 更 为 轻 量， 且 基 于 身 份 的 加 密（Identity Based Encryption，IBE）、基于属性的加密（Attribute-based Encryption，ABE）、代理重加密（Proxy Re-Encryption，PRE）等加密方案多是基于 ECC 上的双线性对映射构造的。为提供公钥密码算法的管理以及身份认证等功能，需配套使用 CA和 KGC 等密码服务。

传统的 TLS 协议对于物联网设备而言负担较重，目前已出现了针对嵌入式设备的轻量级 TLS 协议，如文献 [10] 使用无证书的公钥密码体制减少认证时的开销，文献 [11] 从算法、密钥更新等环节给出了轻量级 SSL 框架，工程方面有针对小型应用程序和设备设计的嵌入式开源 SSLv3 协议栈，如MatrixSSL 等。

针对 MQTT 协议中心化、订阅机制、一对多通信等特点，应根据具体场景的业务需求与安全侧重点综合确定选择应用方式。一般情况下，在网络层使用轻量级 TLS 协议即可。也可应用其他轻量级的口令认证密钥交换协议，除 AugPAKE，还有对称口令密钥认证协议（Symmetric Password-AuthenticatedKey Exchange，SPAKE）、 Katz、Ostrovsky 以 及Yung 提出的 KOY 协议 。

对于只具备传统密码算法能力的场景，如公钥 基 础 设 施 / 认 证 中 心（Public Key Infrastructure/Certificate Authority，PKI/CA）、基于身份标识的密码 系 统（Identity-Based Cryptograph，IBC）， 基 于主题的加密能快速落地。对于想实现数据共享以及细粒度权限控制的场景，KP-ABE 能较好地满足场景需求。对于用户隐私要求较高的场景，代理重加密技术最为合适。但上述非传统密码体制也有明显的缺点，如计算复杂、对资源受限设备不友好等。

本文对 MQTT 协议的安全加固方法进行了研究、对比，并给出了一个通用的 MQTT 协议安全加固框架。该框架除适用于 MQTT 协议，对于其他物联网协议的安全加固，以及云环境下与区块链分布式场景下的隐私数据共享具有一定启发意义。