姜鵬博，王綱領(lǐng)，康 彬，郭 棟

（1.中國(guó)電子科技集團(tuán)公司第三十研究所，四川 成都 610041；2.解放軍96941部隊(duì)，北京 100089）

0 引 言

近年來，隨著通信技術(shù)的快速發(fā)展，出現(xiàn)了許多一對(duì)多或者多對(duì)多的應(yīng)用，如多媒體遠(yuǎn)程教育、分布式系統(tǒng)、網(wǎng)絡(luò)視頻會(huì)議等。這些應(yīng)用都具有一個(gè)明顯的特征即在多個(gè)計(jì)算機(jī)終端之間進(jìn)行交互式通信。如果采用傳統(tǒng)的IP單播或廣播技術(shù)，會(huì)給現(xiàn)有網(wǎng)絡(luò)帶來巨大的負(fù)擔(dān)并造成網(wǎng)絡(luò)帶寬的極大浪費(fèi)。針對(duì)該問題國(guó)際互聯(lián)網(wǎng)工程任務(wù)組（The Internet Engineering Task Force，IETF）提出了IP組播通信模型，是一種全新的高效的網(wǎng)絡(luò)傳輸技術(shù)。它是一種面向“組”的介于單播和廣播通信之間的數(shù)據(jù)傳送方式。IP組播技術(shù)能夠有效地解決網(wǎng)絡(luò)中廣泛存在的一發(fā)多收問題。此外，該技術(shù)的使用能夠極大地降低一對(duì)多應(yīng)用在傳輸業(yè)務(wù)數(shù)據(jù)時(shí)的網(wǎng)絡(luò)帶寬和網(wǎng)絡(luò)負(fù)載。單播、廣播和組播通信模型比較如圖1所示。

隨著互聯(lián)網(wǎng)技術(shù)的不斷發(fā)展，如今IP組播技術(shù)已形成相對(duì)完備的協(xié)議體系。該協(xié)議體系主要包含組成員關(guān)系協(xié)議和組播路由協(xié)議，其中組成員關(guān)系協(xié)議為互聯(lián)網(wǎng)組管理協(xié)議（Internet Group Management Protocol，IGMP），組播路由協(xié)議又分為域內(nèi)組播路由協(xié)議和域間組播路由協(xié)議。域內(nèi)組播路由協(xié)議包含稀疏模式獨(dú)立組播協(xié)議（Protocol Independent Multicast-Sparse Mode，PIM-SM）、密集模式獨(dú)立組播協(xié)議（Protocol Independent Multicast-Dense Mode，PIM-DM）、距離矢量組播路由選擇協(xié)議（Distance Vector Multicast Routing Protocol，DVMRP）等。域間組播路由協(xié)議包括多協(xié)議邊界網(wǎng)關(guān)協(xié)議（Multiprotocol Extension for BGP-4，MBGP）、組播源發(fā)現(xiàn)協(xié)議（Multicast Source Discovery Protocol，MSDP）等。隨著組播應(yīng)用的日趨多樣化，標(biāo)準(zhǔn)的組播業(yè)務(wù)模型已不能滿足組播應(yīng)用的需要。大量新增的組播應(yīng)用是組播源唯一而組播接收者數(shù)目不定且動(dòng)態(tài)變化的，為此IETF提出了特定源組播（Source Specific Multicast，SSM）。

SSM采用一對(duì)多的業(yè)務(wù)通信模型，提出了組播通道這一新的概念。組播通道分為組播源S和組播組G。在SSM中只有組播源S可以發(fā)送組播業(yè)務(wù)數(shù)據(jù)，組播組G是SSM使用的組播組地址，組播路由器在轉(zhuǎn)發(fā)組播數(shù)據(jù)時(shí)會(huì)用到組播通道。SSM是一種依據(jù)組播應(yīng)用新特性，在標(biāo)準(zhǔn)組播業(yè)務(wù)模型基礎(chǔ)上衍生出的新的組播通信模型，相比標(biāo)準(zhǔn)的組播業(yè)務(wù)模型SSM能提供更優(yōu)的網(wǎng)絡(luò)性能[1]。

1 SSM工作原理

