基于代理重加密的消息隊列遙測傳輸協(xié)議端到端安全解決方案

谷正川，郭淵博，方 晨

（1.戰(zhàn)略支援部隊信息工程大學(xué)密碼工程學(xué)院，鄭州 450002；2.中國人民解放軍77562部隊，西藏日喀則 857000）

（*通信作者電子郵箱zhengchuan_g@163.com）

0 引言

物聯(lián)網(wǎng)作為一項改變數(shù)據(jù)共享格局的技術(shù)，近年來伴隨著無線通信技術(shù)的發(fā)展掀起了新的發(fā)展浪潮。據(jù)全球移動通信系統(tǒng)協(xié)會（Global System for Mobile Communications Association，GSMA）預(yù)測，2025年全球物聯(lián)網(wǎng)終端連接數(shù)量將達(dá)到250億［1］。物聯(lián)網(wǎng)將數(shù)字世界與物理世界相映射，通過物聯(lián)網(wǎng)連接到互聯(lián)網(wǎng)的數(shù)百億設(shè)備在共享信息的過程中可能生成數(shù)萬億條信息。如何保證這些信息的安全性是一項基本挑戰(zhàn)。消息隊列遙測傳輸（Message Queue Telemetry Transport，MQTT）作為物聯(lián)網(wǎng)中流行的應(yīng)用層協(xié)議之一，因它在資源和計算上的占用空間小而得到廣泛應(yīng)用［2］。但是MQTT 協(xié)議中只規(guī)范了一些可選的弱防護機制，如使用客戶端ID 以及用戶名/口令對客戶端進(jìn)行身份驗證，這種程度的安全性機制不能滿足物聯(lián)網(wǎng)中不斷增長的安全性需求。為提高M(jìn)QTT 的安全性，協(xié)議給出了一些建議，如客戶端認(rèn)證使用X.509客戶端證書、底層傳輸協(xié)議使用安全傳輸層協(xié)議（Transport Layer Security，TLS）代替純傳輸控制協(xié)議（Transmission Control Protocol，TCP）。但這些機制的安全性成本超出了物聯(lián)網(wǎng)受限設(shè)備在計算能力和內(nèi)存等方面的可接受范圍。因此，開發(fā)一種具備高安全性且適用于物聯(lián)網(wǎng)中資源受限設(shè)備的解決方案，成為MQTT安全性研究的熱點。

另一個問題是MQTT 代理的可信任性越來越受到質(zhì)疑。MQTT 通信模型屬于發(fā)布/訂閱范式，其通信依賴的核心是MQTT 代理。零信任是一種新型安全框架，其核心理念是“從不信任并始終驗證”，即內(nèi)部和外部網(wǎng)絡(luò)都不可信［3］。2020年2 月美國國家標(biāo)準(zhǔn)與技術(shù)研究院（National Institute of Standards and Technology，NIST）發(fā)布的零信任架構(gòu)（第2 版草案）［4］再次強調(diào)：零信任是一種以資源保護為核心的網(wǎng)絡(luò)安全范式，其前提是信任從來不是隱式授予的，而是必須進(jìn)行持續(xù)評估。因此，即使MQTT 代理位于受防火墻保護的內(nèi)部網(wǎng)絡(luò)也是不可信的。而且，隨著云技術(shù)的發(fā)展，MQTT 代理服務(wù)器也從本地轉(zhuǎn)移至云端。阿里云、騰訊云等云服務(wù)商提供的MQTT 云服務(wù)在提供便利時也帶來了代理服務(wù)器端數(shù)據(jù)安全的巨大隱患。

為解決上述問題，本文消除對MQTT 代理的隱式信任，將其定義為半誠實參與方。通過結(jié)合Schnorr 簽名［5］、高級加密標(biāo)準(zhǔn)（Advanced Encryption Standard，AES）和代理重加密三種密碼技術(shù)，提出一種適用于受限物聯(lián)網(wǎng)設(shè)備的MQTT 端到端數(shù)據(jù)安全傳輸解決方案，其主要工作有以下幾點：

1）使用輕量級代理重加密算法進(jìn)行會話密鑰加密傳輸，結(jié)合AES 對稱加密算法確保MQTT 數(shù)據(jù)傳輸?shù)亩说蕉税踩裕?/p>

2）將代理重加密密鑰的生成工作由發(fā)布者端轉(zhuǎn)移至可信中心，避免在發(fā)布者客戶端設(shè)備上進(jìn)行大量復(fù)雜計算和密鑰存儲；

3）采用Schnorr 簽名對發(fā)布消息進(jìn)行數(shù)字簽名，訂閱者不需要存儲發(fā)布者公鑰也可驗證消息來源真實性、完整性和不可否認(rèn)性。

1 相關(guān)工作

