MQTT協議安全加固研究*

張詩怡，朱豪杰，黃明浩，慕瑞華

（成都衛士通信息產業股份有限公司，四川 成都 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。

（3）若U收到的Y等于0,1,1modp，則U終止協議。否則，U計算K=Y zmodp，其中z=1/(x+w×r)modq，r=H'(0x01|U|bn2bin(X))。U計算認證碼V_U=H(0x02|U|S|bn2bin(X)|bn2bin(Y)|bn2bin(K))。U將V_U發送給S。

（4）若S收到的V_U不等于H(0x02|U|S|bn2bi n(X)|bn2bin(Y)|bn2bin(K'))，其中K'=g ymodp，則S終止協議。否則S生成驗證碼V_S=H(0x03|U|S|bn2bin(X)|bn2bin(Y)|bn2bin(K'))，并將V_S發送給U。服務端生成會話密鑰SK=H(0x04|U|S|bn2bin(X)|bn2bin(Y)|bn2bin(K'))。

（5）若U收到的V_S不等于H(0x03|U|S|bn2bin(X)|bn2bin(Y)|bn2bin(K))，則終止協議。否則，U生成會話密鑰SK=H(0x04|U|S|bn2bin(X)|bn2bin(Y)|bn2bin(K))。

至此，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能較好地滿足場景需求。對于用戶隱私要求較高的場景，代理重加密技術最為合適。但上述非傳統密碼體制也有明顯的缺點，如計算復雜、對資源受限設備不友好等。

4 結語

本文對MQTT協議的安全加固方法進行了研究、對比，并給出了一個通用的MQTT協議安全加固框架。該框架除適用于MQTT協議，對于其他物聯網協議的安全加固，以及云環境下與區塊鏈分布式場景下的隱私數據共享具有一定啟發意義。