MQTT協(xié)議安全加固研究*

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

（成都衛(wèi)士通信息產(chǎn)業(yè)股份有限公司，四川 成都 610041）

0 引言

近年來物聯(lián)網(wǎng)（Internet of Things，IoT）飛速發(fā)展，隨著其應(yīng)用范圍越來越廣泛，物聯(lián)網(wǎng)面臨的安全威脅也逐漸呈現(xiàn)出大規(guī)模、多樣化、高頻次等特點。根據(jù)國家計算機網(wǎng)絡(luò)應(yīng)急技術(shù)處理協(xié)調(diào)中心的監(jiān)測數(shù)據(jù)，僅2022年7月，共捕獲物聯(lián)網(wǎng)惡意樣本471 158個，發(fā)現(xiàn)物聯(lián)網(wǎng)惡意程序傳播IP地址55 163個，發(fā)現(xiàn)活躍的僵尸網(wǎng)絡(luò)命令和控制（Command and Control，C&C）服務(wù)器地址2 021個，其地址位置主要分布在美國（33.6%）、中國（8.5%）、俄羅斯（6.7%）等國家。其中，來自美國的680個C&C服務(wù)器控制了中國境內(nèi)的373 080個設(shè)備[1]。因此，IoT面臨的安全威脅不容忽視。

消息隊列遙測傳輸（Message Queuing Telemetry Transport，MQTT）協(xié)議是一個超輕量級的發(fā)布（publish）/訂閱（subscribe）消息傳輸協(xié)議，是專為受限設(shè)備和低帶寬、高延遲或不可靠的網(wǎng)絡(luò)而設(shè)計的。該協(xié)議第1個版本由IBM公司在1999年發(fā)布，版本v3.1.1于2014年成為結(jié)構(gòu)化信息標準促進組織（Organization for the Advancement of Structured Information Standards，OASIS）的標準，其最新版本為MQTT v5.0[2]。

MQTT協(xié)議非常適用于需要代碼占用較小空間或網(wǎng)絡(luò)帶寬非常寶貴的遠程連接。這些特性也使該協(xié)議成為新興的機器到機器（Machine to Machine，M2M）或IoT世界的連接設(shè)備，以及帶寬和電池功率非常高的移動應(yīng)用的理想選擇。MQTT協(xié)議的常見應(yīng)用場景有大規(guī)模傳感器網(wǎng)絡(luò)數(shù)據(jù)采集、智慧家居互聯(lián)、移動及時消息推送等。

1 MQTT協(xié)議簡介與安全需求分析

1.1 MQTT協(xié)議簡介

MQTT協(xié)議中只有客戶端（Client）和MQTT代理服務(wù)器（Broker）兩個角色，以及一個關(guān)鍵概念：主題（Topic）。

客戶端（Client）：使用MQTT的程序或設(shè)備，具有消息發(fā)送和接收能力。客戶端之間不能直接通信，所有客戶端需與代理服務(wù)器（簡稱代理）連接，彼此間的通信全都要經(jīng)過Broker的轉(zhuǎn)發(fā)。

代理服務(wù)器（Broker）：為MQTT服務(wù)端，是一個代理中介，主要實現(xiàn)主題管理、消息接收、消息路由和消息存儲等業(yè)務(wù)。

主題（Topic）：為附著于應(yīng)用消息的標簽，可以被客戶端訂閱?？蛻舳税l(fā)布消息時指明該消息屬于的主題，代理將該條消息推送給所有訂閱了這個主題的客戶端。

可見，MQTT通信是標準的異步通信模式，各個客戶端是對等關(guān)系。

如圖1所示，MQTT的報文由固定頭、可變頭和有效荷載3部分組成。其中固定頭為必選項，長度為2字節(jié)；可變頭和有效荷載是可選項，載荷部分最大支持256 MB的數(shù)據(jù)。

圖1 MQTT協(xié)議報文數(shù)據(jù)格式