在假設(shè)MQTT 代理可信或經(jīng)過身份認(rèn)證后可信的前提下，許多研究通過在MQTT 發(fā)布/訂閱者客戶端與MQTT 代理間使用非對稱密碼體制協(xié)商會話密鑰或安全傳輸會話密鑰。然后使用會話密鑰對傳輸數(shù)據(jù)進(jìn)行對稱加密來實現(xiàn)發(fā)布者與訂閱者間的數(shù)據(jù)機密性。

Calabretta 等［6］提出一種基于增強的口令認(rèn)證密鑰交換（Augmented Password-Authenticated Key Exchange，AugPAKE）協(xié)議的MQTT 安全通信方案，客戶端與代理間通過特定主題進(jìn)行4 次信息交互完成AugPAKE 協(xié)議過程，實現(xiàn)客戶端與代理間的相互認(rèn)證，并協(xié)商出后續(xù)數(shù)據(jù)加密傳輸?shù)臅捗荑€，使每個節(jié)點（無論是發(fā)布者還是訂閱者）都與代理間維持一個會話密鑰。文中明確表示，將代理視為信任的實體，負(fù)責(zé)解密和加密MQTT 有效載荷，對交換數(shù)據(jù)具有完全的可見性。盡管作者建議數(shù)據(jù)由代理以加密格式存儲，只有當(dāng)代理收到授權(quán)（和驗證）的訂閱請求時才能對數(shù)據(jù)進(jìn)行解密和重新加密。但攻擊者仍然可以通過攻擊代理或與代理共謀來窺探MQTT 通信中傳輸?shù)臄?shù)據(jù)。另外，該方案中4次MQTT信息交互產(chǎn)生了較大的額外通信開銷。

文獻(xiàn)［7］中提出了一種基于MQTT 協(xié)議的分級安全框架，使用Rabin 加密密碼系統(tǒng)［8］、橢圓曲線集成加密方案（Elliptic Curve Integrated Encryption Scheme，ECIES）［9］和帶伽羅瓦消息驗證碼的計數(shù)器模式運行高級加密標(biāo)準(zhǔn)（Advanced Encryption Standard in Galois/Counter Mode，AES-GCM）加密方案為不同敏感程度的數(shù)據(jù)提供不同級別的安全性。所有加解密采用輕量級密碼方案，并將密碼方案嵌入正常的MQTT 發(fā)布/訂閱通信流中，無需使用額外的安全性開銷。但該方案也是通過MQTT 代理加密和解密發(fā)布/訂閱者間傳輸?shù)臄?shù)據(jù)，同樣存在代理是否可信的問題。

文獻(xiàn)［10］中，作者試圖通過將MQTT 與通用異步接收器/發(fā)送器和Rime協(xié)議棧一起用作傳輸患者醫(yī)療數(shù)據(jù)的協(xié)議，創(chuàng)建一個安全的端到端物聯(lián)網(wǎng)環(huán)境。使用具有256 位密鑰的AES-GCM 實現(xiàn)端到端數(shù)據(jù)機密性，但是需要通過基于哈希消息認(rèn)證碼的密鑰派生函數(shù)和橢圓曲線上的Diffie-Hellman（DH）密鑰交換算法管理系統(tǒng)中不同實體間的密鑰。同時，路由需要解密含有多個傳感器加密數(shù)據(jù)的聚合數(shù)據(jù)包，分別進(jìn)行驗證后使用預(yù)加載密鑰重新聚合加密再發(fā)送給數(shù)據(jù)訂閱者。

文獻(xiàn)［11-12］中對代理的隱式信任不作強制要求，分別通過基于身份密碼學(xué)和基于代理重加密實現(xiàn)端到端的數(shù)據(jù)安全性。文獻(xiàn)［11］中提出一種基于身份密碼術(shù)的會話密鑰協(xié)商方案。用戶與提供傳感器數(shù)據(jù)的物聯(lián)網(wǎng)網(wǎng)關(guān)間通過基于身份密碼術(shù)的公鑰加密進(jìn)行相互認(rèn)證，并在一個往返時間內(nèi)協(xié)商出可用于后續(xù)通信加解密的會話密鑰。該方案在提供端到端數(shù)據(jù)安全性的同時，還減少了使用基于公鑰基礎(chǔ)設(shè)施（Public Key Infrastructure，PKI）的公鑰加密完成身份認(rèn)證和會話密鑰協(xié)商的方案中的證書存儲開銷。但基于身份密碼術(shù)的公鑰體制對于計算和存儲能力要求較高，難以適用于資源受限的物聯(lián)網(wǎng)設(shè)備。Kim 等［12］提出了一種物聯(lián)網(wǎng)環(huán)境下在輕量級設(shè)備上使用常規(guī)密碼算法共享和管理數(shù)據(jù)的方法，該方案的實現(xiàn)結(jié)合了代理重加密體制［13-14］。代理重加密是一種典型的密文共享方案，通過代理服務(wù)器將一個用戶的密文轉(zhuǎn)換為另一個用戶可以解密的密文，整個過程中不泄露用戶的私鑰和明文信息。文獻(xiàn)［12］通過使用代理重加密減少數(shù)據(jù)共享過程中單個節(jié)點的加密計算負(fù)擔(dān)，每個節(jié)點執(zhí)行加密和創(chuàng)建重加密密鑰，然后將加密密文和重加密密鑰發(fā)送到代理服務(wù)器，由代理服務(wù)器生成允許其他節(jié)點解密的密文。在傳統(tǒng)的點對點數(shù)據(jù)共享方式中，提供數(shù)據(jù)的節(jié)點需要與所有使用該數(shù)據(jù)的節(jié)點間分別進(jìn)行一次加解密操作。因此，與傳統(tǒng)數(shù)據(jù)共享方式相比該方案減少了數(shù)據(jù)共享過程中的加解密次數(shù)；但該方案使用的是基于橢圓曲線密碼系統(tǒng)的代理重加密算法，算法中包含雙線性映射。雙線性映射的計算開銷遠(yuǎn)大于橢圓曲線上的標(biāo)量乘法［15］，并不是輕量級密碼算法的首選。此外，在該方案中每個節(jié)點除執(zhí)行數(shù)據(jù)加密外還需要為每個共享數(shù)據(jù)的節(jié)點生成重加密密鑰，操作時間將隨傳感器節(jié)點的數(shù)量成正比例增加。