SSM是一種指定組播源的組播通信方式。在標(biāo)準(zhǔn)組播通信模型任意源組播（Any Source Multicast，ASM）中，組播接收者不需要知道組播源是誰，組播源和組播接收者是通過組播匯聚點(diǎn)（Rendezous Point，RP）建立關(guān)聯(lián)關(guān)系的。組播業(yè)務(wù)數(shù)據(jù)通過組播共享樹（Rendezvous Point Trees， RPT）從組播源到達(dá)組播接收者。ASM是靠不同的組播地址來區(qū)分組播服務(wù)的，若多個(gè)提供不同組播業(yè)務(wù)的組播源誤用同一個(gè)組播地址，則可能會(huì)導(dǎo)致組播接收者收到意料之外的組播業(yè)務(wù)數(shù)據(jù)。

SSM使用特定源組播獨(dú)立組播協(xié)議（Protocol Independent Multicast-Source Specific Multicast，PIM-SSM）作為組播路由協(xié)議，PIM-SSM基于PIM-SM。與PIM-SM相比，它也需要建立最短路徑樹（Shortest Path Trees，SPT），但省略了RP選舉、RP注冊(cè)、RPT建立以及RPT向SPT切換等流程，從而極大地簡(jiǎn)化了工作流程。在SSM中，使用二元組（組播源地址S，組播組G）來唯一的標(biāo)識(shí)一個(gè)特定的組播業(yè)務(wù)。在SSM中組播接收者在點(diǎn)播特定組播業(yè)務(wù)前，需要預(yù)先知道組播源地址和組播組地址，然后針對(duì)（S，G）進(jìn)行點(diǎn)播。此時(shí)由于組播接收者已預(yù)先知道組播源信息，則SSM可直接建立SPT樹。這樣即使不同的組播源誤使用了相同的組播組地址，組播接收者也不會(huì)收到意料之外的流量。

互聯(lián)網(wǎng)數(shù)字分配機(jī)構(gòu)（The Internet Assigned Numbers Authority，IANA）為SSM預(yù)留的組播地址范圍為232.0.0.0/8。SSM的工作流程為：主機(jī)通過向與它直連的路由器發(fā)送IGMPv3報(bào)文來告知路由器它想要加入某個(gè)組播組；隨后直連路由器直接向組播源發(fā)送SSM加入報(bào)文，沿途所有的路由器都會(huì)建立該（S，G）表項(xiàng)，從而建立最短路徑樹SPT；SPT建立后組播源就可以沿著SPT向組播接收者發(fā)送組播業(yè)務(wù)數(shù)據(jù)[1]。

綜上所述，SSM具有如下特點(diǎn)：

（1）適用于一個(gè)組播組只有一個(gè)組播源的應(yīng)用場(chǎng)景；

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

（3）組播源的發(fā)現(xiàn)過程不需要依靠MSDP（IPv6中沒有MSDP）；

（4）簡(jiǎn)化了組播地址的分配。

2 組播安全問題

組播業(yè)務(wù)數(shù)據(jù)安全是組播安全的核心，而IPSec協(xié)議可以用來確保業(yè)務(wù)數(shù)據(jù)的機(jī)密性和完整性，數(shù)據(jù)源認(rèn)證和抗重放性，是業(yè)務(wù)數(shù)據(jù)安全的理想解決方案。然而，IPSec是基于IP單播提出的端到端的安全解決方案，將IPSec應(yīng)用到組播這種端到多端的場(chǎng)景時(shí)仍存在一些問題。

組播組成員的身份認(rèn)證是組播安全的一個(gè)難題。在組播通信模型中，任何對(duì)組播流感興趣的主機(jī)均可申請(qǐng)加入組播組，然而現(xiàn)實(shí)中對(duì)于機(jī)密性的組播數(shù)據(jù)流往往需要對(duì)組播組成員進(jìn)行嚴(yán)格的訪問控制以確保組成員的合法性，對(duì)于一般的組播數(shù)據(jù)流也需要防范來自惡意主機(jī)的攻擊。如果對(duì)組播組成員實(shí)施訪問控制，那么組播組成員的加入和離開時(shí)必須更新組播密鑰，于是組播密鑰更新以及密鑰更新材料本身的安全性便成為組播密鑰管理的主要內(nèi)容[2]。

組播安全策略用于定義組播業(yè)務(wù)數(shù)據(jù)處理和組密鑰管理的相關(guān)規(guī)則。針對(duì)不同安全級(jí)別的組播數(shù)據(jù)流需采取不同的安全機(jī)制，那么如何為這些組播數(shù)據(jù)流選取合理的安全機(jī)制是組播安全策略需要解決的主要問題。只有制定了合理的組播安全策略，多個(gè)組播業(yè)務(wù)實(shí)體之間的信息交互安全才能得到有力保障。

