杜變霞, 秦 宇, 馮 偉, 初曉博

(中國科學(xué)院 軟件研究所 可信計算與信息保障實驗室, 北京 100190)

引言

當(dāng)今社會, 物聯(lián)網(wǎng)(Internet of Things, 簡稱IoT)的應(yīng)用很廣泛, 從簡單的小規(guī)模系統(tǒng) (如智能家居等)到大規(guī)模的安全敏感環(huán)境 (如軍事系統(tǒng)、工廠自動化、智能檢測系統(tǒng)等)都可見其蹤影. 然而物聯(lián)網(wǎng)中很多設(shè)備通常資源受限, 且缺少通用計算設(shè)備的安全能力或機制, 使它們很容易成為敵手攻擊的目標(biāo), 比如在智能醫(yī)療設(shè)備中, 設(shè)備被攻擊就可能威脅到人的生命. 因此,為了提高物聯(lián)網(wǎng)環(huán)境的安全性, 有必要對設(shè)備的軟硬件狀態(tài)進行完整性驗證, 確保集群設(shè)備的安全可信.

遠程證明是一種驗證設(shè)備軟硬件完整性狀態(tài)的有效機制.傳統(tǒng)遠程證明機制主要針對單一證明者的場景(即“一對一”驗證), 缺少針對大規(guī)模物聯(lián)網(wǎng)設(shè)備構(gòu)成的集群環(huán)境的全局證明機制(或者稱為集群證明). 為此, 本文提出了一種基于設(shè)備分組的高效集群證明方案.首先, 將軟硬件配置一致的同構(gòu)設(shè)備進行分組, 組內(nèi)通過設(shè)置管理節(jié)點采用多數(shù)表決制的方法可以快速認證組內(nèi)各個設(shè)備的可信狀態(tài);其次, 基于自主國密算法設(shè)計全局證明協(xié)議, 使得遠程驗證者可以高效對所有管理節(jié)點的可信狀態(tài)進行驗證. 本文主要貢獻總結(jié)如下:

1) 本文設(shè)計了一個高效的集群證明方案, 通過設(shè)備的軟件證明協(xié)議, 提高了集群的安全性;通過將設(shè)備分組, 提高了集群效率. 實驗表明, 當(dāng)同構(gòu)設(shè)備越多的時候, 管理節(jié)點越少, 效率提高越多;

2) 在Real210[1]開發(fā)板上, 我們實現(xiàn)了集群證明方案終端設(shè)備的證明系統(tǒng), 并基于實驗結(jié)果在CORE模擬器對集群證明網(wǎng)絡(luò)協(xié)議進行了仿真評估, 評估結(jié)果表明了本方案的高效性, 說明本方案可以應(yīng)用于大規(guī)模物聯(lián)網(wǎng)環(huán)境的狀態(tài)證明;

3) 本文依據(jù)集群證明的威脅模型, 對方案的安全性進行分析, 證明了方案能夠抵抗重放攻擊、合謀攻擊等.

本文的組織如下:第1節(jié)討論了遠程證明的相關(guān)性工作;第2節(jié)介紹了方案設(shè)計與實現(xiàn);第3節(jié)是方案的安全性分析;第4節(jié)是方案的實驗評估, 主要評估了方案的性能以及和簡單集群證明方案進行了比較;第5節(jié)是比較與討論, 分別與SEDA以及”一對一”驗證進行了比較并將本文方案擴展成通用模型進行了討論與改進;第6節(jié)是結(jié)語, 總結(jié)了本文工作并提出了未來的研究工作.

1 相關(guān)工作

IoT設(shè)備產(chǎn)生、處理和交換大量數(shù)據(jù), 這些數(shù)據(jù)包含著很多隱私和敏感信息, 所以容易遭受各種攻擊[2–4].為了確保IoT設(shè)備的正確運行和安全操作, 保障底層設(shè)備的完整性是至關(guān)重要的, 特別是他們的代碼和數(shù)據(jù), 可能遭受惡意程序修改[5].

遠程證明允許一個遠程方驗證設(shè)備的可信狀態(tài),其對于IoT設(shè)備的完整性驗證問題是一種有效的解決方案.根據(jù)對遠程證明相關(guān)機制的調(diào)研, 我們將其實現(xiàn)方法分為三類:

(1) 基于硬件安全模塊的遠程證明[6–8]

主要借助于安全硬件, 比如TPM, 這類遠程證明一般都是針對于高端設(shè)備, 比如電腦、手機等, 由于資源受限以及造價昂貴等, 不適用于中低端設(shè)備.但是基于TPM的認證只能在啟動時建立, 不方便且耗時.所以引進了DRTM, 可以在用戶定義的任意時刻進行度量. 通過擴展DRTM思路, Intel提出了SGX[8], 可以提供一個硬件加強的隔離執(zhí)行環(huán)境.

(2) 基于時間和內(nèi)存校驗和的軟件證明[9–13]

基于時間和內(nèi)存校驗和的認證沒有安全硬件的支撐, 一般都是利用側(cè)信道信息, 比如時間.通過設(shè)定認證代碼, 如果設(shè)備被篡改, 在計算設(shè)備內(nèi)存校驗和時都會導(dǎo)致時間的增加. 所以雖然這類型認證比較簡單, 成本最低, 但是由于需要強大的安全假設(shè), 在一些場景中并不適用.

