一種用于多方通信的新的ＳＭＣ安全協(xié)議

(1.北京郵電大學 網(wǎng)絡(luò)與交換技術(shù)國家重點實驗室 信息安全中心， 北京 100876; 2.華為技術(shù)有限公司 北京研發(fā)中心， 北京 100085)

摘要：對主流安全協(xié)議在多方通信環(huán)境下的應(yīng)用進行分析，總結(jié)其各自優(yōu)缺點。在綜合各個協(xié)議優(yōu)點的基礎(chǔ)上，提出并介紹了一個用于多方通信環(huán)境下的SMC(securing multi-party communications)協(xié)議，該協(xié)議工作在傳輸層之上，具有更強的可部署性。SMC協(xié)議被設(shè)計用來取代當前用于多方通信環(huán)境的MSEC協(xié)議族。通過將SMC協(xié)議與MSEC協(xié)議族進行比較，證明SMC協(xié)議具有與MSEC協(xié)議族一致的安全性，并且具有更強的可部署性。

關(guān)鍵詞：網(wǎng)絡(luò)安全；多方通信； 安全傳輸層；數(shù)據(jù)報安全傳輸層； MSEC協(xié)議族；安全多方通信協(xié)議

中圖分類號：TP39308文獻標志碼：A

文章編號：1001-3695(2008)11-3445-04



SMC security protocol designed for multi-party communication scenario



GAO Cheng1，LIU Ya2，XIN Yang1，YANG Yi-xian1(1.Information Security Centre， State Key Laboratory of Networking Switching Technology， Beijing University of Posts Telecommunications， Beijing 100876， China;2.Beijing R D Center， Huawei Technologies Co.， Ltd.， Beijing 100085， China)Abstract:Advantages and disadvantages of performance of several popular security protocols were analyzed when these protocols were deployed in multi-party communication scenario. Based on the advantages of these protocols， a new multi-party communication security protocol named SMC protocol which worked on transport layer and could be deployed more widely was introduced. SMC protocol was designed to replace MSEC protocol suite which has been widely deployed in multi-party communication scenario. Contrasting with MSEC protocol suite， SMC protocol is as secure as MSEC protocol suite， but it has better deploy performance than MSEC protocol suite.

Key words:network security; multi-party communication; TLS; DTLS; MSEC protocol suite; SMC protocol

隨著計算機網(wǎng)絡(luò)的廣泛應(yīng)用，計算機通信數(shù)據(jù)的安全性已經(jīng)成為了一個不可忽視的問題。一些數(shù)據(jù)安全傳輸協(xié)議如TLS、IPSec等，已經(jīng)被廣泛部署并經(jīng)受了實踐的檢驗，為通信數(shù)據(jù)提供保密性、完整性和認證性。但是隨著IPTV、遠程會議、網(wǎng)絡(luò)在線游戲等多方通信環(huán)境的廣泛部署，TLS^[1]、IPSec^[2]等安全協(xié)議并非為多方通信環(huán)境專門設(shè)計，在這種環(huán)境下這些協(xié)議的應(yīng)用均存在各種缺陷。為了解決這個問題，IETF MSEC工作組已經(jīng)制定了多個組密鑰管理協(xié)議來實現(xiàn)多方通信中的組密鑰管理（GDOI、GSAKMP等），然而這些協(xié)議在應(yīng)用中也存在著一些局限性。

1相關(guān)安全協(xié)議的分析

多方通信的安全需求包括保密性、完整性、授權(quán)和認證性、組成員認證、抗重放等。為了實現(xiàn)多播通信報文的保密性，通信端之間的加密、解密密鑰只有組成員才能知道，這樣才能保證只有組成員能獲取組通信內(nèi)容。組成員的認證也可以利用該密鑰來實現(xiàn)，因為只有擁有該密鑰的組員才能生成正確的加密多播報文。利用多方共享密鑰解決安全問題的關(guān)鍵是密鑰的生成和分發(fā)^[3]，這種生成和分發(fā)必須是排外的，即非組員無法獲得密鑰。組密鑰管理主要解決如何為組成員生成、發(fā)布和更新密鑰，并解決由此而帶來的相關(guān)安全問題。

11TLS和DTLS協(xié)議

