林江南, 吳秋新, 馮 偉
1(北京信息科技大學 理學院, 北京 100192)
2(中國科學院 軟件研究所 可信計算與信息保障實驗室, 北京 100190)
在物聯網發展迅速的今天, 物聯網設備早已遍布人們日常生活的周圍. 物聯網設備通常使用低功耗的嵌入式智能設備, 用于執行一些特定的任務, 比如發送、傳輸以及處理一些在環境中所獲得的數據[1], 從而構成了物聯網系統, 以此提高整個網絡的運行速度和服務質量.
由于嵌入式物聯網設備的低成本, 大量的物聯網設備應用于日常生活中, 但其內存、計算能力等方面都存在限制, 特別是缺乏安全機制[2]. 從而導致嵌入式設備系統容易成為網絡攻擊的目標, 如Mirai[3], 將僵尸程序傳播至網絡, 感染在線設備, 從而形成僵尸網絡,導致很多網絡服務功能癱瘓, 無法進行正常工作, 從而造成無法挽回的損失.
而遠程證明能夠證明設備完整性這一特性, 恰好可以用于解決嵌入物聯網設備的安全問題. 利用遠程證明基于證明者提供的可信度建立起一個安全的交互式協議[4]. 目前學術界已經提出了很多的遠程證明協議, 大體可以分為3類: (1) 基于軟件的證明, 無需硬件支持, 但往往基于實踐中難以實現的假設, 如SAKE[5]、VIPER[6]; (2) 基于硬件的證明, 由于其昂貴且復雜的特性, 對于資源受限的嵌入式物聯網設備不太實用, 如TrustVisor[7]、Flicker[8]; (3) 混合證明, 旨在提供最小化的硬件支持來彌補純軟件證明的安全性不足, 實現與基于硬件相似的安全保護, 如TrustLite[9]、TyTAN[10].
本文提出了一種基于信譽機制和Merkle樹的安全集群證明及修復方案, 主要貢獻如下:
(1) 本文方法使用信譽機制實現了多對一的證明協議, 能有效解決單點故障, 消除了固定的驗證設備,可以從設備觸發驗證, 使得證明更加及時, 并且適用于半動態網絡.
(2) 引入Merkle樹進行度量, 能夠快速精確地判斷出被惡意軟件感染的代碼塊, 再形成定制的補丁進行恢復, 不僅減少數據傳輸, 還能高效地修復受損設備.
(3) 本文還對提出的集群證明方法進行了安全性分析和性能評估, 結果表明, 本文集群證明在提高了安全性的同時所導致的性能開銷是可以接受的.
本文結構如下: 第2節介紹集群證明的相關工作;第3節給出本文基于的系統模型與假設; 第4節詳細給出本文提出的集群證明協議與修復機制; 第5節對本文提出的協議進行安全性分析; 第6節為性能評估,包括計算、通信、內存、運行時間以及能源開銷方面的分析、本方案與ESDRA[11]及HEALED[12]的安全性對比以及仿真模擬的實驗結果; 第7節對本文工作進行總結.
集群證明. 縱觀集群證明的發展歷程, 隨著第一個集群證明協議SEDA[13]提出至今, 不少集群證明的方案呈現在公眾的視野中. 大多數都是以SEDA為基礎的一對多證明協議. 這些證明協議以驗證者為根構造生成樹, 從根往下進行證明, 最后不斷將證明結果匯聚至驗證者, 這也就意味著這類協議只能應用于靜態網絡. 比如, SeED[14]在SEDA的基礎上增加了抵抗DoS攻擊, 從而形成了非交互式的拒絕服務攻擊的認證方案. 在2019年, ESDRA提出了第一個多對一的集群證明協議, 通過設備端發起的證明, 從而可以適用于半動態的網絡. POSTER[15], SALAD[16]都是基于設備的自身認證, 積累個體驗證報告, 最后共享至整個網絡, 從而實現適用于動態網絡的認證協議.
安全修復. 目前大多數協議只提出了證明方案, 對于后續的修復沒有詳細的介紹.已有的修復協議方案,如HEALED, 利用集群相同軟件配置的可信設備對其進行修復, 從而將受損設備回滾至可信狀態.
在大規模的集群 S 中包含著軟硬件配置不同的異構設備, 并且在通信過程中,能耗隨距離增加而急劇增加. 面對著無處不在的各式攻擊, 如果讓管理者一一驗證, 不僅存在驗證不及時的風險, 并且驗證者的性能將成為整體認證方案效率的瓶頸. 為了提高驗證效率以及降低功耗, 我們將集群S 中的每個設備按照通信距離分成若干個簇, 每個簇都有一個簇頭節點. 在簇內, 各個設備節點之間相互證明從而構建出集群的可信環境.此外, 檢測到受損設備應當給予修復的機會, 若是修復不了, 即可判定修復成本大于他自身的價值, 可以進行移除操作. 當然, 為了識別集群中由于遭受物理攻擊而探測不到的設備, 實施在線探測及時識別可能受到攻擊的設備, 并進行隔離驗證.
在本文集群證明系統中, 主要的參與者包含: 網絡管理者 M, 負責初始化以及修復集群中受損的設備節點; 簇頭節點Di, 負責管理簇內設備; 組內普通節點Dij,由簇頭節點Di進行管理.
本文方法基于以下幾點假設:
(1) 假設所有節點都滿足安全遠程證明的最低硬件要求, 即只讀存儲器和簡單的內存保護單元, 可以通過SMART[17]等機制實現.
(2) 假設證明例程為原子程序運行, 并且證明代碼無法被修改.
(3) 為了確保證明結果的可靠性, 假設每個節點應至少有3個鄰居設備.
(4) 假設物理攻擊會導致設備一段時間不可用, 從而攻擊期間無法探測到設備.
(5) 由于DDoS攻擊幾乎不可能被完全抵抗, 與其他集群證明方案一樣, 本文不考慮DDoS攻擊.
本方案提出一個多對一的集群證明及修復方案.如圖1所示, 方案可分為兩個階段: 離線階段和在線階段. 在離線階段完成設備的初始化以及設備之間的連接過程, 從而構建出整個集群的網絡. 而在線階段主要完成對設備的驗證以及發現受損設備后進行的修復協議. 此外, 在線階段還加入了缺失探測機制, 可以及時發現因物理攻擊導致不可達的節點, 將其隔離出集群,再進行修復或者徹底移除操作. 表1定義了本文所用的符號及參數.