因此，本文提出了一種基于代理重加密實現(xiàn)MQTT 端到端安全性的解決方案。該方案在確保MQTT 數(shù)據(jù)傳輸端到端安全性的同時，通過采取以下兩點措施來適應(yīng)資源受限的物聯(lián)網(wǎng)環(huán)境：1）使用AES加密傳感數(shù)據(jù)，只對AES加密使用的會話密鑰進(jìn)行代理重加密，大量減少非對稱加解密操作；2）將傳統(tǒng)代理重加密框架［13，16-17］中重加密密鑰的生成操作由發(fā)布者轉(zhuǎn)移到包含有密鑰生成中心（Key Generation Center，KGC）的可信中心，從而減少發(fā)布者端的計算量和密鑰存儲量。此外，本方案中采用Schnorr簽名確保數(shù)據(jù)完整性、來源的真實性和不可否認(rèn)性。

2 MQTT端到端安全解決方案

本章主要介紹為MQTT 服務(wù)提出的基于代理重加密安全框架，以及使用的符號和加密方法、方案架構(gòu)和具體流程的各個階段。

2.1 使用的符號和密碼學(xué)

表1中定義了所提方案中使用的符號。

表1 所提方案使用的符號Tab.1 Notations used in the proposed scheme

根據(jù)效率和安全性，本文選擇了以下密碼學(xué)加密方案：

AES 對稱加密，以及基于改良的計算Diffie-Hellman（modified Computational Diffie-Hellman，mCDH）難題的代理重加密算法和Schnorr簽名算法［13］。

AES 用于數(shù)據(jù)資源加解密，代理重加密算法保護AES 加密密鑰，Schnorr算法對信息進(jìn)行數(shù)字簽名防篡改。

2.2 方案概述

方案框架如圖1 所示，模型由4 個實體組成：發(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ā)布/訂閱者客戶端設(shè)備進(jìn)行信息交互，資源受限客戶端設(shè)備的低安全防護級別擴大了MQTT代理的攻擊面。在這種情況下，選擇信任MQTT代理并對其進(jìn)行安全加固的成本是極高的，并且MQTT 代理上需要客戶端設(shè)備完全響應(yīng)的強安全約束條件也是客戶端設(shè)備難以承受的。本文設(shè)立的可信中心只是擴展了傳統(tǒng)無證書代理重加密系統(tǒng)模型［18］中KGC 實體（如圖2）的功能，而可信中心只響應(yīng)代理的重加密密鑰請求。因此在代理重加密系統(tǒng)模型中建立可信中心比安全加固代理的實用性要高。

圖2 無證書代理重加密Fig.2 Certificateless proxy re-encryption

發(fā)布者可以感知數(shù)據(jù)并生成按主題分類的消息。所有發(fā)布者將消息發(fā)送給代理，代理將它們轉(zhuǎn)發(fā)給最終用戶（訂閱者）。下面分別介紹各實體的組成與功能。

2.2.1 發(fā)布者

發(fā)布者通過密鑰派生函數(shù)（Key Derivation Function，KDF）生成會話密鑰，并利用會話密鑰對感知數(shù)據(jù)進(jìn)行AES加密；同時，使用自己的公鑰對會話密鑰進(jìn)行加密。最后，使用簽名密鑰簽名需要發(fā)送的消息。

2.2.2 代理