(3) 復(fù)合軟件證明[14–19]

為了克服基于軟件的認證的限制, 提出了各種采用軟件/硬件協(xié)同設(shè)計的復(fù)合架構(gòu).復(fù)合架構(gòu)可以彌補在低端設(shè)備上無法容納專用安全硬件(如TPM)的缺憾. 他們通過構(gòu)建一個最小化信任錨點來實現(xiàn), 典型的架構(gòu)有 SMART[14]、TrustLite[15]、Tytan[16]等.

利用復(fù)合架構(gòu), 研究者提出了一些集群證明方案.SEDA[20]引入了對于設(shè)備集群的安全模型定義并在此之下證明了安全性 它基于兩個嵌入式設(shè)備的認證架構(gòu)(SMART和TrustLite)設(shè)計了實現(xiàn)方案.但是SEDA并沒有考慮硬件攻擊, 并且只能提供通過證明的設(shè)備個數(shù), 并不能提供具體失敗設(shè)備的identity等額外信息.

上述遠程證明方案只考慮了軟件攻擊, 敵手的能力被局限在操縱prover的軟件, 在單個prover認證下,是有理由這么假設(shè)的, 特別是當(dāng)設(shè)備被安全保存的時候. 然而我們現(xiàn)在處于一個多設(shè)備互聯(lián)的生活場景下,prover可能是異構(gòu)的, 被分布在一個大的物理范圍內(nèi),所以物理攻擊是極有可能的. DARPA[21]假設(shè)如果敵手物理地攻擊了一個設(shè)備, 則這個設(shè)備會不可達一段時間, 所以將設(shè)備的缺失看做設(shè)備被捕獲的一種信號, 即通過缺失探測來解決物理攻擊.

本文針對現(xiàn)有方案做了改進, 提出了一種更高效安全的集群證明方案, 可以抵御設(shè)備合謀攻擊、重放攻擊等.

2 方案設(shè)計與實現(xiàn)

2.1 系統(tǒng)模型

在大規(guī)模設(shè)備組成的集群S中, 很多設(shè)備是同構(gòu)的, 比如醫(yī)院中存在多種智能醫(yī)療設(shè)備, 每種智能醫(yī)療設(shè)備都有很多個, 它們的軟硬件配置相同, 要是按照通用的集群驗證方法將每個設(shè)備放入集群中, 則耗時且沒必要. 如果單獨一個個驗證的話, 則會非常繁瑣, 且容易使Verifier成為性能瓶頸. 如果將集群設(shè)備分組,同構(gòu)設(shè)備構(gòu)成一組, 每組設(shè)立一個管理節(jié)點(管理節(jié)點也是需要驗證的設(shè)備之一), 這樣, 管理節(jié)點只要比較組內(nèi)設(shè)備校驗和的不同, 即可預(yù)先知道哪個設(shè)備被篡改(在同構(gòu)設(shè)備中大部分沒有被篡改的情況下, 其他情況在第5章進行了討論和改進). 然后遠程驗證者只需要驗證管理節(jié)點即可, 減少了遠程驗證者需要驗證的節(jié)點的數(shù)量, 而且同構(gòu)設(shè)備間的驗證可以在全局證明協(xié)議之前預(yù)先完成, 從而提高了集群認證效率. 我們以圖1為例對集群模型進行說明, 示例集群中有8個管理節(jié)點,Dij表示Di的子節(jié)點, 即Di是Dij的管理節(jié)點,Di管理下的節(jié)點Dij都是同構(gòu)設(shè)備.管理節(jié)點可以和子設(shè)備同構(gòu), 也可以是專門選取的要驗證的設(shè)備.就以醫(yī)院中智能醫(yī)療設(shè)備場景為例,D11可能是智能血壓計,D21、D22可能是智能血糖儀, 其他以此類推將其按照設(shè)備類型分組, 選取的管理設(shè)備負責(zé)驗證組內(nèi), 當(dāng)集群驗證的時候, 只需要驗證管理設(shè)備即可.

IoT集群證明系統(tǒng)中, 主要的參與者有:設(shè)備操作員OP, 負責(zé)離線階段設(shè)備的認證和部署;驗證者VRF,負責(zé)驗證集群設(shè)備的可信性;管理節(jié)點Di, 負責(zé)認證組內(nèi)設(shè)備的可信性以及被VRF認證;設(shè)備節(jié)點Dij, 由其管理節(jié)點Di進行驗證.

圖1 基于軟硬件混合證明的集群證明體系架構(gòu)

本方案要實現(xiàn)的目標(biāo)是:(1) 可以遠程驗證整個集群的完整性;(2) 比單獨驗證每個設(shè)備以及比按相同方式統(tǒng)一驗證所有設(shè)備更高效(在同構(gòu)設(shè)備比較多的情況下);(3) 管理節(jié)點不需要知道子設(shè)備的詳細配置信息;(4) 集群可以擴展, 可以動態(tài)加入或刪除設(shè)備;(5) 可以探測到被軟件攻擊的設(shè)備;(6) 可以探測到被物理攻擊導(dǎo)致探測不到的設(shè)備.

2.2 敵手模型

