基于GDOI的特定源组播加密方案*

姜鹏博，王纲领，康 彬，郭 栋

（1.中国电子科技集团公司第三十研究所，四川 成都 610041；2.解放军96941部队，北京 100089）

0 引 言

近年来，随着通信技术的快速发展，出现了许多一对多或者多对多的应用，如多媒体远程教育、分布式系统、网络视频会议等。这些应用都具有一个明显的特征即在多个计算机终端之间进行交互式通信。如果采用传统的IP单播或广播技术，会给现有网络带来巨大的负担并造成网络带宽的极大浪费。针对该问题国际互联网工程任务组（The Internet Engineering Task Force，IETF）提出了IP组播通信模型，是一种全新的高效的网络传输技术。它是一种面向“组”的介于单播和广播通信之间的数据传送方式。IP组播技术能够有效地解决网络中广泛存在的一发多收问题。此外，该技术的使用能够极大地降低一对多应用在传输业务数据时的网络带宽和网络负载。单播、广播和组播通信模型比较如图1所示。

随着互联网技术的不断发展，如今IP组播技术已形成相对完备的协议体系。该协议体系主要包含组成员关系协议和组播路由协议，其中组成员关系协议为互联网组管理协议（Internet Group Management Protocol，IGMP），组播路由协议又分为域内组播路由协议和域间组播路由协议。域内组播路由协议包含稀疏模式独立组播协议（Protocol Independent Multicast-Sparse Mode，PIM-SM）、密集模式独立组播协议（Protocol Independent Multicast-Dense Mode，PIM-DM）、距离矢量组播路由选择协议（Distance Vector Multicast Routing Protocol，DVMRP）等。域间组播路由协议包括多协议边界网关协议（Multiprotocol Extension for BGP-4，MBGP）、组播源发现协议（Multicast Source Discovery Protocol，MSDP）等。随着组播应用的日趋多样化，标准的组播业务模型已不能满足组播应用的需要。大量新增的组播应用是组播源唯一而组播接收者数目不定且动态变化的，为此IETF提出了特定源组播（Source Specific Multicast，SSM）。

SSM采用一对多的业务通信模型，提出了组播通道这一新的概念。组播通道分为组播源S和组播组G。在SSM中只有组播源S可以发送组播业务数据，组播组G是SSM使用的组播组地址，组播路由器在转发组播数据时会用到组播通道。SSM是一种依据组播应用新特性，在标准组播业务模型基础上衍生出的新的组播通信模型，相比标准的组播业务模型SSM能提供更优的网络性能[1]。

1 SSM工作原理

SSM是一种指定组播源的组播通信方式。在标准组播通信模型任意源组播（Any Source Multicast，ASM）中，组播接收者不需要知道组播源是谁，组播源和组播接收者是通过组播汇聚点（Rendezous Point，RP）建立关联关系的。组播业务数据通过组播共享树（Rendezvous Point Trees， RPT）从组播源到达组播接收者。ASM是靠不同的组播地址来区分组播服务的，若多个提供不同组播业务的组播源误用同一个组播地址，则可能会导致组播接收者收到意料之外的组播业务数据。

SSM使用特定源组播独立组播协议（Protocol Independent Multicast-Source Specific Multicast，PIM-SSM）作为组播路由协议，PIM-SSM基于PIM-SM。与PIM-SM相比，它也需要建立最短路径树（Shortest Path Trees，SPT），但省略了RP选举、RP注册、RPT建立以及RPT向SPT切换等流程，从而极大地简化了工作流程。在SSM中，使用二元组（组播源地址S，组播组G）来唯一的标识一个特定的组播业务。在SSM中组播接收者在点播特定组播业务前，需要预先知道组播源地址和组播组地址，然后针对（S，G）进行点播。此时由于组播接收者已预先知道组播源信息，则SSM可直接建立SPT树。这样即使不同的组播源误使用了相同的组播组地址，组播接收者也不会收到意料之外的流量。

互联网数字分配机构（The Internet Assigned Numbers Authority，IANA）为SSM预留的组播地址范围为232.0.0.0/8。SSM的工作流程为：主机通过向与它直连的路由器发送IGMPv3报文来告知路由器它想要加入某个组播组；随后直连路由器直接向组播源发送SSM加入报文，沿途所有的路由器都会建立该（S，G）表项，从而建立最短路径树SPT；SPT建立后组播源就可以沿着SPT向组播接收者发送组播业务数据[1]。

综上所述，SSM具有如下特点：

（1）适用于一个组播组只有一个组播源的应用场景；

（2）不需要建立RPT，可直接生成SPT；

（3）组播源的发现过程不需要依靠MSDP（IPv6中没有MSDP）；