代理組成如圖3 所示。MQTT 核心模塊實現(xiàn)與發(fā)布/訂閱者在MQTT 協(xié)議標(biāo)準(zhǔn)下通信；安全套接字層超文本傳輸協(xié)議（Hyper Text Transfer Protocol over Secure socket layer，HTTPS）通信模塊實現(xiàn)代理與可信中心間安全的超文本傳輸協(xié)議通信；重加密模塊實現(xiàn)發(fā)布者會話密鑰密文的重加密。最后，將重加密密文和感知數(shù)據(jù)密文重新封裝到有效載荷，發(fā)送給數(shù)據(jù)的訂閱者。

圖3 代理結(jié)構(gòu)Fig.3 Architecture of broker

2.2.3 訂閱者

訂閱者使用主題向代理訂閱數(shù)據(jù)，收到代理發(fā)送的消息后，訂閱者首先解密經(jīng)代理重加密的密文獲取會話密鑰，使用該會話密鑰解密有效載荷得到明文信息。最后進(jìn)行消息簽名驗證，驗證通過則接受消息，否則丟棄。

2.2.4 可信中心

可信中心結(jié)構(gòu)如圖4 所示，主要包含注冊管理中心、密鑰生成中心、重加密密鑰生成器和數(shù)據(jù)庫。發(fā)布/訂閱者設(shè)備由設(shè)備所有者通過客戶端向可信中心注冊，注冊成功后由可信中心的KGC 為每個設(shè)備生成公私鑰對和簽名密鑰對?？尚胖行母鶕?jù)設(shè)備注冊的屬性（發(fā)布/訂閱）和主題進(jìn)行匹配，為每對的發(fā)布者-訂閱者對等方預(yù)生成重加密密鑰，并將生成的重加密密鑰通過安全的方式發(fā)送給代理。由于本文主要分析發(fā)布者與訂閱者端到端的數(shù)據(jù)安全，對于設(shè)備的認(rèn)證授權(quán)與訪問控制方案不進(jìn)行討論。

圖4 可信中心結(jié)構(gòu)Fig.4 Architecture of trusted center

2.3 具體流程

2.3.1 系統(tǒng)初始化與設(shè)備注冊

系統(tǒng)初始化與設(shè)備注冊流程如圖5所示。

圖5 系統(tǒng)初始化與設(shè)備注冊流程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)，其中素數(shù)q，階數(shù)為q的有限循環(huán)群G，g是G的生成元，哈希函數(shù)H1：{0，1}*→哈希函數(shù)H2：G→

2）用戶注冊設(shè)備。

用戶通過客戶端向TC 注冊設(shè)備，注冊內(nèi)容包括：設(shè)備標(biāo)識（如物理地址）、設(shè)備屬性（發(fā)布/訂閱）、設(shè)備主題（設(shè)備在MQTT通信中發(fā)布/訂閱該主題）。

3）公私鑰對生成：KeyGen(i) →(ski，pki)。

注冊成功后，TC 使用密鑰生成算法KeyGen()為設(shè)備i生成公私鑰對(ski，pki)。密鑰生成算法選擇xi并設(shè)ski=xi，pki=

發(fā)布/訂閱者設(shè)備的密鑰生成如下：

隨機選擇xi1，xi2，xi3設(shè)ski1=xi1，pki1=ski2=設(shè)置PKi=(pki1，pki2)，SKi=(ski1，ski2)；SKi_sig=ski3，PKi_sig=pki3。生成設(shè)備的公私鑰對(SKi，PKi)，簽名密鑰對(SKi_sig，PKi_sig)。由TC 統(tǒng)一生成設(shè)備通用唯一識別碼（Universally Unique Identifier，UUID），并設(shè)置UUIDi=PKi_sig。

此過程后，發(fā)布者獲得公私鑰對(SKp，PKp)、簽名密鑰對(SKp_sig，UUIDp)，訂閱者獲得公私鑰對(SKs，PKs)、簽名密鑰對(SKs_sig，UUIDs)；

4）安全參數(shù)返回。

