多播通信中的安全性问题综述

上传人:jiups****uk12 文档编号:90656173 上传时间:2019-06-14 格式:DOCX 页数:20 大小:853.27KB
返回 下载 相关 举报
多播通信中的安全性问题综述_第1页
第1页 / 共20页
多播通信中的安全性问题综述_第2页
第2页 / 共20页
多播通信中的安全性问题综述_第3页
第3页 / 共20页
多播通信中的安全性问题综述_第4页
第4页 / 共20页
多播通信中的安全性问题综述_第5页
第5页 / 共20页
点击查看更多>>
资源描述

《多播通信中的安全性问题综述》由会员分享,可在线阅读,更多相关《多播通信中的安全性问题综述(20页珍藏版)》请在金锄头文库上搜索。

1、多播通信中的安全性问题综述Matthew J. Moyer,Georgia Institute of TechnologyJosyula R. Rao and Pankaj Rohatgi,IBM Thomas J. Wotson Research Center摘要万维网的出现和集团化应用的普及已经引发了组通信的可扩展的安全解决方案的需求。这样一个解决方案,安全多播吸引力,因为它利用组播数据传递的高效率。然而,它也提出了几个研究挑战,最引人注目的是一组通信的体系结构,组密钥管理,消息源认证。在本次调查中,我们讨论这些问题,并验证对它们提出的解决方案。最近万维网迅速发展已经引起了新的研究。互联网

2、组通信的新型类型广泛地应用于各个方面,就像多方视频会议和实时的基于“push”技术 “push”技术:所谓的PUSH技术是一种基于客户服务器机制,由服务器主动的将信息发往客户端的技术。的信息传递系统(如股票报价服务等)。这些应用需要多播,以尽量减少它们所产生的网络通信量。从理论上讲,启用组播的路由器的每个数据包发送多播通道和路由到每一个接收器。而接收器用以监听该通道。发送或接收数据在同一个特定的多播通道的所有主机,构成了多播组。多播比单播的主要优势在于,它允许发送方发送每个数据包只有一次;路由器自动转发数据包到每个需要它的接收器,同时最大限度地减少穿越网络的数据包的副本数量。传统的机制,用于支

3、持多播通信是IP多播。在IPv4中,D类地址(范围从224.0.0.0到239.255.255.255)是为多播通信预留的地址。此外,参加启用多播的主机和路由器必须提供Internet组管理协议(IGMP)1用以管理组成员身份信息,并且启用多播的路由器也参与一个或多个多播路由协议2。目前,IP多播是只能通过UDP访问。呼吁任何主机发送一个UDP包到多播地址,和底层的多播路由机制将所有已明确加入该多播组的受助人提供的数据包和时间到该数据包的生存期(TTL)的范围内。多播有潜力成为非常价值的网络服务,但是它也存在许多问题。这些问题出于发送给大量接收器的路由数据包的固有复杂性。特别是,保证可靠性(及

4、时,有序地将每个数据包传递到每一个组接收)和安全(概念,只有一个多播组的注册会员可以数据包发送到组或接收数据包发送到该组)是非常困难的。这些问题都包含了许多具有挑战性的研究课题。在这篇文章中,我们解释了多播安全的主要研究的挑战和突出在这一领域已作出的重要贡献。下一节将介绍很难研究的问题安全多播的现状。然后,我们提出了安全多播的体系结构和密钥管理的设计解决方案。接着,在三个部分,我们将介绍一些目前一些重大问题最好的解决方案。我们讨论了一些相关的工作,最后一节总结全文。多播安全问题组播安全基础设施的目标很简单:保留所有组通信的身份验证和保密性,因此,只有注册发件人可以发送数据包到组,只有注册的接收

5、器可以读取发送到该组的数据包。在互联网中,由于缺乏在Internet网络层访问控制权利,执行一个多播组的消息保密要求数据加密。这就需要一个组密钥管理方案加密密钥分配和维护注册组的成员。同样,密码认证方案是必要的,以确保注册的接收器可以验证收到来自于注册发件人的报文。安全组通信的大多数研究都集中在安全组和组密钥管理问题的体系结构,然而,最近的研究还集中于高效分组认证。本文概括地介绍了所有这三个领域。密钥管理的设计解决方案我们首先通过介绍一个简单的组密钥管理的解决方案,检查其弱点,并列出了一系列与其它方案比较之后的标准,讨论在密钥管理方面的相关问题。本地组密钥管理的不足本机的组密钥管理问题的解决方