無論是基于可靠傳輸協(xié)議（如TCP）的TLS協(xié)議^[1]，還是基于非可靠傳輸協(xié)議（如UDP）的DTLS協(xié)議^[4]，都是運行在應(yīng)用程序之下，傳輸層之上，通過提供標準API供應(yīng)用程序調(diào)用以實現(xiàn)安全連接的目的。TLS和DTLS基于client/server架構(gòu)，能夠提供認證、密鑰協(xié)商、密鑰更新、加密、完整性保護、抗重放等安全功能。TLS和DTLS協(xié)議無須更改傳輸層之下的系統(tǒng)核心，應(yīng)用程序可以通過調(diào)用其標準API很容易地建立安全連接，因此得到了最廣泛的部署。

由于TLS和DTLS基于client/server架構(gòu)，每個連接只能提供兩方的通信安全，對于三方及以上的通信場景，只能通過建立多個會話（session）的方式來提供安全功能，這種方式繁瑣、效率低下，可行性很低，并非多方通信環(huán)境下的實用解決方案。

12MSEC協(xié)議族

IETF下屬的MSEC工作組的工作是解決IP多播的安全問題，現(xiàn)已制定了多個安全協(xié)議。MSEC工作組的協(xié)議設(shè)計思路是將組密鑰管理和數(shù)據(jù)安全相分離，只解決組密鑰管理方面的問題。MSEC工作組已經(jīng)制定了GDOI^[5]、MIKEY^[6]等多個組密鑰管理協(xié)議，這些協(xié)議的共性是在基于組播方式的數(shù)據(jù)安全協(xié)議基礎(chǔ)上提供組密鑰管理方案。例如GDOI協(xié)議是以IPSec為基礎(chǔ)，添加了組密鑰管理功能。

MSEC協(xié)議族采用組密鑰管理協(xié)議和數(shù)據(jù)安全協(xié)議分開設(shè)計的方式，各個組密鑰管理協(xié)議需要以守護進程（daemon）或應(yīng)用程序的形式單獨運行，如GDOI和GSAKMP^[7]。因此無法提供標準的API調(diào)用接口供應(yīng)用程序?qū)M密鑰管理進行控制，基于MSEC 協(xié)議族開發(fā)的應(yīng)用程序可移植性很低。從數(shù)據(jù)安全方面看，因為MSEC協(xié)議族目前主要支持的ESP和AH這兩種協(xié)議均在IP層實現(xiàn)，需要運行于操作系統(tǒng)的內(nèi)核中。這種實現(xiàn)方式除了不能提供標準的數(shù)據(jù)安全API調(diào)用接口而使得程序可移植性較差外，還將影響應(yīng)用程序的可部署性， 因為不同的操作系統(tǒng)對ESP和AH功能實現(xiàn)可能并不相同，有的可能甚至尚未實現(xiàn)這樣的功能。

此外，即使MSEC 協(xié)議族能夠通過擴展支持新的數(shù)據(jù)安全協(xié)議，但因為目前缺乏一種通用的、應(yīng)用層能直接調(diào)用的、支持多方通信的數(shù)據(jù)安全協(xié)議，應(yīng)用程序同樣不能使用MSEC協(xié)議族提供的服務(wù)。

2一種新的SMC協(xié)議

可以看出，當前的各主流安全協(xié)議在多方通信環(huán)境下的表現(xiàn)都存在著一些問題。為了實現(xiàn)應(yīng)用程序通信的安全需求和使用的方便性，可行的解決方案應(yīng)當像TLS和DTLS一樣工作在傳輸層之上，這樣就能夠以API調(diào)用接口的形式向應(yīng)用程序提供組密鑰管理和數(shù)據(jù)安全服務(wù)，而無須對運行在操作系統(tǒng)內(nèi)核中的IP層進行改動；同時，解決方案需要像MSEC協(xié)議族一樣提供可行的組管理方案，用于安全、可靠地進行組密鑰的產(chǎn)生、分發(fā)等操作。

綜合以上考慮，通過整合TLS、DTLS協(xié)議和MSEC協(xié)議族的優(yōu)點，本章提出了一種新的安全多方通信協(xié)議（SMC協(xié)議）。

21SMC協(xié)議架構(gòu)