表1 符號和參數

圖1 協議網絡圖
離線階段包括設備的初始化( i nitial協議)以及設備連接( j oin協議). 設備初始化過程中, 網絡管理者對新增設備進行初始化工作; 設備連接過程是設備之間通過網絡管理者提供的安全通道建立連接, 為后續證明及信息交流提供基礎.
4.1.1 設備初始化
如圖2所示, 當新設備 D7要加入網絡時, 網絡管理者 M 就會對D7執 行i nitial協議, 生成設備對應的配置信息, 其中包括: 私鑰 s k7, 公鑰 pk7, 身份證書c ert(pk7), 代碼證書c ert(c7), 網路管理員公鑰 pkM, 初始信譽值w7, 最后驗證時間 ta7以及唯一設備標識符d7, M保存軟件配置代碼c7, 便于后續修復(h eal)協議的使用. 對新設備的初始化可以表述為:

圖2 離線階段

每個設備的公私鑰對都是基于SM2 ECC密鑰體制[18]生成. 代碼證書c ert(ci)包含設備的可信散列代碼ci以及證書的公共信息. tai和te主要是在證明階段提供可靠的標準, 當前時刻為 tai+te時, 就會對該設備執行設備證明( a ttest協議). 由于觸發驗證條件在于設備本身, 集群內就可以并發執行a ttest協議. 此外, 每個設備的信譽值取決于它參與的每次證明例程. 在證明例程中, 任何一個節點沒有權限為其他節點報告信譽值. 一旦發現某個節點是不可信的, 其信用值將被設置為-wmax. 在我們的方案中, 信譽值更高節點在鄰居節點的最終證明結果生成中擁有更大的權重.
4.1.2 設備連接
當設備 Di初始化或者更新后, 通過網絡管理者M提供的安全通道, 與鄰居設備進行配置信息的交換.如圖2所示, D7初 始化后, 與鄰居設備D4和D5進行連接. 在連接過程中, 它們雙方交換自身的公鑰 pki、身份證書 c ert(pki) 、代碼證書c ert(ci) 、當前信譽值wi、最后驗證時間tai以及唯一設備標識符di. 設備的配置信息存儲在受硬件保護的內存之中, 這就意味著設備節點無法虛報配置信息. 通過已認證的密鑰協商協議生成基于雙方私鑰的會話密鑰k, 在本文中使用非相鄰形式橢圓曲線Diffie-Hellman密鑰交換協議[19]. 在后面的證明和修復過程中, k是雙方進行數據交流的保證. 設備連接過程可描述為:
網絡管理者 M會周期性地根據簇頭選擇算法來選取簇頭, 使得簇頭的分布能覆蓋整個集群, 本文采用基于最佳簇半徑的無線傳感器網絡分簇路由算法[20]. 簇頭節點通過信息的傳輸形成了以 M為根節點的樹形結構, 其他普通設備節點以傳輸距離為參照連接到對應的簇, 從而形成集群. 普通設備保存簇頭的公鑰 pkM, 便于后期提交證明報告. 對于網絡管理者 M , 存儲集群中所有設備當前的信譽值, 在每次證明例程后會更新對應設備的信譽值. 當簇頭發現不可信的設備節點時, 其信譽值將被設為- wmax, 將wi以 及di發 送給 M , 然后 M 對其進行隔離, 再執行h eal協議或者移除網絡等操作.