注冊成功后，用戶必須將可信中心生成的系統(tǒng)參數(shù)、設(shè)備UUID、設(shè)備簽名密鑰和設(shè)備公私鑰對通過安全通道（如手工嵌入設(shè)備安全固件、使用設(shè)備可信平臺模塊安全存儲等）加載到設(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）會話密鑰預(yù)生成：KDF() →SK。

發(fā)布者使用KDF 生成會話密鑰SK。該算法可以使用計時器觸發(fā)，也可以使用計數(shù)器觸發(fā)。計時器觸發(fā)方式中，根據(jù)設(shè)置的會話密鑰生存周期進(jìn)行定期生成；計數(shù)器觸發(fā)方式中，根據(jù)限制會話密鑰加密次數(shù)進(jìn)行密鑰生成。對于最敏感的數(shù)據(jù)可以實行最高安全級別的防護，將會話密鑰設(shè)置為一次完整的數(shù)據(jù)發(fā)送一更換。

1b）預(yù)加密會話密鑰：Enc(PKp，SK) →Cp。

返回密文Cp=(Cp1，Cp2，Cp3)。

1c）消息簽名與加密。

消息主體為{T，UUID，M，t，sig}。其中T為發(fā)布數(shù)據(jù)對應(yīng)的主題；UUID是設(shè)備在TC 注冊后獲取的統(tǒng)一標(biāo)識，同時也充當(dāng)用于驗證設(shè)備簽名信息的公鑰；M代表可用于承載發(fā)布數(shù)據(jù)資源的主體信息；t為時間戳；sig的生成方法如下：

①u；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 對稱加密，加密密鑰是發(fā)布者預(yù)生成的會話密鑰SK。

2）發(fā)布消息封裝與發(fā)送。

發(fā)布者端消息處理完畢，生成有效載荷Cp||Cm，并將該發(fā)布消息發(fā)送到代理。

3）代理重加密：ReEnc(RKp→s，Cp) →Cs。

在發(fā)布/訂閱者與代理建立連接階段，使用設(shè)備UUID 作為客戶端標(biāo)識。代理收到發(fā)布消息可根據(jù)發(fā)布者UUIDp和相應(yīng)主題的訂閱者UUIDs進(jìn)行重加密密鑰RKp→s的查找或請求。

代理對Cp重加密的計算方法如下：

輸出密文：Cs=(Cs1，Cs2，Cs3，Cs4，Cs5)。

4）代理轉(zhuǎn)發(fā)發(fā)布消息。

重加密密文生成后，代理對消息有效載荷Cs||Cm進(jìn)行封裝并發(fā)送給訂閱者。

5）訂閱信息解析。

訂閱者按如下步驟解析信息：

5a）解密會話密鑰：Dec(SKs，Cs) →SK

算法正確性證明如下：

5b）消息解密：Dec_AES(SK，Cm) →(T，UUIDp，M，t，sig)。

訂閱者使用解密代理重加密密文Cp后獲得的SK對Cm進(jìn)行AES解密，即可得到消息主體(T，UUIDp，M，t，sig)。

5c）簽名驗證。

解密出主體消息后，訂閱者首先核驗時間戳t。如果時間戳核驗通過，訂閱者繼續(xù)對消息主體的簽名(sig=(D，v))進(jìn)行驗證，簽名驗證按如下步驟進(jìn)行：

①計算：H1(T，UUIDp，M，t，D)；

驗證通過的情況下，訂閱者接受消息主體中的數(shù)據(jù)資源M，否則消息被拒絕。

3 性能評估與安全討論

3.1 性能評估

分別與文獻(xiàn)［6］中提出的基于AugPAKE 協(xié)商會話密鑰的方案、文獻(xiàn)［7］中提出的基于輕量級非對稱加密協(xié)商會話密鑰的方案、文獻(xiàn)［11］中提出的基于身份密碼學(xué)非對稱加密協(xié)商會話密鑰的方案和文獻(xiàn)［12］中提出的基于屬性代理重加密數(shù)據(jù)資源的方案進(jìn)行對比分析和性能評估。表2～4提供了本文方案與MQTT 安全性相關(guān)的其他幾個方案間的對比，比較的內(nèi)容包括：性能、計算成本和通信開銷。

性能表現(xiàn)如表2 所示。性能表現(xiàn)對比點的選取是根據(jù)較為嚴(yán)格的零信任安全理念確定的。MQTT 端到端的加密要求數(shù)據(jù)從發(fā)布者端到訂閱者端全程處于密文狀態(tài)，不允許除發(fā)布/訂閱者以外的第三方獲得明文。半誠實代理要求代理嚴(yán)格按照協(xié)議規(guī)范進(jìn)行報文的處理，而不依賴于代理保守秘密。身份認(rèn)證要求從消息中的某些信息能夠確認(rèn)發(fā)布者或訂閱者的身份，但充當(dāng)確認(rèn)角色的可是發(fā)布/訂閱者本身、代理或是其他第三方?？臻g解耦特性是MQTT 通信協(xié)議的優(yōu)勢，指發(fā)布者與訂閱者不需要互相了解。在部分安全性解決方案中（如文獻(xiàn)［11］方案），為加強安全性發(fā)布/訂閱者必須持有關(guān)聯(lián)對方身份的秘密，從而破壞了MQTT協(xié)議本身的優(yōu)勢特性。

表2 不同方案性能表現(xiàn)對比Tab.2 Performance comparison of different schemes

本文主要關(guān)注數(shù)據(jù)傳輸過程的安全性問題，沒有對發(fā)布/訂閱者與代理建立連接的過程進(jìn)行約束，所以方案缺乏對訂閱者認(rèn)證的安全屬性。這一問題將在建立MQTT 認(rèn)證授權(quán)機制的未來工作中進(jìn)行補充。

計算開銷對比如表3 所示。討論中省略相對較快的操作，如隨機數(shù)生成、異或等。

表3 不同方案計算開銷對比Tab.3 Computation overhead comparison of different schemes

為了更加合理地對比各方案，首先對本文的解決方案進(jìn)行如下補充說明：

1）發(fā)布者端密鑰派生函數(shù)生成會話密鑰過程的計算開銷處理。密鑰派生函數(shù)生成會話密鑰過程比較簡單，比如輸入一個隨機數(shù)和一個計數(shù)器當(dāng)前值，然后進(jìn)行一次哈希運算，即得到一個密鑰。在與文獻(xiàn)［7］方案對比時，兩方案均使用密鑰派生函數(shù)生成會話密鑰，同時不討論密鑰派生函數(shù)預(yù)生成會話密鑰的過程。在與文獻(xiàn)［6］、［11］、［12］中方案進(jìn)行對比時，將密鑰派生函數(shù)生成會話密鑰的計算開銷等同于一次哈希運算。

2）訂閱者身份認(rèn)證計算量的補充。由于本文方案沒有討論訂閱者身份認(rèn)證，為公平對比，在訂閱者端增加一次本文所采用簽名算法的簽名計算開銷（1E+1M+1A+1H），在代理處增加一次簽名驗證計算開銷（2E+1M+1H）。表3 中增強的本文方案的計算開銷表示功能補充后的總開銷，本文方案的計算開銷表示解決方案原本的總開銷。

在提供端到端加密方面，主要與文獻(xiàn)［11-12］中的方案進(jìn)行比較。本文的解決方案總共執(zhí)行：6 個模乘法、9 個求冪運算、1個模加法、3個哈希函數(shù)和2個AES運算。文獻(xiàn)［11］方案需要：8個基于身份密碼學(xué)的非對稱加解密運算和2個AES運算。該方案本身優(yōu)勢是實現(xiàn)端到端的數(shù)據(jù)安全，并非為受限環(huán)境定制，因此8 個基于身份密碼學(xué)的非對稱加解密運算的計算開銷是受限環(huán)境中設(shè)備無法承擔(dān)的。文獻(xiàn)［12］方案需要：3 個標(biāo)量乘法、1 個模乘法、7 個求冪運算、4 個雙線性映射運算，其中雙線性映射的計算量遠(yuǎn)遠(yuǎn)大于標(biāo)量乘的計算量。因此，該方案雖然應(yīng)用于物聯(lián)網(wǎng)環(huán)境，但計算開銷比本文方案要大。

與其他不提供端到端加密的文獻(xiàn)［6］方案、文獻(xiàn)［7］方案相比。文獻(xiàn)［6］方案需要：10 個標(biāo)量乘法、6 個模乘法、2 個模加法、16 個哈希函數(shù)、6 個AES 運算、6 個MAC 操作。文獻(xiàn)［7］方案需要：12個標(biāo)量乘法、2個模乘法、4個模加法、4個哈希函數(shù)和6 個AES 操作。與這些方案相比，本文方案在計算開銷方面的優(yōu)勢不突出，但本文方案可以提供端到端的數(shù)據(jù)機密性，防止出現(xiàn)不誠實代理或受攻擊代理泄露數(shù)據(jù)的問題。

通信開銷的對比如表4 所示。文獻(xiàn)［6-7，11］中的方案中發(fā)布/訂閱者與代理間的密鑰協(xié)商分別需要5、1、1 條消息完成，本文方案與文獻(xiàn)［12］方案不需要額外的協(xié)商消息。

表4 不同方案通信開銷對比Tab.4 Communication overhead comparison of different schemes

通過比較可以發(fā)現(xiàn)，本文的端到端加密主要優(yōu)勢在于不需要發(fā)布/訂閱者與代理之間的密鑰協(xié)商操作以及代理解密數(shù)據(jù)再加密數(shù)據(jù)的重復(fù)操作。此外，本文方案使用代理重加密算法并將驗證簽名的公鑰定義為設(shè)備UUID 隨數(shù)據(jù)消息一起傳輸，發(fā)布/訂閱者只需存儲各自的公私鑰對和簽名生成與驗證所使用的密鑰對，無需存儲對等方的公鑰。

本文的解決方案在取得計算開銷、通信開銷以及密鑰存儲開銷方面優(yōu)勢時也有一定的代價。與文獻(xiàn)［7］方案相似，本文提出的解決方案將其他一些信息（主題、UUID、時間戳、簽名、會話密鑰密文）封裝在MQTT 報文的有效載荷中，壓縮了數(shù)據(jù)資源的空間。但主題、UUID、時間戳、簽名四部分信息的位數(shù)僅占有效載荷最大總位數(shù)的1/4，而且會話密鑰密文僅在文件傳輸?shù)氖讉€數(shù)據(jù)包中發(fā)送。因此，本文提出的安全方案不影響協(xié)議正常使用。