SMC協(xié)議是組密鑰管理和數(shù)據(jù)安全性的結(jié)合。SMC協(xié)議的組密鑰管理功能與MSEC協(xié)議族類似，數(shù)據(jù)安全性部分功能則與MSEC協(xié)議族中使用的ESP，AH類似。將這兩者結(jié)合在同一個協(xié)議中可以方便地使用API對其進行封裝。

SMC協(xié)議由兩層協(xié)議構(gòu)成，這與TLS、DTLS協(xié)議類似。這兩層分別是位于下層的SMC 記錄協(xié)議（SMC record protocol）和位于上層的SMC組密鑰管理協(xié)議（SMC GKM protocol），如圖1所示。SMC record層工作在傳輸層（多播環(huán)境下通常使用UDP）之上。

在多方通信環(huán)境中，共有組管理及密鑰服務(wù)器（GCKS）、發(fā)送者（sender）、接收者（receiver）三類主機^[8]。

22SMC 記錄協(xié)議

SMC 記錄層主要功能是為上層數(shù)據(jù)提供數(shù)據(jù)壓縮、解壓縮、加密、解密及完整性驗證功能，用于保證上層數(shù)據(jù)的保密性和完整性。SMC 記錄層對上層數(shù)據(jù)進行處理的相關(guān)壓縮算法、加密算法、密鑰、完整性驗證算法等安全參數(shù)由相關(guān)會話的安全聯(lián)盟（security association，SA）和密鑰下載包（key download，KD)確定。

SMC記錄層存在著初始會話（initiation session）、密鑰更新會話（rekeying session）和數(shù)據(jù)安全會話（data-sec session）三種會話，每個會話的安全參數(shù)均由其對應(yīng)的SA決定。三種不同會話在組播通信中的作用如圖2所示。

221初始會話

作為多播通信組的組員，sender與receiver必須向GCKS注冊，獲取通信組組內(nèi)數(shù)據(jù)傳輸時采用的SA和KD。每個sender/receiver與GCKS間建立一個一對一的初始會話，建立過程與DTLS協(xié)議類似。Initiation session建立后，就相當于在sender/receiver與GCKS間建立了一條安全通道，可以供兩端進行數(shù)據(jù)的安全單播；然后，sender/receiver通過initiation session從GCKS獲取rekeying session SA、rekeying session KD、data-sec session SA、data-sec session KD以進行多播安全組通信。另外，在sender/receiver能夠正常進行安全組通信后，如果發(fā)生如其保存的組播密鑰失效等情況，則也可以通過initiation session從GCKS獲取新的安全參數(shù)。

222密鑰更新會話

為了實現(xiàn)組通信的前向保密性、后向保密性等安全要求，在組中有新成員加入、原有成員離開、組播通信密鑰失效等情況下，組播通信的密鑰必須進行變更以保障組內(nèi)通信的安全。這種情況下，如何將GCKS產(chǎn)生的新密鑰向sender/receiver進行下發(fā)就成了一個問題。雖然GCKS已經(jīng)和各個sender/receiver間擁有了initiation session這個安全通道，但是由GCKS逐一下發(fā)安全參數(shù)顯然是低效的。

密鑰更新會話的功能就是供GCKS向組員安全廣播data-sec session信息，其最重要的應(yīng)用就是在組成員變動的情況下發(fā)送經(jīng)過此會話所保護的新的data-sec session安全參數(shù)。另外，經(jīng)由rekeying session保護的數(shù)據(jù)還包括組關(guān)閉警告等組通知信息。正常情況下每個多播通信組僅存在一個rekeying session。如果GCKS不需要對data-sec session進行更新，在協(xié)議實現(xiàn)時多播通信組中可以不存在rekeying session。

223數(shù)據(jù)安全會話

數(shù)據(jù)安全會話的功能是對多播傳輸數(shù)據(jù)流進行保護，其由GCKS確定，并通過initiation session或rekeying session下發(fā)給sender/receiver。Sender使用data-sec session對需要傳輸?shù)亩嗖?shù)據(jù)進行保護，receiver在接收到多播數(shù)據(jù)后使用對應(yīng)的data-sec session安全參數(shù)進行解密等操作，這樣就可以實現(xiàn)數(shù)據(jù)的安全傳播。