在線階段包括對設備進行驗證(a ttest)、對設備的修復( heal)以及缺失探測3個子協議. 一旦有設備Di觸 發驗證條件, 鄰居設備就會對其執行a ttest協議, 每個鄰居生成臨時的證明結果上傳至簇頭, 由簇頭生成最終的驗證結果, 最后將 Di的最新信譽值上報網絡管理者 M. M 接收到Di的最新信譽值, 若等于信譽值最大值- wmax, M 就會對Di執 行h eal 協議, Di將最終修復結果反饋 M. 在缺失探測中采用心跳協議來進行, M廣播心跳請求, 由簇頭節點負責收集反饋, 找出不可達節點,從而對其進行修復或移除等操作.
在此, 我們引入Merkle樹對設備當前的軟件狀態進行度量. 由于Merkle樹能夠自下而上計算度量值,從而匯聚到根節點. 因此, 在證明階段, 鄰居設備僅需驗證根節點的度量值即可形成臨時驗證報告. 在修復階段, 如圖3所示, 證明設備 Di將待證明的代碼分成ω段等長的部分: c1,c2,···,cω, 并對應計算哈希值:hi[ω+1],hi[ω+2],···,hi[2ω], 然后以這些哈希值為葉子節點,c′i為根, 構造Merkle哈希樹, 其中, 2 ω表示Merkle hash tree (MHT)中除根節點之外的節點數. 受惡意軟件感染的代碼段會導致沿著根路徑生成錯誤的哈希值. 通過這種方式, 可以確認受惡意軟件感染的代碼段.

圖3 Merkle哈希樹
4.2.1 設備證明
每當設備 Di的 信譽值wi<wmin或者到達驗證時刻,鄰居設備 Dj就會對Di發出挑戰, 并記錄發送時間, 挑戰包含隨機數 Nij. Di結合挑戰和自身當前狀態以及會話密鑰kij生成消息驗證碼μij來報告其軟件狀態, 在此采取基于MHT進行度量, 最終度量為以為根節點的樹. Dj接 收到結果后, 通過連接階段保存的cij以及密鑰kij驗證 μij的正確性, 若 μij驗證成功, 則Dj生成臨時驗證結果 bij=1, 反之則推斷 Di受 到攻擊, 即bij=-1, 而當Di無 響應, 即為超時, 則bij=0. 形式化為:

簇頭接收所有鄰居節點的臨時證明結果后, 通過信譽機制進行最終驗證結果, 每個鄰居設備的信譽值代表著其參與生成最終驗證結果的權重. 最后廣播Di的唯一設備標識di以 及當前的信譽值wi. 對于鄰居設備Dj, 簇頭會將最終驗證結果 f與各鄰居節點的臨時證明作對比, 做出相對應的獎懲措施. 最終驗證結果及新信譽值計算公式如下:

其中, x 為 Di鄰居數量, wmed為鄰居節點信譽值中位數,它能夠對于高信譽值的設備起到制衡作用, λ為調和參數, 且λ ∈(0,1], 隨λ 增加驗證的條件越是嚴格. a ttest協議流程如算法1所示.