本文中的解決方案將代理重加密過程中最復(fù)雜的重加密密鑰生成過程轉(zhuǎn)移到可信中心，使得發(fā)布/訂閱者的計算量保持在與文獻(xiàn)［6］方案、文獻(xiàn)［7］方案相當(dāng)?shù)乃?。同時可信中心生成重加密密鑰的過程是伴隨設(shè)備陸續(xù)注冊進(jìn)行的預(yù)處理，因此可信中心的重加密密鑰生成不會成為本文方案的技術(shù)瓶頸。

3.2 算法安全性證明與協(xié)議安全性討論

3.2.1 算法安全性證明

1）困難問題假設(shè)。

本文提出的方案的安全性基于決策性Diffie-Hellman（Decisional Diffie-Hellman，DDH）難解問題。已知gx，gy，gz∈G，其中x，y，z∈不可知，G為階取q的循環(huán)群。判斷輸出與z=xymodq是否一致，即DDH 難解問題。DDH 假設(shè)表示在多項式時間t內(nèi)敵手A能夠以如下概率解決DDH問題：

其中?是可以忽略的，則稱DDH問題是（t，?）難解的。

2）安全模型。

定義如果敵手A在多項式時間內(nèi)以可忽略的優(yōu)勢贏得游戲，那么提出的代理重加密算法滿足選擇密文攻擊（Chosen Ciphertext Attack，CCA）安全性。

