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

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