（4）简化了组播地址的分配。

2 组播安全问题

组播业务数据安全是组播安全的核心，而IPSec协议可以用来确保业务数据的机密性和完整性，数据源认证和抗重放性，是业务数据安全的理想解决方案。然而，IPSec是基于IP单播提出的端到端的安全解决方案，将IPSec应用到组播这种端到多端的场景时仍存在一些问题。

组播组成员的身份认证是组播安全的一个难题。在组播通信模型中，任何对组播流感兴趣的主机均可申请加入组播组，然而现实中对于机密性的组播数据流往往需要对组播组成员进行严格的访问控制以确保组成员的合法性，对于一般的组播数据流也需要防范来自恶意主机的攻击。如果对组播组成员实施访问控制，那么组播组成员的加入和离开时必须更新组播密钥，于是组播密钥更新以及密钥更新材料本身的安全性便成为组播密钥管理的主要内容[2]。

组播安全策略用于定义组播业务数据处理和组密钥管理的相关规则。针对不同安全级别的组播数据流需采取不同的安全机制，那么如何为这些组播数据流选取合理的安全机制是组播安全策略需要解决的主要问题。只有制定了合理的组播安全策略，多个组播业务实体之间的信息交互安全才能得到有力保障。

上述3个问题是组播安全需解决的主要问题。目前被广泛认可的组播安全解决方案是使用IPSec来保护组播数据安全，通过制定合理的组播密钥管理协议来管理组播密钥素材，并在以上两点的基础上研究组播安全策略。因此，制定和使用一个合理的组播密钥管理协议是实现安全组播的关键技术。

3 IPSec与GDOI

IPSec协议为IP及其上层协议和应用提供了一种安全透明的保护机制，它利用了加密、封装、认证、数字签名等技术，为它的上层协议和应用提供了基于密码学的安全性保护，主要包括访问控制、数据源认证、机密性、数据完整性、抗重放性等功能。目前，IPSec已成为端到端安全通信的首选协议[3]。

在单播通信中，利用IPSec机制就可以保障业务数据传输的机密性、完整性及抗重放性。由于IPSec可以有效保障单播通信安全，人们希望IPSec也可适用于组播。然而，由于IPSec协议使用互联网密钥交换协议（Internet Key Exchange，IKE）作为密钥协商协议，而IKE只是一个端到端的密钥交换协议，所以基于IKE的IPSec只能用于端到端的数据加密[4]。而组播是一个点到多点通信方式，且组播成员加入组播组和离开组播组是动态的，这就要求密钥交换协议在保留IKE的密钥特点的同时，还需做到两点：密钥的前向安全和后向安全以及密钥的动态分配和更新。因此不能简单地将已有的IKE协议用于组播密钥交换。为了使IPSec的安全特性能适用于组播，IETF制定了IPSec安全组播管理协议GDOI。

要实现组播通信安全，密钥管理是一个需要解决的关键问题。密钥自动分发是必需的，考虑到扩展性，手工分发密钥在现实中是不可行的。同时密钥分发机制必须是安全的，以防未授权用户获得组密钥。

GDOI协议中定义了一种新的安全关联组安全 关 联 （Group Security Association，GSA），GSA主要用于为组播组成员从组控制器和密钥服务器（Group Controller and Key Server，GCKS）下载和更新密钥提供安全保护，同时能够为组成员之间发送和接收组播业务数据提供IPSec加密保护。

3.1 组密钥管理结构

在RFC4046中定义了组密钥管理结构，如图2所示。它由3种实体组成：组播发送方IPSec VPN、组播接收方IPSec VPN、GCKS。GCKS负责密钥分发和SA管理。为了组播源和组播接收者间的通信需要3个协议。

（1）注册协议。通过这个单播协议，发送者或接受者的一个IPSec VPN要加入组，向GCKS认证。在认证之后，如果这个要加入的成员是经过授权的，那么它就可以得到数据安全关联（Security Association，SA）和密钥更新SA。数据SA用于保护数据安全；密钥更新SA在策略要求它的时候，用来保护密钥更新信息。由于这些信息必须以安全的方式传输，因此通过注册SA来保障这些信息的安全传输。

（2）密钥更新协议。通过使用在注册协议中得到的密钥更新SA，这个协议周期性的对数据SA进行更新。与密钥更新SA有关的是密钥加密密钥（Key Encrypting Keys，KEK），它被用来保护数据SA的更新信息。

（3）数据安全协议。这个协议使用数据SA来对组成员间的通信进行加密。这个协议可以是IPSec，当然也可以是其他的协议，如SRTP。与数据安全SA相关的TEK，用来保护组成员间的通信[5]。

3.2 GDOI原理