下面給出挑戰(zhàn)者C 和敵手A 間的3 個階段組成的選擇密文攻擊游戲。

初始階段 C 運行KeyGen 算法生成公私鑰對，C 將公鑰發(fā)送給A，并將(SKi，PKi)記錄在列表TPK中。

階段1 A 向C 發(fā)出以下系列的預(yù)言機詢問：OSK、ORK、ORE、ODEC，C向A返回查詢結(jié)果。

私鑰生成預(yù)言機OSK：A 輸入PKi=(pki1，pki2)，C 檢索列表TPK查找PKi并將其對應(yīng)的私鑰SKi=(ski1，ski2)返回給A。

重加密密鑰生成預(yù)言機ORK：A輸入(PKi，PKj)，其中PKi和PKj都由C檢索返回。C返回RKi→j=(rk1，rk2，rk3)給A。

代理重加密預(yù)言機ORE：A 輸入(PKi，PKj，Cp)，C 返回重加密密文ReEnc(Cp，ORK(PKi，PKj))。

解密查詢預(yù)言機ODEC：A輸入PK和密文C，C查詢PK對應(yīng)的私鑰SK，執(zhí)行解密算法恢復(fù)明文M并返回M。

挑戰(zhàn)階段 一旦A結(jié)束階段1，將從明文空間中選擇兩個等長的明文消息M0、M1和一個公鑰PK*向C發(fā)起挑戰(zhàn)。C選擇隨機比特d∈｛0，1｝并計算密文C*=Encrypt(PK*，Md)返回給A。

階段2 敵手A在額外的條件下繼續(xù)發(fā)出階段1的查詢。

猜測階段 最終敵手A 返回給C 一個猜測結(jié)果d′∈｛0，1｝，若d′=d，則A在游戲中獲勝。

3）安全性證明。

定理如果DDH 假設(shè)成立，本文提出的代理重加密方案在隨機預(yù)言機模型中安全于適應(yīng)性選擇密文攻擊（Adaptive Chosen Ciphertext Attack，CCA2）。

證明 如果存在敵手A可以在多項式時間內(nèi)以不可忽略的優(yōu)勢破壞CCA2 安全性，那么敵手A 可以構(gòu)建算法來解決DDH 難題。即輸入由構(gòu)建的算法確定T=gab是否成立。挑戰(zhàn)者C構(gòu)建以下隨機預(yù)言機模型。

OH1：C檢查列表H1_list中是否已經(jīng)存在（D，α）。如果存在，C 將α返回給A；如果不存在，隨機選擇將（D，α）記錄到H1_list，同時返回α=H1(D)。

OH2：C檢查列表H2_list中是否已經(jīng)存在（D，β）。如果存在，C 將β返回給A；如果不存在，選擇β，將（D，β）記錄到H2_list，同時返回β=H2(D)。

C記錄兩個列表：Klist為存儲公私鑰對的列表；RKlist為存儲重加密密鑰的列表。

階段1 A 進(jìn)行系列詢問：OPK、OSK、ORK、ORE、ODEC，C 向A返回查詢結(jié)果。

公鑰生成預(yù)言機OPK：輸入公鑰PKi=(pki1，pki2)，預(yù)言機設(shè)置(pki1，pki2)=其中ski1、ski2是中的隨機數(shù)，并將（pki1，pki1，ski1，ski2）加入列表Klist。

私鑰生成預(yù)言機OSK：輸入公鑰PKi=(pki1，pki2)，C在列表Klist中檢索（pki1，pki1，ski1，ski2），并返回給A 相應(yīng)的私鑰SKi=(ski1，ski2)。