MQTT報文第1字節(jié)的前4個比特為MQTT控制報文類型，除0與15為Reserved保留外，還規(guī)定了剩下的14種控制報文類型，如表1所示。

表1 MQTT報文類型

MQTT協(xié)議的通信模型如圖2所示?？蛻舳耸褂胹ubscribe（SUB）向代理訂閱主題，代理和客戶端之間使用publish（PUB）發(fā)布消息。

圖2 MQTT協(xié)議通信模型

1.2 MQTT協(xié)議安全分析

MQTT協(xié)議面臨的安全風(fēng)險主要是由認證、鑒權(quán)、數(shù)據(jù)傳輸，以及代理的可信性的安全缺陷帶來的，這也對應(yīng)著其安全需求。

1.2.1 認證

MQTT協(xié)議的CONNECT報文中提供了可選的用戶名（UserName）+口令（PassWord）的認證方式。其中UserName字段為一個字符串，PassWord字段為二進制類型，最大支持65 535 Byte的長度。該認證方式簡單，且口令在傳輸過程中是明文。此外，若不設(shè)置認證機制，可以有無限多客戶端連接到代理，對代理造成很大的連接沖擊。

1.2.2 鑒權(quán)

MQTT協(xié)議中規(guī)定按照層級劃分主題，并規(guī)定了兩個特殊字符“?！焙汀埃保@兩個特殊字符導(dǎo)致訂閱者在不知道主題的情況下就能夠?qū)υ撝黝}進行訂閱，而MQTT協(xié)議本身并沒有給出訪問控制相關(guān)的說明。

1.2.3 數(shù)據(jù)傳輸

MQTT協(xié)議數(shù)據(jù)本身都是明文傳輸?shù)模瑪?shù)據(jù)傳輸過程中面臨著機密性與完整性被破壞的風(fēng)險。

1.2.4 代理的可信性

代理是整個MQTT協(xié)議的核心，客戶端間發(fā)送的數(shù)據(jù)均會在代理處落地。若代理不可信，則整個MQTT通信網(wǎng)絡(luò)毫無安全可言。

2 MQTT協(xié)議安全加固方案

2.1 TLS

安全傳輸層協(xié)議（Transport Layer Security，TLS）是多數(shù)MQTT協(xié)議使用者首選的安全通信方案，也是業(yè)界使用最廣泛的MQTT安全解決方案。該方案在傳輸層解決了認證與數(shù)據(jù)安全的問題，但也有如下弊端：

（1）TLS占用CPU與硬件存儲，對資源受限的物聯(lián)網(wǎng)設(shè)備而言開銷較大。

（2）所有加密數(shù)據(jù)在經(jīng)過代理時必須先解密，再加密給接收方，帶來了大量加解密運算開銷。同時，代理是整個通信網(wǎng)絡(luò)的性能瓶頸，也面臨著可信性的問題。

（3）物聯(lián)網(wǎng)設(shè)備中節(jié)點狀態(tài)動態(tài)變化迅速，對節(jié)點安全憑證的管理難度大。

2.2 增強的口令認證密鑰交換協(xié)議

相較于TLS協(xié)議需花費大量字節(jié)用于認證和密鑰協(xié)商，增強的口令認證密鑰交換（Augmented Password Authenticated Key Exchange，AugPAKE）協(xié)議[3]利用口令完成了客戶端接入代理時的雙向認證，同時基于D-H（Diffee-Hellman）密鑰交換，協(xié)商了后續(xù)通信過程中使用的對稱密鑰（一般是AES密鑰）。

2.2.1 AugPAKE協(xié)議簡介

令p和q是兩個大素數(shù)，且q是(p-1)/2的因子，同時(p-1)/2的每個因子都是與q大小相當?shù)乃財?shù)。使用模p的整數(shù)群來表示有限域GF(p)上的q階乘法子群，G=Zq。令g是子群G的生成元，即G=＜g＞。AugPAKE協(xié)議可在群G中實現(xiàn)。表2給出了AugPAKE協(xié)議涉及的符號說明。