上述3個(gè)問題是組播安全需解決的主要問題。目前被廣泛認(rèn)可的組播安全解決方案是使用IPSec來保護(hù)組播數(shù)據(jù)安全，通過制定合理的組播密鑰管理協(xié)議來管理組播密鑰素材，并在以上兩點(diǎn)的基礎(chǔ)上研究組播安全策略。因此，制定和使用一個(gè)合理的組播密鑰管理協(xié)議是實(shí)現(xiàn)安全組播的關(guān)鍵技術(shù)。

3 IPSec與GDOI

IPSec協(xié)議為IP及其上層協(xié)議和應(yīng)用提供了一種安全透明的保護(hù)機(jī)制，它利用了加密、封裝、認(rèn)證、數(shù)字簽名等技術(shù)，為它的上層協(xié)議和應(yīng)用提供了基于密碼學(xué)的安全性保護(hù)，主要包括訪問控制、數(shù)據(jù)源認(rèn)證、機(jī)密性、數(shù)據(jù)完整性、抗重放性等功能。目前，IPSec已成為端到端安全通信的首選協(xié)議[3]。

在單播通信中，利用IPSec機(jī)制就可以保障業(yè)務(wù)數(shù)據(jù)傳輸?shù)臋C(jī)密性、完整性及抗重放性。由于IPSec可以有效保障單播通信安全，人們希望IPSec也可適用于組播。然而，由于IPSec協(xié)議使用互聯(lián)網(wǎng)密鑰交換協(xié)議（Internet Key Exchange，IKE）作為密鑰協(xié)商協(xié)議，而IKE只是一個(gè)端到端的密鑰交換協(xié)議，所以基于IKE的IPSec只能用于端到端的數(shù)據(jù)加密[4]。而組播是一個(gè)點(diǎn)到多點(diǎn)通信方式，且組播成員加入組播組和離開組播組是動(dòng)態(tài)的，這就要求密鑰交換協(xié)議在保留IKE的密鑰特點(diǎn)的同時(shí)，還需做到兩點(diǎn)：密鑰的前向安全和后向安全以及密鑰的動(dòng)態(tài)分配和更新。因此不能簡(jiǎn)單地將已有的IKE協(xié)議用于組播密鑰交換。為了使IPSec的安全特性能適用于組播，IETF制定了IPSec安全組播管理協(xié)議GDOI。

要實(shí)現(xiàn)組播通信安全，密鑰管理是一個(gè)需要解決的關(guān)鍵問題。密鑰自動(dòng)分發(fā)是必需的，考慮到擴(kuò)展性，手工分發(fā)密鑰在現(xiàn)實(shí)中是不可行的。同時(shí)密鑰分發(fā)機(jī)制必須是安全的，以防未授權(quán)用戶獲得組密鑰。

GDOI協(xié)議中定義了一種新的安全關(guān)聯(lián)組安全 關(guān) 聯(lián) （Group Security Association，GSA），GSA主要用于為組播組成員從組控制器和密鑰服務(wù)器（Group Controller and Key Server，GCKS）下載和更新密鑰提供安全保護(hù)，同時(shí)能夠?yàn)榻M成員之間發(fā)送和接收組播業(yè)務(wù)數(shù)據(jù)提供IPSec加密保護(hù)。

3.1 組密鑰管理結(jié)構(gòu)

在RFC4046中定義了組密鑰管理結(jié)構(gòu)，如圖2所示。它由3種實(shí)體組成：組播發(fā)送方IPSec VPN、組播接收方IPSec VPN、GCKS。GCKS負(fù)責(zé)密鑰分發(fā)和SA管理。為了組播源和組播接收者間的通信需要3個(gè)協(xié)議。

（1）注冊(cè)協(xié)議。通過這個(gè)單播協(xié)議，發(fā)送者或接受者的一個(gè)IPSec VPN要加入組，向GCKS認(rèn)證。在認(rèn)證之后，如果這個(gè)要加入的成員是經(jīng)過授權(quán)的，那么它就可以得到數(shù)據(jù)安全關(guān)聯(lián)（Security Association，SA）和密鑰更新SA。數(shù)據(jù)SA用于保護(hù)數(shù)據(jù)安全；密鑰更新SA在策略要求它的時(shí)候，用來保護(hù)密鑰更新信息。由于這些信息必須以安全的方式傳輸，因此通過注冊(cè)SA來保障這些信息的安全傳輸。