前文已经对GDOI进行了简要的介绍，本节将对它的基本原理进行说明。

如图3所示，第一类SA是注册SA，第二类SA是密钥更新SA，第三类SA是数据安全SA。

GDOI的工作流程为以下两个步骤。

（1）一个组成员和GCKS取得联系，两者共同协商一个安全通道。通过这个通道以一种安全的方式交换信息，这就是GDOI的阶段1。这个安全通道是上图的第1类SA，即注册SA。任何可以提供对端认证、保密性和完整性的方法都可以用来协商该安全通道，不过最常使用和推荐使用的是IKE。

（2）使用阶段1得到的安全通道，组成员从GCKS上下载与组通信相关的SA和密钥。这个PULL交换属于阶段2。在这次交换中，组成员获得数据安全SA及数据安全SA需要用到的TEK。同时还可以获得密钥更新SA，GCKS用它来个给发送到所有组成员的控制信息进行保护。最后一步是阶段2的PUSH交换。在这个阶段，GCKS发送包含新的TEK的密钥更新消息到所有的组成员。GCKS通过某种动态密钥更新机制，如LKH，可以周期性或动态地发送密钥更新消息。这些消息通过KEK进行加密[6]。

4 基于GDOI的SSM组播加密方案

采用组密钥管理结构对组播通信进行加密保护时，与传统的单播加密保护的差异主要是需要在网络中部署一个GCKS，且网络中的所有IPSec VPN需支持GDOI协议。若想在一个已经具备单播IPSec加密保护手段的网络中新增组播加密保护功能，虽然GDOI协议的支持在软件层面的工作相对容易实现，但在现有网络中部署GCKS，通常会遇到一些困难，如部署的网络位置选择，可能需要更改现有网络拓扑等。

特定源组播中仅有一个数据发送源，为一种典型的单向通信模型，即组播业务数据都是由组播源流向多个组播接收终端，结合使用GDOI协议需要部署一个独立的GCKS，提出一种由组播源IPSec VPN替代GCKS角色的SSM组播加密方案。

4.1 SSM组播加密场景

如图4所示的SSM组播应用场景中，存在一个组播源和两个组播接收方，IPSec VPN部署在组播源和路由交换设备之间，用于保护组播源和组播接收方之间的组播业务数据安全。

4.2 SSM组播加密密钥协商工作原理

SSM组播加密密钥协商流程如图5所示。

具体工作流程如下：

（1）组播源IPSec VPN和组播接收IPSec VPN进行IKE阶段1交互；

（2）组播接收IPSec VPN向组播源IPSec VPN提供组播地址；

（3）组播源IPSec VPN根据组播地址提供安全关联策略；

（4）组播接收方IPSec VPN对收到的安全关联进行确认；

（5）组播源IPSec VPN向组播接收方IPSec VPN提供密码资源（TEK和KEK）。

通过上述流程，组播接收方IPSec VPN将组播源IPSec VPN的安全管理策略和密码资源“拉”到本地。组播接收方IPSec VPN获取到安全关联和密钥后，组播源和组播接收方之间的业务数据在组播源IPSec VPN进行加密，在组播接收方IPSec VPN进行解密，从而实现了对组播源和接收方之间的数据加密保护[7]。

组播源IPSec VPN检测到密钥即将过期时，会向组播接收方IPSec VPN主动推送密钥更新消息，该消息受到Rekey SA的加密保护。若组播接收方IPSec VPN在密钥超期前仍未收到组播源IPSec VPN的密钥更新消息，则组播接收方IPSec VPN会重新向组播源IPSec VPN发起一次注册，将安全关联和密钥“拉”回来。

4.3 协议交互细节

SSM组播加密密钥协商协议参与方为组播源IPSec VPN和组播接收方IPSec VPN，具体交互过程分为两个阶段：阶段1和阶段2。其中阶段1和IKE协议的阶段1类似。

阶段1的目的是保护阶段2的协议交互过程，阶段2的目的是在组播接收方IPSec VPN为特定的组播组建立密钥更新SA和（或）数据安全SA。图6对阶段2中消息交换进行了详细介绍。

如图6所示，[]中的内容是可选的。对于PULL交换，“*”表示该交换受到阶段1生成的SA的保护，对HDR后面的内容加密；对于PUSH交换，“*”表示用KEK加密HDR后面的内容。

符号说明如下所述。

（1）HDR是ISAKMP报头，当写成HDR*，表示载荷被加密。

（2）Ni和Nr分别是组播接收方IPSec VPN和组播源IPSec VPN的当前时间Nonce载荷。

（3）ID）是组播业务使用的组播地址。

