谷正川，郭淵博，方 晨

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

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

0 引言

物聯(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)性。

1 相關(guā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)性。

2 MQTT端到端安全解決方案

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

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

表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ù)字簽名防篡改。

2.2 方案概述

方案框架如圖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 具體流程

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，否則消息被拒絕。

3 性能評(píng)估與安全討論

3.1 性能評(píng)估

分別與文獻(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 算法安全性證明與協(xié)議安全性討論

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í)身份。

4 結(jié)語(yǔ)

本文提出了一種將代理重加密算法用于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ī)制。