表2 符號說明

初始化時，用戶U計算W=gw'，其中w'是有效口令，并將W發(fā)送給S，作為向S的注冊口令。

協(xié)議執(zhí)行流程如圖3所示。

圖3 AugPAKE協(xié)議流程

AugPAKE協(xié)議具體的執(zhí)行流程描述如下：

（1）用戶U從Zq*中選擇隨機數(shù)x，計算DH公開值X=gxmodp，并將(U,X)發(fā)送給服務(wù)端S。

（2）若S收到的X等于0,1,1modp，則S終止協(xié)議。否則，S從中選擇隨機數(shù)y，計算Y=(X×Wr)ymodp，其中r=H'(0x01|U|S|bn2bin(X))。S將(S,Y)發(fā)送給U。

（3）若U收到的Y等于0,1,1modp，則U終止協(xié)議。否則，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發(fā)送給S。

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

至此，U和S間基于口令完成了雙向身份認證，并產(chǎn)生了后續(xù)加密消息的會話密鑰SK。

2.2.2 基于AugPAKE的MQTT

設(shè)發(fā)方客戶端ClientA與收方客戶端ClientB分別通過AugPAKE協(xié)議與代理建立了會話密鑰SKa與SKb。圖4給出了基于AugPAKE協(xié)議的MQTT通信流程。

圖4 基于AugPAKE的MQTT

基于AugPAKE協(xié)議的MQTT通信流程如下：

（1）ClientA使用SKa加密該主題下待發(fā)布的消息，并將消息密文發(fā)送給代理。

（2）Broker使用SKa解密消息，然后分別使用訂閱了該主題的所有客戶端的會話密鑰加密明文消息，將密文推送給收方客戶端，如使用同ClientB共享的SKb再次加密消息。

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

綜上，AugPAKE可視作較輕量的TLS，它也可以被其他認證密鑰交換協(xié)議替換。

2.3 基于主題的加密方案

由于MQTT的消息推送是與主題相關(guān)的，因此容易想到基于主題對消息進行加密。相較于TLS與AugPAKE方案，基于主題的加密方案可以避免密文消息在Broker處的解密與重新加密。

2.3.1 非對稱主題密鑰分發(fā)與消息加解密

2016年，Mektoubi等人提出了一種基于主題的加密方案[4]。該方案需使用配套的公鑰基礎(chǔ)設(shè)施，為客戶端與主題生成證書，并將主題證書與其對應(yīng)的私鑰手動地公開給通過認證的客戶端，用于消息的安全傳輸。

新加入主題的客戶端請求主題證書的流程如圖5所示，首次請求主題私鑰的流程如圖6所示。圖5和圖6省略了Broker的轉(zhuǎn)發(fā)過程。

圖5 新加入主題的客戶端請求主題證書

圖6 首次請求主題私鑰

新加入主題的客戶端請求主題證書的具體流程描述如下：

（1）當新加入主題的客戶端Client1要加密消息時，它首先需請求主題的證書，發(fā)布Requset Topic消息。

（2）某個已訂閱該主題的客戶端Client2監(jiān)聽到請求，檢查自己是否擁有主題的證書，若有，則返回Response Topic消息，里面包含主題的證書。

（3）Client1收到主題證書，驗證其有效性（CA簽名等）。

首次請求主題私鑰的具體流程如下：

（1）首次解密消息時，Client1需請求主題的私鑰，發(fā)送Request Privatekey消息，其中包含用主題證書公鑰加密的Client1的證書。

（2）某個已訂閱該主題的客戶端Client3監(jiān)聽到請求，檢查主題私鑰是否可用。若可用，則使用主題私鑰解密得Client1證書。

（3）Client3驗證Client1證書的有效性，并用Client1證書公鑰加密主題私鑰，構(gòu)造并返回Response Privatekey消息。

（4）Client1收到Response Privatekey消息后，使用自己證書對應(yīng)的私鑰進行解密，獲得主題私鑰。

