一種新的基于分層分組式結構的組播密鑰管理方案

陳 娟

（廣東舞蹈戲劇職業學院，廣東 廣州 51000）

1. 引言

組播與廣播相比，突破了廣播通信對同一個子網的限制；與單播相比具有優化帶寬，減少了服務器負載，降低網絡流量和提高網絡通信效率，減少了主干網擁塞等優點。所以，組播研究逐漸成為一個熱點，安全組播通信是組播通信研究中的重點。安全組播必須要解決的重要問題是如何通過組播密鑰管理的生成、發送和更新組播密鑰來滿足加密等安全需求。安全組播包括保密、組成員認證、源認證、匿名性和完整性。組播密鑰問題主要是分層數據處理問題，根據組成員的加入/離開，采用不同的管理方案。組播是建立在一個開放的網絡環境中的，它使用UDP包來實現一對多通信，可以接收發向某個組播組的組播數據，組中的成員是動態的，可以隨時加入和退出組播組。組成員變動頻繁時，密鑰更新量也很大，使得組播的安全問題比單播更加嚴峻。相比于單播的密鑰管理，如何實現信息的排外共享是組播密鑰管理特有的問題。

現有的組播密鑰管理方法主要分三種：集中控制式、分布式和分層分布式。在這三類方案中，分層分組式通過糅合集中控制式和分布式這兩種形式，使得分層分組式在某些方面的性能有所改進，更能適用于規模大、分布廣泛的組。

2. 相關研究

分層分組式密鑰管理方案中是把集中式管理中單點失效的情況減少到最小作為目的。把子組定義分層不同的組成員，每個子組制定一個組管理者，再把組管理者繼續分成不同的組，層層分下去。

文獻[1]中提出的Iolus方案主要通過將組播組劃分成有層次的子組，已解決密鑰更新效率和可靠數據傳輸問題。每個子組都只有少量組成員，并且有自己的組播地址。Iolus是通過使用安全分發數來做到這點的。這種方法的優點是組員的加入和退出只會影響所在的子組，并不會影響到整個組播組。缺點是如果GSC不能正常工作，很多子組將互相斷開；必須充分信任中間節點GSI，這將會帶來安全隱患。文獻[2]中提出的CBT方法，由一系列核心節點構成核心樹，核心樹上的每個節點都可執行身份認證和密鑰分發。CBT使用統一的密鑰管理中心KDC，組播組創建，KDC產生密鑰加密密鑰KEK和數據加密密鑰DEK。成員加入組播組后會獲得這兩個密鑰。密鑰更新時，KDC向組播組發送使用KEK加密的新DEK的組播消息。在預定義的時間間隔到達后，成員開始使用新的DEK加密消息。這種方法的主要缺點是沒有考慮前向安全問題。文獻[3]中提出的STB方法，構造了一條安全傳輸骨干STB。STB上的每個核心節點都有自己的公鑰，并存儲相鄰節點的公鑰。發送數據時，數據源產生DEK，對數據進行加密傳輸，同時使用相鄰節點的公鑰加密DEK。此種方案的優點是使用的密鑰數量較少，同時避免了復雜的密鑰管理問題。缺點是數據包經每個安全主干上的核心節點轉發時，都要進行私鑰解密/公鑰加密的操作，而公鑰算法開銷較大，嚴重影響效率并且未考慮到前向/后向的安全問題。

3. 一種新的分層分布式結構的組播密鑰管理

本文提出了一種新的分層分組式的密鑰管理方案，其主要思想是先在組播組管理成員中構造一棵加權核心平衡樹，加權核心平衡樹上的核心節點構成一個密鑰管理層次。每個核心節點與所在區域內的其它組成員構成一顆子樹并確保此密鑰樹是平衡樹。每個核心節點都帶有一個權值，這個權值在一定時間內是其所在子樹中最大的。核心節點是子組的集中控制節點。GC中存有兩個數據結構如下：1}……}

其中W11，W21，…..Wm1，為核心節點的權值。flag=0，表示核心節點試用期滿可以構建子樹，flag=1，表示該節點為惡意節點，已經離開組播組，刪除該數據結構項。

圖1 加權核心平衡樹的結構圖

3.1 加權核心平衡樹的構建

為了防止單點失效問題，我們在這里采用一個輔助的組控制器來備份組控制器，其中輔助的組控制器的配置以及保存的信息與組控制器（GC）完全一樣。組播組初始化時，根據要求加入組播組的請求，我們分別算出各個client的權值，并將權值存入組控制器。根據圖1加權核心平衡樹的結構圖可以看出若核心節點（CN）加入或退出的頻率大的話會嚴重影響子樹的重構的頻率，會使整棵樹的振動率加大，這對數據的傳輸及其不利。所以我們在選取CN的時候，節點的在線時間(ST)是一個極為重要的考慮因素，由于CN是整棵子樹的集中控制器，所以，CN的CPU的主頻（GZ），內存容量（MC），硬盤容量（DC）都是影響因素。

在此我們可以得出如下的權重公式：

其中ST=承諾離開時間-加入時間；

W=ST*50%+GZ*20%+DC*20%+MC*10%

核心樹與組控制器之間我們采用兩層結構，從圖1中可以看出，若CN離開，為了確保前向加密，密鑰更新的代價為M-1，其中M為CN的數量。由此可以看出，核心節點離開組時密鑰更新代價較高，并且CN的配置等都比較好，所以我們決定采用無需密鑰加密的方式，犧牲計算來換取有限的網絡帶寬。