每個data-sec session對組內(nèi)一條多播數(shù)據(jù)流進行保護。由于每個多播通信組可能存在多條數(shù)據(jù)流（如IPTV中每個多播組中可能有多個頻道），一個多播通信組可以存在多個data-sec session，每個data-sec session安全參數(shù)可以不同。Data-sec session安全參數(shù)由GCKS確定，但由于GCKS并不參與組多播通信數(shù)據(jù)的傳輸，在GCKS端并不存在data-sec session。

23SMC組密鑰管理協(xié)議

SMC記錄層被封裝以供上層的SMC組密鑰管理協(xié)議（SMC GKM protocol）調(diào)用。SMC GKM層為GCKS和sender/receiver提供相互驗證身份、協(xié)商并發(fā)布SA，協(xié)商并發(fā)布KD等功能。

SMC GKM協(xié)議包括三個子協(xié)議，分別是初始化子協(xié)議(initiation sub-protocol)、密鑰更新子協(xié)議(rekeying sub-protocol)和通知子協(xié)議(notification sub-protocol)。

231初始化子協(xié)議

初始化子協(xié)議定義了如何在GCKS與sender/receiver之間建立一對一的initiation session，以及sender/receiver如何通過建立的initiation session從GCKS獲取rekeying session、data-sec session的相關(guān)安全參數(shù)。

1)握手交互

握手交互用于建立一對一的initiation session，即為GCKS與sender/receiver之間的握手過程。握手過程如圖3所示，將握手雙方的GCKS作為server，sender/receiver作為client。

a)第一條握手消息由client向server發(fā)送，包括SAc、KEc、Nc。SAc指client所支持的所有SA，server從中選擇適當SA建立initiation session；KEc的定義與GDOI協(xié)議中一致；Nc為client發(fā)送的一個隨機數(shù)。

b)Server接收到第一條握手消息后，從SAc中選取一條本地支持的SA作為SAs（即initiation session的安全算法），同時server生成自己的KEs和Ns。最后server將SAs、KEs、Ns構(gòu)成第二條握手消息發(fā)送給client端。證書請求字段CERTREQ是可選的，但如果雙方在握手前沒有預(yù)共享密鑰，第二條消息中必須包括此字段。

發(fā)送出第二條消息后，server通過DH算法從KEs、KEc、Ns、Nc中算出主密鑰，然后使用PRF算法對主密鑰進行變換以獲取initiation session的雙向加密密鑰和完整性保護密鑰。

c)Client在收到第二條消息后，同樣通過DH算法從KEs、KEc、Ns、Nc中算出主密鑰，然后通過PRF算法對主密鑰進行變換以獲取initiation session的雙向加密密鑰和雙向完整性保護密鑰，同時由SAs確定initiation session的安全算法。這樣通信雙方得以建立initiation session以保護雙方通信數(shù)據(jù)。

Client需要對之前握手信息的完整性進行確認以保障initiation session是安全的。Client將第一條注冊消息、Ns字段、client標志IDc字段連接在一起并計算其摘要值A(chǔ)UTH。計算AUTH所用密鑰為雙方預(yù)共享密鑰或Client證書公鑰，根據(jù)不同情況，client需要同時發(fā)送預(yù)共享密鑰標志IDkey或本地證書CERT。第三條注冊消息由以下字段構(gòu)成：client標志IDc、申請加入的組的標志IDgroup、AUTH值、IDkey或CERT，證書請求CERTREQ（可選）。第三條消息的傳輸過程由initiation session進行保護。

d)Server收到第三條消息后，根據(jù)IDkey或CERT字段對client發(fā)送的AUTH值進行驗證，同時檢查對端client是否擁有加入IDgroup所對應(yīng)組的權(quán)限。驗證通過后，server將client加入相應(yīng)組，并將組中rekeying session和data-sec sessions的SAs、KDs發(fā)送給client。

第四條注冊消息由以下字段構(gòu)成：server標志IDs、SAs、KDs、server端AUTH（由第二條消息、Nc、IDs計算），IDkey或CERT。其傳輸過程也由initiation session進行保護。