至此，Mektoubi等人的方案完成了主題證書與私鑰的分發(fā)，Client1可用其對MQTT通信消息進行加解密。實際上，還可利用數(shù)字信封技術(shù)實現(xiàn)會話加密，如圖7所示。

圖7 基于主題加密的MQTT——數(shù)字信封

利用數(shù)字信封實現(xiàn)基于主題加密的MQTT流程如下：

（1）發(fā)方客戶端Client1產(chǎn)生會話密鑰key，用key加密某個主題下的消息。

（2）Client1使用主題證書的公鑰加密key，并將key的密文寫入MQTT載荷。

（3）Client1將消息發(fā)給Broker，Broker將之推送給所有訂閱了相關(guān)主題的客戶端，如Client4。

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

2.3.2 對稱主題密鑰分發(fā)與消息加解密

為不同主題生成相應(yīng)的主題密鑰（對稱密鑰），在客戶端訂閱主題時獲取主題密鑰，使用主題密鑰來加密該主題下的所有消息。

如圖8所示為客戶端注冊流程?？蛻舳俗詴r需提交加密公鑰、證書、身份標識等，用于主題密鑰的分發(fā)。主題密鑰的生成與分發(fā)流程如圖9所示。

圖8 客戶端注冊

圖9 主題密鑰的生成與分發(fā)

主題密鑰的生成與分發(fā)的具體流程描述如下：

（1）Broker為每個主題生成的主題密鑰，可根據(jù)主題層級利用密鑰衍生算法產(chǎn)生。

（2）客戶端訂閱主題時，從Broker處安全獲取主題密鑰，主題密鑰可使用客戶端提交的公鑰、證書、身份標識等加密。

基于主題的加密流程如圖10所示。

圖10 基于主題的加密

基于主題的加密流程具體描述如下：

（1）發(fā)方客戶端Client1使用主題密鑰加密該主題下待發(fā)布的消息；

（2）Broker將該密文消息推送給所有訂閱了該主題的客戶端；

（3）收方客戶端收到密文消息，使用對應(yīng)的主題密鑰解密。

由于主題密鑰是預(yù)先生成的，故Broker需維護與主題等量的主題密鑰。當主題密鑰采用層級衍生時，Broker可只維護最頂層密鑰，要用時實時生成，以減少密鑰存儲量。

2.4 基于屬性的加密方案

相較于傳統(tǒng)的公鑰密碼算法，基于屬性的加密（Attribute-Based Encryption，ABE）能較好地滿足一對多的通信場景，同時還能對數(shù)據(jù)的訪問進行細粒度的控制，非常適合MQTT協(xié)議的訂閱—推送機制。典型的基于屬性加密構(gòu)造的MQTT安全通信解決方案有安全消息隊列遙測傳輸協(xié)議（Secure Message Queuing Telemetry Transport，SMQTT）[5]。

2.4.1 屬性加密簡介

所謂屬性是指某個對象所具備的性質(zhì)，如性別、年齡、學(xué)歷等組成該對象的屬性集。訪問策略（簡稱策略）指由屬性及它們間的關(guān)系所組成的一個邏輯表達式，一般用樹形結(jié)構(gòu)表示。若屬性集合使得策略的邏輯表達式為真，稱屬性與策略匹配，允許用戶執(zhí)行相關(guān)操作。

在基于屬性的加密中，根據(jù)設(shè)計者將屬性集合與策略嵌入到用戶私鑰還是密文中，可分為密鑰策略屬性加密（Key Policy-Attribute-Based Ecryption，KP-ABE）與密文策略屬性加密（Ciphertext Policy-Attribute-Based Ecryption，CP-ABE）兩個方案，二者是等價的。

KP-ABE的訪問策略由服務(wù)端產(chǎn)生，作為產(chǎn)生用戶私鑰的輸入。消息發(fā)布方在加密消息時，需用屬性集合生成密文索引。解密時要求密文索引滿足密鑰訪問策略，用戶才能正確解密。由于訪問策略是服務(wù)端制定的，因此該方案適用于靜態(tài)場景，如付費點播等。