假設(shè)敵手A可以竊聽、插入或修改所有設(shè)備間交互的信息. 假設(shè)敵手在認證之前, 已經(jīng)控制設(shè)備內(nèi)存,修改平臺上的內(nèi)存區(qū)域.假設(shè)敵手可以實施重放攻擊、預(yù)先計算待遍歷的內(nèi)存、實施內(nèi)存替換攻擊等;假設(shè)敵手可以實施通過缺失探測檢測出來的物理攻擊, 但是不能物理攻擊所有的設(shè)備;假設(shè)攻擊者可以操作設(shè)備的所有軟件, 但不能偽造簽名, 也不能發(fā)動整個網(wǎng)絡(luò)規(guī)模的DDoS攻擊, 也不考慮運行時攻擊.

2.3 安全假設(shè)

本文有如下假設(shè):(1) 敵手在認證期間, 不能修改硬件設(shè)備等;考慮有限的DOS攻擊. (2) VRF知道每個管理節(jié)點的軟硬件配置. (3) 設(shè)備的時鐘是和OP以及VRF同步的, 并且敵手不能攻擊;同構(gòu)設(shè)備中大多數(shù)設(shè)備是可信的, 只有少部分設(shè)備是被篡改的(對于該假設(shè), 在第5章中進行了討論和改進);操作者OP是可信的, 以及所有的密碼學(xué)函數(shù)是安全的;在離線階段進行初始密鑰交換時, 我們假設(shè)任何兩個節(jié)點之間存在安全信道. (4) 集群S中的設(shè)備可以動態(tài)移動, 但是在認證期間, 集群拓撲是靜態(tài)的. (5) 假設(shè)集群中每個設(shè)備都有:① 一個存儲代碼段(代碼和數(shù)據(jù))的靜態(tài)非易失寫保護內(nèi)存區(qū)域R;② 密鑰的安全存儲, 只有R中的代碼執(zhí)行的時候才可以被訪問;③ R中代碼是安全的,除了最終結(jié)果外, 不會泄露任何信息, 它們構(gòu)成設(shè)備的信任根.該信任根已經(jīng)在多種架構(gòu)中實現(xiàn), 如SMART 架構(gòu)[13]、TrustLite[14]架構(gòu)、TyTan[15]等, 同時也在TrustZone[16]等中實現(xiàn). 它們都由受保護存儲區(qū)域和不受保護存儲區(qū)域組成, 具體如圖2所示.

圖2 內(nèi)存劃分

2.4 符號說明

表1 協(xié)議用到的標(biāo)識符

2.5 方案架構(gòu)與協(xié)議

如圖1所示, 我們將集群中的設(shè)備分為兩種, 管理節(jié)點Di和子節(jié)點Dij. 集群證明具體分為兩個階段:(1)離線階段, 完成設(shè)備的初始化與更新, 分別對應(yīng)圖1中的init、join協(xié)議;(2) 在線階段, 執(zhí)行真正的驗證,包括圖1中的AttVerify和Subattest協(xié)議. 在線階段主要做設(shè)備的缺失探測和收集證明. 缺失探測目的在于探測因受到物理攻擊而不可達的節(jié)點, 通過重組拓撲結(jié)構(gòu)確保集群驗證的穩(wěn)定性. 收集證明主要分為兩方面:一方面是管理節(jié)點對同構(gòu)設(shè)備子節(jié)點的驗證, 我們采用的方法是管理節(jié)點比較子節(jié)點發(fā)來的校驗和, 不同于大多數(shù)的為被篡改節(jié)點, 否則為可信節(jié)點;另一方面是網(wǎng)絡(luò)拓撲結(jié)構(gòu)中, 管理節(jié)點組成的集群的全局證明.

2.5.1 離線階段

離線階段主要完成設(shè)備的初始化和更新. 在初始化的時候, OP配置設(shè)備的簽名密鑰對(被OP簽名)以及通信密鑰, 并將VRF的公鑰分發(fā)給每個設(shè)備, 同時,OP將同構(gòu)設(shè)備歸于同一個管理節(jié)點下用以實現(xiàn)子節(jié)點驗證的高效化. 除此之外, 鄰居節(jié)點間以及管理節(jié)點和子設(shè)備之間要進行密鑰交換. 這些都由圖1中的init協(xié)議完成. 設(shè)備更新分為新設(shè)備加入和鄰居更新,由join協(xié)議完成. 當(dāng)新設(shè)備加入集群中時, OP為其分配密鑰對以及VRF的公鑰. 如果為子設(shè)備節(jié)點, 需要和相應(yīng)的管理節(jié)點進行密鑰交換;如果為管理節(jié)點, 則需要和鄰居節(jié)點進行密鑰交換. 鄰居更新則是管理節(jié)點定時發(fā)送信息來更新該節(jié)點的鄰居列表以及子設(shè)備節(jié)點列表并通知OP.

2.5.2 在線階段

在線階段主要完成對集群的可信驗證操作. 當(dāng)OP和VRF不是同一個設(shè)備的情況下, 驗證者想要驗證集群的可信狀態(tài)時, 需要先經(jīng)過OP, OP先對驗證者進行驗證, 以防VRF是攻擊節(jié)點, 發(fā)起DOS攻擊, 然后OP傳達VRF的數(shù)據(jù)給集群中的設(shè)備. 因此, 我們統(tǒng)一將和集群設(shè)備交互的設(shè)備稱為VRF. 同時因為OP在此階段只負責(zé)轉(zhuǎn)發(fā)VRF和管理節(jié)點的信息, 在本節(jié)將認為VRF與管理節(jié)點直接通信.