e)Client收到第四條注冊消息后，在對AUTH成功驗證后，便可以使用SAs和KDs建立相應(yīng)的rekeying session和data-sec sessions，在組中進行安全通信。至此，握手過程結(jié)束。

由于傳輸層使用UDP，握手過程中不得不考慮的問題便是握手數(shù)據(jù)包可能會丟失。這個問題的解決方法是使用類似DTLS協(xié)議的超時重傳機制^[4]。

2）下拉交互

下拉交互（pull exchange）的作用是供已經(jīng)加入組中的sender/receiver通過單播方式經(jīng)initiation session從GCKS獲取新的安全參數(shù)，以更新rekeying session和data-sec sessions。Sender/Receiver的下拉行為（pull）通常發(fā)生在其某個session無法正常通信，且GCKS沒有多播新的安全參數(shù)的情況下。

Sender/Receiver需要通過initiation session發(fā)送一條含有需要更新的組標志IDgroup的pull消息來進行pull操作。GCKS在收到這條消息后，對IDgroup對應(yīng)的組進行權(quán)限認證，驗證成功后，將組中rekeying session和data-sec sessions的SAs、KDs發(fā)送給sender/receiver。這樣，就完成了一次pull操作。

232密鑰更新子協(xié)議

在組中新加入組員或組員離開時，為了保證組通信的保密性，就必須更新組通信密鑰，組密鑰的更新過程可以通過LKH等組密鑰管理算法實現(xiàn)^[9]。新的安全參數(shù)被封裝在一條下發(fā)消息（push）中由GCKS通過組rekeying session向sender/receiver多播下發(fā)。Push消息一般包括data-sec sessions的SAs和KDs，rekeying session較少進行更新；但當rekeying session需要進行更新時，push消息中也包括rekeying session的SA和KD。所有sender/receiver在收到push消息后，通過檢查哪個rekeying session接收此消息便可以確定要更新的是哪個組，然后通過更新SA和KD來更新相應(yīng)session。

233通知子協(xié)議

在組通信過程中，sender/receiver與GCKS間可能需要傳輸一些通知或告警信息以供對方處理，如sender/receiver通知離開組、組關(guān)閉通知、傳輸超時等。如果是單播的消息，通過sender/receiver與GCKS間的initiation session進行傳輸，如sender/receiver通知離開組信息；如果是GCKS需要通知所有組員的消息，由GCKS通過rekeying session多播發(fā)送，如組關(guān)閉消息。

3SMC協(xié)議與MSEC協(xié)議族的對比

SMC協(xié)議是作為MSEC協(xié)議族的替代協(xié)議被設(shè)計的，其相對于MSEC協(xié)議族的最大優(yōu)勢在于：SMC協(xié)議在達到了MSEC協(xié)議族安全性要求的基礎(chǔ)上，具有更強的可部署性。以下從安全性、可部署性方面對兩者進行對比分析。

31安全性對比

311SMC協(xié)議安全性分析

SMC協(xié)議組通信的安全性建立在GCKS與sender/recei-ver間initiation session安全性的基礎(chǔ)上。在握手建立initiation session的過程中，雙方首先在第一條和第二條握手消息中通過DH算法在兩端計算出相同的密鑰材料（key material）。在這個過程中，只要頭兩條握手消息未被竄改，DH公鑰算法就能夠確保所產(chǎn)生的密鑰材料的私密性，也即能保證由密鑰材料計算出的initiation session雙向加密密鑰和完整性保護密鑰的安全性。而保障頭兩條握手消息的完整性是通過第三條和第四條握手消息中的AUTH值來實現(xiàn)的。AUTH值由頭兩條握手消息中關(guān)鍵信息計算得出。計算有兩種方法：使用通信雙方在握手進行前所預(yù)共享的密鑰對關(guān)鍵信息計算HMAC值作為AUTH；使用握手過程中對端發(fā)送的證書對關(guān)鍵信息進行簽名并將簽名值作為AUTH。通信雙方向?qū)Ψ桨l(fā)送由頭兩條握手消息中關(guān)鍵信息計算得出的本端AUTH，并在收到對端所發(fā)送的AUTH值后與根據(jù)本地所保存的消息計算得出的AUTH值對比。如果對比結(jié)果一致則說明頭兩條消息未被竄改；否則頭兩條握手消息可能被竄改，握手過程失敗，握手過程中斷。通過這樣的握手過程就可以保證所建立的initiation session的安全性。

