基于聯盟鏈的物聯網跨域認證?

魏 欣 ,王心妍 ,于 卓 ,郭少勇 ,邱雪松

1(網絡與交換技術國家重點實驗室(北京郵電大學),北京 100876)

2(國網河南省電力公司,河南 鄭州 450000)

3(北京中電普華信息技術有限公司,北京 100192)

隨著網絡技術的高速發展和低成本智能設備的大規模部署,物聯網取得了飛速的發展,對跨系統之間的信息交互提出了需求.傳統物聯網采用封閉建設模式,不同系統之間存在認證模式不同、證書形式不同等差異,從而造成了顯著的隔離,形成了多個信任域.由于同一信任域內的資源已經不能滿足用戶和設備的需求,高效簡潔的跨域訪問流程設計成為當下的研究重點.

傳統的跨域訪問流程分為兩類.

?一類采取實時授權的方式.在這種情況下,雙方信任域的認證CA交互授權提供短期跨域訪問憑證,這種方式交互復雜,時延較高.

?另一類采取長期授權的方式,一方CA將另一方CA提供的標準化信息作為登錄信息長期存儲.該類情況下,常有更新不及時導致的信息過期等問題.

以上跨域方式都難以適應物聯網的低時延高可信的需求,究其根本原因,在于CA之間無法快速達成信任.

區塊鏈作為一種近年來取得廣泛關注的分布式信任環境,可為多CA之間的合作提供標準化的可信任機制,進而實現不同信任域之間的快速認證.但區塊鏈因其公開透明的特性,在打通多CA之間信任的同時,也增加了隱私泄露的風險.本文針對該問題設計了隱私保護的認證方式,增強了跨域交互過程中的信息保護.

本文所做的貢獻如下:

1)本文設計了一種適用于物聯網跨域認證的架構.通過引入邊緣網關,實現對物聯網設備的接入及管理,提高物聯網的管理效率,屏蔽底層異構性問題.在物聯網的不同CA之間部署聯盟鏈,利用多CA共識簡化多信任域之間的認證流程,為物聯網構建了可信的跨域信息交互環境.通過邊緣網關實現物的描述及接口上鏈,訪問者可通過調用智能合約對物進行操作,增強了物聯網的連通性.

2)本文針對區塊鏈引入的隱私問題,設計了一種隱私保護的跨域認證.首先,通過預處理設置全局參數,完成全部CA的導入;而后,對邊緣網關及訪問者執行接入認證.訪問者通過邊緣網關生成匿名身份,使用匿名身份完成校驗.收到訪問請求的邊緣網關,可基于區塊鏈完成對身份的核驗.經過證明,本文設計的跨域認證流程可提供安全高效且保護隱私的認證環境.

本文第1 節對基于區塊鏈的物聯網跨域交互方案進行總結.第2 節介紹物、網關、CA、區塊鏈之間的整體架構.第3 節提供對系統的整體描述以及跨域訪問的流程設計.第4 節對本文設計的跨域認證流程進行正確性及安全性的證明.第5 節對提出的方法進行仿真實現并完成了評估.第6 節總結全文,并對未來值得關注的研究方向進行初步探討.

1 相關工作

區塊鏈是中本聰提出的一種分布式賬本技術[1],糅合了P2P 網絡、加密散列技術、數字簽名等技術,可用于分布式環境下的數據可信讀寫.在區塊鏈環境下,互相不信任的節點可達成合作,并形成可信的數據.通常來講,區塊鏈中的活動可以概括為:用戶通過一堆非對稱加密密鑰獲得身份,并以此簽署交易.網絡中的節點收集交易,并打包成區塊鏈接到前一個區塊.通過共識,網絡中所有節點維護著完全相同的交易歷史.智能合約是一種特殊的數據,當被調用時,將在區塊鏈上自動且獨立地執行對應的腳本.由于記錄在區塊鏈上的數據由全網共享,因此無法進行篡改,可確保數據的真實可信.由此,區塊鏈的可信在互聯網資源分配中逐漸引起了廣泛重視,如針對IP 及域名資源的分配及管理等[2,3].2014 年,麻省理工的Conner 團隊[4]提出了首個基于區塊鏈的身份認證系統,通過區塊鏈對用戶的身份證書進行管理.考慮到隱私性問題,Axon 等人[5]通過節點權限分級的方式實現了隱私保護的身份認證系統.

