谷正川,郭淵博,方 晨
(1.戰(zhàn)略支援部隊(duì)信息工程大學(xué)密碼工程學(xué)院,鄭州 450002;2.中國(guó)人民解放軍77562部隊(duì),西藏日喀則 857000)
(*通信作者電子郵箱zhengchuan_g@163.com)
物聯(lián)網(wǎng)作為一項(xiàng)改變數(shù)據(jù)共享格局的技術(shù),近年來(lái)伴隨著無(wú)線通信技術(shù)的發(fā)展掀起了新的發(fā)展浪潮。據(jù)全球移動(dòng)通信系統(tǒng)協(xié)會(huì)(Global System for Mobile Communications Association,GSMA)預(yù)測(cè),2025年全球物聯(lián)網(wǎng)終端連接數(shù)量將達(dá)到250億[1]。物聯(lián)網(wǎng)將數(shù)字世界與物理世界相映射,通過(guò)物聯(lián)網(wǎng)連接到互聯(lián)網(wǎng)的數(shù)百億設(shè)備在共享信息的過(guò)程中可能生成數(shù)萬(wàn)億條信息。如何保證這些信息的安全性是一項(xiàng)基本挑戰(zhàn)。消息隊(duì)列遙測(cè)傳輸(Message Queue Telemetry Transport,MQTT)作為物聯(lián)網(wǎng)中流行的應(yīng)用層協(xié)議之一,因它在資源和計(jì)算上的占用空間小而得到廣泛應(yīng)用[2]。但是MQTT 協(xié)議中只規(guī)范了一些可選的弱防護(hù)機(jī)制,如使用客戶(hù)端ID 以及用戶(hù)名/口令對(duì)客戶(hù)端進(jìn)行身份驗(yàn)證,這種程度的安全性機(jī)制不能滿(mǎn)足物聯(lián)網(wǎng)中不斷增長(zhǎng)的安全性需求。為提高M(jìn)QTT 的安全性,協(xié)議給出了一些建議,如客戶(hù)端認(rèn)證使用X.509客戶(hù)端證書(shū)、底層傳輸協(xié)議使用安全傳輸層協(xié)議(Transport Layer Security,TLS)代替純傳輸控制協(xié)議(Transmission Control Protocol,TCP)。但這些機(jī)制的安全性成本超出了物聯(lián)網(wǎng)受限設(shè)備在計(jì)算能力和內(nèi)存等方面的可接受范圍。因此,開(kāi)發(fā)一種具備高安全性且適用于物聯(lián)網(wǎng)中資源受限設(shè)備的解決方案,成為MQTT安全性研究的熱點(diǎn)。
另一個(gè)問(wèn)題是MQTT 代理的可信任性越來(lái)越受到質(zhì)疑。MQTT 通信模型屬于發(fā)布/訂閱范式,其通信依賴(lài)的核心是MQTT 代理。零信任是一種新型安全框架,其核心理念是“從不信任并始終驗(yàn)證”,即內(nèi)部和外部網(wǎng)絡(luò)都不可信[3]。2020年2 月美國(guó)國(guó)家標(biāo)準(zhǔn)與技術(shù)研究院(National Institute of Standards and Technology,NIST)發(fā)布的零信任架構(gòu)(第2 版草案)[4]再次強(qiáng)調(diào):零信任是一種以資源保護(hù)為核心的網(wǎng)絡(luò)安全范式,其前提是信任從來(lái)不是隱式授予的,而是必須進(jìn)行持續(xù)評(píng)估。因此,即使MQTT 代理位于受防火墻保護(hù)的內(nèi)部網(wǎng)絡(luò)也是不可信的。而且,隨著云技術(shù)的發(fā)展,MQTT 代理服務(wù)器也從本地轉(zhuǎn)移至云端。阿里云、騰訊云等云服務(wù)商提供的MQTT 云服務(wù)在提供便利時(shí)也帶來(lái)了代理服務(wù)器端數(shù)據(jù)安全的巨大隱患。
為解決上述問(wèn)題,本文消除對(duì)MQTT 代理的隱式信任,將其定義為半誠(chéng)實(shí)參與方。通過(guò)結(jié)合Schnorr 簽名[5]、高級(jí)加密標(biāo)準(zhǔn)(Advanced Encryption Standard,AES)和代理重加密三種密碼技術(shù),提出一種適用于受限物聯(lián)網(wǎng)設(shè)備的MQTT 端到端數(shù)據(jù)安全傳輸解決方案,其主要工作有以下幾點(diǎn):
1)使用輕量級(jí)代理重加密算法進(jìn)行會(huì)話(huà)密鑰加密傳輸,結(jié)合AES 對(duì)稱(chēng)加密算法確保MQTT 數(shù)據(jù)傳輸?shù)亩说蕉税踩裕?/p>
2)將代理重加密密鑰的生成工作由發(fā)布者端轉(zhuǎn)移至可信中心,避免在發(fā)布者客戶(hù)端設(shè)備上進(jìn)行大量復(fù)雜計(jì)算和密鑰存儲(chǔ);
3)采用Schnorr 簽名對(duì)發(fā)布消息進(jìn)行數(shù)字簽名,訂閱者不需要存儲(chǔ)發(fā)布者公鑰也可驗(yàn)證消息來(lái)源真實(shí)性、完整性和不可否認(rèn)性。
在假設(shè)MQTT 代理可信或經(jīng)過(guò)身份認(rèn)證后可信的前提下,許多研究通過(guò)在MQTT 發(fā)布/訂閱者客戶(hù)端與MQTT 代理間使用非對(duì)稱(chēng)密碼體制協(xié)商會(huì)話(huà)密鑰或安全傳輸會(huì)話(huà)密鑰。然后使用會(huì)話(huà)密鑰對(duì)傳輸數(shù)據(jù)進(jìn)行對(duì)稱(chēng)加密來(lái)實(shí)現(xiàn)發(fā)布者與訂閱者間的數(shù)據(jù)機(jī)密性。
Calabretta 等[6]提出一種基于增強(qiáng)的口令認(rèn)證密鑰交換(Augmented Password-Authenticated Key Exchange,AugPAKE)協(xié)議的MQTT 安全通信方案,客戶(hù)端與代理間通過(guò)特定主題進(jìn)行4 次信息交互完成AugPAKE 協(xié)議過(guò)程,實(shí)現(xiàn)客戶(hù)端與代理間的相互認(rèn)證,并協(xié)商出后續(xù)數(shù)據(jù)加密傳輸?shù)臅?huì)話(huà)密鑰,使每個(gè)節(jié)點(diǎn)(無(wú)論是發(fā)布者還是訂閱者)都與代理間維持一個(gè)會(huì)話(huà)密鑰。文中明確表示,將代理視為信任的實(shí)體,負(fù)責(zé)解密和加密MQTT 有效載荷,對(duì)交換數(shù)據(jù)具有完全的可見(jiàn)性。盡管作者建議數(shù)據(jù)由代理以加密格式存儲(chǔ),只有當(dāng)代理收到授權(quán)(和驗(yàn)證)的訂閱請(qǐng)求時(shí)才能對(duì)數(shù)據(jù)進(jìn)行解密和重新加密。但攻擊者仍然可以通過(guò)攻擊代理或與代理共謀來(lái)窺探MQTT 通信中傳輸?shù)臄?shù)據(jù)。另外,該方案中4次MQTT信息交互產(chǎn)生了較大的額外通信開(kāi)銷(xiāo)。
文獻(xiàn)[7]中提出了一種基于MQTT 協(xié)議的分級(jí)安全框架,使用Rabin 加密密碼系統(tǒng)[8]、橢圓曲線集成加密方案(Elliptic Curve Integrated Encryption Scheme,ECIES)[9]和帶伽羅瓦消息驗(yàn)證碼的計(jì)數(shù)器模式運(yùn)行高級(jí)加密標(biāo)準(zhǔn)(Advanced Encryption Standard in Galois/Counter Mode,AES-GCM)加密方案為不同敏感程度的數(shù)據(jù)提供不同級(jí)別的安全性。所有加解密采用輕量級(jí)密碼方案,并將密碼方案嵌入正常的MQTT 發(fā)布/訂閱通信流中,無(wú)需使用額外的安全性開(kāi)銷(xiāo)。但該方案也是通過(guò)MQTT 代理加密和解密發(fā)布/訂閱者間傳輸?shù)臄?shù)據(jù),同樣存在代理是否可信的問(wèn)題。
文獻(xiàn)[10]中,作者試圖通過(guò)將MQTT 與通用異步接收器/發(fā)送器和Rime協(xié)議棧一起用作傳輸患者醫(yī)療數(shù)據(jù)的協(xié)議,創(chuàng)建一個(gè)安全的端到端物聯(lián)網(wǎng)環(huán)境。使用具有256 位密鑰的AES-GCM 實(shí)現(xiàn)端到端數(shù)據(jù)機(jī)密性,但是需要通過(guò)基于哈希消息認(rèn)證碼的密鑰派生函數(shù)和橢圓曲線上的Diffie-Hellman(DH)密鑰交換算法管理系統(tǒng)中不同實(shí)體間的密鑰。同時(shí),路由需要解密含有多個(gè)傳感器加密數(shù)據(jù)的聚合數(shù)據(jù)包,分別進(jìn)行驗(yàn)證后使用預(yù)加載密鑰重新聚合加密再發(fā)送給數(shù)據(jù)訂閱者。
文獻(xiàn)[11-12]中對(duì)代理的隱式信任不作強(qiáng)制要求,分別通過(guò)基于身份密碼學(xué)和基于代理重加密實(shí)現(xiàn)端到端的數(shù)據(jù)安全性。文獻(xiàn)[11]中提出一種基于身份密碼術(shù)的會(huì)話(huà)密鑰協(xié)商方案。用戶(hù)與提供傳感器數(shù)據(jù)的物聯(lián)網(wǎng)網(wǎng)關(guān)間通過(guò)基于身份密碼術(shù)的公鑰加密進(jìn)行相互認(rèn)證,并在一個(gè)往返時(shí)間內(nèi)協(xié)商出可用于后續(xù)通信加解密的會(huì)話(huà)密鑰。該方案在提供端到端數(shù)據(jù)安全性的同時(shí),還減少了使用基于公鑰基礎(chǔ)設(shè)施(Public Key Infrastructure,PKI)的公鑰加密完成身份認(rèn)證和會(huì)話(huà)密鑰協(xié)商的方案中的證書(shū)存儲(chǔ)開(kāi)銷(xiāo)。但基于身份密碼術(shù)的公鑰體制對(duì)于計(jì)算和存儲(chǔ)能力要求較高,難以適用于資源受限的物聯(lián)網(wǎng)設(shè)備。Kim 等[12]提出了一種物聯(lián)網(wǎng)環(huán)境下在輕量級(jí)設(shè)備上使用常規(guī)密碼算法共享和管理數(shù)據(jù)的方法,該方案的實(shí)現(xiàn)結(jié)合了代理重加密體制[13-14]。代理重加密是一種典型的密文共享方案,通過(guò)代理服務(wù)器將一個(gè)用戶(hù)的密文轉(zhuǎn)換為另一個(gè)用戶(hù)可以解密的密文,整個(gè)過(guò)程中不泄露用戶(hù)的私鑰和明文信息。文獻(xiàn)[12]通過(guò)使用代理重加密減少數(shù)據(jù)共享過(guò)程中單個(gè)節(jié)點(diǎn)的加密計(jì)算負(fù)擔(dān),每個(gè)節(jié)點(diǎn)執(zhí)行加密和創(chuàng)建重加密密鑰,然后將加密密文和重加密密鑰發(fā)送到代理服務(wù)器,由代理服務(wù)器生成允許其他節(jié)點(diǎn)解密的密文。在傳統(tǒng)的點(diǎn)對(duì)點(diǎn)數(shù)據(jù)共享方式中,提供數(shù)據(jù)的節(jié)點(diǎn)需要與所有使用該數(shù)據(jù)的節(jié)點(diǎn)間分別進(jìn)行一次加解密操作。因此,與傳統(tǒng)數(shù)據(jù)共享方式相比該方案減少了數(shù)據(jù)共享過(guò)程中的加解密次數(shù);但該方案使用的是基于橢圓曲線密碼系統(tǒng)的代理重加密算法,算法中包含雙線性映射。雙線性映射的計(jì)算開(kāi)銷(xiāo)遠(yuǎn)大于橢圓曲線上的標(biāo)量乘法[15],并不是輕量級(jí)密碼算法的首選。此外,在該方案中每個(gè)節(jié)點(diǎn)除執(zhí)行數(shù)據(jù)加密外還需要為每個(gè)共享數(shù)據(jù)的節(jié)點(diǎn)生成重加密密鑰,操作時(shí)間將隨傳感器節(jié)點(diǎn)的數(shù)量成正比例增加。
因此,本文提出了一種基于代理重加密實(shí)現(xiàn)MQTT 端到端安全性的解決方案。該方案在確保MQTT 數(shù)據(jù)傳輸端到端安全性的同時(shí),通過(guò)采取以下兩點(diǎn)措施來(lái)適應(yīng)資源受限的物聯(lián)網(wǎng)環(huán)境:1)使用AES加密傳感數(shù)據(jù),只對(duì)AES加密使用的會(huì)話(huà)密鑰進(jìn)行代理重加密,大量減少非對(duì)稱(chēng)加解密操作;2)將傳統(tǒng)代理重加密框架[13,16-17]中重加密密鑰的生成操作由發(fā)布者轉(zhuǎn)移到包含有密鑰生成中心(Key Generation Center,KGC)的可信中心,從而減少發(fā)布者端的計(jì)算量和密鑰存儲(chǔ)量。此外,本方案中采用Schnorr簽名確保數(shù)據(jù)完整性、來(lái)源的真實(shí)性和不可否認(rèn)性。
本章主要介紹為MQTT 服務(wù)提出的基于代理重加密安全框架,以及使用的符號(hào)和加密方法、方案架構(gòu)和具體流程的各個(gè)階段。
表1中定義了所提方案中使用的符號(hào)。
表1 所提方案使用的符號(hào)Tab.1 Notations used in the proposed scheme
根據(jù)效率和安全性,本文選擇了以下密碼學(xué)加密方案:
AES 對(duì)稱(chēng)加密,以及基于改良的計(jì)算Diffie-Hellman(modified Computational Diffie-Hellman,mCDH)難題的代理重加密算法和Schnorr簽名算法[13]。
AES 用于數(shù)據(jù)資源加解密,代理重加密算法保護(hù)AES 加密密鑰,Schnorr算法對(duì)信息進(jìn)行數(shù)字簽名防篡改。
方案框架如圖1 所示,模型由4 個(gè)實(shí)體組成:發(fā)布者(Publisher,P)、代理(Broker,B)、訂閱者(Subscriber,S)和可信中心(Trusted Center,TC)。
圖1 MQTT端到端安全解決方案Fig.1 Solution for MQTT end-to-end security
可信中心的設(shè)立與放棄信任MQTT 代理的做法并不矛盾。MQTT代理需要與眾多的發(fā)布/訂閱者客戶(hù)端設(shè)備進(jìn)行信息交互,資源受限客戶(hù)端設(shè)備的低安全防護(hù)級(jí)別擴(kuò)大了MQTT代理的攻擊面。在這種情況下,選擇信任MQTT代理并對(duì)其進(jìn)行安全加固的成本是極高的,并且MQTT 代理上需要客戶(hù)端設(shè)備完全響應(yīng)的強(qiáng)安全約束條件也是客戶(hù)端設(shè)備難以承受的。本文設(shè)立的可信中心只是擴(kuò)展了傳統(tǒng)無(wú)證書(shū)代理重加密系統(tǒng)模型[18]中KGC 實(shí)體(如圖2)的功能,而可信中心只響應(yīng)代理的重加密密鑰請(qǐng)求。因此在代理重加密系統(tǒng)模型中建立可信中心比安全加固代理的實(shí)用性要高。
圖2 無(wú)證書(shū)代理重加密Fig.2 Certificateless proxy re-encryption
發(fā)布者可以感知數(shù)據(jù)并生成按主題分類(lèi)的消息。所有發(fā)布者將消息發(fā)送給代理,代理將它們轉(zhuǎn)發(fā)給最終用戶(hù)(訂閱者)。下面分別介紹各實(shí)體的組成與功能。
2.2.1 發(fā)布者
發(fā)布者通過(guò)密鑰派生函數(shù)(Key Derivation Function,KDF)生成會(huì)話(huà)密鑰,并利用會(huì)話(huà)密鑰對(duì)感知數(shù)據(jù)進(jìn)行AES加密;同時(shí),使用自己的公鑰對(duì)會(huì)話(huà)密鑰進(jìn)行加密。最后,使用簽名密鑰簽名需要發(fā)送的消息。
2.2.2 代理
代理組成如圖3 所示。MQTT 核心模塊實(shí)現(xiàn)與發(fā)布/訂閱者在MQTT 協(xié)議標(biāo)準(zhǔn)下通信;安全套接字層超文本傳輸協(xié)議(Hyper Text Transfer Protocol over Secure socket layer,HTTPS)通信模塊實(shí)現(xiàn)代理與可信中心間安全的超文本傳輸協(xié)議通信;重加密模塊實(shí)現(xiàn)發(fā)布者會(huì)話(huà)密鑰密文的重加密。最后,將重加密密文和感知數(shù)據(jù)密文重新封裝到有效載荷,發(fā)送給數(shù)據(jù)的訂閱者。
圖3 代理結(jié)構(gòu)Fig.3 Architecture of broker
2.2.3 訂閱者
訂閱者使用主題向代理訂閱數(shù)據(jù),收到代理發(fā)送的消息后,訂閱者首先解密經(jīng)代理重加密的密文獲取會(huì)話(huà)密鑰,使用該會(huì)話(huà)密鑰解密有效載荷得到明文信息。最后進(jìn)行消息簽名驗(yàn)證,驗(yàn)證通過(guò)則接受消息,否則丟棄。
2.2.4 可信中心
可信中心結(jié)構(gòu)如圖4 所示,主要包含注冊(cè)管理中心、密鑰生成中心、重加密密鑰生成器和數(shù)據(jù)庫(kù)。發(fā)布/訂閱者設(shè)備由設(shè)備所有者通過(guò)客戶(hù)端向可信中心注冊(cè),注冊(cè)成功后由可信中心的KGC 為每個(gè)設(shè)備生成公私鑰對(duì)和簽名密鑰對(duì)??尚胖行母鶕?jù)設(shè)備注冊(cè)的屬性(發(fā)布/訂閱)和主題進(jìn)行匹配,為每對(duì)的發(fā)布者-訂閱者對(duì)等方預(yù)生成重加密密鑰,并將生成的重加密密鑰通過(guò)安全的方式發(fā)送給代理。由于本文主要分析發(fā)布者與訂閱者端到端的數(shù)據(jù)安全,對(duì)于設(shè)備的認(rèn)證授權(quán)與訪問(wèn)控制方案不進(jìn)行討論。
圖4 可信中心結(jié)構(gòu)Fig.4 Architecture of trusted center
2.3.1 系統(tǒng)初始化與設(shè)備注冊(cè)
系統(tǒng)初始化與設(shè)備注冊(cè)流程如圖5所示。
圖5 系統(tǒng)初始化與設(shè)備注冊(cè)流程Fig.5 Process of system initialization and device registration
1)系統(tǒng)初始化:GlobalSetup(1k) →(par)。
全局設(shè)置算法GlobalSetup()將安全參數(shù)k作為輸入。它輸出全局參數(shù)par:(q,G,g,H1,H2),其中素?cái)?shù)q,階數(shù)為q的有限循環(huán)群G,g是G的生成元,哈希函數(shù)H1:{0,1}*→哈希函數(shù)H2:G→
2)用戶(hù)注冊(cè)設(shè)備。
用戶(hù)通過(guò)客戶(hù)端向TC 注冊(cè)設(shè)備,注冊(cè)內(nèi)容包括:設(shè)備標(biāo)識(shí)(如物理地址)、設(shè)備屬性(發(fā)布/訂閱)、設(shè)備主題(設(shè)備在MQTT通信中發(fā)布/訂閱該主題)。
3)公私鑰對(duì)生成:KeyGen(i) →(ski,pki)。
注冊(cè)成功后,TC 使用密鑰生成算法KeyGen()為設(shè)備i生成公私鑰對(duì)(ski,pki)。密鑰生成算法選擇xi并設(shè)ski=xi,pki=
發(fā)布/訂閱者設(shè)備的密鑰生成如下:
隨機(jī)選擇xi1,xi2,xi3設(shè)ski1=xi1,pki1=ski2=設(shè)置PKi=(pki1,pki2),SKi=(ski1,ski2);SKi_sig=ski3,PKi_sig=pki3。生成設(shè)備的公私鑰對(duì)(SKi,PKi),簽名密鑰對(duì)(SKi_sig,PKi_sig)。由TC 統(tǒng)一生成設(shè)備通用唯一識(shí)別碼(Universally Unique Identifier,UUID),并設(shè)置UUIDi=PKi_sig。
此過(guò)程后,發(fā)布者獲得公私鑰對(duì)(SKp,PKp)、簽名密鑰對(duì)(SKp_sig,UUIDp),訂閱者獲得公私鑰對(duì)(SKs,PKs)、簽名密鑰對(duì)(SKs_sig,UUIDs);
4)安全參數(shù)返回。
注冊(cè)成功后,用戶(hù)必須將可信中心生成的系統(tǒng)參數(shù)、設(shè)備UUID、設(shè)備簽名密鑰和設(shè)備公私鑰對(duì)通過(guò)安全通道(如手工嵌入設(shè)備安全固件、使用設(shè)備可信平臺(tái)模塊安全存儲(chǔ)等)加載到設(shè)備中。
5)重加密密鑰預(yù)生成:ReKeyGen(SKi,PKi,PKj) →RKi→j。
算法按以下步驟生成重加密密鑰:
返回重加密密鑰RKp→s=(rk1,rk2,rk3)。
2.3.2 數(shù)據(jù)傳輸
數(shù)據(jù)傳輸流程如圖6所示。
圖6 數(shù)據(jù)傳輸流程Fig.6 Data transmission process
1)發(fā)布信息生成。
1a)會(huì)話(huà)密鑰預(yù)生成:KDF() →SK。
發(fā)布者使用KDF 生成會(huì)話(huà)密鑰SK。該算法可以使用計(jì)時(shí)器觸發(fā),也可以使用計(jì)數(shù)器觸發(fā)。計(jì)時(shí)器觸發(fā)方式中,根據(jù)設(shè)置的會(huì)話(huà)密鑰生存周期進(jìn)行定期生成;計(jì)數(shù)器觸發(fā)方式中,根據(jù)限制會(huì)話(huà)密鑰加密次數(shù)進(jìn)行密鑰生成。對(duì)于最敏感的數(shù)據(jù)可以實(shí)行最高安全級(jí)別的防護(hù),將會(huì)話(huà)密鑰設(shè)置為一次完整的數(shù)據(jù)發(fā)送一更換。
1b)預(yù)加密會(huì)話(huà)密鑰:Enc(PKp,SK) →Cp。
返回密文Cp=(Cp1,Cp2,Cp3)。
1c)消息簽名與加密。
消息主體為{T,UUID,M,t,sig}。其中T為發(fā)布數(shù)據(jù)對(duì)應(yīng)的主題;UUID是設(shè)備在TC 注冊(cè)后獲取的統(tǒng)一標(biāo)識(shí),同時(shí)也充當(dāng)用于驗(yàn)證設(shè)備簽名信息的公鑰;M代表可用于承載發(fā)布數(shù)據(jù)資源的主體信息;t為時(shí)間戳;sig的生成方法如下:
①u(mài);D=gu;
②e=H1(T,UUIDp,M,t,D);
③v=(u+SKp_sig·e)modq;
返回簽名sig=(D,v)。
消息加密:Cm=Enc_AES(SK,(T,UUIDp,M,t,sig))。消息加密采用AES 對(duì)稱(chēng)加密,加密密鑰是發(fā)布者預(yù)生成的會(huì)話(huà)密鑰SK。
2)發(fā)布消息封裝與發(fā)送。
發(fā)布者端消息處理完畢,生成有效載荷Cp||Cm,并將該發(fā)布消息發(fā)送到代理。
3)代理重加密:ReEnc(RKp→s,Cp) →Cs。
在發(fā)布/訂閱者與代理建立連接階段,使用設(shè)備UUID 作為客戶(hù)端標(biāo)識(shí)。代理收到發(fā)布消息可根據(jù)發(fā)布者UUIDp和相應(yīng)主題的訂閱者UUIDs進(jìn)行重加密密鑰RKp→s的查找或請(qǐng)求。
代理對(duì)Cp重加密的計(jì)算方法如下:
輸出密文:Cs=(Cs1,Cs2,Cs3,Cs4,Cs5)。
4)代理轉(zhuǎn)發(fā)發(fā)布消息。
重加密密文生成后,代理對(duì)消息有效載荷Cs||Cm進(jìn)行封裝并發(fā)送給訂閱者。
5)訂閱信息解析。
訂閱者按如下步驟解析信息:
5a)解密會(huì)話(huà)密鑰:Dec(SKs,Cs) →SK
算法正確性證明如下:
5b)消息解密:Dec_AES(SK,Cm) →(T,UUIDp,M,t,sig)。
訂閱者使用解密代理重加密密文Cp后獲得的SK對(duì)Cm進(jìn)行AES解密,即可得到消息主體(T,UUIDp,M,t,sig)。
5c)簽名驗(yàn)證。
解密出主體消息后,訂閱者首先核驗(yàn)時(shí)間戳t。如果時(shí)間戳核驗(yàn)通過(guò),訂閱者繼續(xù)對(duì)消息主體的簽名(sig=(D,v))進(jìn)行驗(yàn)證,簽名驗(yàn)證按如下步驟進(jìn)行:
①計(jì)算:H1(T,UUIDp,M,t,D);
驗(yàn)證通過(guò)的情況下,訂閱者接受消息主體中的數(shù)據(jù)資源M,否則消息被拒絕。
分別與文獻(xiàn)[6]中提出的基于AugPAKE 協(xié)商會(huì)話(huà)密鑰的方案、文獻(xiàn)[7]中提出的基于輕量級(jí)非對(duì)稱(chēng)加密協(xié)商會(huì)話(huà)密鑰的方案、文獻(xiàn)[11]中提出的基于身份密碼學(xué)非對(duì)稱(chēng)加密協(xié)商會(huì)話(huà)密鑰的方案和文獻(xiàn)[12]中提出的基于屬性代理重加密數(shù)據(jù)資源的方案進(jìn)行對(duì)比分析和性能評(píng)估。表2~4提供了本文方案與MQTT 安全性相關(guān)的其他幾個(gè)方案間的對(duì)比,比較的內(nèi)容包括:性能、計(jì)算成本和通信開(kāi)銷(xiāo)。
性能表現(xiàn)如表2 所示。性能表現(xiàn)對(duì)比點(diǎn)的選取是根據(jù)較為嚴(yán)格的零信任安全理念確定的。MQTT 端到端的加密要求數(shù)據(jù)從發(fā)布者端到訂閱者端全程處于密文狀態(tài),不允許除發(fā)布/訂閱者以外的第三方獲得明文。半誠(chéng)實(shí)代理要求代理嚴(yán)格按照協(xié)議規(guī)范進(jìn)行報(bào)文的處理,而不依賴(lài)于代理保守秘密。身份認(rèn)證要求從消息中的某些信息能夠確認(rèn)發(fā)布者或訂閱者的身份,但充當(dāng)確認(rèn)角色的可是發(fā)布/訂閱者本身、代理或是其他第三方??臻g解耦特性是MQTT 通信協(xié)議的優(yōu)勢(shì),指發(fā)布者與訂閱者不需要互相了解。在部分安全性解決方案中(如文獻(xiàn)[11]方案),為加強(qiáng)安全性發(fā)布/訂閱者必須持有關(guān)聯(lián)對(duì)方身份的秘密,從而破壞了MQTT協(xié)議本身的優(yōu)勢(shì)特性。
表2 不同方案性能表現(xiàn)對(duì)比Tab.2 Performance comparison of different schemes
本文主要關(guān)注數(shù)據(jù)傳輸過(guò)程的安全性問(wèn)題,沒(méi)有對(duì)發(fā)布/訂閱者與代理建立連接的過(guò)程進(jìn)行約束,所以方案缺乏對(duì)訂閱者認(rèn)證的安全屬性。這一問(wèn)題將在建立MQTT 認(rèn)證授權(quán)機(jī)制的未來(lái)工作中進(jìn)行補(bǔ)充。
計(jì)算開(kāi)銷(xiāo)對(duì)比如表3 所示。討論中省略相對(duì)較快的操作,如隨機(jī)數(shù)生成、異或等。
表3 不同方案計(jì)算開(kāi)銷(xiāo)對(duì)比Tab.3 Computation overhead comparison of different schemes
為了更加合理地對(duì)比各方案,首先對(duì)本文的解決方案進(jìn)行如下補(bǔ)充說(shuō)明:
1)發(fā)布者端密鑰派生函數(shù)生成會(huì)話(huà)密鑰過(guò)程的計(jì)算開(kāi)銷(xiāo)處理。密鑰派生函數(shù)生成會(huì)話(huà)密鑰過(guò)程比較簡(jiǎn)單,比如輸入一個(gè)隨機(jī)數(shù)和一個(gè)計(jì)數(shù)器當(dāng)前值,然后進(jìn)行一次哈希運(yùn)算,即得到一個(gè)密鑰。在與文獻(xiàn)[7]方案對(duì)比時(shí),兩方案均使用密鑰派生函數(shù)生成會(huì)話(huà)密鑰,同時(shí)不討論密鑰派生函數(shù)預(yù)生成會(huì)話(huà)密鑰的過(guò)程。在與文獻(xiàn)[6]、[11]、[12]中方案進(jìn)行對(duì)比時(shí),將密鑰派生函數(shù)生成會(huì)話(huà)密鑰的計(jì)算開(kāi)銷(xiāo)等同于一次哈希運(yùn)算。
2)訂閱者身份認(rèn)證計(jì)算量的補(bǔ)充。由于本文方案沒(méi)有討論訂閱者身份認(rèn)證,為公平對(duì)比,在訂閱者端增加一次本文所采用簽名算法的簽名計(jì)算開(kāi)銷(xiāo)(1E+1M+1A+1H),在代理處增加一次簽名驗(yàn)證計(jì)算開(kāi)銷(xiāo)(2E+1M+1H)。表3 中增強(qiáng)的本文方案的計(jì)算開(kāi)銷(xiāo)表示功能補(bǔ)充后的總開(kāi)銷(xiāo),本文方案的計(jì)算開(kāi)銷(xiāo)表示解決方案原本的總開(kāi)銷(xiāo)。
在提供端到端加密方面,主要與文獻(xiàn)[11-12]中的方案進(jìn)行比較。本文的解決方案總共執(zhí)行:6 個(gè)模乘法、9 個(gè)求冪運(yùn)算、1個(gè)模加法、3個(gè)哈希函數(shù)和2個(gè)AES運(yùn)算。文獻(xiàn)[11]方案需要:8個(gè)基于身份密碼學(xué)的非對(duì)稱(chēng)加解密運(yùn)算和2個(gè)AES運(yùn)算。該方案本身優(yōu)勢(shì)是實(shí)現(xiàn)端到端的數(shù)據(jù)安全,并非為受限環(huán)境定制,因此8 個(gè)基于身份密碼學(xué)的非對(duì)稱(chēng)加解密運(yùn)算的計(jì)算開(kāi)銷(xiāo)是受限環(huán)境中設(shè)備無(wú)法承擔(dān)的。文獻(xiàn)[12]方案需要:3 個(gè)標(biāo)量乘法、1 個(gè)模乘法、7 個(gè)求冪運(yùn)算、4 個(gè)雙線性映射運(yùn)算,其中雙線性映射的計(jì)算量遠(yuǎn)遠(yuǎn)大于標(biāo)量乘的計(jì)算量。因此,該方案雖然應(yīng)用于物聯(lián)網(wǎng)環(huán)境,但計(jì)算開(kāi)銷(xiāo)比本文方案要大。
與其他不提供端到端加密的文獻(xiàn)[6]方案、文獻(xiàn)[7]方案相比。文獻(xiàn)[6]方案需要:10 個(gè)標(biāo)量乘法、6 個(gè)模乘法、2 個(gè)模加法、16 個(gè)哈希函數(shù)、6 個(gè)AES 運(yùn)算、6 個(gè)MAC 操作。文獻(xiàn)[7]方案需要:12個(gè)標(biāo)量乘法、2個(gè)模乘法、4個(gè)模加法、4個(gè)哈希函數(shù)和6 個(gè)AES 操作。與這些方案相比,本文方案在計(jì)算開(kāi)銷(xiāo)方面的優(yōu)勢(shì)不突出,但本文方案可以提供端到端的數(shù)據(jù)機(jī)密性,防止出現(xiàn)不誠(chéng)實(shí)代理或受攻擊代理泄露數(shù)據(jù)的問(wèn)題。
通信開(kāi)銷(xiāo)的對(duì)比如表4 所示。文獻(xiàn)[6-7,11]中的方案中發(fā)布/訂閱者與代理間的密鑰協(xié)商分別需要5、1、1 條消息完成,本文方案與文獻(xiàn)[12]方案不需要額外的協(xié)商消息。
表4 不同方案通信開(kāi)銷(xiāo)對(duì)比Tab.4 Communication overhead comparison of different schemes
通過(guò)比較可以發(fā)現(xiàn),本文的端到端加密主要優(yōu)勢(shì)在于不需要發(fā)布/訂閱者與代理之間的密鑰協(xié)商操作以及代理解密數(shù)據(jù)再加密數(shù)據(jù)的重復(fù)操作。此外,本文方案使用代理重加密算法并將驗(yàn)證簽名的公鑰定義為設(shè)備UUID 隨數(shù)據(jù)消息一起傳輸,發(fā)布/訂閱者只需存儲(chǔ)各自的公私鑰對(duì)和簽名生成與驗(yàn)證所使用的密鑰對(duì),無(wú)需存儲(chǔ)對(duì)等方的公鑰。
本文的解決方案在取得計(jì)算開(kāi)銷(xiāo)、通信開(kāi)銷(xiāo)以及密鑰存儲(chǔ)開(kāi)銷(xiāo)方面優(yōu)勢(shì)時(shí)也有一定的代價(jià)。與文獻(xiàn)[7]方案相似,本文提出的解決方案將其他一些信息(主題、UUID、時(shí)間戳、簽名、會(huì)話(huà)密鑰密文)封裝在MQTT 報(bào)文的有效載荷中,壓縮了數(shù)據(jù)資源的空間。但主題、UUID、時(shí)間戳、簽名四部分信息的位數(shù)僅占有效載荷最大總位數(shù)的1/4,而且會(huì)話(huà)密鑰密文僅在文件傳輸?shù)氖讉€(gè)數(shù)據(jù)包中發(fā)送。因此,本文提出的安全方案不影響協(xié)議正常使用。
本文中的解決方案將代理重加密過(guò)程中最復(fù)雜的重加密密鑰生成過(guò)程轉(zhuǎn)移到可信中心,使得發(fā)布/訂閱者的計(jì)算量保持在與文獻(xiàn)[6]方案、文獻(xiàn)[7]方案相當(dāng)?shù)乃?。同時(shí)可信中心生成重加密密鑰的過(guò)程是伴隨設(shè)備陸續(xù)注冊(cè)進(jìn)行的預(yù)處理,因此可信中心的重加密密鑰生成不會(huì)成為本文方案的技術(shù)瓶頸。
3.2.1 算法安全性證明
1)困難問(wèn)題假設(shè)。
本文提出的方案的安全性基于決策性Diffie-Hellman(Decisional Diffie-Hellman,DDH)難解問(wèn)題。已知gx,gy,gz∈G,其中x,y,z∈不可知,G為階取q的循環(huán)群。判斷輸出與z=xymodq是否一致,即DDH 難解問(wèn)題。DDH 假設(shè)表示在多項(xiàng)式時(shí)間t內(nèi)敵手A能夠以如下概率解決DDH問(wèn)題:
其中?是可以忽略的,則稱(chēng)DDH問(wèn)題是(t,?)難解的。
2)安全模型。
定義如果敵手A在多項(xiàng)式時(shí)間內(nèi)以可忽略的優(yōu)勢(shì)贏得游戲,那么提出的代理重加密算法滿(mǎn)足選擇密文攻擊(Chosen Ciphertext Attack,CCA)安全性。
下面給出挑戰(zhàn)者C 和敵手A 間的3 個(gè)階段組成的選擇密文攻擊游戲。
初始階段 C 運(yùn)行KeyGen 算法生成公私鑰對(duì),C 將公鑰發(fā)送給A,并將(SKi,PKi)記錄在列表TPK中。
階段1 A 向C 發(fā)出以下系列的預(yù)言機(jī)詢(xún)問(wèn):OSK、ORK、ORE、ODEC,C向A返回查詢(xún)結(jié)果。
私鑰生成預(yù)言機(jī)OSK:A 輸入PKi=(pki1,pki2),C 檢索列表TPK查找PKi并將其對(duì)應(yīng)的私鑰SKi=(ski1,ski2)返回給A。
重加密密鑰生成預(yù)言機(jī)ORK:A輸入(PKi,PKj),其中PKi和PKj都由C檢索返回。C返回RKi→j=(rk1,rk2,rk3)給A。
代理重加密預(yù)言機(jī)ORE:A 輸入(PKi,PKj,Cp),C 返回重加密密文ReEnc(Cp,ORK(PKi,PKj))。
解密查詢(xún)預(yù)言機(jī)ODEC:A輸入PK和密文C,C查詢(xún)PK對(duì)應(yīng)的私鑰SK,執(zhí)行解密算法恢復(fù)明文M并返回M。
挑戰(zhàn)階段 一旦A結(jié)束階段1,將從明文空間中選擇兩個(gè)等長(zhǎng)的明文消息M0、M1和一個(gè)公鑰PK*向C發(fā)起挑戰(zhàn)。C選擇隨機(jī)比特d∈{0,1}并計(jì)算密文C*=Encrypt(PK*,Md)返回給A。
階段2 敵手A在額外的條件下繼續(xù)發(fā)出階段1的查詢(xún)。
猜測(cè)階段 最終敵手A 返回給C 一個(gè)猜測(cè)結(jié)果d′∈{0,1},若d′=d,則A在游戲中獲勝。
3)安全性證明。
定理如果DDH 假設(shè)成立,本文提出的代理重加密方案在隨機(jī)預(yù)言機(jī)模型中安全于適應(yīng)性選擇密文攻擊(Adaptive Chosen Ciphertext Attack,CCA2)。
證明 如果存在敵手A可以在多項(xiàng)式時(shí)間內(nèi)以不可忽略的優(yōu)勢(shì)破壞CCA2 安全性,那么敵手A 可以構(gòu)建算法來(lái)解決DDH 難題。即輸入由構(gòu)建的算法確定T=gab是否成立。挑戰(zhàn)者C構(gòu)建以下隨機(jī)預(yù)言機(jī)模型。
OH1:C檢查列表H1_list中是否已經(jīng)存在(D,α)。如果存在,C 將α返回給A;如果不存在,隨機(jī)選擇將(D,α)記錄到H1_list,同時(shí)返回α=H1(D)。
OH2:C檢查列表H2_list中是否已經(jīng)存在(D,β)。如果存在,C 將β返回給A;如果不存在,選擇β,將(D,β)記錄到H2_list,同時(shí)返回β=H2(D)。
C記錄兩個(gè)列表:Klist為存儲(chǔ)公私鑰對(duì)的列表;RKlist為存儲(chǔ)重加密密鑰的列表。
階段1 A 進(jìn)行系列詢(xún)問(wèn):OPK、OSK、ORK、ORE、ODEC,C 向A返回查詢(xún)結(jié)果。
公鑰生成預(yù)言機(jī)OPK:輸入公鑰PKi=(pki1,pki2),預(yù)言機(jī)設(shè)置(pki1,pki2)=其中ski1、ski2是中的隨機(jī)數(shù),并將(pki1,pki1,ski1,ski2)加入列表Klist。
私鑰生成預(yù)言機(jī)OSK:輸入公鑰PKi=(pki1,pki2),C在列表Klist中檢索(pki1,pki1,ski1,ski2),并返回給A 相應(yīng)的私鑰SKi=(ski1,ski2)。
重加密密鑰生成預(yù)言機(jī)ORK:輸入PKi、PKj(二者均來(lái)自O(shè)PK),C 從Klist檢索相應(yīng)的公鑰獲取私鑰SKi=(ski1,ski2),其中w3=ski1-ski2·w2modq。然后運(yùn)行重加密密鑰生成算法獲取重加密密鑰,并返回RKi→j=(rk1,rk2,rk3)給C。
代理重加密預(yù)言機(jī)ORE:A 輸入(PKi,PKj,Cp),C 返回重加密密文ReEnc(Cp,ORK(PKi,PKj))。
解密查詢(xún)預(yù)言機(jī)ODEC:輸入(PKi,Cs),C 檢索相應(yīng)的私鑰SKj,并返回Dec(ReEnc(Cp,ORK(PKi,PKj)),skj)。
挑戰(zhàn)階段 完成上述詢(xún)問(wèn)后,A向C發(fā)送PK′i以及兩條等長(zhǎng)消息M0、M1∈{0,1}。算法A 從列表Klist中恢復(fù)出PKi,SKi和密文。C 選擇隨機(jī)比特d∈{0,1}并按如下步驟生成挑戰(zhàn)密文:
階段2 敵手A在以下條件下重復(fù)詢(xún)問(wèn)。
①詢(xún)問(wèn)ORK(,PKj);
②如果敵手A 發(fā)布ReEnc(Cp,RK) →Cs,其中RK由公式ReKeyGen(par,SKi,PKj) →RK;
③詢(xún)問(wèn)ODE(Cs,SKj)。
猜測(cè)階段 最終,A 返回給C 一個(gè)猜測(cè)值d′∈{0,1}。當(dāng)T=gab時(shí),C*=與ReEnc(Cp,RK)→Cs相同。T=gab被隨機(jī)數(shù)T∈G替換。因此敵手A 無(wú)法以高于1/2的概率猜測(cè)到挑戰(zhàn)密文中的值d。
3.2.2 協(xié)議安全性討論
本文提出的解決方案基于安全的代理重加密算法,并支持的安全屬性:
1)數(shù)據(jù)端到端的機(jī)密性。
數(shù)據(jù)資源與會(huì)話(huà)密鑰在通信全程都是以密文的形式進(jìn)行傳輸,代理也無(wú)法解密數(shù)據(jù),只有發(fā)布者和對(duì)應(yīng)的訂閱者可以解密密文獲得明文信息。
2)數(shù)據(jù)真實(shí)性、完整性和不可否認(rèn)性。
方案通過(guò)Schnorr 簽名方案確保此屬性。只有擁有簽名密鑰的發(fā)布者才能對(duì)報(bào)文進(jìn)行簽名。
3)重放攻擊保護(hù)。
發(fā)布消息均包含時(shí)間戳,可以防止攻擊者重放這些消息。
4)中間人攻擊防護(hù)。
發(fā)布/訂閱者通過(guò)用戶(hù)向TC 注冊(cè)獲取密鑰信息,除發(fā)布者用來(lái)驗(yàn)證簽名的公鑰以設(shè)備UUID 的形式會(huì)公開(kāi)給代理外,其他的密鑰信息即使是公鑰也不對(duì)外公開(kāi),因此中間人無(wú)法窺探到以密文形式傳輸?shù)膱?bào)文中任何秘密信息;而且本文中的方案不涉及發(fā)布者與訂閱者之間或發(fā)布/訂閱者與代理之間的密鑰協(xié)商過(guò)程,因此中間人無(wú)法實(shí)施攻擊。危害最大的是一個(gè)合法的訂閱者充當(dāng)中間人角色,并且該中間人與代理合謀。代理將傳輸給目標(biāo)訂閱者的報(bào)文重加密后發(fā)送給合謀的中間人。但重加密密鑰是與真實(shí)訂閱者密鑰對(duì)中的公鑰相關(guān)聯(lián)的,即使攻擊者獲得密文也會(huì)因缺乏對(duì)應(yīng)的私鑰而無(wú)法解密。
5)隱私保護(hù)。
本文的解決方案中,唯一代表發(fā)布/訂閱者身份的公開(kāi)信息是UUID,但該UUID 真正代表的設(shè)備和用戶(hù)的身份只有TC知道。發(fā)布/訂閱者相互間不知道對(duì)方身份信息,代理也不了解發(fā)布/訂閱者的真實(shí)身份。
6)發(fā)布者認(rèn)證。
發(fā)布者在發(fā)布信息中加入簽名,訂閱者只要驗(yàn)證簽名就可以確定UUID 的真實(shí)性。在有需要的情況下(如安全事件發(fā)生),訂閱者可以將UUID提交給TC就可以認(rèn)證發(fā)布者的真實(shí)身份。
本文提出了一種將代理重加密算法用于MQTT 通信的安全解決方案,為MQTT 通信模型提供端到端的數(shù)據(jù)安全性。方案降低了對(duì)代理的信任度要求,可以很好適應(yīng)基于云服務(wù)的應(yīng)用環(huán)境。所提解決方案使用有效的代理重加密方案并進(jìn)行修改,以適應(yīng)資源受限的物聯(lián)網(wǎng)環(huán)境。通過(guò)與該領(lǐng)域的相關(guān)工作進(jìn)行比較,證明了所提解決方案的安全消息開(kāi)銷(xiāo)很小。
下一步工作主要填補(bǔ)解決方案中對(duì)客戶(hù)端設(shè)備接入認(rèn)證和發(fā)布/訂閱請(qǐng)求授權(quán)的空白,結(jié)合代理重加密密鑰的生成,制定與本方案契合的認(rèn)證授權(quán)機(jī)制。