（2）密鑰更新協(xié)議。通過使用在注冊(cè)協(xié)議中得到的密鑰更新SA，這個(gè)協(xié)議周期性的對(duì)數(shù)據(jù)SA進(jìn)行更新。與密鑰更新SA有關(guān)的是密鑰加密密鑰（Key Encrypting Keys，KEK），它被用來保護(hù)數(shù)據(jù)SA的更新信息。

（3）數(shù)據(jù)安全協(xié)議。這個(gè)協(xié)議使用數(shù)據(jù)SA來對(duì)組成員間的通信進(jìn)行加密。這個(gè)協(xié)議可以是IPSec，當(dāng)然也可以是其他的協(xié)議，如SRTP。與數(shù)據(jù)安全SA相關(guān)的TEK，用來保護(hù)組成員間的通信[5]。

3.2 GDOI原理

前文已經(jīng)對(duì)GDOI進(jìn)行了簡(jiǎn)要的介紹，本節(jié)將對(duì)它的基本原理進(jìn)行說明。

如圖3所示，第一類SA是注冊(cè)SA，第二類SA是密鑰更新SA，第三類SA是數(shù)據(jù)安全SA。

GDOI的工作流程為以下兩個(gè)步驟。

（1）一個(gè)組成員和GCKS取得聯(lián)系，兩者共同協(xié)商一個(gè)安全通道。通過這個(gè)通道以一種安全的方式交換信息，這就是GDOI的階段1。這個(gè)安全通道是上圖的第1類SA，即注冊(cè)SA。任何可以提供對(duì)端認(rèn)證、保密性和完整性的方法都可以用來協(xié)商該安全通道，不過最常使用和推薦使用的是IKE。

（2）使用階段1得到的安全通道，組成員從GCKS上下載與組通信相關(guān)的SA和密鑰。這個(gè)PULL交換屬于階段2。在這次交換中，組成員獲得數(shù)據(jù)安全SA及數(shù)據(jù)安全SA需要用到的TEK。同時(shí)還可以獲得密鑰更新SA，GCKS用它來個(gè)給發(fā)送到所有組成員的控制信息進(jìn)行保護(hù)。最后一步是階段2的PUSH交換。在這個(gè)階段，GCKS發(fā)送包含新的TEK的密鑰更新消息到所有的組成員。GCKS通過某種動(dòng)態(tài)密鑰更新機(jī)制，如LKH，可以周期性或動(dòng)態(tài)地發(fā)送密鑰更新消息。這些消息通過KEK進(jìn)行加密[6]。

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

采用組密鑰管理結(jié)構(gòu)對(duì)組播通信進(jìn)行加密保護(hù)時(shí)，與傳統(tǒng)的單播加密保護(hù)的差異主要是需要在網(wǎng)絡(luò)中部署一個(gè)GCKS，且網(wǎng)絡(luò)中的所有IPSec VPN需支持GDOI協(xié)議。若想在一個(gè)已經(jīng)具備單播IPSec加密保護(hù)手段的網(wǎng)絡(luò)中新增組播加密保護(hù)功能，雖然GDOI協(xié)議的支持在軟件層面的工作相對(duì)容易實(shí)現(xiàn)，但在現(xiàn)有網(wǎng)絡(luò)中部署GCKS，通常會(huì)遇到一些困難，如部署的網(wǎng)絡(luò)位置選擇，可能需要更改現(xiàn)有網(wǎng)絡(luò)拓?fù)涞取?/p>

特定源組播中僅有一個(gè)數(shù)據(jù)發(fā)送源，為一種典型的單向通信模型，即組播業(yè)務(wù)數(shù)據(jù)都是由組播源流向多個(gè)組播接收終端，結(jié)合使用GDOI協(xié)議需要部署一個(gè)獨(dú)立的GCKS，提出一種由組播源IPSec VPN替代GCKS角色的SSM組播加密方案。

4.1 SSM組播加密場(chǎng)景

如圖4所示的SSM組播應(yīng)用場(chǎng)景中，存在一個(gè)組播源和兩個(gè)組播接收方，IPSec VPN部署在組播源和路由交換設(shè)備之間，用于保護(hù)組播源和組播接收方之間的組播業(yè)務(wù)數(shù)據(jù)安全。

4.2 SSM組播加密密鑰協(xié)商工作原理

SSM組播加密密鑰協(xié)商流程如圖5所示。

具體工作流程如下：