考慮到物聯網與互聯網的相似性,同樣具備著大量互不信任的節點高效達成信任的需求,引入區塊鏈以解決物聯網的可信問題成為一大研究方向.Christidis 等人[6]分析了區塊鏈在物聯網中的適用性,指出區塊鏈可以為物聯網提供可信任、可審計的環境,智能合約可以整合工作流,節約成本及時間.Kshetri 等人[7]指出,區塊鏈的分布式處理及可信審計特性,為物聯網的身份管理及接入控制帶來了巨大便利,可以提高物聯網的安全性.Tseng 等人[8]指出,區塊鏈部署于物聯網中,存在異構性、可擴展性、可監管性等風險挑戰.

在分析區塊鏈如何用于物聯網的同時,大量基于區塊鏈的物聯網架構設計涌現.Huh 等人[9]及Alphand 等人[10]利用區塊鏈對物聯網身份進行管理、授權,從而驅動物與物之間的數據共享.Sharma PK 等人[11]指出,中心化的云架構無法實時對海量數據進行處理,難以用于未來的物聯網;而區塊鏈可以推進分布式可信運行,進而為霧計算提供支撐.Novo 等人[12]提出由管理網關將WSN 網絡匯聚到區塊鏈,管理節點定義智能合約并實現共識.在該設計中,管理網關用于突破物聯網設備的限制,實現接口轉換,完成物與智能合約的交互.宋文斌[13]、賀毅[14]、梅晨[15]等人在各自的學位論文中設計并實現了基于區塊鏈的物聯網身份認證支撐系統.但以上設計并未考慮到針對物聯網中的多信任域造成的連通性問題.

萬雨薇[16]對物聯網下的跨域認證做了細致的流程分析及設計.Wang 等人[17]設計了跨域場景下的區塊鏈擴展方案及認證流程.針對基于區塊鏈的跨異構域認證,周致成等人[18]與馬曉婷等人[19]提出了鏈模型、證書格式,實現了跨異構域的認證.Lei 等人[20]針對車聯網中移動性帶來的認證域變化,提出了基于區塊鏈的動態密鑰管理方法.但以上方法采用直接將設備信息公開到區塊鏈,缺乏對隱私的保護機制.Thomas 等人[21]提出了基于聯盟鏈的匿名身份及訪問控制,但該設計中對于每次跨域請求均上鏈,帶來了巨大的訪問開銷,難以滿足物聯網的實時性需求.Ma 等人[22]構建了基于多鏈的密鑰管理框架,在物聯網設備注冊時,即將權限控制策略發布上鏈,實現對內容的權限訪問,通過主鏈協調跨域的訪問請求.Cha 等人[23]針對藍牙低功耗設備設計了網關的工作流程,并設計了隱私保護設定,當且僅當用戶與發布到鏈上的設置吻合時可以對設備進行訪問,該設計對身份信息不作保護.Yao 等人[24]通過引入第三方來構建區塊鏈,并針對車聯網場景研究了面向車聯網的跨域隱私認證方法,但未能說明第三方提供認證服務的動機.

在以上工作的基礎上,本文設計了適用于物聯網的區塊鏈部署架構,引入原有物聯網CA作為區塊鏈共識節點,邊緣網關作為區塊鏈客戶端,為人和物提供服務.在交互過程中,通過邊緣網關完成身份匿名情況下的校驗,減少跨域認證過程中不必要的隱私泄露.

本文設計的架構較傳統架構有以下優勢.

1)整合了多CA的認證資源,為更豐富的物聯網服務提供了可能性.相比較傳統CA之間互通困難造成的信任孤島,本文設計的結構打通了認證域之間的隔離,促使不同的物聯網之間打通隔離;

2)縮短了不同CA的跨域流程,為現有的物聯網服務提高了效率.傳統CA之間互相多次重定向并簽密,延長了跨域認證所需的時間;本文設計的結構通過智能合約加速了跨域之間的認證,提高了效率.