CP-ABE的訪問策略由消息發(fā)布方產(chǎn)生，加密消息時作為輸入，生成密文索引。用戶私鑰的生成需輸入用戶屬性，只有屬性滿足密文訪問策略的用戶才能正確解密。該方案中數(shù)據(jù)擁有者可以通過設(shè)定策略來決定擁有哪些屬性的人能夠訪問這份密文，一般應(yīng)用于公有云上的數(shù)據(jù)加密存儲與基于屬性的細粒度共享。

2.4.2 與屬性加密結(jié)合的MQTT

文獻[5]中考慮到用戶對發(fā)布消息的細粒度訪問控制，采用的是基于CP-ABE的加密方式?？紤]到適配MQTT訂閱—推送的機制，結(jié)合基于主題加密的思想，本文采用KP-ABE的加密方式，為訂閱了不同主題的用戶生成訪問策略。

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

圖11 KP-ABE初始化

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

（1）Client_i向Broker提供屬性、證書等信息進行注冊。

（2）Broker生成系統(tǒng)主密鑰（Main Secret Key，MSK）、公開參數(shù)（Public Key，PK），并將全體用戶的屬性集U={A1,A2,…,An}公開。

（3）Broker針對不同的主題，根據(jù)訂閱的用戶生成訪問策略，并以此為輸入生成用戶的私鑰。

（4）Broker將 與Client_i相關(guān)的私鑰集{SKi1,SKi2,…,SKit}安全返回給它（如使用證書中的公鑰加密）。

（5）Client_i對于自己訂閱的每個主題，都擁有一個對應(yīng)的私鑰。

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

圖12 KP-ABE加解密

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

（1）消息發(fā)布方Client_i使用公開參數(shù)PK與加密屬性集（該消息所屬主題）加密待發(fā)布的消息，將密文消息推送給Broker。

（2）Broker將該消息推送給訂閱了相關(guān)主題的客戶端。

（3）某個客戶端Client_j收到消息后，驗證密文屬性是否符合自己所擁有的密鑰的訪問策略，若符合，則使用對應(yīng)的私鑰SKjk解密消息。

上述過程同樣也可利用數(shù)字信封技術(shù)實現(xiàn)。

2.5 基于代理重加密技術(shù)

代理重加密（Proxy Re-Enceyption，PRE）技術(shù)可以在代理不解密的情況下，將發(fā)送方公鑰加密的密文轉(zhuǎn)化為可被接收方私鑰解密的密文，能較好地解決MQTT中Broker的可信性問題。

2.5.1 代理重加密技術(shù)簡介

代理重加密系統(tǒng)模型如圖13所示。

圖13 代理重加密系統(tǒng)模型

代理重加密的流程具體為：

（1）初始化時，各通信客戶端需向密鑰生成中心（Key Generation Center，KGC）請求自己的加密公私鑰對(PK,SK)。

（2）KGC使用消息發(fā)送方客戶端的私鑰SKi與接收方的公鑰PKj作為輸入，生成代理重加密密鑰PKi→j，并將之安全地傳輸給代理服務(wù)端。

（3）發(fā)送方使用自己的公鑰PKi加密明文消息m，得密文Ci，并將之上傳到代理服務(wù)端。

（4）代理服務(wù)端使用重加密密鑰PKi→j重加密密文Ci得Cj，將Cj發(fā)送給接收方。

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

常規(guī)的PRE方案中，代理方重加密次數(shù)與接收者人數(shù)成正比，消耗較多的網(wǎng)絡(luò)資源，并且發(fā)送者不能對云端的重加密對象做細粒度控制。

2.5.2 基于代理重加密技術(shù)的MQTT