(1) 缺失探測階段

缺失探測階段本文采用心跳協(xié)議[20]來進行, 主要基于兩個目標(biāo):① 發(fā)現(xiàn)被物理攻擊節(jié)點;② 基于返回的缺失節(jié)點, 重新選擇初始節(jié)點(如果拓撲不是連通的, 可以選多個構(gòu)成多組, 每組之間互相連通), 這樣就避免因為中間某個節(jié)點被攻擊而導(dǎo)致整個驗證無法進行. 缺失探測中, 探測設(shè)備發(fā)送心跳請求. 在一定時間段內(nèi), 未反饋心跳信息的設(shè)備將被認為失去連接. 這時候需要通過重新選取初始節(jié)點, 保證缺失設(shè)備不影響鏈路傳送.

當(dāng)要進行心跳協(xié)議時, VRF廣播心跳請求給集群中的所有管理節(jié)點, 然后等待接收心跳信息, 如果收到一個管理節(jié)點的日志記錄, 就查看記錄中的心跳信息,找出失敗管理節(jié)點, 然后重新設(shè)置網(wǎng)絡(luò)拓撲, 以免一個初始節(jié)點壞掉之后, 還按原來的拓撲進行, 后面的節(jié)點狀態(tài)都不知道. 重設(shè)的話, 可以根據(jù)失敗管理節(jié)點選擇幾個初始節(jié)點等, 使得集群內(nèi)每個設(shè)備都不會因為初始節(jié)點的問題而連接不上. 而管理節(jié)點除了發(fā)送自身的心跳信息之外還要接受鄰居節(jié)點的心跳信息. 如果收到鄰居節(jié)點心跳信息后發(fā)現(xiàn)這個心跳信息自己沒有記錄, 則將這個信息記錄在日志中, 然后將該心跳信息再轉(zhuǎn)發(fā)給所有鄰居. 直到管理節(jié)點收到所有設(shè)備的心跳信息或者超時, 最后將自身的日志信息發(fā)送給VRF.

(2) 收集證明階段

收集證明階段的目標(biāo)分為兩方面:一方面是管理節(jié)點對同構(gòu)設(shè)備子節(jié)點的驗證, 如圖1中的Subatt, 管理節(jié)點比較子節(jié)點發(fā)來的校驗和, 不同于大多數(shù)的為被篡改節(jié)點, 否則為可信節(jié)點;另一方面是網(wǎng)絡(luò)拓撲結(jié)構(gòu)中, 對管理節(jié)點組成的集群的證明, 如圖1中的AttVerify.

實驗涉及到的主要消息類型有:① req, 表示消息類型是請求類型. ② rep, 表示消息類型是響應(yīng)類型. ③subreq, 表示管理節(jié)點對子設(shè)備節(jié)點的請求信息. ④subrep, 表示子設(shè)備節(jié)點對管理節(jié)點的回復(fù)信息. 對于待發(fā)送和接收的數(shù)據(jù)包, 我們分別用MsgS(MsgF)和MsgR表示.

1) 對分組內(nèi)部同構(gòu)節(jié)點間的驗證.

由于同構(gòu)節(jié)點的內(nèi)存內(nèi)容是相同的, 因此內(nèi)存的校驗和也是相同的.所以可以讓大量的同構(gòu)節(jié)點同時進行內(nèi)存校驗, 校驗和不同的節(jié)點將被認為是內(nèi)存被篡改節(jié)點.具體流程見算法S u b a t t_M g r N o d e,Subatt_SubNode, 分別從管理節(jié)點和子設(shè)備節(jié)點的角度來描述協(xié)議Subatt.

a) 管理節(jié)點:管理節(jié)點的驗證分為四步, 如算法1.

① 發(fā)送請求:管理節(jié)點每隔一個固定的時間(這個時間小于遠程驗證間隔)就發(fā)送加密的驗證請求subreq檢測子設(shè)備節(jié)點的狀態(tài).驗證請求中包含一個隨機數(shù)據(jù)Randata和一個遞增的序列號CurSeq以及設(shè)備ID. 然后設(shè)置定時器進入等待階段. 每次等待的時間固定為TAtt.

② 等待:管理節(jié)點等待子設(shè)備節(jié)點傳回來的驗證信息subrep.如果收到信息時未超過定時器設(shè)置的時間則進入記錄階段.

④ 校驗:驗證時間超過定時器設(shè)置的時間之后進入該階段. 管理節(jié)點比對所有于記錄階段記錄的子設(shè)備節(jié)點的校驗和, 和大多數(shù)子設(shè)備節(jié)點不同的校驗和的節(jié)點加入驗證失敗子設(shè)備集合FailSubDevs中, 其余的加入驗證成功子設(shè)備集合SucSubDevs. 剩余未發(fā)來驗證信息的子設(shè)備節(jié)點加入未回復(fù)子設(shè)備集合NorepSubDevs中.

b) 子設(shè)備節(jié)點:子設(shè)備節(jié)點的驗證分為三步, 如算法2所示.

① 等待:等待管理節(jié)點發(fā)來的驗證請求subreq. 收到請求則進入驗證階段.