2 系統設計

本文設計的物聯網跨域認證總體架構與傳統架構對比如圖1 所示.

Fig.1 IoT architecture圖1 物聯網架構

在傳統架構中,物聯網不同場景設備通過網絡匯聚到各自位于云端的服務器,云服務器為所在信任域的設備提供信任背書,并對外提供接口提供服務.當需要調用其余信任域的設備以實現物聯網服務時,云服務器之間將展開密切的‘請求-校驗-重定向-認證-背書-校驗’合作過程,以確保各方信任域內的設備的可信.但是,由于服務通過云服務器提供的接口實現調用,在設備到云服務器之間可能發生其余云服務器無法察覺的不可信行為.此外,在跨域的合作中,多個服務器為了確保彼此可信的合作,將帶來大量的通信開銷及時延.因此,傳統架構難以滿足物聯網的高效及可信需求.

本文設計的架構如圖1,在傳統基礎上,做了以下改造.

1)在云服務器與物聯網設備之間增加邊緣層,引入邊緣網關對設備進行匯聚處理并屏蔽隱私信息,與設備進行最直接的交互.由于跨域認證的計算在邊緣執行,對云服務器的依賴性降低,從而降低了認證所需的時延,并減少了對云服務器造成的壓力.通過在接入時對設備進行匿名化處理等操作,設備關鍵信息僅暴露給邊緣網關,降低了隱私泄露風險.

2)引入聯盟鏈技術,實現云服務器之間的認證信息透明可信共享.云服務器可為自身信任域的設備及網關提供注冊、更新及注銷等服務.通過查詢區塊鏈,可獲取設備及網關的信息,進而提高跨域認證的效率及可信,從而支撐物聯網的各項服務.

對于本架構的詳細解釋如下.

設備指代是物聯網中的各類設備,是物聯網中業務的實際執行者,具有迥異的通信接口和隱私保護需求.打通物聯網首先需要屏蔽其接口底層的異構特性實現管控,同時對其隱私進行保護.本文關注的重點在于設備的身份隱私及行為隱私,即通過匿名化處理避免顯式的身份信息暴露上鏈;同時,通過更新設備身份信息避免對設備行為的持續追溯分析.

邊緣層部署網關對設備進行匯聚,屏蔽底層異構特性.根據Byungseok 等人[25]提出的IoT 網關概念,IoT 網關支持各種設備之間的多種通信協議和數據類型,可以實現各種設備之間通信的數據格式轉換,并以統一的數據格式上傳.同時,可將收到的獲取或控制命令映射為生成滿足特定設備通信協議的消息.網關僅作為邏輯概念,可部署于某些能力較強的設備上.

區塊鏈層由傳統架構中的云服務器組成聯盟鏈.作為CA角色,為自身可操控的設備身份及能力提供信任背書,作為區塊鏈完整節點,對發布到鏈上的信息進行共識,提供認證信息的實時共享,從而避免不同CA之間反復重定向帶來的流程冗余及失效等問題.區塊鏈提供基礎的查詢及寫入功能,節點之間通過協商發布智能合約,并通過調用合約實現復雜功能.

在本文的設計中,邊緣網關對設備進行接入后,根據隱私需求對設備進行匿名化處理,真實身份與匿名身份的映射關系僅保存在本地;將匿名身份及公鑰簽名后通過智能合約發布到區塊鏈完成注冊,從而避免了設備的真實身份泄露.云服務器之間達成共識后,設備的信息可通過智能合約進行查詢及同步.在服務過程中,當網關收到跨域的調用請求后,查詢區塊鏈對請求進行校驗,校驗通過后,執行相應操作并返回結果.為避免設備的狀態及偏好被分析,網關可隨時更新設備的公私鑰對,以新的身份參與跨域交互.詳細流程將在下一節展開介紹.

3 跨域認證機制

本節首先對系統的運行流程進行設計,包括聯盟鏈及網關的初始化、設備的寫入、跨域的訪問過程等.而后對流程中涉及到的交互協議進行設計,包括網關寫入到聯盟鏈的物信息注冊、更新、注銷;網關從聯盟鏈讀取的信息查詢;網關與網關之間的跨域訪問請求.

