張?jiān)娾?，朱豪杰，黃明浩，慕瑞華

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

0 引言

近年來(lái)物聯(lián)網(wǎng)（Internet of Things，IoT）飛速發(fā)展，隨著其應(yīng)用范圍越來(lái)越廣泛，物聯(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)惡意樣本471 158個(gè)，發(fā)現(xiàn)物聯(lián)網(wǎng)惡意程序傳播IP地址55 163個(gè)，發(fā)現(xiàn)活躍的僵尸網(wǎng)絡(luò)命令和控制（Command and Control，C&C）服務(wù)器地址2 021個(gè)，其地址位置主要分布在美國(guó)（33.6%）、中國(guó)（8.5%）、俄羅斯（6.7%）等國(guó)家。其中，來(lái)自美國(guó)的680個(gè)C&C服務(wù)器控制了中國(guó)境內(nèi)的373 080個(gè)設(shè)備[1]。因此，IoT面臨的安全威脅不容忽視。

消息隊(duì)列遙測(cè)傳輸（Message Queuing Telemetry Transport，MQTT）協(xié)議是一個(gè)超輕量級(jí)的發(fā)布（publish）/訂閱（subscribe）消息傳輸協(xié)議，是專(zhuān)為受限設(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)組織（Organization for the Advancement of Structured Information Standards，OASIS）的標(biāo)準(zhǔn)，其最新版本為MQTT v5.0[2]。

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

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

1.1 MQTT協(xié)議簡(jiǎn)介

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

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

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

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

可見(jiàn)，MQTT通信是標(biāo)準(zhǔn)的異步通信模式，各個(gè)客戶(hù)端是對(duì)等關(guān)系。

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

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

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

表1 MQTT報(bào)文類(lèi)型

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

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

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

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

1.2.1 認(rèn)證

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

1.2.2 鑒權(quán)

MQTT協(xié)議中規(guī)定按照層級(jí)劃分主題，并規(guī)定了兩個(gè)特殊字符“＃”和“／”，這兩個(gè)特殊字符導(dǎo)致訂閱者在不知道主題的情況下就能夠?qū)υ撝黝}進(jìn)行訂閱，而MQTT協(xié)議本身并沒(méi)有給出訪(fǎng)問(wèn)控制相關(guān)的說(shuō)明。

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

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

1.2.4 代理的可信性

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

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

2.1 TLS

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

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

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

（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)證密鑰交換（Augmented Password Authenticated Key Exchange，AugPAKE）協(xié)議[3]利用口令完成了客戶(hù)端接入代理時(shí)的雙向認(rèn)證，同時(shí)基于D-H（Diffee-Hellman）密鑰交換，協(xié)商了后續(xù)通信過(guò)程中使用的對(duì)稱(chēng)密鑰（一般是AES密鑰）。

2.2.1 AugPAKE協(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ù)群來(lái)表示有限域GF(p)上的q階乘法子群，G=Zq。令g是子群G的生成元，即G=＜g＞。AugPAKE協(xié)議可在群G中實(shí)現(xiàn)。表2給出了AugPAKE協(xié)議涉及的符號(hào)說(shuō)明。

表2 符號(hào)說(shuō)明

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

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

圖3 AugPAKE協(xié)議流程

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