（1）組播源IPSec VPN和組播接收IPSec VPN進(jìn)行IKE階段1交互；

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

（3）組播源IPSec VPN根據(jù)組播地址提供安全關(guān)聯(lián)策略；

（4）組播接收方IPSec VPN對(duì)收到的安全關(guān)聯(lián)進(jìn)行確認(rèn)；

（5）組播源IPSec VPN向組播接收方IPSec VPN提供密碼資源（TEK和KEK）。

通過上述流程，組播接收方IPSec VPN將組播源IPSec VPN的安全管理策略和密碼資源“拉”到本地。組播接收方IPSec VPN獲取到安全關(guān)聯(lián)和密鑰后，組播源和組播接收方之間的業(yè)務(wù)數(shù)據(jù)在組播源IPSec VPN進(jìn)行加密，在組播接收方IPSec VPN進(jìn)行解密，從而實(shí)現(xiàn)了對(duì)組播源和接收方之間的數(shù)據(jù)加密保護(hù)[7]。

組播源IPSec VPN檢測(cè)到密鑰即將過期時(shí)，會(huì)向組播接收方IPSec VPN主動(dòng)推送密鑰更新消息，該消息受到Rekey SA的加密保護(hù)。若組播接收方IPSec VPN在密鑰超期前仍未收到組播源IPSec VPN的密鑰更新消息，則組播接收方IPSec VPN會(huì)重新向組播源IPSec VPN發(fā)起一次注冊(cè)，將安全關(guān)聯(lián)和密鑰“拉”回來。

4.3 協(xié)議交互細(xì)節(jié)

SSM組播加密密鑰協(xié)商協(xié)議參與方為組播源IPSec VPN和組播接收方IPSec VPN，具體交互過程分為兩個(gè)階段：階段1和階段2。其中階段1和IKE協(xié)議的階段1類似。

階段1的目的是保護(hù)階段2的協(xié)議交互過程，階段2的目的是在組播接收方IPSec VPN為特定的組播組建立密鑰更新SA和（或）數(shù)據(jù)安全SA。圖6對(duì)階段2中消息交換進(jìn)行了詳細(xì)介紹。

如圖6所示，[]中的內(nèi)容是可選的。對(duì)于PULL交換，“*”表示該交換受到階段1生成的SA的保護(hù)，對(duì)HDR后面的內(nèi)容加密；對(duì)于PUSH交換，“*”表示用KEK加密HDR后面的內(nèi)容。

符號(hào)說明如下所述。

（1）HDR是ISAKMP報(bào)頭，當(dāng)寫成HDR*，表示載荷被加密。

（2）Ni和Nr分別是組播接收方IPSec VPN和組播源IPSec VPN的當(dāng)前時(shí)間Nonce載荷。

（3）ID）是組播業(yè)務(wù)使用的組播地址。

（4）SA包含了密鑰更新SA和數(shù)據(jù)傳輸SA，具體描述了 KEK（Key Encrypting Keys）和TEK（Traffic Encrypting Keys）加密材料、認(rèn)證轉(zhuǎn)碼和SPI，但是它不包含密鑰（KEK和TEK）。

（5）KE_I和KE_R時(shí)用于Diffie-Hellman交換的公共信息的密鑰交換載。

（6）CERT是證書載荷，用來向?qū)Ψ綐?biāo)識(shí)自己的身份。

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

（8）SEQ載荷包含了一個(gè)從0開始單向遞增的4 Byte的數(shù)字。

（9）KD載荷包含了組播接收方IPSec VPN從組播源接收方IPSec VPN“拉”到的密鑰（包含KEK和TEK）。

（10）各個(gè)HASH載荷計(jì)算方式：

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消息提供數(shù)據(jù)完整性和數(shù)據(jù)源身份認(rèn)證密鑰的密鑰。

協(xié)議交互流程如下文所述。

（1）第1條消息。除了頭部和HASH載荷外，它還包含一個(gè)隨機(jī)數(shù)Ni和一個(gè)ISAKMP ID載荷用來標(biāo)識(shí)它希望加入的組，由組播接收方IPSec VPN發(fā)送。

（2）第2條消息。在對(duì)HASH 載荷進(jìn)行校驗(yàn)以后，組播源IPSec VPN通過發(fā)送一個(gè)包含隨機(jī)數(shù)Nr和SA載荷（包含SA的細(xì)節(jié)，如源地址、目的地址、生命周期，但不包含通信密鑰）的響應(yīng)消息。