② 驗證:如果收到的消息屬于subreq類型, 檢查管理節(jié)點發(fā)來的驗證請求的簽名并解密獲取序列號及隨機數(shù)據(jù). 再驗證該請求的序列號, 必須大于子設(shè)備節(jié)點存儲的上一次驗證階段使用的序列號. 通過驗證之后, 子設(shè)備節(jié)點用隨機數(shù)填充空白內(nèi)存, 然后計算內(nèi)存和收到的隨機數(shù)據(jù)的校驗和. 進入回應(yīng)階段.

③ 回應(yīng):子設(shè)備節(jié)點將節(jié)點ID, 接收到的序列號和上一步產(chǎn)生的校驗和打包加密以subrep類型的消息發(fā)回管理節(jié)點(父節(jié)點par). 記錄當(dāng)次校驗的序列號并恢復(fù)內(nèi)存.

2) 對全局集群環(huán)境內(nèi)所有管理節(jié)點的驗證.

對管理節(jié)點的驗證比較簡單, 由于VRF中已有管理節(jié)點的內(nèi)存信息, 并且管理節(jié)點不同構(gòu), 因此可以針對每個管理節(jié)點的內(nèi)存校驗和進行單獨比對.具體流程見算法AttVerify_VRF, AttVerify_MgrNode. 分別從驗證者VRF和管理節(jié)點的角度來描述協(xié)議AttVerify.

a) 驗證者VRF:VRF的驗證分為四步, 如算法3.

①體溫高于38.5℃;②符合中醫(yī)辨證:發(fā)熱重,惡風(fēng),有汗或少汗,頭痛,鼻塞,鼻流濁涕,噴嚏,咳嗽咳痰,痰稠色白或黃,咽紅腫痛,口干渴,舌質(zhì)紅,苔薄黃,脈浮數(shù)或指紋浮紫,兼見脘腹脹滿,不思飲食,嘔吐酸腐,口氣穢濁,大便酸臭[2];③監(jiān)護人知情同意,患兒能夠配合治療。

① 發(fā)送請求:VRF根據(jù)需求選擇一個管理節(jié)點InitNode向其發(fā)送加密的驗證請求來檢測所有設(shè)備節(jié)點的狀態(tài). InitNode優(yōu)先選擇更安全的管理節(jié)點或者距離更近的管理節(jié)點. 驗證請求中包含InitNode要計算校驗和的隨機數(shù)據(jù)RanData和一個遞增的序列號CurSeq. 然后設(shè)置定時器進入等待階段. 設(shè)定接收驗證和最長需要時間TRep.

② 等待:VRF等待管理節(jié)點傳回來的驗證信息rep. 如果收到信息時未超過定時器設(shè)置的時間則進入校驗階段.

③ 校驗:如果收到的消息屬于rep類型, VRF檢查收到的信息的簽名并解密. 如果信息中的序列號Seq跟管理節(jié)點發(fā)送的序列號CurSeq一致則根據(jù)收到的隨機數(shù)據(jù)RanData計算對應(yīng)管理節(jié)點的校驗和并與該信息中的校驗和比對. 如果比對結(jié)果一致則將該管理節(jié)點歸于SucSubDevs, 并根據(jù)信息中的子設(shè)備狀態(tài)S u b S t a t e L i s t將子設(shè)備歸于S u c S u b D e v s,FailSubDevs或者NorepSubDevs. 再將信息中包含的節(jié)點ID放入已回復(fù)子節(jié)點集合RecSubNode中進入等待階段.

④ 結(jié)束:驗證時間超過定時器設(shè)置的時間之后進入該階段. 失去聯(lián)絡(luò)的管理節(jié)點歸為NorepSubDevs.將這三組集合跟校驗階段收集的子節(jié)點驗證記錄一起輸出給用戶.

b) 管理節(jié)點:管理節(jié)點的驗證分為三步, 如算法4.

① 等待:等待本次驗證相關(guān)信息. 如果收到VRF發(fā)來的驗證請求req則進入驗證階段;如果收到其余管理節(jié)點的驗證信息rep則進入轉(zhuǎn)發(fā)階段.

② 驗證:判斷接收到的信息的簽名是否正確.正確則解密信息從信息中獲得序列號Seq和隨機數(shù)據(jù)RanData. 再驗證該請求信息的序列號, 必須大于管理節(jié)點存儲的上一次驗證階段使用的序列號PrevSeq. 通過驗證之后先產(chǎn)生一個新的隨機數(shù)據(jù)NewRanData并將其與剛才獲取的序列號Seq一起加密之后以req信息的形式群發(fā)給鄰居節(jié)點. 接著將內(nèi)存中的空白部分用隨機數(shù)進行填充, 然后計算內(nèi)存和隨機數(shù)據(jù)RanData的校驗和. 再將本節(jié)點ID, 校驗和Checksum,序列號Seq, 隨機數(shù)據(jù)RanData連同子設(shè)備的可信狀態(tài)一起傳送給父節(jié)點. 記錄當(dāng)次校驗的序列號并恢復(fù)內(nèi)存, 進入等待階段.

③ 轉(zhuǎn)發(fā):將收到的rep類型的消息轉(zhuǎn)發(fā)給父節(jié)點.進入等待階段.

3 安全性分析

為了保障驗證結(jié)果的安全性, 我們依據(jù)遠程證明安全威脅模型針對常見攻擊方法進行如下安全分析.