3.1 機制描述

本文設計的跨域認證流程與傳統流程相比對比如圖2 所示,紅線框出的部分即為認證階段.為了方便描述,本文將區塊鏈的節點配置作為聯盟鏈初始化部分,網關配置作為網關初始化部分;注冊部分將設備接入到網關并發布上鏈,認證部分完成設備的跨域交互.

Fig.2 Comparsion between our process and traditional process圖2 本文流程與傳統流程的對比

1.聯盟鏈初始化

在構建基于聯盟鏈的服務之前,首先對聯盟鏈進行配置.不同于公有鏈,聯盟鏈中存在至少一個管理節點為參與共識的云服務器發放證書并配置網絡,但管理節點本身不參與鏈上的業務.完成配置后,參與共識的各云服務器的身份信息及對應權限、采用的共識算法、區塊大小等將寫入創世區塊,同步到每一個云服務器.此時,云服務器可作為CA對外提供認證服務.由于聯盟鏈的多中心特性,單個CA癱瘓后,其余CA仍可完成共識,提供服務.此外,創世區塊中公布的是共識節點的初始集群,系統的使用過程中,節點可按照創世區塊中配置的策略加入或退出集群,更新將在鏈上留下記錄.如CA退出,其之前簽發的網關及設備仍在鏈上可查,不影響繼續使用,但更新需要重新注冊.如部分CA根據自身的風險感知,認為某CA為大量惡意節點頒發了證書或不再具備提供驗證服務的能力,則采用對“該節點不可信任”達成共識的形式,迫使其退出.與CA主動退出集群的區別在于,該情況需對該CA自不可信起發布的全部證書做過期處理.在聯盟鏈上發生的業務將打包成塊鏈接到前一個區塊,最終可追溯到創世區塊.

具體流程如下.

1)多個CA協商生成大素數q,并利用q生成橢圓曲線群G及生成元P.

2)定義哈希函數如下:

其中,H0根據二進制序列和橢圓曲線上的兩個點生成一個不大于q的素數.其余類似.

4)公布q,P,G.類似地,其余CA按照相同方法生成各自的密鑰對.以4 個節點為例,其余3 個節點的公鑰為PK2,PK3,PK4.

5)公布系統參數及各CA的公鑰列表到創世區塊,同時部署合約支持對CA公鑰列表進行查詢.后續CA的加入,按照創世區塊中指定的原則完成:如開放有加入接口,則新的CA調用注冊獲取到身份及權限對應證書后,將現有區塊鏈同步到本地,參與到后續的認證服務;如未開放接口,則需要管理節點實現對新CA的添加及部署.

2.網關初始化

網關注冊的過程如下.

1)網關i選擇一個不大于q的整數作為自己的私鑰,并計算出,向某位可驗證該網關身份的CA(以CA1 為例)發送其身份與公鑰,并利用CA1 的公鑰對其進行加密

在這一步的操作中,網關向CA提交了僅該CA可見的身份,請求驗證.

2)CA1 收到消息后,對其進行解密,并校驗網關的身份.校驗通過后選擇不大于q的整數di,并計算:

3.設備注冊到網關

由于部分啞設備不具備遠距離通信及自主密鑰的管理,網關協助CA對設備身份進行管理.鑒于設備與用戶的行為直接相關,隱私敏感,本文分析如下.

1)網關用于擴展設備的安全及通信能力,與設備直接連接,獲取到的是設備的明文信息.

2)設備的身份及行為與用戶密切相關,有必要對鏈上其余CA及網關保密.

3)設備本身具有移動性,應確保即使其更換所屬網關,仍可繼續使用.

在此基礎上,本文為設備設計流程如下.

1)網關與設備建立連接,獲取到設備的能力fj={method:type},并配置設備的權限管理策略PRTj.

2)網關對設備實施匿名化:生成隨機數w后計算pidj=hash(w+idj),在本地建立身份映射.

3)生成設備j的本地密鑰對并用網關的域內私鑰簽名,完成域內注冊.此時,該網關域內的設備可對該新注冊的設備進行訪問.