6、案很简单。我们建立一个集中的组控制器,负责管理该组的密钥。控制器将组密钥通过一个安全的单播传送到每个组独立的成员。分发到每一组的密钥要求与沟通成本与组成员的数量呈线性关系。这种解决方案的简单是极具吸引力的的。然而,由于两方面的原因,它的低效率使大部分的多播应用稍显不足。首先,我们必须分配新组密钥每当有一方加入或离开了团队。为了保护过去信息的保密性和完整性,本组必须改变其密钥每当一个新的成员加入时。此外,为了保障未来信息的保密性和完整性,本组必须改变其密钥在每次当前成员离开时。唯一可以知道当前密钥的人士是那些目前在参与小组交流。对于具有高度动态成员的大型多播组,在每一个成员加入或离开的时候执行线

7、性成本的密钥更新是不可行的。因此,我们需要密钥管理解决方案,即被一个密钥更新的次线性消息成本。其次,多种多样的系统和网络问题,很难始终如一地使路线包从一个单一来源及时地到一个分布广泛的接收器组。第一个潜在的危险是失败的组控制器结点,对于任何采用集中式解决方案的组,这是致命的。可能出现的第二个问题是网络故障。如果有一个高流量负载或分区在位于网络某处,一些成员可能会收到密钥更新比别人更迅速,也可能完全错过密钥更新。这不仅抑制一个合法组成员之间的安全通信,而且还造成潜在的安全漏洞。并非所有现任成员使用相同的密钥,这样的事实可能会被以前的小组成员所利用。恶意的一方可以使用过时的密钥向组发送非法的消息加

8、密,或发送合法邮件到该组下的过时的密钥可以哄到当前的一些成员。显然,一个集中密钥管理解决方案是不可靠的设计。系统和网络经常变慢或者崩溃,我们需要一个架构,可以有效一个处理这些现实情况。密钥管理解决方案的评估标准基于以上的论述,我们展示和评估了一个安全多播组的组密钥管理的替代解决方案。在我们讨论每一个解决方案之前,我们也提出了一个有益研究和比较不同解决方案的标准列表,检查标准比较不同的方案。每一个标准都列出并给予简要介绍:l 系统架构:一个理想的系统面对网络和系统故障可能会降低性能,但不应该完全失败。各种分层和分布式体系结构可以提供这个级别的可用性,集中解决方案(尤其是简单的解决方案)不能。l

9、故障恢复:一个精心设计的系统不仅要经受住各种结点和网络故障,同时也能从大多数系统故障中恢复,而无需重新初始化整个组。l 可扩展性:解决方案应扩展到系统能够处理非常大的并且分布广泛群体。同时它也应该能够处理频繁的密钥更新,以适应高度动态的成员群体。l 控制器的密钥数:一般解决方案要求组控制器存储n + 1键:每个组成员的一对双密钥,再加上一个共享的组密钥。其他的方案中,控制器储存更多的密钥来容纳更多高效的密钥管理算法。l 组成员的密钥数:一般解决方案要求成员存储密钥的数量一直不变,但其带宽的需求是不可实现的。后来我们提出了一个替代方案,即每个成员存储更多的密钥,但同时也实现更高的带宽效率。l 加

10、入和离开保密:在小组交流时,加入保密,确保新组的成员不能读取过去的消息,离开保密确保过去的组的成员不能读取当前或未来的消息。在一般情况下,加入保密容易实现高效:在有新成员加入时,组密钥可以及时更新。新密钥和旧的组密钥一起加密后通过多播传送给该组。一般的解决方案,保留加入保密和离开保密;然而,使用一般的解决方案维护离开保密,这就意味着在每一个成员离开该组时需要一个线性成本密钥更新。一些替代解决方案并不总是通过在离开的时候更新密钥来提高密钥更新效率。在一些应用中,这种行为是可行的。总体上来说保证加入和离开保密是必要的。l 新成员加入时密钥更新的消息数:在新成员加入时一般的解决方案更新组密钥需要使用

11、n条消息:每个小组成员一条信息。一些替代方案在更新组密钥时利用多播在消息带宽一定的情况下。而其他交易在加入时使用代价较高的密钥分配,用以提高密离开时的钥分配。l 离开时密钥更新的消息数:当一个成员离开多播组,一般的解决方案使用n消息更新组密钥:剩余的每个组成员一条消息。我们提出的替代方案,使用多播消息组合、物理和虚拟群的成员、以及辅助密钥的层次结构组合。通过这些做法来减少该组规模的次线性数量。l 密钥管理的处理时间:一般的解决方案,当一个成员加入或离开该组,该组控制器必须生成新的密钥,然后加密和标记含有该密钥的n条信息。替代方案,为了达到更好的加密处理性能,要一个更复杂的密钥管理结构为代价。l