重加密密鑰生成預(yù)言機ORK：輸入PKi、PKj（二者均來自O(shè)PK），C 從Klist檢索相應(yīng)的公鑰獲取私鑰SKi=(ski1，ski2)，其中w3=ski1-ski2·w2modq。然后運行重加密密鑰生成算法獲取重加密密鑰，并返回RKi→j=(rk1，rk2，rk3)給C。

代理重加密預(yù)言機ORE：A 輸入(PKi，PKj，Cp)，C 返回重加密密文ReEnc(Cp，ORK(PKi，PKj))。

解密查詢預(yù)言機ODEC：輸入(PKi，Cs)，C 檢索相應(yīng)的私鑰SKj，并返回Dec(ReEnc(Cp，ORK(PKi，PKj))，skj)。

挑戰(zhàn)階段 完成上述詢問后，A向C發(fā)送PK′i以及兩條等長消息M0、M1∈｛0，1｝。算法A 從列表Klist中恢復(fù)出PKi，SKi和密文。C 選擇隨機比特d∈｛0，1｝并按如下步驟生成挑戰(zhàn)密文：

階段2 敵手A在以下條件下重復(fù)詢問。

①詢問ORK(，PKj)；

②如果敵手A 發(fā)布ReEnc(Cp，RK) →Cs，其中RK由公式ReKeyGen(par，SKi，PKj) →RK；

③詢問ODE(Cs，SKj)。

猜測階段 最終，A 返回給C 一個猜測值d′∈｛0，1｝。當(dāng)T=gab時，C*=與ReEnc(Cp，RK)→Cs相同。T=gab被隨機數(shù)T∈G替換。因此敵手A 無法以高于1/2的概率猜測到挑戰(zhàn)密文中的值d。

3.2.2 協(xié)議安全性討論

本文提出的解決方案基于安全的代理重加密算法，并支持的安全屬性：

1）數(shù)據(jù)端到端的機密性。

數(shù)據(jù)資源與會話密鑰在通信全程都是以密文的形式進(jìn)行傳輸，代理也無法解密數(shù)據(jù)，只有發(fā)布者和對應(yīng)的訂閱者可以解密密文獲得明文信息。

2）數(shù)據(jù)真實性、完整性和不可否認(rèn)性。

方案通過Schnorr 簽名方案確保此屬性。只有擁有簽名密鑰的發(fā)布者才能對報文進(jìn)行簽名。

3）重放攻擊保護。

發(fā)布消息均包含時間戳，可以防止攻擊者重放這些消息。

4）中間人攻擊防護。

發(fā)布/訂閱者通過用戶向TC 注冊獲取密鑰信息，除發(fā)布者用來驗證簽名的公鑰以設(shè)備UUID 的形式會公開給代理外，其他的密鑰信息即使是公鑰也不對外公開，因此中間人無法窺探到以密文形式傳輸?shù)膱笪闹腥魏蚊孛苄畔?；而且本文中的方案不涉及發(fā)布者與訂閱者之間或發(fā)布/訂閱者與代理之間的密鑰協(xié)商過程，因此中間人無法實施攻擊。危害最大的是一個合法的訂閱者充當(dāng)中間人角色，并且該中間人與代理合謀。代理將傳輸給目標(biāo)訂閱者的報文重加密后發(fā)送給合謀的中間人。但重加密密鑰是與真實訂閱者密鑰對中的公鑰相關(guān)聯(lián)的，即使攻擊者獲得密文也會因缺乏對應(yīng)的私鑰而無法解密。

5）隱私保護。

本文的解決方案中，唯一代表發(fā)布/訂閱者身份的公開信息是UUID，但該UUID 真正代表的設(shè)備和用戶的身份只有TC知道。發(fā)布/訂閱者相互間不知道對方身份信息，代理也不了解發(fā)布/訂閱者的真實身份。

6）發(fā)布者認(rèn)證。

發(fā)布者在發(fā)布信息中加入簽名，訂閱者只要驗證簽名就可以確定UUID 的真實性。在有需要的情況下（如安全事件發(fā)生），訂閱者可以將UUID提交給TC就可以認(rèn)證發(fā)布者的真實身份。

4 結(jié)語

本文提出了一種將代理重加密算法用于MQTT 通信的安全解決方案，為MQTT 通信模型提供端到端的數(shù)據(jù)安全性。方案降低了對代理的信任度要求，可以很好適應(yīng)基于云服務(wù)的應(yīng)用環(huán)境。所提解決方案使用有效的代理重加密方案并進(jìn)行修改，以適應(yīng)資源受限的物聯(lián)網(wǎng)環(huán)境。通過與該領(lǐng)域的相關(guān)工作進(jìn)行比較，證明了所提解決方案的安全消息開銷很小。

下一步工作主要填補解決方案中對客戶端設(shè)備接入認(rèn)證和發(fā)布/訂閱請求授權(quán)的空白，結(jié)合代理重加密密鑰的生成，制定與本方案契合的認(rèn)證授權(quán)機制。