一种新的基于分层分组式结构的组播密钥管理方案

陈 娟

（广东舞蹈戏剧职业学院，广东 广州 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).