Dj Di attest算法1. 鄰居設備對的算法Nijc′icijkij輸入: ; ; ;b輸出:Dj 1: // 運行程序reqij=mac(kij;Nij)Nij Di 2: 發送 , 給 ;startTimer()3: ;Timerout()=1 bij=0 4: if then ;Vermac(kij;Nij||cij,μij)=1 bij=1 5: else if then ;bij=-1 6: else ;7: end if bij 8: 將 發送至簇頭Di 9: // 運行程序Vermac(kij;|reqij)=1 10: if thenμij=mac(kij;Nij||c′i)11:12: end if
4.2.2 設備修復
網絡管理者 M接收簇頭上報證明結果, 包括證明設備 Di的更新信譽值wi以 及唯一設備標識符di. 當wi=-wmax, M 對Di執行heal協議. 具體流程如下.
由于每個設備都有 M的公鑰, 因此 M 可以在集群中與任意設備進行通信, M 向Di發送一個請求信息reqi. Di接收后將其軟件配置和一個新的隨機數Ni利用MHT算法度量后用 M 的公鑰加密后發送給 M . M將自己保存的軟件配置 ci以同樣方式度量進行MHT的遍歷, 直到到達葉子節點. 最后, M為每個異常的葉子節點添加一個代碼段l, 用自身私鑰 s kM對l進行簽名生成補丁Γ, 并將其發送回Di. 一個代碼段l ={s,e,p}包含其起始地址s、結束地址e , 其代碼p. Di進行補丁修復,修復成功輸出 r =1. 否則, 輸出r =0. h eal過程可以通過如下公式表述為:

Di可以謊報修復結果來躲避補丁修復, 因此, 當heal 結束后, 將Di的信譽值設置為0, 這樣Di就會觸發attest 協議, 對Di進行再次證明, 若證明可信, 則說明Di已經恢復正常的軟件配置. 反之, Di的信譽值將被設置為- wmax, 從而需要進行再次修復, 直到其配置正常. 此外, 為了避免同一設備a ttest 與h eal反 復執行, M記錄設備執行 heal 的時間, 如果出現連續3次執行h eal失敗, 將直接移除該設備. h eal協議的算法流程如算法2所示.

M Di heal算法2. 網絡管理者對的算法Nic′i{hi[0],···,hi[2ω]}pkM ci{hM[0],···,hM[2ω]}輸入: ; ; ; ; ;r輸出:M 1: //運行程序reqi=Sign(skM;Ni) Di 2: 發送 給 ;wait()3: //等待接收反饋decrypt(skM;d′i)=1 4: if then k<2ω 5: while ( ) then hi[k]!=hM[k]6: if ( ) then k=2k+1 7: ;8: else k++9: ;10: end if 11: end if l={s,e,p}12: ;Γ=Sign(skM;l) Di 13: 將 發送至wait() Di 14: //等待 回復后r=0 15: if then attest()16: ;17: end if Di 18: // 運行程序VerSign(pkM;Ni||reqi)=1 19: if then di=MHT(c′i)20: ;d′i=encrypt(pkM;di) M 21: 將 發送至22: end if wait()23: //等待接收補丁VerSign(pkM;Γ)=1 24: if then DoPatch(Γ)25: ;

