多播通信中的安全性问题综述.docx
- 文档编号:28816922
- 上传时间:2023-07-19
- 格式:DOCX
- 页数:28
- 大小:821.42KB
多播通信中的安全性问题综述.docx
《多播通信中的安全性问题综述.docx》由会员分享,可在线阅读,更多相关《多播通信中的安全性问题综述.docx(28页珍藏版)》请在冰豆网上搜索。
多播通信中的安全性问题综述
多播通信中的安全性问题综述
MatthewJ.Moyer,GeorgiaInstituteofTechnology
JosyulaR.RaoandPankajRohatgi,IBMThomasJ.WotsonResearchCenter
摘要
万维网的出现和集团化应用的普及已经引发了组通信的可扩展的安全解决方案的需求。
这样一个解决方案,安全多播吸引力,因为它利用组播数据传递的高效率。
然而,它也提出了几个研究挑战,最引人注目的是一组通信的体系结构,组密钥管理,消息源认证。
在本次调查中,我们讨论这些问题,并验证对它们提出的解决方案。
最近万维网迅速发展已经引起了新的研究。
互联网组通信的新型类型广泛地应用于各个方面,就像多方视频会议和实时的基于“push”技术的信息传递系统(如股票报价服务等)。
这些应用需要多播,以尽量减少它们所产生的网络通信量。
从理论上讲,启用组播的路由器的每个数据包发送多播通道和路由到每一个接收器。
而接收器用以监听该通道。
发送或接收数据在同一个特定的多播通道的所有主机,构成了多播组。
多播比单播的主要优势在于,它允许发送方发送每个数据包只有一次;路由器自动转发数据包到每个需要它的接收器,同时最大限度地减少穿越网络的数据包的副本数量。
传统的机制,用于支持多播通信是IP多播。
在IPv4中,D类地址(范围从224.0.0.0到239.255.255.255)是为多播通信预留的地址。
此外,参加启用多播的主机和路由器必须提供Internet组管理协议(IGMP)[1]用以管理组成员身份信息,并且启用多播的路由器也参与一个或多个多播路由协议[2]。
目前,IP多播是只能通过UDP访问。
呼吁任何主机发送一个UDP包到多播地址,和底层的多播路由机制将所有已明确加入该多播组的受助人提供的数据包和时间到该数据包的生存期(TTL)的范围内。
多播有潜力成为非常价值的网络服务,但是它也存在许多问题。
这些问题出于发送给大量接收器的路由数据包的固有复杂性。
特别是,保证可靠性(及时,有序地将每个数据包传递到每一个组接收)和安全(概念,只有一个多播组的注册会员可以数据包发送到组或接收数据包发送到该组)是非常困难的。
这些问题都包含了许多具有挑战性的研究课题。
在这篇文章中,我们解释了多播安全的主要研究的挑战和突出在这一领域已作出的重要贡献。
下一节将介绍很难研究的问题——安全多播的现状。
然后,我们提出了安全多播的体系结构和密钥管理的设计解决方案。
接着,在三个部分,我们将介绍一些目前一些重大问题最好的解决方案。
我们讨论了一些相关的工作,最后一节总结全文。
多播安全问题
组播安全基础设施的目标很简单:
保留所有组通信的身份验证和保密性,因此,只有注册发件人可以发送数据包到组,只有注册的接收器可以读取发送到该组的数据包。
在互联网中,由于缺乏在Internet网络层访问控制权利,执行一个多播组的消息保密要求数据加密。
这就需要一个组密钥管理方案加密密钥分配和维护注册组的成员。
同样,密码认证方案是必要的,以确保注册的接收器可以验证收到来自于注册发件人的报文。
安全组通信的大多数研究都集中在安全组和组密钥管理问题的体系结构,然而,最近的研究还集中于高效分组认证。
本文概括地介绍了所有这三个领域。
密钥管理的设计解决方案
我们首先通过介绍一个简单的组密钥管理的解决方案,检查其弱点,并列出了一系列与其它方案比较之后的标准,讨论在密钥管理方面的相关问题。
本地组密钥管理的不足
本机的组密钥管理问题的解决方案很简单。
我们建立一个集中的组控制器,负责管理该组的密钥。
控制器将组密钥通过一个安全的单播传送到每个组独立的成员。
分发到每一组的密钥要求与沟通成本与组成员的数量呈线性关系。
这种解决方案的简单是极具吸引力的的。
然而,由于两方面的原因,它的低效率使大部分的多播应用稍显不足。
首先,我们必须分配新组密钥每当有一方加入或离开了团队。
为了保护过去信息的保密性和完整性,本组必须改变其密钥每当一个新的成员加入时。
此外,为了保障未来信息的保密性和完整性,本组必须改变其密钥在每次当前成员离开时。
唯一可以知道当前密钥的人士是那些目前在参与小组交流。
对于具有高度动态成员的大型多播组,在每一个成员加入或离开的时候执行线性成本的密钥更新是不可行的。
因此,我们需要密钥管理解决方案,即被一个密钥更新的次线性消息成本。
其次,多种多样的系统和网络问题,很难始终如一地使路线包从一个单一来源及时地到一个分布广泛的接收器组。
第一个潜在的危险是失败的组控制器结点,对于任何采用集中式解决方案的组,这是致命的。
可能出现的第二个问题是网络故障。
如果有一个高流量负载或分区在位于网络某处,一些成员可能会收到密钥更新比别人更迅速,也可能完全错过密钥更新。
这不仅抑制一个合法组成员之间的安全通信,而且还造成潜在的安全漏洞。
并非所有现任成员使用相同的密钥,这样的事实可能会被以前的小组成员所利用。
恶意的一方可以使用过时的密钥向组发送非法的消息加密,或发送合法邮件到该组下的过时的密钥可以哄到当前的一些成员。
显然,一个集中密钥管理解决方案是不可靠的设计。
系统和网络经常变慢或者崩溃,我们需要一个架构,可以有效一个处理这些现实情况。
密钥管理解决方案的评估标准
基于以上的论述,我们展示和评估了一个安全多播组的组密钥管理的替代解决方案。
在我们讨论每一个解决方案之前,我们也提出了一个有益研究和比较不同解决方案的标准列表,检查标准比较不同的方案。
每一个标准都列出并给予简要介绍:
●系统架构:
一个理想的系统面对网络和系统故障可能会降低性能,但不应该完全失败。
各种分层和分布式体系结构可以提供这个级别的可用性,集中解决方案(尤其是简单的解决方案)不能。
●故障恢复:
一个精心设计的系统不仅要经受住各种结点和网络故障,同时也能从大多数系统故障中恢复,而无需重新初始化整个组。
●可扩展性:
解决方案应扩展到系统能够处理非常大的并且分布广泛群体。
同时它也应该能够处理频繁的密钥更新,以适应高度动态的成员群体。
●控制器的密钥数:
一般解决方案要求组控制器存储n+1键:
每个组成员的一对双密钥,再加上一个共享的组密钥。
其他的方案中,控制器储存更多的密钥来容纳更多高效的密钥管理算法。
●组成员的密钥数:
一般解决方案要求成员存储密钥的数量一直不变,但其带宽的需求是不可实现的。
后来我们提出了一个替代方案,即每个成员存储更多的密钥,但同时也实现更高的带宽效率。
●加入和离开保密:
在小组交流时,加入保密,确保新组的成员不能读取过去的消息,离开保密确保过去的组的成员不能读取当前或未来的消息。
在一般情况下,加入保密容易实现高效:
在有新成员加入时,组密钥可以及时更新。
新密钥和旧的组密钥一起加密后通过多播传送给该组。
一般的解决方案,保留加入保密和离开保密;然而,使用一般的解决方案维护离开保密,这就意味着在每一个成员离开该组时需要一个线性成本密钥更新。
一些替代解决方案并不总是通过在离开的时候更新密钥来提高密钥更新效率。
在一些应用中,这种行为是可行的。
总体上来说保证加入和离开保密是必要的。
●新成员加入时密钥更新的消息数:
在新成员加入时一般的解决方案更新组密钥需要使用n条消息:
每个小组成员一条信息。
一些替代方案在更新组密钥时利用多播在消息带宽一定的情况下。
而其他交易在加入时使用代价较高的密钥分配,用以提高密离开时的钥分配。
●离开时密钥更新的消息数:
当一个成员离开多播组,一般的解决方案使用n消息更新组密钥:
剩余的每个组成员一条消息。
我们提出的替代方案,使用多播消息组合、物理和虚拟群的成员、以及辅助密钥的层次结构组合。
通过这些做法来减少该组规模的次线性数量。
●密钥管理的处理时间:
一般的解决方案,当一个成员加入或离开该组,该组控制器必须生成新的密钥,然后加密和标记含有该密钥的n条信息。
替代方案,为了达到更好的加密处理性能,要一个更复杂的密钥管理结构为代价。
●防止共谋:
thenaivesolution,确保该多播组的非成员不能串通,打破多播组的加密方案。
然而,也有其他的密钥管理解决方案为了实现更有效的密钥管理牺牲了防止共谋的强度。
在一般情况下,这种做法在防止非成员之间的共谋上是可取的。
●可靠性要求:
天真的解决方案使用单播向组成员分发密钥。
因此,在其中一个成员错过了密钥的更新消息时,很容易及时发现和纠正的。
其他计划使用多播更有效地分发密钥更新消息,但是不可靠的IP多播(尽最大努力交付)。
因此如果要使用多播来分发密钥,必须采用可靠多播子系统。
●路由协议的可依赖性:
在这一点上,并不是所有互联网路由器支持IP多播,并存在着许多不同的多播路由协议。
就长远来说,目前还不清楚是否会出现作为互联网标准的多播协议。
因此,保持完全独立底层多播路由协议的组播安全基础设施是最可取。
然而,也存在这样的解决方案,依赖特定的多播基础设施。
在灵活性的成本上,这些解决方案往往能够比模块化系统取得更好的性能。
●特定应用的约束:
在这篇文章中工作重点在通用安全多播解决方案上;然而,重要的是要注意,有许多应用通用解决方案是不必要和低效的。
本文的大纲和范围
在本文的其余部分中,我们总结了安全多播中的一些重要研究,包括工作进程和原型系统。
我们集中于安全组播体系结构,组密钥管理,和数据包的源认证的研究。
我们的结论,包括对每个贡献的一个高层次的概述。
当然,我们鼓励有兴趣的读者咨询的原始来源以了解更多。
安全多播体系
路由包的固有复杂性到大量的,分布广泛的接受组成为设计安全多播的体系框架的动机。
Iolus
Iolus[5],是高层次的安全多播的基础设施.作为一个独立的组密钥管理服务是非常有用的。
它为多播应用程序的安全多播或安全模块提供服务。
我们将会首先描述Iolus的主要特点,然后分析其优点和缺点。
体系结构框架——Iolus将多播组按层次分成许多子组,每个子组有较少的组成员并拥有自己的多播组地址。
每个子组是相对独立的。
可以用一种称为安全分布树的结构来描述这种框架。
这个树由组安全代理(GSAs)构成,它是一种可信赖的实体,负责协调分组的路由并维护组的安全性。
在结点上的GSA称为组安全控制器(GSC),其它的GSAs称为组安全中(GSIs)。
GSI主要为子组提供两种服务:
●管理本子组的密钥;
●处理本子组和其它子组问的通信。
GSls和相应的子组可以分布在多个层次上,低层次的GSIs作为高层次GSIs的客户。
所有的这些GSAs和GSIs形成了整个多播组的一个映像。
图1是一个安全分布树的例子。
图1安全分布树
操作语义——本节提供了一个最重要的操作细节的Iolous高层次的概述,包括用于初始化组,添加和删除成员,并传送信息的算法。
●组的初始化和成员的加入:
严格地说,要启动安全多播组只需要先启动组中的GSC。
GSC拥有一张访问控制列表,通过它可以设置一些主机有权访问安全组。
一旦GSC启动起来,GSIs和其它成员就可以申请加入它的子组。
具体实现时可以将所有的GSls也启动起来,但这不是必需的;OSls也可以等到有成员申请加入时再启动。
要加入安全多播组,主机要定位一个GSA并通过安全单播通道向它发出加入请求。
在收到请求后,GSA检查信息库以判断是否接受请求。
假设接受了请求,GSA要执行以下操作:
首先生成一个密钥,它只在GSA和新成员之间共享。
然后将密钥以及其它一些和新成员有关的信息存储到数据库中。
最后通过安全单播通道将新生成的密钥送给新成员。
在这以后,GSA需要更新子组的密钥。
为此,GsA在子组中多播一条密钥更新信息,它包含新的密钥(用旧密钥加密),所有组中已有的成员都能够收到这条信息。
然后它通过安全单播通道将新的组密钥发送给新成员。
在执行以上这些操作之前,GSA本身必须是多播组的成员。
如果不是,那么它可以用类似的步骤加入父亲子组。
●成员的删除:
有两种情况会引发成员的删除,即成员自己提出离开请求或是GSA强制成员离开。
如果要删除的成员是子组中的最后一个,那么GSA与它的父GSA联系并将自己从安全分布树中删除。
如果组中还有其它成员,GSA必须产生新的子组密钥并通过单播将它发布给子组中剩余的成员。
更新操作附加的通信开销是子组大小的线性函数,与整个多播组的大小无关。
也可以使用多播来实现密钥更新,这需要将新的组密钥分别用每个单播密钥加密并封装在一条信息里。
这减少了更新所需发布的信息数,代价是增加了信息长度并需要可靠的多播传输支持。
●数据传输:
因为每个分组适用不同的密钥,在GSIs中负责传输数据从一个密钥到其它,并且选择合适的路由将其传送到其它的GSI。
如图2所示,如图2所示,如果在小组1的一个客户端发送消息到组,他需要为小组1将信息用子组密钥加密。
小组1所有的成员都知道这个密钥,包括GSI;然而,小组1外的任何人都不知道这个密钥。
为了将消息发送到其它小组,需要用GSI对消息进行解密,并为小组12创建新的密钥,然后将密钥发送到小组12的所有成员。
一旦收到消息,GSI将会对其解密,并对其重新加密,然后将密钥发送给小组2的所有成员。
图2Iolus中的数据传输
优点和缺点——Iolus方案主要有以下优点:
将组成员变化产生的影响限制在一个子组中,由于每个子组比较小,因此密钥更新的开销很低;实现了一定程度的分布式安全性,当GSI失效时,只会影响到它的子组成员,不会千扰其它组的成员;结构比较简单,运行效率高,可以扩展到大型和动态变化的多播组,并且支持多层次的安全控制。
Iolus方案的缺点也很明显:
管理多个子组需要额外的资源,当组很大,子组很多时,这种复杂的层次结构将降低系统性能,对于特定的应用程序,如果可以事先估计到组成员的数目和分布情况,那么通过合理的规划这种层次结构,能够减弱这种影响。
由于Internet本身就是由各种自治系统组成的,Iolus的内在结构符合这一特点,因此可以参考网络的拓扑结构来设计安全分布树。
虽然这种结构具有一定的分布式安全性。
但GSC却是整个系统的脆弱点,它的崩溃将导致整个系统失效,为了避免出现这种情况,可以在最高层引入多个GSC,各GSC间通过分布式协议进行协商,确定一个主GSC,主GSC执行一般操作,其它GSC充当后备。
当主GSC失效时,其它GSC重新协商产生新的主GSC。
新的主GSC通告其子GSI,更新地址信息。
这种方式通过增加冗余信息提高了系统的健壮性。
北电网络框架
我们解决第二个架构来自一对北电公布的Internet草案。
文献[6]指定一个高层次的的体系结构框架,没有讨论密钥管理的细节,和[7]介绍了可使用的架构内的一个特别的密钥管理解决方案,。
我们将会总结这两项草案。
高层次的体系结构框架——北电网络架构包含一个区域的两个层次结构。
在最高级别的主干区域,它是由许多叶片地区接壤。
每个叶区域有边界的密钥管理,这也是一个主干区域成员。
图3展示了这个设计。
每个叶区域的边境密钥管理为主干密钥参加密钥管理协议。
图3北电网络构架
主干密钥允许每个叶区域和消息转换的边界密钥管理,发送和接收消息和来自于其他叶区域。
主干密钥管理的细节是不确定的;然而,在实践中,主干密钥可以由一个集中式主干控制器进行管理或边界的密钥管理人员之间的谈判。
一个强大的主干密钥协商算法可以使这个架构非常强大,可以应付在任何边界的密钥管理器的故障。
在此我们不讨论主干层次更详细的内容。
在下一节中,我们讨论每个叶区域内的密钥管理基础设施。
叶区域密钥管理——我们前面提到的将多播组成员进行分组,当成员变化时可以将影响局部化。
这种体系结构的另一个好处是,它允许每个叶区域拥有自己的密钥管理技术。
在实践中,任何密钥管理方案可用在每个叶区域。
但是北电叶区域提出了具体的密钥管理基础设施,我们将会在这里对它进行描述。
每个叶的逻辑组成部分:
密钥管理器,一个或多个具有多播功能的路由器,一个密钥的翻译器,和一定数量的多播组成员。
在叶区域最高级别的密钥管理者是域密钥分配器(DKD)。
DKD为一系列区域密钥分配器(AKDs)管理密钥;每一个ADK作为多播组子集的密钥管理者。
这些多播组子集在叶区域。
DKD和AKDs的目的是进一步是组成员变动的影响局部化。
图4显示了一个leaf的逻辑结构。
图4一个leaf的逻辑结构
北电的叶级密钥管理方案的一个有趣的特点是,它由两个平面组成:
控制平面和数据平面。
在一片树叶,DKD和AKDs存储在控制平面。
DKD管理密钥称为All-KD-key,在叶之间共享DKD和所有的AKDs。
每个AKD管理区域组密钥。
这个密钥将会在组内和它所有的子集成员里共享。
但是这些密钥不用于加密应用数据。
整个叶的应用程序数据是在一个特殊的多播密钥(MKey)下加密的。
它是数据平面的一部分。
边境密钥管理转换应用程序数据和来自主干密钥和叶多播密钥之间的主干。
控制平面的目的是有效地分配多播密钥到叶中多播组的所有成员。
因此,随时随地在叶成员加入或离开多播组,所有组成员必须接受一个新的多播密钥。
这可能看起来代价很高,但因为成员变动只限于一个AKD区域,而在其他区域的AKDs可以通过多播的方式将多播密钥发送给组成。
他们可以在区组密钥下加密新的多播密钥。
在成员变动频繁的区域,其密钥管理语义也是相当复杂的。
假设每个区域的成员数量仍然相对较小,即使是在一个简单的密钥管理解决方案中,这样的成本也不是很高。
优点和缺点——北电的框架有类似于Iolus的地方:
在其层次结构最大限度地减少成员变动成本,并使它对结点故障有更加强大处理能力。
然而,与Iolus不同的是在其顶层(主干线)的地区可能是完全分布式的。
从而有可能比Iolus在处理高层次的结点故障上有更好的健壮性。
在其他大多数方面,这个框架与Iolus相比有相同的长处和短处。
SRM工具包——Changetal.已经建立了一个关于安全可靠多播(SRM)工具包的Java原型。
SRM是结合Iolus和北电网络框架的原理推导出来的。
总体结构——SRM的架构由以下几部分组成组成:
●目录服务器
●主控制器,类似于Iolus中的GSC
●一些区域控制器,类似于Iolus中的GSIs
●一个处理区域间数据包路由的反射器
●使用其他系统组件所提供的服务的客户端
该系统采用两个层次结构,类似北电的框架,将多播组分割成很多区域。
一个域控制器管理在域中客户端共享的密钥。
每个域也都有反射与域控制器相对应。
它从该组中的其他区域转换和发送路由数据包,,类似于Iolus中GSIs转换和发送路由数据包的方式。
在更高的层次,是一个顶级配置的服务器,也称为主控制器。
它用来管理域控制器。
目录服务器实现一组目录服务。
域控制器加入一个组播组时,它使用轻量目录访问协议(LDAP)来回答客户的查询。
因此,它必须有一个存储该组域控制器的数据库,以及可能加入客户的一个访问控制列表(ACL)。
主控制器与启动了的目录服务器联系,然后为该组和其他域控制器的地址列表下载ACL。
客户登记及取消登记——加入一个组,一个客户第一次接触的目录服务器并获得该组的域控制器的地址。
然后,客户端接触在一个安全的单播通道的域控制器,并验证自己。
如果认证成功,在域控制器更新域的共享密钥,并发送相应的消息域的新成员和现任成员。
删除客户端与添加一个客户端类似。
去除发生通过更新域的共享密钥和将相应的消息多播给区域中的客户。
我们稍后来讨论SRM密钥管理结构的细节。
优势和缺点——SRM构架的优缺点与北电网络构架有很多相似的地方。
它的两个层次的框架是简单,但比之于Iolus的多层结构,就缺少潜在的可扩展性。
此外,不同于北电的框架,它受到在主控制器中的单一故障点,与Iolus类似。
技术比较——表1总结了我们刚刚讨论过的三种框架的主要特点。
表1安全多播体系结构的比较
组密钥管理技术
前面的部分集中在组架构,但它也描述了一些为这些架构已提出的密钥管理方案。
在本节中,我们把注意力放在高效的多播组密钥管理算法和结构上。
我们将讨论的一些方案不是在所有情况下都适用,是在可靠多播的基础上。
然而,他们很有趣,可能证明是有用的,特别是子密钥管理。
我们首先从回顾一般的密钥管理方案开始展开讨论,然后我们将介绍基于逻辑的密钥层次和单向函数树的更加有效的策略。
最后,我们将提出一个方案,通过牺牲共谋灵敏度和加入/离开加密实现更好的效率。
一般密钥管理解决方案重谈
集中的组控制器在组间共享一个密钥。
在成员加入或离开时,控制器更新密钥通过单播通道将新密钥发送给每个成员。
每个客户端存储两个密钥(主一个与控制器共享的密钥和一个组密钥),控制器存储n+1个密钥(每个客户端的一个密钥,加上组密钥)。
这就是一般的密钥管理解决方案。
这个方案也有很多引人注目的积极特征。
首先,它实现起来是简单易行的。
其次,它的密钥存储容量是合理的如果我们假定组控制器工作在一台高效能的计算机上。
然后,这个方案保证了加入和离开的保密性,并且容忍组中非成员之间任意的共谋。
最后,这个方案不需要专业化、底层的基础设施就像可靠的多播通信。
然而,撇开这些优点,这个模型在组规模和组动态上有所欠缺。
网络负载和组控制器在加入或离开时的处理负荷,同组的大小成线性比例。
因此,除去它的一些理想特性,一般密钥解决方案在除了小规模组之外的大部分时候是不适用的。
基于树的密钥管理
现在我们介绍另外一种可供选择的密钥管理技术。
这种技术使用了更加复杂的底层构架和用以减少密钥更新开销的新增设想。
Wallner等人和Wong等人曾由实验总结,通过使用逻辑层次密钥加密密钥和可靠多播,所有密钥更新产生的通讯和计算的成本同组的大小成对数增长。
我们可以基于此管理组密钥。
Wong等人有各类密钥图表上进行了广泛的理论和实验分析;他们得出结论:
大部分高效的组密钥管理图表是一个k叉树。
Wallner等人使用二叉树以同样的方式描述了密钥管理结构。
在这一部分,我们将会描述和分析一个k叉树更一般的情况。
二叉树算法是适用更一般情况的简单的专业化模型。
基于树的密钥管理方案的工作过程如下:
一个多播组有n个成员,从M1到M2,以及一个集成的组控制器。
当一个成员要加入多播组时,它需要通过一个安全的单播通道与主控制器联系。
在新成员加入的同时,它和主控制器生成了一个成对的保密密钥。
主控制器存储一个k叉树结构,每个结点包含一个密钥。
在树的叶结点有n个秘密密钥。
主控制器通过此密钥与各个成员进行通信。
每个成员存储主控制器的密钥的子集。
成员j存储的密钥子集与叶结点j到根结点的路径上的所有密钥集合是一样的,包括叶结点j和根结点本身。
根结点存储组的共享密钥;树中其他所有的密钥都是辅助密钥,仅用于更高效的密钥更新。
主控制器共享密钥的总数约为:
kn-1/k-1,每个成员所存储的密钥总数为logkn。
图5说明了这棵树的k=3,n=9。
图5k=3、n=9的k元密钥管理树
现在我们讨论的是在一个成员离开或者加入时,密钥是怎样进行更新的。
在图5中,假设M9离开了该组。
当组成员发生改变的时候,除控制器和变动成员之间的共享密钥之外,必须更新已加入和已离开成员的所有已知密钥。
在这个例子中,我们必须更新Kc和Kroot。
我们可以使用现有的密钥层次以及可靠多播,高效地分配新的密钥。
首先,我们将发布一个新版本的Kc给那些需要的剩余成员。
我们在K7和K8下通过单播或者多播发送加密的Kc。
接着,我们将通过多播发送三次来发布一个新版本的Kroot,根据KA、KB和新版本的KC加密。
在这一点上,M9可以有效地排除任何未知的通信。
在新成员加入时更新密钥的语义都非常相似。
一般情况下,为一个K叉树更新密钥必须在树的logkn层,在每个层次中,我们必须发送K条密钥更新的消息。
因此,基于树的密钥更新算法可以使用klogkn条消息来完成密钥更新。
这个方案里有有几个需要注意重要的地方。
首先,它需要一个可靠的多播基础设施。
这种做法是必要的,因为如果组成员错过了密钥更新,他将不能够参加小组交流或解密未来的密钥更新消息。
第二,这个方案可以很好地从组的大小这方
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 通信 中的 安全性 问题 综述
![提示](https://static.bdocx.com/images/bang_tan.gif)