每棵子樹的CN代替組控制器對子組進行控制和管理，子樹采用LKH[4]管理方式。每棵子樹都有一個子組密鑰SKEKi，CN與每個字節點都有一個私密KEKi。

3.2 成員的加入

成員要求加入組播組是，GC根據加權公式計算出其權值并與其所存的權值相比較可以得出兩種結果：

(1)若新成員的權值大于所有的W11，W12……，則新成員成為核心節點（CN），并把權值存入GC的新集合中；

(2)若新成員加入權值

若是第二種情況，核心節點將當前子組密鑰更新為SKEK‘i，將{SKEK‘i}用SKEK組播發送給當前子組成員以保證后向安全。同時用分配給新成員的私密KEKi加密{SKEK‘i}，發送給新成員。這樣根據LKH的原理我們可知，成員加入時密鑰更新代價為2logdN，其中d為密鑰樹的深度-1，N為子組成員個數。

3.3 成員離開

節點離開分為兩種：核心節點位于加權核心平衡樹上，其它的為非核心節點。

當子組成員離開時，只需要更新當前子樹密鑰。子組采用LKH的方式，密鑰的更新代價為dlogdN-1.

若核心節點離開，此核心節點所在的子樹需要重新構造。由于我們采用平衡樹的方式所以有兩種情況：

(1)GC從該子樹中選取權值最大的為核心節點，重新構造一課子樹。

(2)若根據第一這種情況構造的子樹，導致整棵樹不平衡，則放棄此子樹，并且把其子節點加入到其它子樹中，并且修改GC中的數據結構。密鑰更新代價為O(2N logdN).從中可以看出我們應當要選擇合適的d和N使得N logdN最優。

由于核心樹采用無需密鑰更新，所以核心樹不需要進行密鑰更新，只需要重新計算新密鑰。

3.4 數據傳輸

當向組成員發送數據時，若只發送本地子組，使用SKEKi加密數據即可。發送給其它子組成員的數據，核心節點將參與數據加密/解密以及數據轉發過程。其它核心節點收到轉發消息后，一方面向核心樹上的其它節點轉發數據，同時解密數據，以子組SKEKi加密數據后轉發給整個子組。

3.5 對惡意節點的處理

有些惡意節點會在一段時間內不停地加入、離開導致系統不停地更新密鑰，嚴重影響網絡帶寬的可用率。在此，我們參考了文獻[5]中提出的基于時間片輪轉的思想。我們認為可以給新加入的成員提供一個試用期T。新成員可以分為兩種情況進行處理：

(1)當新成員為核心節點時，GC先不把其權重值存入，只是存入一個flag=1，表示其為使用，當其實際在線時間大于T時，flag=0，并把其權值存入GC，表示允許其接受其它新成員成為子組控制器。

(2)當新成員為非核心節點時，若其實際在線時間大于T時，CN分配其一個私鑰，并且更新組密鑰。并把其權值寫入GC。

若不采用上述方式，可能在T時間內就會有m2N logdN次密鑰更新，其中m為惡意節點在T時間加入的次數。

4. 實驗結果及分析

密鑰更新次數對效率有很重要的影響。本實驗從成員加入及成員離開兩個方面描述了密鑰的更新次數。其中，d表示密鑰樹的深度，N表示節點數，join_keynums表示成員加入時需要更新的密鑰次數，leave_keynums表示成員離開時需要更新的密鑰次數。

表1 密鑰的更新次數

通過對表1及第3部分的分析，可以發現采用加權密鑰樹的方式具有如下優缺點：

其中優點為：

(1)健壯性好。當部分組成員失效時，仍然能夠繼續工作，避免了單點失敗問題。

(2)可擴展性較好。子組成員變動不會影響到其它子組。

(3)數據傳輸開銷較小。當組成員需要向其它子組發送數據時，只需子組的核心控制節點對數據做一次解密/加密即可，大大降低了數據傳輸開銷。

(4)密鑰更新代價小。子組成員離開時，本地子組正確地產生密鑰，進行密鑰更新即可。使用層次式控制結構，密鑰更新增加了計算量，不需要網絡帶寬。

(5)安全性較好。組成員加入/離開時進行密鑰更新，不能冒充組成員，不能重新分發密鑰，充分保證了播組的前向/后向安全。

缺點為：

(1)在核心樹更新密鑰時，計算量大。

(2)要選擇合適的d和N使得N logdN最優難度很大。

5. 總結

本文首先討論了組播密鑰管理的幾種主要解決方案，并其優缺點進行了分析。提出了一種新的分層分組式的密鑰管理方案，完善密鑰管理，使系統具有更強的適應性。這種方案提高了可擴展性、健壯性和可預測性，密鑰更新代價低，有效解決了其它分層分組式方案中普遍存在的難以統一的組播密鑰管理方案，同時保證了組播組前向/后向安全，提高效率。

[1]Mittra S．A Framework for Scalable SecureMulticasting[C]//Proceedingsof ACM SIGCOMM'97，Cannes，France．1997：277．

[2]Ballardie T． Scalable Multicast Key Distribution[S]． RFC 1949，1996-05．

[3]Du F，Ni L M，Esfahanian A H．Towards Solving Multicast Key-Management Problem[C]//Proceedings of International ConferenceonComputer Communications and Networks．1999：232-236．

[4]Wallner D M Harder E J，Agee R C．Key Management for Multicast：Issues and Architectures[Z]．1997．http：//Internet Draft draft- wallner-kyarch-00．txt．

[5]趙志國，楊波.一種基于時間結構樹的多播密鑰管理方案[J].電子科技，2004，(8).