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

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

張?jiān)娾?，朱豪杰，黃明浩，慕瑞華（成都衛(wèi)士通信息產(chǎn)業(yè)股份有限公司，四川成都610041）0引言近年來物聯(lián)網(wǎng)（InternetofThings，IoT）飛速發(fā)展，隨著其應(yīng)用范圍越來越廣泛，物聯(lián)網(wǎng)面臨的安全威脅也逐漸呈現(xiàn)出大規(guī)模、多樣化、高頻次等特點(diǎn)。根據(jù)國(guó)家計(jì)算機(jī)網(wǎng)絡(luò)應(yīng)急技術(shù)處理協(xié)調(diào)中心的監(jiān)測(cè)數(shù)據(jù)，僅2022年7月，共捕獲物聯(lián)網(wǎng)惡意樣本471158個(gè)，發(fā)現(xiàn)物聯(lián)網(wǎng)惡意程序傳播IP地址55163個(gè)，發(fā)現(xiàn)活躍的僵尸網(wǎng)絡(luò)命令和控制（CommandandControl，C&C）服務(wù)器地址2021個(gè)，其地址位置主要分布在美國(guó)（33.6%）、中國(guó)（8.5%）、俄羅斯（6.7%）等國(guó)家。其中，來自美國(guó)的680個(gè)C&C服務(wù)器控制了中國(guó)境內(nèi)的373080個(gè)設(shè)備[1]。因此，IoT面臨的安全威脅不容忽視。消息隊(duì)列遙測(cè)傳輸（MessageQueuingTelemetryTransport，MQTT）協(xié)議是一個(gè)超輕量級(jí)的發(fā)布（publish）/訂閱（subscribe）消息傳輸協(xié)議，是專為受限設(shè)備和低帶寬、高延遲或不可靠的網(wǎng)絡(luò)而設(shè)計(jì)的。該協(xié)議第1個(gè)版本由IBM公司在1999年發(fā)布，版本v3.1.1于2014年成為結(jié)構(gòu)化信息標(biāo)準(zhǔn)促進(jìn)組織（OrganizationfortheAdvancementofStructuredInformationStandards，OASIS）的標(biāo)準(zhǔn)，其最新版本為MQTTv5.0[2]。MQTT協(xié)議非常適用于需要代碼占用較小空間或網(wǎng)絡(luò)帶寬非常寶貴的遠(yuǎn)程連接。這些特性也使該協(xié)議成為新興的機(jī)器到機(jī)器（MachinetoMachine，M2M）或IoT世界的連接設(shè)備，以及帶寬和電池功率非常高的移動(dòng)應(yīng)用的理想選擇。MQTT協(xié)議的常見應(yīng)用場(chǎng)景有大規(guī)模傳感器網(wǎng)絡(luò)數(shù)據(jù)采集、智慧家居互聯(lián)、移動(dòng)及時(shí)消息推送等。1MQTT協(xié)議簡(jiǎn)介與安全需求分析1.1MQTT協(xié)議簡(jiǎn)介MQTT協(xié)議中只有客戶端（Client）和MQTT代理服務(wù)器（Broker）兩個(gè)角色，以及一個(gè)關(guān)鍵概念：主題（Topic）?？蛻舳耍–lient）：使用MQTT的程序或設(shè)備，具有消息發(fā)送和接收能力。客戶端之間不能直接通信，所有客戶端需與代理服務(wù)器（簡(jiǎn)稱代理）連接，彼此間的通信全都要經(jīng)過Broker的轉(zhuǎn)發(fā)。代理服務(wù)器（Broker）：為MQTT服務(wù)端，是一個(gè)代理中介，主要實(shí)現(xiàn)主題管理、消息接收、消息路由和消息存儲(chǔ)等業(yè)務(wù)。主題（Topic）：為附著于應(yīng)用消息的標(biāo)簽，可以被客戶端訂閱?？蛻舳税l(fā)布消息時(shí)指明該消息屬于的主題，代理將該條消息推送給所有訂閱了這個(gè)主題的客戶端。可見，MQTT通信是標(biāo)準(zhǔn)的異步通信模式，各個(gè)客戶端是對(duì)等關(guān)系。如圖1所示，MQTT的報(bào)文由固定頭、可變頭和有效荷載3部分組成。其中固定頭為必選項(xiàng)，長(zhǎng)度為2字節(jié)；可變頭和有效荷載是可選項(xiàng)，載荷部分最大支持256MB的數(shù)據(jù)。圖1MQTT協(xié)議報(bào)文數(shù)據(jù)格式MQTT報(bào)文第1字節(jié)的前4個(gè)比特為MQTT控制報(bào)文類型，除0與15為Reserved保留外，還規(guī)定了剩下的14種控制報(bào)文類型，如表1所示。表1MQTT報(bào)文類型MQTT協(xié)議的通信模型如圖2所示?？蛻舳耸褂胹ubscribe（SUB）向代理訂閱主題，代理和客戶端之間使用publish（PUB）發(fā)布消息。圖2MQTT協(xié)議通信模型1.2MQTT協(xié)議安全分析MQTT協(xié)議面臨的安全風(fēng)險(xiǎn)主要是由認(rèn)證、鑒權(quán)、數(shù)據(jù)傳輸，以及代理的可信性的安全缺陷帶來的，這也對(duì)應(yīng)著其安全需求。1.2.1認(rèn)證MQTT協(xié)議的CONNECT報(bào)文中提供了可選的用戶名（UserName）+口令（PassWord）的認(rèn)證方式。其中UserName字段為一個(gè)字符串，PassWord字段為二進(jìn)制類型，最大支持65535Byte的長(zhǎng)度。該認(rèn)證方式簡(jiǎn)單，且口令在傳輸過程中是明文。此外，若不設(shè)置認(rèn)證機(jī)制，可以有無限多客戶端連接到代理，對(duì)代理造成很大的連接沖擊。1.2.2鑒權(quán)MQTT協(xié)議中規(guī)定按照層級(jí)劃分主題，并規(guī)定了兩個(gè)特殊字符“?！焙汀埃?，這兩個(gè)特殊字符導(dǎo)致訂閱者在不知道主題的情況下就能夠?qū)υ撝黝}進(jìn)行訂閱，而MQTT協(xié)議本身并沒有給出訪問控制相關(guān)的說明。1.2.3數(shù)據(jù)傳輸MQTT協(xié)議數(shù)據(jù)本身都是明文傳輸?shù)?，?shù)據(jù)傳輸過程中面臨著機(jī)密性與完整性被破壞的風(fēng)險(xiǎn)。1.2.4代理的可信性代理是整個(gè)MQTT協(xié)議的核心，客戶端間發(fā)送的數(shù)據(jù)均會(huì)在代理處落地。若代理不可信，則整個(gè)MQTT通信網(wǎng)絡(luò)毫無安全可言。2MQTT協(xié)議安全加固方案2.1TLS安全傳輸層協(xié)議（TransportLayerSecurity，TLS）是多數(shù)MQTT協(xié)議使用者首選的安全通信方案，也是業(yè)界使用最廣泛的MQTT安全解決方案。該方案在傳輸層解決了認(rèn)證與數(shù)據(jù)安全的問題，但也有如下弊端：（1）TLS占用CPU與硬件存儲(chǔ)，對(duì)資源受限的物聯(lián)網(wǎng)設(shè)備而言開銷較大。（2）所有加密數(shù)據(jù)在經(jīng)過代理時(shí)必須先解密，再加密給接收方，帶來了大量加解密運(yùn)算開銷。同時(shí)，代理是整個(gè)通信網(wǎng)絡(luò)的性能瓶頸，也面臨著可信性的問題。（3）物聯(lián)網(wǎng)設(shè)備中節(jié)點(diǎn)狀態(tài)動(dòng)態(tài)變化迅速，對(duì)節(jié)點(diǎn)安全憑證的管理難度大。2.2增強(qiáng)的口令認(rèn)證密鑰交換協(xié)議相較于TLS協(xié)議需花費(fèi)大量字節(jié)用于認(rèn)證和密鑰協(xié)商，增強(qiáng)的口令認(rèn)證密鑰交換（AugmentedPasswordAuthenticatedKeyExchange，AugPAKE）協(xié)議[3]利用口令完成了客戶端接入代理時(shí)的雙向認(rèn)證，同時(shí)基于D-H（Diffee-Hellman）密鑰交換，協(xié)商了后續(xù)通信過程中使用的對(duì)稱密鑰（一般是AES密鑰）。2.2.1AugPAKE協(xié)議簡(jiǎn)介令p和q是兩個(gè)大素?cái)?shù)，且q是(p-1)/2的因子，同時(shí)(p-1)/2的每個(gè)因子都是與q大小相當(dāng)?shù)乃財(cái)?shù)。使用模p的整數(shù)群來表示有限域GF(p)上的q階乘法子群，G=Zq。令g是子群G的生成元，即G=＜g＞。AugPAKE協(xié)議可在群G中實(shí)現(xiàn)。表2給出了AugPAKE協(xié)議涉及的符號(hào)說明。表2符號(hào)說明初始化時(shí)，用戶U計(jì)算W=gw'，其中w'是有效口令，并將W發(fā)送給S，作為向S的注冊(cè)口令。協(xié)議執(zhí)行流程如圖3所示。圖3AugPAKE協(xié)議流程AugPAKE協(xié)議具體的執(zhí)行流程描述如下：（1）用戶U從Zq*中選擇隨機(jī)數(shù)x，計(jì)算DH公開值X=gxmodp，并將(U,X)發(fā)送給服務(wù)端S。（2）若S收到的X等于0,1,1modp，則S終止協(xié)議。否則，S從中選擇隨機(jī)數(shù)y，計(jì)算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計(jì)算K=Yzmodp，其中z=1/(x+w×r)modq，r=H'(0x01|U|bn2bin(X))。U計(jì)算認(rèn)證碼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|bn2bin(X)|bn2bin(Y)|bn2bin(K'))，其中K'=gymodp，則S終止協(xié)議。否則S生成驗(yàn)證碼V_S=H(0x03|U|S|bn2bin(X)|bn2bin(Y)|bn2bin(K'))，并將V_S發(fā)送給U。服務(wù)端生成會(huì)話密鑰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生成會(huì)話密鑰SK=H(0x04|U|S|bn2bin(X)|bn2bin(Y)|bn2bin(K))。至此，U和S間基于口令完成了雙向身份認(rèn)證，并產(chǎn)生了后續(xù)加密消息的會(huì)話密鑰SK。2.2.2基于AugPAKE的MQTT設(shè)發(fā)方客戶端ClientA與收方客戶端ClientB分別通過AugPAKE協(xié)議與代理建立了會(huì)話密鑰SKa與SKb。圖4給出了基于AugPAKE協(xié)議的MQTT通信流程。圖4基于AugPAKE的MQTT基于AugPAKE協(xié)議的MQTT通信流程如下：（1）ClientA使用SKa加密該主題下待發(fā)布的消息，并將消息密文發(fā)送給代理。（2）Broker使用SKa解密消息，然后分別使用訂閱了該主題的所有客戶端的會(huì)話密鑰加密明文消息，將密文推送給收方客戶端，如使用同ClientB共享的SKb再次加密消息。（3）ClientB使用SKb解密消息。綜上，AugPAKE可視作較輕量的TLS，它也可以被其他認(rèn)證密鑰交換協(xié)議替換。2.3基于主題的加密方案由于MQTT的消息推送是與主題相關(guān)的，因此容易想到基于主題對(duì)消息進(jìn)行加密。相較于TLS與AugPAKE方案，基于主題的加密方案可以避免密文消息在Broker處的解密與重新加密。2.3.1非對(duì)稱主題密鑰分發(fā)與消息加解密2016年，Mektoubi等人提出了一種基于主題的加密方案[4]。該方案需使用配套的公鑰基礎(chǔ)設(shè)施，為客戶端與主題生成證書，并將主題證書與其對(duì)應(yīng)的私鑰手動(dòng)地公開給通過認(rèn)證的客戶端，用于消息的安全傳輸。新加入主題的客戶端請(qǐng)求主題證書的流程如圖5所示，首次請(qǐng)求主題私鑰的流程如圖6所示。圖5和圖6省略了Broker的轉(zhuǎn)發(fā)過程。圖5新加入主題的客戶端請(qǐng)求主題證書圖6首次請(qǐng)求主題私鑰新加入主題的客戶端請(qǐng)求主題證書的具體流程描述如下：（1）當(dāng)新加入主題的客戶端Client1要加密消息時(shí)，它首先需請(qǐng)求主題的證書，發(fā)布RequsetTopic消息。（2）某個(gè)已訂閱該主題的客戶端Client2監(jiān)聽到請(qǐng)求，檢查自己是否擁有主題的證書，若有，則返回ResponseTopic消息，里面包含主題的證書。（3）Client1收到主題證書，驗(yàn)證其有效性（CA簽名等）。首次請(qǐng)求主題私鑰的具體流程如下：（1）首次解密消息時(shí)，Client1需請(qǐng)求主題的私鑰，發(fā)送RequestPrivatekey消息，其中包含用主題證書公鑰加密的Client1的證書。（2）某個(gè)已訂閱該主題的客戶端Client3監(jiān)聽到請(qǐng)求，檢查主題私鑰是否可用。若可用，則使用主題私鑰解密得Client1證書。（3）Client3驗(yàn)證Client1證書的有效性，并用Client1證書公鑰加密主題私鑰，構(gòu)造并返回ResponsePrivatekey消息。（4）Client1收到ResponsePrivatekey消息后，使用自己證書對(duì)應(yīng)的私鑰進(jìn)行解密，獲得主題私鑰。至此，Mektoubi等人的方案完成了主題證書與私鑰的分發(fā)，Client1可用其對(duì)MQTT通信消息進(jìn)行加解密。實(shí)際上，還可利用數(shù)字信封技術(shù)實(shí)現(xiàn)會(huì)話加密，如圖7所示。圖7基于主題加密的MQTT——數(shù)字信封利用數(shù)字信封實(shí)現(xiàn)基于主題加密的MQTT流程如下：（1）發(fā)方客戶端Client1產(chǎn)生會(huì)話密鑰key，用key加密某個(gè)主題下的消息。（2）Client1使用主題證書的公鑰加密key，并將key的密文寫入MQTT載荷。（3）Client1將消息發(fā)給Broker，Broker將之推送給所有訂閱了相關(guān)主題的客戶端，如Client4。（4）Client4先使用主題私鑰解密key，再使用key解密消息。2.3.2對(duì)稱主題密鑰分發(fā)與消息加解密為不同主題生成相應(yīng)的主題密鑰（對(duì)稱密鑰），在客戶端訂閱主題時(shí)獲取主題密鑰，使用主題密鑰來加密該主題下的所有消息。如圖8所示為客戶端注冊(cè)流程?？蛻舳俗?cè)時(shí)需提交加密公鑰、證書、身份標(biāo)識(shí)等，用于主題密鑰的分發(fā)。主題密鑰的生成與分發(fā)流程如圖9所示。圖8客戶端注冊(cè)圖9主題密鑰的生成與分發(fā)主題密鑰的生成與分發(fā)的具體流程描述如下：（1）Broker為每個(gè)主題生成的主題密鑰，可根據(jù)主題層級(jí)利用密鑰衍生算法產(chǎn)生。（2）客戶端訂閱主題時(shí)，從Broker處安全獲取主題密鑰，主題密鑰可使用客戶端提交的公鑰、證書、身份標(biāo)識(shí)等加密?；谥黝}的加密流程如圖10所示。圖10基于主題的加密基于主題的加密流程具體描述如下：（1）發(fā)方客戶端Client1使用主題密鑰加密該主題下待發(fā)布的消息；（2）Broker將該密文消息推送給所有訂閱了該主題的客戶端；（3）收方客戶端收到密文消息，使用對(duì)應(yīng)的主題密鑰解密。由于主題密鑰是預(yù)先生成的，故Broker需維護(hù)與主題等量的主題密鑰。當(dāng)主題密鑰采用層級(jí)衍生時(shí)，Broker可只維護(hù)最頂層密鑰，要用時(shí)實(shí)時(shí)生成，以減少密鑰存儲(chǔ)量。2.4基于屬性的加密方案相較于傳統(tǒng)的公鑰密碼算法，基于屬性的加密（Attribute-BasedEncryption，ABE）能較好地滿足一對(duì)多的通信場(chǎng)景，同時(shí)還能對(duì)數(shù)據(jù)的訪問進(jìn)行細(xì)粒度的控制，非常適合MQTT協(xié)議的訂閱—推送機(jī)制。典型的基于屬性加密構(gòu)造的MQTT安全通信解決方案有安全消息隊(duì)列遙測(cè)傳輸協(xié)議（SecureMessageQueuingTelemetryTransport，SMQTT）[5]。2.4.1屬性加密簡(jiǎn)介所謂屬性是指某個(gè)對(duì)象所具備的性質(zhì)，如性別、年齡、學(xué)歷等組成該對(duì)象的屬性集。訪問策略（簡(jiǎn)稱策略）指由屬性及它們間的關(guān)系所組成的一個(gè)邏輯表達(dá)式，一般用樹形結(jié)構(gòu)表示。若屬性集合使得策略的邏輯表達(dá)式為真，稱屬性與策略匹配，允許用戶執(zhí)行相關(guān)操作。在基于屬性的加密中，根據(jù)設(shè)計(jì)者將屬性集合與策略嵌入到用戶私鑰還是密文中，可分為密鑰策略屬性加密（KeyPolicy-Attribute-BasedEcryption，KP-ABE）與密文策略屬性加密（CiphertextPolicy-Attribute-BasedEcryption，CP-ABE）兩個(gè)方案，二者是等價(jià)的。KP-ABE的訪問策略由服務(wù)端產(chǎn)生，作為產(chǎn)生用戶私鑰的輸入。消息發(fā)布方在加密消息時(shí)，需用屬性集合生成密文索引。解密時(shí)要求密文索引滿足密鑰訪問策略，用戶才能正確解密。由于訪問策略是服務(wù)端制定的，因此該方案適用于靜態(tài)場(chǎng)景，如付費(fèi)點(diǎn)播等。CP-ABE的訪問策略由消息發(fā)布方產(chǎn)生，加密消息時(shí)作為輸入，生成密文索引。用戶私鑰的生成需輸入用戶屬性，只有屬性滿足密文訪問策略的用戶才能正確解密。該方案中數(shù)據(jù)擁有者可以通過設(shè)定策略來決定擁有哪些屬性的人能夠訪問這份密文，一般應(yīng)用于公有云上的數(shù)據(jù)加密存儲(chǔ)與基于屬性的細(xì)粒度共享。2.4.2與屬性加密結(jié)合的MQTT文獻(xiàn)[5]中考慮到用戶對(duì)發(fā)布消息的細(xì)粒度訪問控制，采用的是基于CP-ABE的加密方式?？紤]到適配MQTT訂閱—推送的機(jī)制，結(jié)合基于主題加密的思想，本文采用KP-ABE的加密方式，為訂閱了不同主題的用戶生成訪問策略。KP-ABE的初始化流程如圖11所示。圖11KP-ABE初始化KP-ABE的初始化流程具體描述如下：（1）Client_i向Broker提供屬性、證書等信息進(jìn)行注冊(cè)。（2）Broker生成系統(tǒng)主密鑰（MainSecretKey，MSK）、公開參數(shù)（PublicKey，PK），并將全體用戶的屬性集U={A1,A2,…,An}公開。（3）Broker針對(duì)不同的主題，根據(jù)訂閱的用戶生成訪問策略，并以此為輸入生成用戶的私鑰。（4）Broker將與Client_i相關(guān)的私鑰集{SKi1,SKi2,…,SKit}安全返回給它（如使用證書中的公鑰加密）。（5）Client_i對(duì)于自己訂閱的每個(gè)主題，都擁有一個(gè)對(duì)應(yīng)的私鑰。KP-ABE加解密流程如圖12所示。圖12KP-ABE加解密KP-ABE的加解密流程具體描述如下：（1）消息發(fā)布方Client_i使用公開參數(shù)PK與加密屬性集（該消息所屬主題）加密待發(fā)布的消息，將密文消息推送給Broker。（2）Broker將該消息推送給訂閱了相關(guān)主題的客戶端。（3）某個(gè)客戶端Client_j收到消息后，驗(yàn)證密文屬性是否符合自己所擁有的密鑰的訪問策略，若符合，則使用對(duì)應(yīng)的私鑰SKjk解密消息。上述過程同樣也可利用數(shù)字信封技術(shù)實(shí)現(xiàn)。2.5基于代理重加密技術(shù)代理重加密（ProxyRe-Enceyption，PRE）技術(shù)可以在代理不解密的情況下，將發(fā)送方公鑰加密的密文轉(zhuǎn)化為可被接收方私鑰解密的密文，能較好地解決MQTT中Broker的可信性問題。2.5.1代理重加密技術(shù)簡(jiǎn)介代理重加密系統(tǒng)模型如圖13所示。圖13代理重加密系統(tǒng)模型代理重加密的流程具體為：（1）初始化時(shí)，各通信客戶端需向密鑰生成中心（KeyGenerationCenter，KGC）請(qǐng)求自己的加密公私鑰對(duì)(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ā)送者不能對(duì)云端的重加密對(duì)象做細(xì)粒度控制。2.5.2基于代理重加密技術(shù)的MQTT文獻(xiàn)[6]給出了一種基于代理重加密技術(shù)實(shí)現(xiàn)MQTT通信中發(fā)布者與訂閱者間端到端數(shù)據(jù)安全傳輸?shù)慕鉀Q方案，如圖14所示。該方案中，KGC根據(jù)設(shè)備注冊(cè)的屬性（發(fā)布/訂閱）和主題進(jìn)行匹配，為每對(duì)的發(fā)布者—訂閱者對(duì)等方預(yù)生成重加密密鑰，并將生成的重加密密鑰通過安全的方式發(fā)送給Broker。圖14基于代理重加密的MQTT初始化時(shí)，客戶端需向KGC申請(qǐng)自己的加密公私鑰對(duì)與簽名公私鑰，分別用于會(huì)話密鑰的分發(fā)消息與簽名。其中，簽名公鑰為客戶端的唯一身份標(biāo)識(shí)，實(shí)際加密消息的密鑰為會(huì)話密鑰?；诖碇丶用芗夹g(shù)的MQTT的具體實(shí)現(xiàn)流程如下：（1）發(fā)方客戶端Client_i產(chǎn)生會(huì)話密鑰key，使用自己的加密公鑰PKEnci加密key，得密文Ckeyi。（2）Client_i使用自己的簽名私鑰SKSigni對(duì)待發(fā)布的消息m進(jìn)行簽名，得sig，并用key加密m||sig。（3）Client_i將密文消息、Ckeyi和自己的唯一身份標(biāo)識(shí)UUIDi（簽名公鑰）發(fā)送到Broker。（4）Broker查詢訂閱了該條消息所屬主題的客戶端有哪些，并使用相應(yīng)的重加密密鑰RKij重加密Ckeyi，得會(huì)話密鑰密文Ckeyj。（5）Broker使用keyi重加密會(huì)話密鑰密文1，得會(huì)話密鑰密文2。（6）Broker將密文消息、Ckeyj和發(fā)方UUIDi推送給相應(yīng)收方客戶端Client_j。（7）Client_j首先使用自己的私鑰SKDecj解密Ckeyj，得會(huì)話密鑰key，其次使用key解密消息，得m||sig。（8）Client_j使用UUIDi驗(yàn)證sig的有效性。3MQTT協(xié)議安全加固框架3.1對(duì)比與小結(jié)設(shè)想一個(gè)MQTT通信網(wǎng)絡(luò)中有1個(gè)消息發(fā)送方與n個(gè)消息訂閱方。用E表示加密、D表示解密、T表示密鑰分發(fā)/密鑰轉(zhuǎn)保護(hù)（對(duì)密鑰解密并加密1次為1個(gè)完整的T）。本文使用上述操作出現(xiàn)的次數(shù)來直觀地衡量各方案的開銷，對(duì)比結(jié)果見表3。如表3所示，TLS協(xié)議為成熟的網(wǎng)絡(luò)層安全通信方案，對(duì)應(yīng)用層MQTT協(xié)議透明；但傳統(tǒng)的TLS協(xié)議在物聯(lián)網(wǎng)環(huán)境中應(yīng)用的開銷較大。雖然AugPAKE協(xié)議在一定程度上降低了認(rèn)證過程的開銷，但當(dāng)認(rèn)證完成后，方案1與方案2的數(shù)據(jù)傳輸保護(hù)方式是一樣的。表3中后面3種方案的認(rèn)證過程都是提前完成的，只有通過認(rèn)證的客戶端才能獲得消息解密密鑰，進(jìn)而解密消息。表35種方案對(duì)比基于主題的加密方案中，Mektoubi等人的方案是基于非對(duì)稱算法的，需要對(duì)私鑰進(jìn)行分發(fā)，且非對(duì)稱加解密的效率并不高。本文給出了基于對(duì)稱算法的主題加密與密鑰衍生，維護(hù)的密鑰量并不比Mektoubi等人的方案多，且加解密效率更高。基于屬性的加密能很好地實(shí)現(xiàn)一對(duì)多的數(shù)據(jù)分發(fā)，且可以對(duì)數(shù)據(jù)的訪問進(jìn)行控制，這是方案4相較于其他方案最大的優(yōu)勢(shì)。本文給出的是基于KPABE的屬性加密方案，相較于文獻(xiàn)[4]推薦的CPABE，雖然不能由數(shù)據(jù)擁有者對(duì)數(shù)據(jù)的訪問進(jìn)行控制，但更適合MQTT協(xié)議的訂閱—推送機(jī)制，然而其本質(zhì)仍是控制對(duì)主題密鑰的訪問。方案5相較于其他方案的優(yōu)勢(shì)在于代理重加密技術(shù)可以較好地解決Broker的可信性問題。加密消息的密鑰由數(shù)據(jù)擁有者產(chǎn)生，Broker不能獲取數(shù)據(jù)明文。但方案5仍是一對(duì)一的方案，針對(duì)不同用戶的分享要生成不同的重加密密鑰。3.2框架基于上文的分析，給出MQTT協(xié)議安全加固框架如圖15所示。圖15MQTT協(xié)議安全加固框架安全的協(xié)議需要底層密碼算法與基礎(chǔ)設(shè)施支撐，而所有基于公鑰加密的方案都可以轉(zhuǎn)化為使用數(shù)字信封技術(shù)實(shí)現(xiàn)的對(duì)稱加密的方案。因此針對(duì)消息自身的加密，主要使用適合嵌入式設(shè)備的輕量級(jí)分組密碼算法，如國(guó)際標(biāo)準(zhǔn)化組織（InternationalOrganizationforStandardization，ISO）、國(guó)際電工委員會(huì)（InternationalElectrotechnicalCommission，IEC）輕量級(jí)分組密碼標(biāo)準(zhǔn)：PRESENT[7]、CLEFIA[8]與LEA[9]等。而分組密碼的工作模式可采用伽羅瓦計(jì)數(shù)器模式（GaloisCounterMode，GCM）或使用分組密碼鏈接消息認(rèn)證碼的計(jì)數(shù)器模式（CounterwithCBC-MAC，CCM），來同時(shí)實(shí)現(xiàn)通信