(1)偽造攻擊:指在攻擊者不知道密鑰的情況下,構(gòu)造一個新的消息及其簽名值. 本系統(tǒng)采用加密簽名算法, 由于假設(shè)在離線階段的初始密鑰交換階段, 通信信道是安全的以及密碼函數(shù)是安全的, 所以當(dāng)敵手在通信信道上篡改或者偽造消息時, 會導(dǎo)致簽名驗證失敗, 從而達到防偽造效果. 而且當(dāng)管理節(jié)點與子設(shè)備節(jié)點同構(gòu)時, 管理節(jié)點也不能利用子節(jié)點傳來的校驗信息, 因為隨機數(shù)產(chǎn)生函數(shù)存儲在被保護內(nèi)存區(qū)域R中,外部函數(shù)無法訪問到它, 這樣隨機數(shù)產(chǎn)生函數(shù)只能由認證代碼控制, 而每次產(chǎn)生的隨機數(shù)不同, 即管理節(jié)點計算校驗和的隨機數(shù)和子設(shè)備節(jié)點不同, 所以無法偽造;而且即使管理節(jié)點可以給子設(shè)備節(jié)點傳自己的隨機數(shù)也會帶來時間的延遲, 所以基本上無法直接利用子節(jié)點信息進行偽造.

(2)重放攻擊:指通過將以前認證的數(shù)據(jù)傳送給VRF, 本系統(tǒng)通過將隨機數(shù)加入驗證過程來防止預(yù)計算, 從而避免重放攻擊.

(3)內(nèi)存復(fù)制或內(nèi)存替換攻擊:指攻擊者將內(nèi)存復(fù)制到空白區(qū)域, 當(dāng)驗證內(nèi)存時, 通過修改程序計數(shù)器PC和數(shù)據(jù)指針DP來實現(xiàn)攻擊, 本系統(tǒng)通過給空白內(nèi)存填充隨機數(shù)使得沒有空間存儲攻擊代碼達到防范的目的.

(4)代理攻擊:指使用更快的遠程設(shè)備代理checksum計算.但是遠程設(shè)備無法獲得真正的密鑰, 所以無法正確加密和簽名, 可以防御.

(5)內(nèi)存壓縮攻擊:壓縮獲得可以利用的空閑內(nèi)存,證明時實時解壓. 本系統(tǒng)通過設(shè)定認證時間以及在空白內(nèi)存中填充隨機數(shù)能一定程度上防范這種攻擊.

(6)合謀攻擊:指兩個設(shè)備串聯(lián)攻擊.本系統(tǒng)中當(dāng)合謀攻擊發(fā)生在子設(shè)備節(jié)點下的時候, 因為發(fā)送的都是加密簽名過的結(jié)果, 即使發(fā)送給合謀節(jié)點, 因為合謀節(jié)點沒有對應(yīng)的密鑰, 無法解密, 所以合謀攻擊無效;當(dāng)發(fā)生在管理節(jié)點之間的時候, 場景是鄰居節(jié)點將隨機數(shù)預(yù)先傳給下一節(jié)點, 導(dǎo)致下一節(jié)點可以預(yù)先計算. 本系統(tǒng)通過將產(chǎn)生隨機數(shù)的函數(shù)放于被保護內(nèi)存區(qū)域R中, 只有認證代碼可以調(diào)用它, 使得隨機數(shù)不能事先產(chǎn)生, 防止了合謀攻擊.

除此之外, 本系統(tǒng)采用一些方式來加強系統(tǒng)安全性.

(7)機密性保障:本系統(tǒng)采用信息加密的方式, 并且假設(shè)使用的密碼學(xué)函數(shù)是安全的, 所以敵手即使截獲信息, 也無法獲取消息內(nèi)容, 達到防竊聽的目的;另一方面, 本系統(tǒng)中除了VRF, 任何兩個節(jié)點之間不知道對方的軟硬件配置, 一定程度上可以保護隱私, 而且當(dāng)一臺設(shè)備被攻擊的時候, 不會獲取其他設(shè)備的數(shù)據(jù), 使設(shè)備更安全.

(8)可用性保障:本系統(tǒng)通過在缺失探測節(jié)點之后,重新選取管理節(jié)點, 使得缺失節(jié)點不影響其他節(jié)點的傳輸來保障協(xié)議的進一步運行. 除此之外, 本方案先用OP來驗證VRF, 可以在一定程度上防范DOS攻擊. 而且, 本方案因為可以發(fā)現(xiàn)偽造攻擊, 所以當(dāng)敵手偽造一個請求的時候, 接下來的設(shè)備要進行身份驗證, 驗證沒通過時會停止轉(zhuǎn)發(fā)與計算校驗和等, 所以只有身份驗證這一步會產(chǎn)生DOS攻擊, 一定程度上也可以減弱.

同時, 針對本文不考慮的攻擊:運行時攻擊和無法通過缺失探測檢測的物理攻擊, 進行一些相關(guān)討論.針對運行時攻擊如ROP攻擊(Return-oriented Programming), 對于該攻擊, 現(xiàn)在已有一些運行時證明方案如C-FLAT[21], ATRIUM[22]等, 可以設(shè)計方案對執(zhí)行指令以及控制流等進行認證;對于不能通過缺失探測檢測出的物理攻擊, 如側(cè)信道攻擊等, 需要對設(shè)備的安全架構(gòu)進行改進, 現(xiàn)在已有相關(guān)的架構(gòu), 如文獻[23]中所示架構(gòu), 針對cache側(cè)信道攻擊, 利用硬件事務(wù)內(nèi)存使得敏感代碼和數(shù)據(jù)在程序執(zhí)行過程中常駐cache來防止信息泄露.