（3）第3條消息。組播接收方IPSec VPN對(duì)HASH載荷進(jìn)行校驗(yàn)，并查看SA載荷包含的參數(shù)是否自己可得。然后發(fā)送第3條消息，該消息包含KE載荷、CERT載荷和/或POP載荷。如果使用證書來進(jìn)行認(rèn)證時(shí)，CERT和POP載荷都會(huì)用到。在這種情況下，CERT載荷包含發(fā)起者的公鑰，而POP載荷包含用經(jīng)發(fā)起者私鑰處理的Ni和Nr。KE載荷是可選的，它包含一個(gè)Diffie-Hellman 密鑰，組播源IPSec VPN使用它來和KD載荷進(jìn)行異或處理。這樣做的目的是保證前向加密安全。

（4）第4條消息。組播源IPSec VPN對(duì)HASH載荷進(jìn)行校驗(yàn)，若使用證書認(rèn)證，還需要對(duì)POP載荷中的簽名進(jìn)行校驗(yàn)。然后組播源IPSec VPN生成第4條消息。這條消息包含KD載荷（包含與最后一步中提到的SA相關(guān)的密鑰）、CERT載荷和POP載荷。此外，如果GCKS發(fā)送密鑰更新報(bào)文，SEQ載荷可以提供密鑰更新報(bào)文的抗重傳保護(hù)。發(fā)起者對(duì)第4條消息進(jìn)行驗(yàn)證，得到SA的密鑰[6]。

在這些步驟完成后，協(xié)議雙方進(jìn)入階段2的PUSH交換。在這個(gè)交換中，組播源IPSec VPN發(fā)送密鑰更新消息到所有的組播接收方IPSec VPN，這些密鑰更新消息包含有新的數(shù)據(jù)安全SA的密鑰（新的TEK）。這些消息是通過KEK來保護(hù)的。一個(gè)PUSH交換信息包含SEQ載荷（提供抗重傳保護(hù)）、SA載荷（包含SA的策略）、KD 載荷（包含和SA相關(guān)的密鑰）、SIG載荷（包含GCKS的簽名）和CERT載荷（可選的，用來對(duì)SIG載荷進(jìn)行檢驗(yàn)）。

4.4 前向安全和后向安全

離開組播組的組播接收方不能再獲得將來這個(gè)組的通信數(shù)據(jù)，稱之為前向安全；新加入組播組的組播接收方不能獲得過去這個(gè)組的通信數(shù)據(jù)，稱之為后向安全。前向安全和后向安全是組播安全需要考慮的兩個(gè)重要因素。

對(duì)于前向安全，當(dāng)組播源IPSec VPN發(fā)現(xiàn)有新的組播接收方IPSec VPN向其注冊(cè)時(shí)，會(huì)發(fā)起密鑰更新，同時(shí)通過組播的方式將更新后的密鑰發(fā)送給當(dāng)前所有組播接收方IPSec VPN。

對(duì)于后向安全，組播源IPSec VPN會(huì)定期向組播接收方IPSec VPN發(fā)送組播心跳報(bào)文，組播接收方IPSec VPN收到該報(bào)文后，用單播的方式進(jìn)行響應(yīng)。當(dāng)組播源IPSec VPN多次未收到某接收方IPSec VPN的心跳響應(yīng)后，則判定該接收方IPSec VPN已離線，隨后發(fā)起密鑰更新，同時(shí)通過組播的方式將更新后的密鑰發(fā)送給當(dāng)前所有組播接收方IPSec VPN。

5 結(jié) 語

本文提出了一種SSM組播加密方案，通過GDOI協(xié)議和IPSec協(xié)議的結(jié)合使用，能夠在不增加安全基礎(chǔ)設(shè)施的情況下有效的解決SSM組播發(fā)送方和組播接收方之間的業(yè)務(wù)數(shù)據(jù)傳輸?shù)臋C(jī)密性和完整性問題，同時(shí)當(dāng)組播接收方動(dòng)態(tài)變化時(shí)，能夠保障組播業(yè)務(wù)數(shù)據(jù)的前向安全和后向安全。相比傳統(tǒng)的必須部署GCKS以支持組播密鑰管理的方式，該方案使用SSM中的組播發(fā)送方IPSec VPN替代GCKS，可以使網(wǎng)絡(luò)管理人員通過較低的代價(jià)實(shí)現(xiàn)SSM組播業(yè)務(wù)安全。