（1）用戶(hù)U從Zq*中選擇隨機(jī)數(shù)x，計(jì)算DH公開(kāi)值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=Y zmodp，其中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|bn2bi n(X)|bn2bin(Y)|bn2bin(K'))，其中K'=g ymodp，則S終止協(xié)議。否則S生成驗(yàn)證碼V_S=H(0x03|U|S|bn2bin(X)|bn2bin(Y)|bn2bin(K'))，并將V_S發(fā)送給U。服務(wù)端生成會(huì)話(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ì)話(huà)密鑰SK=H(0x04|U|S|bn2bin(X)|bn2bin(Y)|bn2bin(K))。

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

2.2.2 基于AugPAKE的MQTT

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

圖4 基于AugPAKE的MQTT

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

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

（2）Broker使用SKa解密消息，然后分別使用訂閱了該主題的所有客戶(hù)端的會(huì)話(huà)密鑰加密明文消息，將密文推送給收方客戶(hù)端，如使用同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ì)稱(chēng)主題密鑰分發(fā)與消息加解密

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

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

圖5 新加入主題的客戶(hù)端請(qǐng)求主題證書(shū)

圖6 首次請(qǐng)求主題私鑰

新加入主題的客戶(hù)端請(qǐng)求主題證書(shū)的具體流程描述如下：

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

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

（3）Client1收到主題證書(shū)，驗(yàn)證其有效性（CA簽名等）。

首次請(qǐng)求主題私鑰的具體流程如下：

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

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

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

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

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

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

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

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

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

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

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

2.3.2 對(duì)稱(chēng)主題密鑰分發(fā)與消息加解密

為不同主題生成相應(yīng)的主題密鑰（對(duì)稱(chēng)密鑰），在客戶(hù)端訂閱主題時(shí)獲取主題密鑰，使用主題密鑰來(lái)加密該主題下的所有消息。

如圖8所示為客戶(hù)端注冊(cè)流程?？蛻?hù)端注冊(cè)時(shí)需提交加密公鑰、證書(shū)、身份標(biāo)識(shí)等，用于主題密鑰的分發(fā)。主題密鑰的生成與分發(fā)流程如圖9所示。

圖8 客戶(hù)端注冊(cè)

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

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

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

（2）客戶(hù)端訂閱主題時(shí)，從Broker處安全獲取主題密鑰，主題密鑰可使用客戶(hù)端提交的公鑰、證書(shū)、身份標(biāo)識(shí)等加密。

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

圖10 基于主題的加密

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

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

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

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

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

2.4 基于屬性的加密方案

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

2.4.1 屬性加密簡(jiǎn)介

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

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

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

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

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

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

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

圖11 KP-ABE初始化

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

（1）Client_i向Broker提供屬性、證書(shū)等信息進(jìn)行注冊(cè)。

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

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

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

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

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

圖12 KP-ABE加解密

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

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

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

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

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

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

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

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

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

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

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

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

（2）KGC使用消息發(fā)送方客戶(hù)端的私鑰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ù)生成重加密密鑰，并將生成的重加密密鑰通過(guò)安全的方式發(fā)送給Broker。

圖14 基于代理重加密的MQTT

初始化時(shí)，客戶(hù)端需向KGC申請(qǐng)自己的加密公私鑰對(duì)與簽名公私鑰，分別用于會(huì)話(huà)密鑰的分發(fā)消息與簽名。其中，簽名公鑰為客戶(hù)端的唯一身份標(biāo)識(shí)，實(shí)際加密消息的密鑰為會(huì)話(huà)密鑰。

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

（1）發(fā)方客戶(hù)端Client_i產(chǎn)生會(huì)話(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查詢(xún)訂閱了該條消息所屬主題的客戶(hù)端有哪些，并使用相應(yīng)的重加密密鑰RKij重加密Ckeyi，得會(huì)話(huà)密鑰密文Ckeyj。

（5）Broker使用keyi重加密會(huì)話(huà)密鑰密文1，得會(huì)話(huà)密鑰密文2。

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

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

（8）Client_j使用UUIDi驗(yàn)證sig的有效性。

3 MQTT協(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ù)來(lái)直觀地衡量各方案的開(kāi)銷(xiāo)，對(duì)比結(jié)果見(jiàn)表3。

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

表3中后面3種方案的認(rèn)證過(guò)程都是提前完成的，只有通過(guò)認(rèn)證的客戶(hù)端才能獲得消息解密密鑰，進(jìn)而解密消息。

表3 5種方案對(duì)比

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

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

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

3.2 框架

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

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

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

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

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

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

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

4 結(jié)語(yǔ)

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