4)網關向自己所屬的CA發出注冊請求,該請求中包含有設備的匿名身份、功能列表、權限.

5)CA校驗了網關的簽名后,為設備生成.得到網關的確認消息及設備信息后,使用設備注冊合約,將設備信息如功能描述、設備公鑰、密鑰版本、密鑰有效期等發布上鏈.

6)網關注銷后,由于設備信息仍可在鏈上查到,仍可通過校驗.但由于更新設備信息需要該網關簽名,因此,如果之前注冊設備時使用的網關注銷而需要更新權限規則或功能列表等信息,需重新注冊到其他網關.

7)設備如需更新,網關可對更新信息進行簽名并發布上鏈.注銷是一種特殊的更新:將該設備狀態更新為不可用.為了避免設備行為被持續的分析挖掘,可通過對設備進行重新注冊后注銷原ID 進行隱蔽.

4.跨域通信

考慮以下兩種情況.

1)設備自身即具備與外部通信的能力,向非自身所在域的網關請求調用其他設備.

2)通過網關向其余網關請求對應設備的服務.

對于第1)種情形,當gwm域的設備pidj訪問gwi的資源時,執行如下操作:

1)設備利用自己的域內私鑰及跨域私鑰并結合隨機數完成簽名并加密,而后利用網關gwi的公鑰對隨機數進行加密.由j隨機選取兩個不大于q的整數r1,r2,計算:

2)網關收到后,首先利用自身身份解密,獲取到設備的簽名及身份.而后對設備的身份展開校驗.

解密過程:

根據R′恢復原始信息、設備身份pidj及s:

計算哈希值以完成校驗:

第2)種情形與第1)種類似,但以網關的身份對設備進行調用.此時,C=H2(R)⊕s.驗證網關身份后,根據訪問控制策略決定是否執行來自該網關的指令.

假定m域的設備pidj訪問n域內的pidi,跨域訪問流程如下.

3.2 消息協議設計

設備接入到網關的底層通信協議,根據設備的不同有所不同;但寫入到網關的上層數據格式可統一如下:

設備的信息按照json 格式列出如下.

其中:當設備密鑰由設備自身生成時,填寫加密后的私鑰;由網關生成,則直接填充密鑰.

權限許可類型分為3 類:public,protected,private.對于public 設備,可直接發起調用;protected 需獲取到本地網關的許可;private 情形下,需獲取到設備自身的許可.privacy 部分填充密鑰更新的頻率.此字段為空時,說明無需更換.

網關與CA及聯盟鏈之間的交互主要包括以下幾項:設備的注冊、更新、以及查詢.

網關向CA發起的請求格式如下.

查詢請求的description 字段為空,合約為其返回對應設備的信息.注冊請求需提供設備描述及權限許可等屬性信息.更新請求的description 字段只包括需要更新的信息.

網關向網關發出的跨域認證請求如下.

此時收到請求的網關校驗權限允許之后,執行conmandtype 中的函數.

4 認證機制分析

4.1 正確性證明

在第3.1 節的機制設計中,提出了認證時使用的數據,被請求的網關校驗通過后證明該請求來自于合法的網關或設備.其中,為證明校驗的正確性,證明如下.

根據設計的協議,需要證明以下兩處.

?R′=R.即:網關根據自身密鑰恢復出的數據確為加密前的原始數據;

?h′=h.即:在數據未經過篡改的情況下,恢復出的哈希值h′與原數據的哈希相同.

對設備與網關的R與h計算及校驗過程類似,以對設備的校驗為例進行證明.

4.2 安全性證明

針對網關的安全性分析:在本文設計的架構中,設備的隱私保護與跨域訪問校驗均通過網關完成,因此系統整體安全依賴于網關.網關的職能在于對單個物理域或信任域內的設備進行統一的匯聚及管理,可部署于用戶的個人終端或小型服務器.考慮到用戶通過網關對設備進行直接操控,攻擊者如攻擊網關繞過本系統架構直接獲取權限,可認為該網關已被攻破,注銷該網關即可.

以下為常見攻擊的分析.