4 實驗評估

我們先在一個普通的ARMSOC開發(fā)板Real210上[24]對加密等關(guān)鍵操作進行測試和評估, 然后針對評估結(jié)果, 用Python語言在Common Open Research Emulator (CORE)[25]軟件上對本文提出的高效集群證明方案進行了模擬. CORE是一個運行于Linux操作系統(tǒng)上的虛擬網(wǎng)絡(luò)仿真工具. 該工具利用了Linux的網(wǎng)絡(luò)堆棧從而使得該工具的仿真性能與真實網(wǎng)絡(luò)非常相似.

4.1 實驗設(shè)置

在本次模擬實驗中, 我們使用了兩種集群證明方案. 第一種采用最簡單的集群證明方案, VRF發(fā)一個驗證請求給星型拓撲中的初始節(jié)點, 然后初始節(jié)點將驗證請求轉(zhuǎn)發(fā)給鄰居節(jié)點, 以此類推, 一層層轉(zhuǎn)發(fā). 每個節(jié)點計算完校驗和后將結(jié)果經(jīng)過一層層轉(zhuǎn)發(fā), 傳給VRF. VRF收到回應(yīng)后, 一個個進行證明. 所有新加入的節(jié)點都直接加入星型拓撲中. 第二種則是本文提出的高效集群證明方案, VRF跟管理節(jié)點處于同一個星型拓撲中.

兩種方案中的所有節(jié)點都采用802.11作為數(shù)據(jù)鏈路層的介質(zhì)訪問控制協(xié)議. 同時采用Optimized Link State Routing (OLSR) 協(xié)議作為網(wǎng)絡(luò)層協(xié)議. 在密碼方面選擇128位的SM4進行加解密以及采用256位的SM2進行簽名及簽名驗證操作. 內(nèi)存驗證則采用SM3算法.

本文采用的實驗機器分別是Lenovo ThinkCentre M4000t, 與Real210開發(fā)板, 它們通過USB host接口連接;Real210開發(fā)板采用ARM Cortex-A8, 頻率為1 GHz, 有 512 MB 內(nèi)存, 256 MB NAND Flash. 數(shù)據(jù)采集SM4加解密和SM2簽名驗證分別是在Real210開發(fā)板上[24]測試出來的. 由于Verifier也要進行節(jié)點內(nèi)存驗證, 所以節(jié)點內(nèi)存驗證速度是在Windows機器上模擬出來的, 具體結(jié)果如表2所示.

表2 采用的密碼操作耗時

4.2 實驗結(jié)果

本次模擬實驗分成兩部分. 第一部分測試兩種集群證明方案的運行時間. 兩種集群都有50個節(jié)點并且節(jié)點只需要驗證1 MB的內(nèi)存. 第二部分測試高效集群證明方案的性能.

第一部分測試的結(jié)果如圖3所示.對于簡單集群驗證,x軸表示整個集群節(jié)點一共有50個節(jié)點. 對于高效集群驗證,x軸表示管理節(jié)點的數(shù)量, 從10個到50個.由圖可知, 集群中全部都是管理節(jié)點時, 高效集群驗證跟簡單集群驗證效率一樣. 但是隨著同構(gòu)程度的加深, 管理節(jié)點開始變少, 而管理節(jié)點的子節(jié)點開始增多, 高效集群驗證的效率越來越高. 當(dāng)只有10個管理節(jié)點時, 高效集群驗證使用的時間大約只有簡單集群驗證的1/4.

圖3 不同管理節(jié)點數(shù)量下兩種方案運行時間

第二部分測試的結(jié)果如圖4所示. 高效集群證明所耗費的時間隨著需要驗證的內(nèi)存增大而增大. 這主要是因為VRF計算管理節(jié)點的校驗和的時間也隨著內(nèi)存大小的增加而增加. 同時CPU運行時間隨著需要驗證的內(nèi)存大小的增加而增加. 節(jié)點的平均傳輸數(shù)據(jù) 與節(jié)點數(shù)量相關(guān)性比較大, 與內(nèi)存大小相關(guān)性比較小.

圖4 高效集群證明性能測試

5 比較與討論

“一對一”驗證指Verifier一個個驗證設(shè)備節(jié)點. 我們這里指Verifier同時發(fā)送n個驗證請求, 然后設(shè)備節(jié)點進行計算并將驗證結(jié)果返回給Verifier, 然后Verifier一個個進行相關(guān)計算與比對來驗證設(shè)備的可信性.