在建立initiation session后，sender/receiver就可以安全地通過此會話獲取rekeying session和data-sec sessions相關(guān)安全參數(shù)以建立相應(yīng)會話。之后，在組中成員發(fā)生變動時，新的安全參數(shù)可以通過rekeying session安全下發(fā)。組成員變動時，GCKS的SMC GKM層首先產(chǎn)生新的data-sec sessions安全參數(shù)，然后根據(jù)適當?shù)慕M密鑰管理算法（如LKH）用舊的data-sec sessions安全參數(shù)加密新的data-sec sessions安全參數(shù)，并經(jīng)rekeying session向所有組成員多播。在使用合理組密鑰管理算法的情況下，可以保證離開的組員無法再解密組通信內(nèi)容（即離開的組員不能使用自己舊的data-sec sessions安全參數(shù)解密新的data-sec sessions安全參數(shù)）、新加入的組員無法解密加入前組通信內(nèi)容，從而保障組內(nèi)通信數(shù)據(jù)的安全性。由于在SMC GKM層已完成了對新安全參數(shù)的加密，GCKS的rekeying session無須對GKM數(shù)據(jù)再進行加密，只需使用自己的證書對消息進行簽名以確保消息的傳輸過程中未經(jīng)竄改即可。

這樣，在保障了SMC協(xié)議initiation session和rekeying session安全性的基礎(chǔ)上，Sender/Receiver可以安全地從GCKS獲取并更新data-sec sessions安全參數(shù)，從而實現(xiàn)安全組通信的目標。

由于工作在UDP之上，SMC協(xié)議通過在SMC 記錄協(xié)議中加入序列編號字段以實現(xiàn)抗重放攻擊。為了防止DoS攻擊，可以在握手過程中加入cookie驗證過程。這些方法與DTLS協(xié)議中相關(guān)方法一致。

312與MSEC協(xié)議族的對比

MSEC工作組制定的現(xiàn)有多播安全協(xié)議（GDOI^[5]、MIKEY^[6]等）具有完善的安全機制，能夠保障多播通信環(huán)境下的安全需求。

由3.1.1節(jié)可見，在多播通信環(huán)境下部署SMC協(xié)議可以保障多播通信數(shù)據(jù)的保密性，其在安全性上的表現(xiàn)和MSEC協(xié)議族一致，都能夠保障多播通信的安全性。

32可部署性對比

如2.2節(jié)所述，MSEC協(xié)議族目前主要支持的ESP和AH這兩種協(xié)議均在IP層實現(xiàn)，需要運行于操作系統(tǒng)的內(nèi)核中，這種實現(xiàn)方式由于不能提供標準的數(shù)據(jù)安全API調(diào)用接口而使得程序可移植性較差。同時由于不同操作系統(tǒng)對ESP和AH的實現(xiàn)可能不同，導(dǎo)致基于MSEC協(xié)議族的應(yīng)用程序可移植性較差。

SMC協(xié)議只是在傳輸層和應(yīng)用層間增加了一個SMC層以實現(xiàn)安全多播的功能，并提供了標準的API接口供上層調(diào)用。SMC協(xié)議的實現(xiàn)以一個獨立功能模塊的形式獨立于傳輸層與應(yīng)用層，無須對上下層進行任何修改，因此基于SMC協(xié)議的應(yīng)用程序具有更強的可部署性，應(yīng)用范圍也會更加廣泛。

33SMC協(xié)議驗證

為了測試SMC協(xié)議在多播環(huán)境中的實際運行效果，搭建了一個含有五臺運行了Red Hat Linux 9.0的計算機局域網(wǎng)作為實驗環(huán)境，SMC協(xié)議的實現(xiàn)采用了LKH組密鑰管理算法，分為服務(wù)器端的實現(xiàn)和客戶端實現(xiàn)。實驗環(huán)境五臺計算機中一臺安裝服務(wù)器端實現(xiàn)，另外四臺計算機安裝SMC協(xié)議的客戶端實現(xiàn)。