?拒絕服務攻擊:本文設計的架構中,利用多CA構建基于區塊鏈的認證服務機制.攻擊單個CA之后,仍可在其余CA維護的區塊鏈上查詢到正確的網關及設備信息,抗DDoS 攻擊能力顯著增強.

?偽造攻擊:本處討論對設備的偽造和對網關的偽造.為了通過偽造攻擊,攻擊者需要偽造一個能夠通過認證的請求信息δ.對于偽造設備,其無法獲得,因此無法生成s,進而無法生成C,無法通過校驗;同理,對于偽造網關,無法獲得,同樣無法通過校驗.由于無法獲得密鑰,即使盜取設備或網關,也無法實施智能卡丟失攻擊.

?內部攻擊:由于網關提交到區塊鏈的身份以及跨域交互所需的身份僅為設備的公鑰PKT1,PKT2,僅能證明設備合法,無從確認設備的真實身份pid,無法形成內部攻擊.僅有直接與設備連接的本地網關可完成設備公鑰到設備身份的映射.此外,設備可要求網關對設備的密鑰進行更新,以避免被追蹤.

?重放攻擊:發布到鏈上的信息帶有時間戳,網關之間的交互協議均帶有時間戳,保證消息新鮮.此外,隨機數部分保證每次發布的消息均不同.

?中間人攻擊:由于中間人無法實施偽造攻擊將自己偽裝為用戶或網關,也無法實施服務欺騙攻擊提供服務,因而無法實施中間人攻擊竊取信息.

4.3 隱私分析

本文針對的隱私保護在于CA之間數據共享造成的跨云服務器之間的數據共享,考慮到物聯網直面用戶的特性,主要隱私涵蓋以下兩處:設備的身份與設備的行為.

?設備的身份隱私:設備的真實身份在網關處做了匿名化的處理,防止透露個人信息.如網關i操控的設備中涵蓋了一盞燈,在屏蔽其真實ID 信息進行歸一化處理之后,無法從中推測燈的型號等信息,其余網關或設備僅知道在獲取相應權限之后可對其進行狀態查詢及開關操作,不存在文獻[10?14]中身份明文上鏈帶來的隱私問題.

?設備的行為隱私:行為泄露來源于兩方面,由于設備僅有必要的描述信息發布在鏈上,因此規避了文獻[15]中每次訪問請求均上鏈導致的行為泄露.在交互過程中,全程采用密文傳輸,交互行為僅雙方網關知曉,避免了明文調用帶來的危險.

4.4 開銷分析

本文與文獻[18,19]的方案進行對比.在該兩種方案中,CA多方完成校驗之后,將簽署本輪訪問的憑證上鏈,憑證內容為在某有效期內,允許外域的某身份訪問本域.此處針對從A域的身份i發起請求至獲取到本次訪問所需憑證的計算及通信進行比對見表1 和表2.其中,其他計算指代本文在第3.1 節中構造的加解密計算.

Table 1 Communication consumption表1 通信開銷

Table 2 Computing consumption表2 計算開銷

根據表1 的通信開銷對比,本文設計的方案在CA之間、網關之間、網關到區塊鏈之間的通信次數都顯著低于文獻[18,19]提出的方案,在通信開銷上具有顯著優勢.

表2 的計算開銷顯示:由于通信次數少,本文的公私鑰加解密次數較文獻[19]顯著偏少,但高于文獻[18];而執行哈希運算次數顯著高于文獻[18,19].此外,本方案中涉及到的計算均在網關展開,認證過程不占用CA資源.

詳細的計算開銷及通信開銷將在第5.2 節認證階段的實驗中展開比對.

5 實驗設計及分析

在本文中,考慮到網關與設備距離極近,不考慮網關到設備之間的傳輸時延.同時,假定網關-網關之間、網關-CA之間的傳輸時延均為T.

聯盟鏈實驗環境為部署于金山云上的1 核2G 服務器,Ubuntu 16.04 系統.聯盟鏈采用Hyperledger Fabric 1.4.0,并利用docker 容器部署聯盟鏈節點,智能合約采用JavaScript 進行編寫.網關及CA實驗環境為Windows10系統,CPU 主頻1.6GHz,內存4GB.跨域認證流程采用Python3.8 模擬實現,實驗數據均為運行50 次的平均值.