我們與SEDA[19]以及“一對一”驗證進行了比較, 如表3所示. 我們假設(shè)總設(shè)備個數(shù)為n, 管理節(jié)點個數(shù)為m, 時間耗費主要考慮從Verifier發(fā)送校驗請求到Verifier完成整個校驗總共花費的計算校驗和的時間.本文方案, 管理節(jié)點可以預(yù)先得知子節(jié)點信息, 所以Verifier只要驗證管理節(jié)點信息即可, 而且管理節(jié)點和管理節(jié)點之間傳完隨機數(shù)后, 計算校驗和以及傳輸?shù)倪^程都是并行的, 比較省時. 如表3所示, 本文提出的高效集群證明機制可以識別具體損壞設(shè)備、時間消耗也比較低, 同時可以一定程度上抵御物理攻擊和DOS攻擊. 當(dāng)SEDA以及“一對一”驗證和本文的假設(shè)條件一致時, 本文抵御的軟件攻擊更多. 在可用性上,如第3節(jié)安全性分析那章所示, 因為采用了缺失探測提前排查設(shè)備等, 提高了可用性;從通用性的角度來說,因為本實驗方案在同構(gòu)設(shè)備比較多的情況下有效, 如果沒有同構(gòu)設(shè)備, 其時間性能也是O(n). 從Verifier是否容易成為性能瓶頸來說, 因為“一對一”驗證一般要收發(fā)n個包并對這n個設(shè)備進行校驗, 比較繁瑣而且容易成為性能瓶頸, 而SEDA和本文方案可以減輕這一點, 只需要發(fā)一個包就可以得到驗證結(jié)果, 而且Verifier要驗證的設(shè)備大幅度減少, 降低了Verifier的計算量, 使其相對不容易成為性能瓶頸.

表3 高效集群證明機制和SEDA[19]以及單一prover驗證的比較

雖然本文在SEDA上進行了改進, 但是本文因為采用管理節(jié)點驗證子節(jié)點的想法, 所以當(dāng)管理節(jié)點被驗證失敗的時候, 其負責(zé)的子節(jié)點就要重新被驗證.

將本方案擴展成通用模型, 使其可以應(yīng)用到其他場景時, 就有必要對本實驗方案做進一步討論.

(1) 本文管理節(jié)點驗證子設(shè)備節(jié)點用的是多數(shù)表決機制, 但是如果管理節(jié)點和子設(shè)備節(jié)點采取的是同構(gòu)設(shè)備, 也可以采用一一驗證. 因為管理節(jié)點和子設(shè)備節(jié)點的內(nèi)存一樣, 但是因為填充內(nèi)存以及計算內(nèi)存校驗和的隨機數(shù)不同, 所以管理節(jié)點還需要重新計算子設(shè)備節(jié)點的校驗和, 增加了管理節(jié)點負載.

(2) 本文假設(shè)同構(gòu)設(shè)備中大多數(shù)是可信的. 但是在通用場景中, 存在著大多數(shù)設(shè)備被攻擊的可能性. 在這種情況下, 可以通過在管理節(jié)點中存儲同構(gòu)設(shè)備子節(jié)點中的一個標(biāo)準(zhǔn)值, 當(dāng)收到子設(shè)備節(jié)點的校驗和時, 用這個標(biāo)準(zhǔn)值和隨機數(shù)進行計算, 然后分別和每個子設(shè)備節(jié)點傳來的校驗信息進行比較, 不同的即為被篡改設(shè)備來進行改進. 或者也可以通過預(yù)先驗證一輪, 使其同構(gòu)設(shè)備中大多數(shù)可信.

(3) 本文Verifier因為要驗證所有的管理節(jié)點, 所以在設(shè)備類型比較多的情況下, 可能成為性能瓶頸, 而且網(wǎng)絡(luò)傳輸量也比較大. 可以通過讓管理節(jié)點之間互相驗證, 最終由初始節(jié)點統(tǒng)一上傳驗證結(jié)果, 但是這樣的話, 也會帶來問題, 比如會增加隱私泄露, 特別是對醫(yī)療設(shè)備來說, 攻擊一個設(shè)備就可以獲取到其他設(shè)備的信息, 造成更大的破壞. 同時需要管理節(jié)點有足夠的內(nèi)存去存儲集群設(shè)備內(nèi)其他節(jié)點的信息, 因為每種設(shè)備的配置不一致, 所以有些設(shè)備可能沒有足夠的能力去存儲別的設(shè)備的內(nèi)存信息. 而且管理節(jié)點之間要相互等待, 是串行的, 耗時也會相應(yīng)增加.

(4) 本文的實驗場景是在同組內(nèi)子設(shè)備不更新或者同時更新的情況下(比如智能醫(yī)療設(shè)備), 但對于一些經(jīng)常需要更新的場景(比如安裝不同的軟件)則不適用. 如果管理節(jié)點和子設(shè)備節(jié)點是同構(gòu)設(shè)備的情況下,可能需要將設(shè)備操作傳輸給管理節(jié)點, 因為是同構(gòu)設(shè)備, 所以管理節(jié)點可以根據(jù)收到的操作進行相同操作,然后進行驗證.

6 結(jié)語

本文針對物聯(lián)網(wǎng)集群設(shè)備遠程證明和驗證的問題,提出了一種高效集群設(shè)備可信性證明安全方案, 該方案通過采取安全驗證策略, 可以檢測設(shè)備存在的軟件攻擊. 該方案通過將設(shè)備分組, 然后基于管理節(jié)點再進行驗證, 提高了集群認證的效率. 方案的安全性評估結(jié)果表明, 它能夠防御集群證明場景下的常用安全攻擊.但是該方案有些方面有待提高, 比如物聯(lián)網(wǎng)設(shè)備無法抵御運行時攻擊如ROP攻擊以及不能抵御通過缺失探測檢測不出的物理攻擊, 如側(cè)信道攻擊等.除此之外,本方案假設(shè)密鑰交換時存在可信信道等以及擴展到通用模型中各種場景下的問題, 未來將重點研究這些方面的安全問題.