MQTT协议安全加固研究*

2022-03-01张诗怡朱豪杰黄明浩慕瑞华

通信技术 2022年12期

张诗怡，朱豪杰，黄明浩，慕瑞华

（成都卫士通信息产业股份有限公司，四川成都 610041）

0 引言

近年来物联网（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个设备[1]。因此，IoT面临的安全威胁不容忽视。

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

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

1 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所示。

表1 MQTT报文类型

MQTT协议的通信模型如图2所示。客户端使用subscribe（SUB）向代理订阅主题，代理和客户端之间使用publish（PUB）发布消息。

图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 MQTT协议安全加固方案

2.1 TLS

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

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

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

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

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

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

2.2.1 AugPAKE协议简介

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

表2 符号说明

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

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

图3 AugPAKE协议流程

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

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

（2）若S收到的X等于0,1,1modp，则S终止协议。否则，S从中选择随机数y，计算Y=(X×Wr)ymodp，其中r=H'(0x01|U|S|bn2bin(X))。S将(S,Y)发送给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等人提出了一种基于主题的加密方案[4]。该方案需使用配套的公钥基础设施，为客户端与主题生成证书，并将主题证书与其对应的私钥手动地公开给通过认证的客户端，用于消息的安全传输。

新加入主题的客户端请求主题证书的流程如图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）[5]。

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）Client_i向Broker提供属性、证书等信息进行注册。

（2）Broker生成系统主密钥（Main Secret Key，MSK）、公开参数（Public Key，PK），并将全体用户的属性集U={A1,A2,…,An}公开。

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

（4）Broker将与Client_i相关的私钥集{SKi1,SKi2,…,SKit}安全返回给它（如使用证书中的公钥加密）。

（5）Client_i对于自己订阅的每个主题，都拥有一个对应的私钥。

KP-ABE加解密流程如图12所示。

图12 KP-ABE加解密

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

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

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

（3）某个客户端Client_j收到消息后，验证密文属性是否符合自己所拥有的密钥的访问策略，若符合，则使用对应的私钥SKjk解密消息。

上述过程同样也可利用数字信封技术实现。

2.5 基于代理重加密技术

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

2.5.1 代理重加密技术简介

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

图13 代理重加密系统模型

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

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

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

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

（4）代理服务端使用重加密密钥PKi→j重加密密文Ci得Cj，将Cj发送给接收方。

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

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

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

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

图14 基于代理重加密的MQTT

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

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

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

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

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

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

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

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

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

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

3 MQTT协议安全加固框架

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[7]、CLEFIA[8]与LEA[9]等。而分组密码的工作模式可采用伽罗瓦计数器模式（Galois Counter Mode，GCM）或使用分组密码链接消息认证码的计数器模式（Counter with CBC-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[12]等。

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

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