文獻[6]給出了一種基于代理重加密技術(shù)實現(xiàn)MQTT通信中發(fā)布者與訂閱者間端到端數(shù)據(jù)安全傳輸?shù)慕鉀Q方案，如圖14所示。該方案中，KGC根據(jù)設(shè)備注冊的屬性（發(fā)布/訂閱）和主題進行匹配，為每對的發(fā)布者—訂閱者對等方預(yù)生成重加密密鑰，并將生成的重加密密鑰通過安全的方式發(fā)送給Broker。

圖14 基于代理重加密的MQTT

初始化時，客戶端需向KGC申請自己的加密公私鑰對與簽名公私鑰，分別用于會話密鑰的分發(fā)消息與簽名。其中，簽名公鑰為客戶端的唯一身份標識，實際加密消息的密鑰為會話密鑰。

基于代理重加密技術(shù)的MQTT的具體實現(xiàn)流程如下：

（1）發(fā)方客戶端Client_i產(chǎn)生會話密鑰key，使用自己的加密公鑰PKEnci加密key，得密文Ckeyi。

（2）Client_i使用自己的簽名私鑰SKSigni對待發(fā)布的消息m進行簽名，得sig，并用key加密m||sig。

（3）Client_i將密文消息、Ckeyi和自己的唯一身份標識UUIDi（簽名公鑰）發(fā)送到Broker。

（4）Broker查詢訂閱了該條消息所屬主題的客戶端有哪些，并使用相應(yīng)的重加密密鑰RKij重加密Ckeyi，得會話密鑰密文Ckeyj。

（5）Broker使用keyi重加密會話密鑰密文1，得會話密鑰密文2。

（6）Broker將密文消息、Ckeyj和發(fā)方UUIDi推送給相應(yīng)收方客戶端Client_j。

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

（8）Client_j使用UUIDi驗證sig的有效性。

3 MQTT協(xié)議安全加固框架

3.1 對比與小結(jié)

設(shè)想一個MQTT通信網(wǎng)絡(luò)中有1個消息發(fā)送方與n個消息訂閱方。用E表示加密、D表示解密、T表示密鑰分發(fā)/密鑰轉(zhuǎn)保護（對密鑰解密并加密1次為1個完整的T）。本文使用上述操作出現(xiàn)的次數(shù)來直觀地衡量各方案的開銷，對比結(jié)果見表3。

如表3所示，TLS協(xié)議為成熟的網(wǎng)絡(luò)層安全通信方案，對應(yīng)用層MQTT協(xié)議透明；但傳統(tǒng)的TLS協(xié)議在物聯(lián)網(wǎng)環(huán)境中應(yīng)用的開銷較大。雖然AugPAKE協(xié)議在一定程度上降低了認證過程的開銷，但當認證完成后，方案1與方案2的數(shù)據(jù)傳輸保護方式是一樣的。

表3中后面3種方案的認證過程都是提前完成的，只有通過認證的客戶端才能獲得消息解密密鑰，進而解密消息。

表3 5種方案對比

基于主題的加密方案中，Mektoubi等人的方案是基于非對稱算法的，需要對私鑰進行分發(fā)，且非對稱加解密的效率并不高。本文給出了基于對稱算法的主題加密與密鑰衍生，維護的密鑰量并不比Mektoubi等人的方案多，且加解密效率更高。

基于屬性的加密能很好地實現(xiàn)一對多的數(shù)據(jù)分發(fā)，且可以對數(shù)據(jù)的訪問進行控制，這是方案4相較于其他方案最大的優(yōu)勢。本文給出的是基于KPABE的屬性加密方案，相較于文獻[4]推薦的CPABE，雖然不能由數(shù)據(jù)擁有者對數(shù)據(jù)的訪問進行控制，但更適合MQTT協(xié)議的訂閱—推送機制，然而其本質(zhì)仍是控制對主題密鑰的訪問。

方案5相較于其他方案的優(yōu)勢在于代理重加密技術(shù)可以較好地解決Broker的可信性問題。加密消息的密鑰由數(shù)據(jù)擁有者產(chǎn)生，Broker不能獲取數(shù)據(jù)明文。但方案5仍是一對一的方案，針對不同用戶的分享要生成不同的重加密密鑰。