12、 防止共谋:the naive solution,确保该多播组的非成员不能串通,打破多播组的加密方案。然而,也有其他的密钥管理解决方案为了实现更有效的密钥管理牺牲了防止共谋的强度。在一般情况下,这种做法在防止非成员之间的共谋上是可取的。l 可靠性要求:天真的解决方案使用单播向组成员分发密钥。因此,在其中一个成员错过了密钥的更新消息时,很容易及时发现和纠正的。其他计划使用多播更有效地分发密钥更新消息,但是不可靠的IP多播(尽最大努力交付)。因此如果要使用多播来分发密钥,必须采用可靠多播子系统。l 路由协议的可依赖性: 在这一点上,并不是所有互联网路由器支持IP多播,并存在着许多不同的多播路由协议

13、。就长远来说,目前还不清楚是否会出现作为互联网标准的多播协议。因此,保持完全独立底层多播路由协议的组播安全基础设施是最可取。然而,也存在这样的解决方案,依赖特定的多播基础设施。在灵活性的成本上,这些解决方案往往能够比模块化系统取得更好的性能。l 特定应用的约束:在这篇文章中工作重点在通用安全多播解决方案上;然而,重要的是要注意,有许多应用通用解决方案是不必要和低效的。本文的大纲和范围在本文的其余部分中,我们总结了安全多播中的一些重要研究,包括工作进程和原型系统。我们集中于安全组播体系结构,组密钥管理,和数据包的源认证的研究。我们的结论,包括对每个贡献的一个高层次的概述。当然,我们鼓励有兴趣的读

14、者咨询的原始来源以了解更多。安全多播体系路由包的固有复杂性到大量的,分布广泛的接受组成为设计安全多播的体系框架的动机。IolusIolus5,是高层次的安全多播的基础设施.作为一个独立的组密钥管理服务是非常有用的。它为多播应用程序的安全多播或安全模块提供服务。我们将会首先描述Iolus的主要特点,然后分析其优点和缺点。体系结构框架Iolus将多播组按层次分成许多子组,每个子组有较少的组成员并拥有自己的多播组地址。每个子组是相对独立的。可以用一种称为安全分布树的结构来描述这种框架。这个树由组安全代理(GSAs)构成,它是一种可信赖的实体,负责协调分组的路由并维护组的安全性。在结点上的GSA称为组

15、安全控制器(GSC),其它的GSAs称为组安全中(GSIs)。GSI主要为子组提供两种服务:l 管理本子组的密钥;l 处理本子组和其它子组问的通信。GSls和相应的子组可以分布在多个层次上,低层次的GSIs作为高层次GSIs的客户。所有的这些GSAs和GSIs形成了整个多播组的一个映像。图1是一个安全分布树的例子。图1 安全分布树操作语义本节提供了一个最重要的操作细节的Iolous高层次的概述,包括用于初始化组,添加和删除成员,并传送信息的算法。l 组的初始化和成员的加入:严格地说,要启动安全多播组只需要先启动组中的GSC。GSC拥有一张访问控制列表,通过它可以设置一些主机有权访问安全组。一旦

16、GSC启动起来,GSIs和其它成员就可以申请加入它的子组。具体实现时可以将所有的GSls也启动起来,但这不是必需的;OSls也可以等到有成员申请加入时再启动。要加入安全多播组,主机要定位一个GSA并通过安全单播通道向它发出加入请求。在收到请求后,GSA检查信息库以判断是否接受请求。假设接受了请求,GSA要执行以下操作:首先生成一个密钥,它只在GSA和新成员之间共享。然后将密钥以及其它一些和新成员有关的信息存储到数据库中。最后通过安全单播通道将新生成的密钥送给新成员。在这以后,GSA需要更新子组的密钥。为此,GsA在子组中多播一条密钥更新信息,它包含新的密钥(用旧密钥加密),所有组中已有的成员都能够收到这条信息。然后它通过安全单播通道将新的组密钥发送给新成员。在执行以上这些操作之前,GSA本身必须

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 中学教育 > 其它中学文档

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号