（4）SA包含了密钥更新SA和数据传输SA，具体描述了 KEK（Key Encrypting Keys）和TEK（Traffic Encrypting Keys）加密材料、认证转码和SPI，但是它不包含密钥（KEK和TEK）。

（5）KE_I和KE_R时用于Diffie-Hellman交换的公共信息的密钥交换载。

（6）CERT是证书载荷，用来向对方标识自己的身份。

（7）POP 载荷，POP=hash(“pop” | Ni | Nr)。

（8）SEQ载荷包含了一个从0开始单向递增的4 Byte的数字。

（9）KD载荷包含了组播接收方IPSec VPN从组播源接收方IPSec VPN“拉”到的密钥（包含KEK和TEK）。

（10）各个HASH载荷计算方式：

HASH(1) = prf(SKEYID_a, M-ID | Ni | ID)

HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA)

HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ |KE_I ][ | CERT ][ | POP_I ])

HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ |KE_R ][ | SEQ | ]KD [ | CERT ][ | POP_R])。

式中：SKEYID-a是IKE阶段1生成的用来为GROUPKEY-PULL消息提供数据完整性和数据源身份认证密钥的密钥。

协议交互流程如下文所述。

（1）第1条消息。除了头部和HASH载荷外，它还包含一个随机数Ni和一个ISAKMP ID载荷用来标识它希望加入的组，由组播接收方IPSec VPN发送。

（2）第2条消息。在对HASH 载荷进行校验以后，组播源IPSec VPN通过发送一个包含随机数Nr和SA载荷（包含SA的细节，如源地址、目的地址、生命周期，但不包含通信密钥）的响应消息。

（3）第3条消息。组播接收方IPSec VPN对HASH载荷进行校验，并查看SA载荷包含的参数是否自己可得。然后发送第3条消息，该消息包含KE载荷、CERT载荷和/或POP载荷。如果使用证书来进行认证时，CERT和POP载荷都会用到。在这种情况下，CERT载荷包含发起者的公钥，而POP载荷包含用经发起者私钥处理的Ni和Nr。KE载荷是可选的，它包含一个Diffie-Hellman 密钥，组播源IPSec VPN使用它来和KD载荷进行异或处理。这样做的目的是保证前向加密安全。

（4）第4条消息。组播源IPSec VPN对HASH载荷进行校验，若使用证书认证，还需要对POP载荷中的签名进行校验。然后组播源IPSec VPN生成第4条消息。这条消息包含KD载荷（包含与最后一步中提到的SA相关的密钥）、CERT载荷和POP载荷。此外，如果GCKS发送密钥更新报文，SEQ载荷可以提供密钥更新报文的抗重传保护。发起者对第4条消息进行验证，得到SA的密钥[6]。

在这些步骤完成后，协议双方进入阶段2的PUSH交换。在这个交换中，组播源IPSec VPN发送密钥更新消息到所有的组播接收方IPSec VPN，这些密钥更新消息包含有新的数据安全SA的密钥（新的TEK）。这些消息是通过KEK来保护的。一个PUSH交换信息包含SEQ载荷（提供抗重传保护）、SA载荷（包含SA的策略）、KD 载荷（包含和SA相关的密钥）、SIG载荷（包含GCKS的签名）和CERT载荷（可选的，用来对SIG载荷进行检验）。

4.4 前向安全和后向安全

离开组播组的组播接收方不能再获得将来这个组的通信数据，称之为前向安全；新加入组播组的组播接收方不能获得过去这个组的通信数据，称之为后向安全。前向安全和后向安全是组播安全需要考虑的两个重要因素。

对于前向安全，当组播源IPSec VPN发现有新的组播接收方IPSec VPN向其注册时，会发起密钥更新，同时通过组播的方式将更新后的密钥发送给当前所有组播接收方IPSec VPN。

对于后向安全，组播源IPSec VPN会定期向组播接收方IPSec VPN发送组播心跳报文，组播接收方IPSec VPN收到该报文后，用单播的方式进行响应。当组播源IPSec VPN多次未收到某接收方IPSec VPN的心跳响应后，则判定该接收方IPSec VPN已离线，随后发起密钥更新，同时通过组播的方式将更新后的密钥发送给当前所有组播接收方IPSec VPN。

5 结 语

本文提出了一种SSM组播加密方案，通过GDOI协议和IPSec协议的结合使用，能够在不增加安全基础设施的情况下有效的解决SSM组播发送方和组播接收方之间的业务数据传输的机密性和完整性问题，同时当组播接收方动态变化时，能够保障组播业务数据的前向安全和后向安全。相比传统的必须部署GCKS以支持组播密钥管理的方式，该方案使用SSM中的组播发送方IPSec VPN替代GCKS，可以使网络管理人员通过较低的代价实现SSM组播业务安全。