實驗中，首先運行服務(wù)器端以初始化組安全參數(shù)，然后運行另外四臺客戶端先后加入組中。以其中一臺客戶端作為發(fā)送者向另三臺客戶端不斷發(fā)送信息，同時服務(wù)器端對組安全參數(shù)定時進行更新；最后，三臺接收者先后離開組。

在測試中，每加入一個新的客戶端時，服務(wù)器端就會更新一次組安全參數(shù)并進行下發(fā)，保障了多播通信能夠順利進行，接收者能夠接收并解密發(fā)送者所發(fā)送的信息。新加入客戶端由于無法獲得加入前的組安全參數(shù)，保障了其加入前的傳輸信息不會被泄露。在將四臺客戶端全部加入組后，服務(wù)器定時通過多播更新組安全參數(shù)，實驗結(jié)果同樣證明客戶端可以實時更新組密鑰并使用最新的組安全密鑰進行數(shù)據(jù)的加/解密。最后，每離開一個接收者時，服務(wù)器端也會更新一次組安全參數(shù)并進行下發(fā)，余下的所有客戶端機器使用更新后的組安全參數(shù)進行數(shù)據(jù)的收發(fā)。離開后的客戶端使用舊的組安全參數(shù)無法再解密多播信息，保證了其離開后組播數(shù)據(jù)的安全性。

從測試中可看出，組內(nèi)通信的保密性是可以保證的。在更新組安全參數(shù)時，新的安全參數(shù)根據(jù)SMC協(xié)議進行下發(fā)并更新，從而保障了組內(nèi)通信數(shù)據(jù)的前向保密性和后向保密性。

4結(jié)束語

本文從分析各主流安全協(xié)議在多播組通信環(huán)境下部署的優(yōu)缺點入手，綜合各協(xié)議在可部署性、可移值性、協(xié)議安全性的優(yōu)點，并在充分考慮新協(xié)議可能遭受的安全威脅的基礎(chǔ)上，設(shè)計出一個新的、專用于多播組通信環(huán)境下的安全協(xié)議。這個協(xié)議同IETF MSEC工作組多播安全協(xié)議相比，其主要優(yōu)點在于安全性未被削弱的情況下具有更強的可移植性和可部署性，因此該協(xié)議可以在多種應(yīng)用環(huán)境下取代現(xiàn)有多播安全協(xié)議。

參考文獻：

[1]DIERKS T，RESCORLA E.The transport layer security (TLS) protocol version 1.1[EB/OL].（2006）[2007]. http://www.ietf.org/rfc/rfc4346.txt.

[2]KENT S，ATKINSON R.Security architecture for the Internet protocol[EB/OL].(1998)[2007].http://www.ietf.org/rfc/rfc2401.txt.

[3]BAUGHER M，CANETTI R，DONDETI L，et al.HOLM:multicast security (MSEC) group key management architecture [EB/OL].(2005)[2007].http://www.ietf.org/rfc/rfc4046.txt.

[4]RESCORLA E，MODADUGU N.Datagram transport layer security[EB/OL].(2006)[2007].http://www.ietf.org/rfc/rfc4347.txt.

[5]BAUGHER M，WEIS B，HARDJONO T，et al.The group domain of interpretation [EB/OL].(2003)[2007].http://www.ietf.org/rfc/rfc2246.txt.

[6]ARKKO J，CARRAR E，LINDHOLM F，et al.MIKEY:multimedia Internet KEYing [EB/OL].(2004)[2007].http://www.ietf.org/rfc/rfc3830.txt.

[7]HARNEY H，COLEGROVE A，GROSS G.GSAKMP:group secure association key management protocol[EB/OL].(2006)[2007].http://www.ietf.org/rfc/rfc4535.txt.

［8］HARDJONO T，VERISIGN B.WEIS:the multicast group security architecture[EB/OL].(2004)[2007].http://www.ietf.org/rfc/rfc3740.txt.

[9]WONG C K，GOUDA M，LAM S.Secure group communications using key graphs[J].IEEE/ACM Trans on Networking，2000，8(1):16-30. 

[10]ROLF O，RALF H，DAVID B.SSL/TLS session-aware user authentication-or how to effectively thwart the man-in-the-middle[J].Computer Communications，2006，29:2238-2246.