3.2 框架

基于上文的分析，給出MQTT協(xié)議安全加固框架如圖15所示。

圖15 MQTT協(xié)議安全加固框架

安全的協(xié)議需要底層密碼算法與基礎(chǔ)設(shè)施支撐，而所有基于公鑰加密的方案都可以轉(zhuǎn)化為使用數(shù)字信封技術(shù)實現(xiàn)的對稱加密的方案。因此針對消息自身的加密，主要使用適合嵌入式設(shè)備的輕量級分組密碼算法，如國際標準化組織（International Organization for Standardization，ISO）、國際電工委員會（International Electrotechnical Commission，IEC）輕量級分組密碼標準：PRESENT[7]、CLEFIA[8]與LEA[9]等。而分組密碼的工作模式可采用伽羅瓦計數(shù)器模式（Galois Counter Mode，GCM）或使用分組密碼鏈接消息認證碼的計數(shù)器模式（Counter with CBC-MAC，CCM），來同時實現(xiàn)通信數(shù)據(jù)的機密性與完整性。

公鑰密碼算法主要用作密鑰的分發(fā)，橢圓曲線密碼（Elliptic Curve Cryptography，ECC）算法相較于RSA等更為輕量，且基于身份的加密（Identity Based Encryption，IBE）、基于屬性的加密（Attribute-based Encryption，ABE）、代理重加密（Proxy Re-Encryption，PRE）等加密方案多是基于ECC上的雙線性對映射構(gòu)造的。為提供公鑰密碼算法的管理以及身份認證等功能，需配套使用CA和KGC等密碼服務(wù)。

傳統(tǒng)的TLS協(xié)議對于物聯(lián)網(wǎng)設(shè)備而言負擔(dān)較重，目前已出現(xiàn)了針對嵌入式設(shè)備的輕量級TLS協(xié)議，如文獻[10]使用無證書的公鑰密碼體制減少認證時的開銷，文獻[11]從算法、密鑰更新等環(huán)節(jié)給出了輕量級SSL框架，工程方面有針對小型應(yīng)用程序和設(shè)備設(shè)計的嵌入式開源SSLv3協(xié)議棧，如MatrixSSL[12]等。

針對MQTT協(xié)議中心化、訂閱機制、一對多通信等特點，應(yīng)根據(jù)具體場景的業(yè)務(wù)需求與安全側(cè)重點綜合確定選擇應(yīng)用方式。一般情況下，在網(wǎng)絡(luò)層使用輕量級TLS協(xié)議即可。也可應(yīng)用其他輕量級的口令認證密鑰交換協(xié)議，除AugPAKE，還有對稱口令密鑰認證協(xié)議（Symmetric Password-Authenticated Key Exchange，SPAKE）[13]、Katz、Ostrovsky以及Yung提出的KOY協(xié)議[14]。

對于只具備傳統(tǒng)密碼算法能力的場景，如公鑰基礎(chǔ)設(shè)施/認證中心（Public Key Infrastructure/Certificate Authority，PKI/CA）、基于身份標識的密碼系統(tǒng)（Identity-Based Cryptograph，IBC），基于主題的加密能快速落地。對于想實現(xiàn)數(shù)據(jù)共享以及細粒度權(quán)限控制的場景，KP-ABE能較好地滿足場景需求。對于用戶隱私要求較高的場景，代理重加密技術(shù)最為合適。但上述非傳統(tǒng)密碼體制也有明顯的缺點，如計算復(fù)雜、對資源受限設(shè)備不友好等。

4 結(jié)語

本文對MQTT協(xié)議的安全加固方法進行了研究、對比，并給出了一個通用的MQTT協(xié)議安全加固框架。該框架除適用于MQTT協(xié)議，對于其他物聯(lián)網(wǎng)協(xié)議的安全加固，以及云環(huán)境下與區(qū)塊鏈分布式場景下的隱私數(shù)據(jù)共享具有一定啟發(fā)意義。