5.1 注冊階段

在本文中,定義注冊所需的時間為設備請求到設備信息可在鏈上查詢到的時間,分為4 部分:t1為網關為設備生成密鑰的時間,t2為網關調用合約的時間,t3為CA之間達成共識的時間,t4為網關查詢到合約所需的時間.其中,t1不考慮網關到設備之間的傳輸時延,t4僅考慮網關到CA之間的傳輸時延.

由于t1階段與傳統流程無差別以及傳統流程同樣需要寫入及查詢的時間,因此,本節的實驗模擬僅考慮采用本架構后增加的時延t2+t3+t4,即:從請求發布到鏈,到共識結束.

對于t2階段,對注冊及更新信息進行打包發布上鏈.測試結果表明,對于每個注冊請求,網關對數據進行打包并提交交易的時間約為2 060ms,記作tS,并隨著注冊請求個數呈現線性增長.假設網關以固定的時間間隔T進行信息發布,注冊及更新信息分布服從參數為λ泊松分布,則每個周期內產生的注冊請求個數為λT.

假設網關收集注冊請求的時段為[t,t+T],某個設備的請求在t+t0到來,且λt0?ts

考慮到每個收集間隔至少應能打包一份請求,因此存在T0≥ts.由此可知,t2的期望值約為3090ms.

對于t3+t4階段,即數據提交上鏈到結束共識的時間,本文分別對4,6,8 個CA的情形進行模擬,取平均值見表3.實驗結果表明,本文設計的模式下,注冊從提交到生效僅增加約3.17s 的時延.考慮到注冊環節對時延的要求不高,且隨著CA性能提升,該階段的時延可以迅速下降,本文設計的模式仍然具備實用性.

Table 3 Consensus delay表3 共識時延

5.2 認證階段

本節對本文及文獻[18,19]所設計的跨域認證方案在不同橢圓曲線下進行了模擬.文獻[18]設計的方案中,將各信任域的認證服務器作為區塊鏈節點,域間跨域認證通過查詢驗證對方域的根CA證書服務發布在鏈上的無簽名證書實現.但文獻[18]的設計中大量采用明文通信,隱私泄露風險極大.文獻[19]的設計中,基于SM9 國密算法改進了證書的設計,每次完成認證后將本次認證密鑰寫入區塊鏈,證書有效期超出之前均可憑借該證書訪問.文獻[19]的設計意味鏈上存儲的是實體之間的交互許可.考慮到區塊鏈可增可查不可刪改的特性,隨著用戶的增長,將帶來巨大的查詢壓力.本文在文獻[18]的設計理念基礎之上增加了簽名校驗及加解密計算,在高效同時提高了安全性.實驗結果證明,本文方案的時延損耗在常用的橢圓加密曲線下具有優勢.

如圖3 所示,在每種加密曲線中,文獻[19]均帶來最高的時延,文獻[18]產生的時延最小,本文設計產生的時延接近于文獻[18].隨著采用的加密曲線更加復雜,三者之間差距更加明顯.

Fig.3 Time delay comparsions among our method and traditional method圖3 本文時延與傳統時延對比

考慮到CA及區塊鏈部署于云服務器上,計算性能較強,而網關及設備能力計算能力較弱,按照第4.4 節的計算開銷分析再次展開詳細分析.鑒于不同加密曲線下呈現出相同的趨勢,以NIST384p 為例對用戶側的網關及設備、服務器側的CA及區塊鏈計算時延進行分析.

如圖4 所示,文獻[18,19]的方案中,大部分計算在服務器端完成,通過提高服務器端性能可大幅降低計算時延遲;但由于大量計算部署在服務器端,給網絡帶來了較大的通信開銷.

Fig.4 Time delay of different sides in different ways圖4 不同方法下不同側的時延

結合第4.4 節中表1 的通信開銷分析,以NIST384p 為例,其身份信息為48 字節,簽名長度為104 字節.參照文獻[18]的設定,消息平均長度為24 字節.按照文獻[19]的假設,證書長度為定長16 字節,隨機數長度為24 字節.則各端通信量分別分析如下:

圖5 計算各端發出的數據量,據圖可觀察到以下現象.

1)文獻[19]的CA或區塊鏈發出的數據量最多,本文最少.原因在于,文獻[18]和文獻[19]均需要反復從CA或鏈上獲取到證書信息,而本文僅查詢一次網關或設備的信息.

2)本地網關發出的數據三者接近,文獻[19]略高于本文,文獻[18]最低.因此,在請求時未造成網關的額外負擔.

3)對于目標網關,文獻[19]發出的數據量最多,文獻[18]次之,本文最少.原因在于,本文的目標網關確認訪問者的身份后,在本地決策是否授權;此外,網關之間直接通信,減少了通過CA進行中轉及轉換的環節.由此可知,收到請求的網關同樣未給網絡帶來額外壓力.

Fig.5 Outgoing data of different sides in different ways圖5 不同方法下不同側發出的數據量

圖6 計算各端收到的數據量,據圖可觀察到以下現象.

1)文獻[19]的CA或區塊鏈收到的數據量最多,本文其次,文獻[18]最少.這一點符合常識:認證過程主要從服務器請求判斷憑證而非上傳新的數據.文獻[19]中不同CA互相確認身份的流程較為復雜,因此交互數據量較大.文獻[18]由于認證包含的信息簡單且交互次數較少,數據量最少.本文在簡化認證流程的基礎上增加了用于確保信息安全的操作,數據量略高于文獻[18].

2)對于本地網關,文獻[19]收到的數據量最多,文獻[18]次之,而本文發出請求并簽名后僅等待對方提供服務不再確認,因此本地網關的認證過程不再收到消息.而對于目標網關,文獻[18]收到的數據量最多與本文收到的數據量持平,文獻[19]最少.

3)對于目標網關,本文與文獻[18]收到的數據量持平,而文獻[19]最少.文獻[18]及本文均需攜帶認證信息訪問目標網關,而文獻[19]僅需獲取用戶身份,決定通過校驗后將證書寫入區塊鏈.

Fig.6 Incoming data of different sides in different ways圖6 不同方法下各端收到的數據量

總體的通信量對比如圖7.可以看到,由于簽名和加解密的環節極少,更換加密曲線對文獻[18]幾乎不造成影響;反之,由于簽名和加解密環節較多,文獻[19]的開銷隨著加密曲線的復雜迅速上升.本文由于網關之間直接進行信息交換,僅調用一次區塊鏈進行查詢,因此步驟簡潔,開銷較少.

Fig.7 Data volume in different curves圖7 不同加密曲線下總數據量

根據以上的仿真結果及分析,本文設計的認證方法在時延和通信量上均具有較好的性能.

6 結 語

本文針對物聯網建設封閉導致的認證復雜,提出了基于區塊鏈構建多CA合作認證的思想,進而提出了基于聯盟鏈的跨域物聯網信任.其核心內容是:部署邊緣網關對兼容物聯網的多種接入協議,同時利用多CA實現網關可信接入、設備可信校驗,從而大幅度縮減傳統認證模式導致的互操作困難、認證流程復雜、認證系統冗余建設等問題.在提出系統架構、部署方式、運行流程的基礎上,設計適用于物聯網的跨域認證協議,并對其進行了正確性、安全性及開銷的分析.

但區塊鏈應用于物聯網中仍存在大量的風險及挑戰:首先,多中心備份的服務方式在促進可信合作的同時,作為完整節點參與到區塊鏈,需對鏈上全部信息進行存儲,成本顯著上升;其次,區塊鏈本身增量不可刪除的特性,也導致其數據不斷增長,規模化實施之后,查詢效率難以保證;此外,在匿名化保證隱私和身份可認證確保可信之間存在微妙的平衡,在實際部署中更要參考相關法律法規的指導;物聯網的環境錯綜復雜,完整節點難以到達‘最后一公里’確保數據可信發布,而設備常以微弱的計算及安全性能暴露在大量攻擊下,難以保證上鏈的數據確實可信.下一步工作將針對網關及設備的信任評估及權限控制進行展開,進一步提高網絡的安全性.