r=1 26: ;27: else r=0 28: ;29: end if r M 30: 將 加密后發往
4.2.3 在線探測
在線探測階段負責對整個集群設備進行定期的探測, 監測設備的運行狀態. 本文采用基于多級心跳協議[21],由網絡管理者定期給簇頭節點發出心跳信息, 簇頭節點在組內廣播心跳信息, 并收集組內普通節點的心跳信息, 形成一個alive-node消息, 發給網絡管理者. 若在規定的時間未接收到節點設備的心跳信息, 利用多級心跳協議增加和刪除節點的便利性, 將其從集群的拓撲網絡中刪除, 經過驗證為可信后, 再重新連接進入集群中.
我們將這個過程形式化為一個安全實驗EXPADV敵手 A DV可以與其相連的設備進行通信, 至少修改一個設備 Di的軟件配置, A DV可以篡改、竊聽或刪除所有通過 Di傳輸的信息. 經過一個多項式步驟后, Di被驗證簇頭最終驗證為1, 即為證明成功. 也就是敵手成功攻破Di.
定義1. 安全集群證明. F是一個關于?N,?sign,?hmac的多項式函數. 受損設備通過證明的概率為Pr[f=1|EXPADV(1?)=b] 在?=F(?N,?sign,?hmac)中被認為是可以忽略的, 則證明和修復方案是安全的.
定理1. 如果底層簽名、加密和MHTMAC方案是選擇性防偽的, 則本方案是一個安全的集群證明方案.
證明: ADV 可以通過欺騙鄰居節點返回b =1或欺騙網絡管理者返回 r=1來破壞本方案的安全. 下面通過兩種情況來分析:
(1) ADV 攻擊a ttest: A DV 想要使得b =1來通過鄰居節點的驗證可以使用以下策略: 1) 使用基于原始代碼的先前的HMAC μold; 2) 計算出基于新挑戰的HMAC μ′; 3) 入侵多個鄰居節點, 影響最終的證明結果.
對于策略1), 每次的挑戰 N 都是新的隨機值, 當且僅當 N =Nold時 , 驗證可以通過. 然而N =Nold的概率為2-?N. 所以通過驗證的概率可以忽略. 對于策略2), 一旦軟件配置發生改變生成的HMAC無法通過鄰居節點的驗證, 因此μ′通過驗證的概率也可以忽略. 對于策略3), 對于單個節點而言, P r[f=1|EXPADV(1?)=b]是可以忽略的, 而同時攻破 k個節點概率為(Pr[f=1|EXPADV(1?)=b])k, 也是可以忽略的.
(2) ADV 攻擊h eal: h eal 協議由網絡管理者 M 對受損設備 Di進行修復, A DV 可以以下策略來逃避h eal協議: 1) 偽造r =1返 回給 M ; 2) 在Di安裝補丁前篡改補丁.
對于策略1), 雖然可以逃避補丁Γ 安裝, 但是在之后的證明例程依舊被檢測出來, 超過3次將被移出集群. 對于策略2), 與a ttest 類似, A DV 試圖提取Γ 中提取補丁代碼再進行修改的概率是可以忽略的.
因此, ADV 通過攻擊a ttest 協議h eal協議來攻破良性設備的概率在 ?N,?sign,?hmac上可以忽略不計, 再加上在線探測階段對物理攻擊進行檢測, 由此可證明本方案是一個安全的集群證明方案.
本節將從計算開銷、通信開銷、內存開銷、運行時間以及能源開銷這幾個方面對本協議進行分析, 此外我們還對本文集群證明協議進行了仿真, 并與其他幾個類似方法進行了對比.
(1) 計算開銷. 對于普通設備而言, 主要計算開銷在于一些密碼操作. 在證明階段, 證明設備需要計算mi個m ac() 并驗證mi個V ermac() , 其中mi表示Di鄰居設備的數量. 鄰居設備驗證一個 V ermac() 并 計算一個 S ign().對于簇頭設備, 需要驗證 mi個V erSign()并計算2個Sign(), 一個發往網絡管理者 M, 一個廣播到組內各個節點. 在修復階段, 修復設備需計算2個e ncrypt()驗證2個d ecrypt() , 而 M 需要驗證2個V erSign()并計算2個Sign().
(2) 通信開銷. 我們使用SM3實現MHTMAC, 密鑰協商算法和簽名方案都是采用基于SM2的算法. 以len(x)=1 表 示 x 的長度為1 B. 因此,len(MHTMAC)=32ω-16, 其中ω 為 驗證代碼分割的段數, l en(Sign)=64,len(N)=16, l en(μ)=16, l en(w)=4, l en(t)=4, l en(d)=4,len(b)=4, l en(r)=4. 證書的大小取決于密鑰和簽名,所以 l en(cert)=48. 因此, 在證明階段, 證明設備而言,需發送( 32ω-16)miB以及接收1 6miB; 鄰居設備而言,需發送20 B以及接收 ( 32ω-16) B; 簇頭節點需發送(128+8ni) B接收4 miB; 網絡管理者 M 接收64 B. 在修復階段, 修復設備需接收36 B以及發送( 32ω-12) B,M發送36 B以及接收( 32ω-12) B.
(3) 內存開銷. 每個普通設備需要存儲: 1)自己的密鑰對 ( ski,pki)和 設備標識符di; 2)鄰居設備的設備標識符dj及 其信用值wj、 最近證明時間taj、 代碼證書cert(hj)和會話密鑰kij; 3) 簇頭的公鑰. 簇頭設備還需要存儲簇內所有節點的設備標識、相應的信用值和公鑰. 因此,普通節點需要 ( 52+80mi) B的存儲空間, 簇頭節點需要(52+80mi+24ni)B的存儲空間.
(4) 運行時間. 我們使用th、 tp、 tca、 ttr、 ts、 tv來表示計算或驗證 MHTMAC、生成隨機數、一跳訪問信道并傳輸一個字節、簽名或驗證簽名的時間. H是群的生成樹的高度. 因此, 總證明時間tattest為:

總修復時間theal為 :

(5) 能源開銷. 我們分別使用 Es、 Er、 Ep、 Eh、 Esg、Ev表示發送 1 B、接收 1 B、生成隨機數、計算或驗證 MHTMAC 以及簽名和驗證或簽名的能源開銷. 在一個證明過程中, 簇頭節點的最大能耗為:
E≤(128+8(ni+1)Es)+4miEr+2Esg+tvmiEv
證明設備的最大能耗為:
Ei≤(32ω-16)miEs+16miEr+miEh+Ev
鄰居設備的最大能耗為:
Ej≤20Es+(32ω-16)Er+Ep+Esg+Ev
在一個修復過程中, 修復設備的最大能耗為:
Ei≤(32ω+24)Es+(32ω+24)Er+Ep+Eh+4Esg+4Ev
本方案還與ESDRA、SEDA、SALAD在運行時間、平均能耗等方面進行比較, 具體數據展示如表2所示.

表2 不同方案對比
(6) 安全性對比. 我們將本方案與ESDRA、HEALED進行安全性對比. 如表3所示, 在我們的方案中, 增加了在線探測技術, 可以針對物理攻擊造成探測不到的設備進行識別, 從而預防物理攻擊. 在ESDRA中, 簇頭與所有簇內設備公用一個會話密碼, 存在會話密鑰泄露的風險, 本方案改用簇頭的公鑰進行加密, 僅有簇頭本身能夠解密, 解決了會話密鑰竊取的風險. 此外, 在ESDRA中, 證明設備的新信譽值計算存在高信譽值影響整個結果的風險, 一旦攻擊者入侵高信譽值設備, 足以影響整個集群的安全性, 本方案引入中位數, 計算每個證明設備的鄰居設備信譽值的中位數, 以此作為基準, 從而規避高信譽值設備“一票否定”的情況, 而在HEALED中, 利用傳遞性, 也同樣存在高信任度的設備, 再加上證明節點的任意性, 很難快速找到受損設備.

表3 安全性比較
(7) 仿真結果. 我們使用OMNet++[22]對本文集群證明協議進行了仿真模擬, 并與ESDRA、SEDA、SALAD幾個代表性工作進行了比較. 在仿真過程中, 我們使用嵌入式開發板上測得的密碼算法性能數據[23]進行仿真, 相關密碼算法在嵌入式開發板上的數據如表4所示.

表4 采用的密碼操作耗時
對于本方案, 我們設置初始信譽值為3, 最大信譽值wmax為5, 最小信譽值wmin為 1, 調和參數λ 為0.8, 獎勵信譽值為1, 懲罰信譽值為2. 通過仿真模擬, 以上4個方案得出數據如圖4、圖5所示.
圖4展現了本方案與ESDRA、SEDA以及SALAD關于證明設備不同鄰居數量的驗證時間. 相較于ESDRA,由于本方案在上報臨時驗證結果是采用簇頭的公鑰進行加密, 并且后期廣播證明設備的驗證結果采用簇頭簽名, 因此運行時間有所增加, 但在總體看來, 為了提高協議的安全性, 這些性能犧牲還是在可以接收的范圍內, 并且分布式證明的優勢依舊可以體現. 圖5描繪了本方案與ESDRA、SEDA以及SALAD關于不同的集群設備數量所進行的證明時間, 本方案對于集群數量的增大, 受影響的幅度較小.

圖4 鄰居節點數量與運行時間關系圖

圖5 集群設備數量與運行時間關系圖
本文提出了一種基于信譽機制和Merkle樹的安全集群證明及修復方案. 利用信譽機制實現了多對一的證明協議, 不僅能有效解決單點故障, 可以從設備觸發驗證, 并且適用于半動態網絡. 引入Merkle樹進行度量, 能夠快速精確地識別被惡意軟件感染的代碼塊,并進行高效地恢復到可信狀態. 通過對方案的安全性分析和性能評估, 結果表明, 本文集群證明在提高了安全性的同時導致的性能開銷是可以接受的.