一種用于多方通信的新的ＳＭＣ安全協議
2008-12-31 00:00:00高程劉亞辛陽楊義
計算機應用研究 2008年11期
(1.北京郵電大學 網絡與交換技術國家重點實驗室 信息安全中心， 北京 100876; 2.華為技術有限公司 北京研發中心， 北京 100085)
摘要：對主流安全協議在多方通信環境下的應用進行分析，總結其各自優缺點。在綜合各個協議優點的基礎上，提出并介紹了一個用于多方通信環境下的SMC(securing multi-party communications)協議，該協議工作在傳輸層之上，具有更強的可部署性。SMC協議被設計用來取代當前用于多方通信環境的MSEC協議族。通過將SMC協議與MSEC協議族進行比較，證明SMC協議具有與MSEC協議族一致的安全性，并且具有更強的可部署性。
關鍵詞：網絡安全；多方通信； 安全傳輸層；數據報安全傳輸層； MSEC協議族；安全多方通信協議
中圖分類號：TP39308文獻標志碼：A
文章編號：1001-3695(2008)11-3445-04
SMC security protocol designed for multi-party communication scenario
GAO Cheng1，LIU Ya2，XIN Yang1，YANG Yi-xian1(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
隨著計算機網絡的廣泛應用，計算機通信數據的安全性已經成為了一個不可忽視的問題。一些數據安全傳輸協議如TLS、IPSec等，已經被廣泛部署并經受了實踐的檢驗，為通信數據提供保密性、完整性和認證性。但是隨著IPTV、遠程會議、網絡在線游戲等多方通信環境的廣泛部署，TLS[1]、IPSec[2]等安全協議并非為多方通信環境專門設計，在這種環境下這些協議的應用均存在各種缺陷。為了解決這個問題，IETF MSEC工作組已經制定了多個組密鑰管理協議來實現多方通信中的組密鑰管理（GDOI、GSAKMP等），然而這些協議在應用中也存在著一些局限性。
1相關安全協議的分析
多方通信的安全需求包括保密性、完整性、授權和認證性、組成員認證、抗重放等。為了實現多播通信報文的保密性，通信端之間的加密、解密密鑰只有組成員才能知道，這樣才能保證只有組成員能獲取組通信內容。組成員的認證也可以利用該密鑰來實現，因為只有擁有該密鑰的組員才能生成正確的加密多播報文。利用多方共享密鑰解決安全問題的關鍵是密鑰的生成和分發[3]，這種生成和分發必須是排外的，即非組員無法獲得密鑰。組密鑰管理主要解決如何為組成員生成、發布和更新密鑰，并解決由此而帶來的相關安全問題。
11TLS和DTLS協議
無論是基于可靠傳輸協議（如TCP）的TLS協議[1]，還是基于非可靠傳輸協議（如UDP）的DTLS協議[4]，都是運行在應用程序之下，傳輸層之上，通過提供標準API供應用程序調用以實現安全連接的目的。TLS和DTLS基于client/server架構，能夠提供認證、密鑰協商、密鑰更新、加密、完整性保護、抗重放等安全功能。TLS和DTLS協議無須更改傳輸層之下的系統核心，應用程序可以通過調用其標準API很容易地建立安全連接，因此得到了最廣泛的部署。
由于TLS和DTLS基于client/server架構，每個連接只能提供兩方的通信安全，對于三方及以上的通信場景，只能通過建立多個會話（session）的方式來提供安全功能，這種方式繁瑣、效率低下，可行性很低，并非多方通信環境下的實用解決方案。
12MSEC協議族
IETF下屬的MSEC工作組的工作是解決IP多播的安全問題，現已制定了多個安全協議。MSEC工作組的協議設計思路是將組密鑰管理和數據安全相分離，只解決組密鑰管理方面的問題。MSEC工作組已經制定了GDOI[5]、MIKEY[6]等多個組密鑰管理協議，這些協議的共性是在基于組播方式的數據安全協議基礎上提供組密鑰管理方案。例如GDOI協議是以IPSec為基礎，添加了組密鑰管理功能。
MSEC協議族采用組密鑰管理協議和數據安全協議分開設計的方式，各個組密鑰管理協議需要以守護進程（daemon）或應用程序的形式單獨運行，如GDOI和GSAKMP[7]。因此無法提供標準的API調用接口供應用程序對組密鑰管理進行控制，基于MSEC 協議族開發的應用程序可移植性很低。從數據安全方面看，因為MSEC協議族目前主要支持的ESP和AH這兩種協議均在IP層實現，需要運行于操作系統的內核中。這種實現方式除了不能提供標準的數據安全API調用接口而使得程序可移植性較差外，還將影響應用程序的可部署性， 因為不同的操作系統對ESP和AH功能實現可能并不相同，有的可能甚至尚未實現這樣的功能。
此外，即使MSEC 協議族能夠通過擴展支持新的數據安全協議，但因為目前缺乏一種通用的、應用層能直接調用的、支持多方通信的數據安全協議，應用程序同樣不能使用MSEC協議族提供的服務。
2一種新的SMC協議
可以看出，當前的各主流安全協議在多方通信環境下的表現都存在著一些問題。為了實現應用程序通信的安全需求和使用的方便性，可行的解決方案應當像TLS和DTLS一樣工作在傳輸層之上，這樣就能夠以API調用接口的形式向應用程序提供組密鑰管理和數據安全服務，而無須對運行在操作系統內核中的IP層進行改動；同時，解決方案需要像MSEC協議族一樣提供可行的組管理方案，用于安全、可靠地進行組密鑰的產生、分發等操作。
綜合以上考慮，通過整合TLS、DTLS協議和MSEC協議族的優點，本章提出了一種新的安全多方通信協議（SMC協議）。
21SMC協議架構
SMC協議是組密鑰管理和數據安全性的結合。SMC協議的組密鑰管理功能與MSEC協議族類似，數據安全性部分功能則與MSEC協議族中使用的ESP，AH類似。將這兩者結合在同一個協議中可以方便地使用API對其進行封裝。
SMC協議由兩層協議構成，這與TLS、DTLS協議類似。這兩層分別是位于下層的SMC 記錄協議（SMC record protocol）和位于上層的SMC組密鑰管理協議（SMC GKM protocol），如圖1所示。SMC record層工作在傳輸層（多播環境下通常使用UDP）之上。
在多方通信環境中，共有組管理及密鑰服務器（GCKS）、發送者（sender）、接收者（receiver）三類主機[8]。
22SMC 記錄協議
SMC 記錄層主要功能是為上層數據提供數據壓縮、解壓縮、加密、解密及完整性驗證功能，用于保證上層數據的保密性和完整性。SMC 記錄層對上層數據進行處理的相關壓縮算法、加密算法、密鑰、完整性驗證算法等安全參數由相關會話的安全聯盟（security association，SA）和密鑰下載包（key download，KD)確定。
SMC記錄層存在著初始會話（initiation session）、密鑰更新會話（rekeying session）和數據安全會話（data-sec session）三種會話，每個會話的安全參數均由其對應的SA決定。三種不同會話在組播通信中的作用如圖2所示。
221初始會話
作為多播通信組的組員，sender與receiver必須向GCKS注冊，獲取通信組組內數據傳輸時采用的SA和KD。每個sender/receiver與GCKS間建立一個一對一的初始會話，建立過程與DTLS協議類似。Initiation session建立后，就相當于在sender/receiver與GCKS間建立了一條安全通道，可以供兩端進行數據的安全單播；然后，sender/receiver通過initiation session從GCKS獲取rekeying session SA、rekeying session KD、data-sec session SA、data-sec session KD以進行多播安全組通信。另外，在sender/receiver能夠正常進行安全組通信后，如果發生如其保存的組播密鑰失效等情況，則也可以通過initiation session從GCKS獲取新的安全參數。
222密鑰更新會話
為了實現組通信的前向保密性、后向保密性等安全要求，在組中有新成員加入、原有成員離開、組播通信密鑰失效等情況下，組播通信的密鑰必須進行變更以保障組內通信的安全。這種情況下，如何將GCKS產生的新密鑰向sender/receiver進行下發就成了一個問題。雖然GCKS已經和各個sender/receiver間擁有了initiation session這個安全通道，但是由GCKS逐一下發安全參數顯然是低效的。
密鑰更新會話的功能就是供GCKS向組員安全廣播data-sec session信息，其最重要的應用就是在組成員變動的情況下發送經過此會話所保護的新的data-sec session安全參數。另外，經由rekeying session保護的數據還包括組關閉警告等組通知信息。正常情況下每個多播通信組僅存在一個rekeying session。如果GCKS不需要對data-sec session進行更新，在協議實現時多播通信組中可以不存在rekeying session。
223數據安全會話
數據安全會話的功能是對多播傳輸數據流進行保護，其由GCKS確定，并通過initiation session或rekeying session下發給sender/receiver。Sender使用data-sec session對需要傳輸的多播數據進行保護，receiver在接收到多播數據后使用對應的data-sec session安全參數進行解密等操作，這樣就可以實現數據的安全傳播。
每個data-sec session對組內一條多播數據流進行保護。由于每個多播通信組可能存在多條數據流（如IPTV中每個多播組中可能有多個頻道），一個多播通信組可以存在多個data-sec session，每個data-sec session安全參數可以不同。Data-sec session安全參數由GCKS確定，但由于GCKS并不參與組多播通信數據的傳輸，在GCKS端并不存在data-sec session。
23SMC組密鑰管理協議
SMC記錄層被封裝以供上層的SMC組密鑰管理協議（SMC GKM protocol）調用。SMC GKM層為GCKS和sender/receiver提供相互驗證身份、協商并發布SA，協商并發布KD等功能。
SMC GKM協議包括三個子協議，分別是初始化子協議(initiation sub-protocol)、密鑰更新子協議(rekeying sub-protocol)和通知子協議(notification sub-protocol)。
231初始化子協議
初始化子協議定義了如何在GCKS與sender/receiver之間建立一對一的initiation session，以及sender/receiver如何通過建立的initiation session從GCKS獲取rekeying session、data-sec session的相關安全參數。
1)握手交互
握手交互用于建立一對一的initiation session，即為GCKS與sender/receiver之間的握手過程。握手過程如圖3所示，將握手雙方的GCKS作為server，sender/receiver作為client。
a)第一條握手消息由client向server發送，包括SAc、KEc、Nc。SAc指client所支持的所有SA，server從中選擇適當SA建立initiation session；KEc的定義與GDOI協議中一致；Nc為client發送的一個隨機數。
b)Server接收到第一條握手消息后，從SAc中選取一條本地支持的SA作為SAs（即initiation session的安全算法），同時server生成自己的KEs和Ns。最后server將SAs、KEs、Ns構成第二條握手消息發送給client端。證書請求字段CERTREQ是可選的，但如果雙方在握手前沒有預共享密鑰，第二條消息中必須包括此字段。
發送出第二條消息后，server通過DH算法從KEs、KEc、Ns、Nc中算出主密鑰，然后使用PRF算法對主密鑰進行變換以獲取initiation session的雙向加密密鑰和完整性保護密鑰。
c)Client在收到第二條消息后，同樣通過DH算法從KEs、KEc、Ns、Nc中算出主密鑰，然后通過PRF算法對主密鑰進行變換以獲取initiation session的雙向加密密鑰和雙向完整性保護密鑰，同時由SAs確定initiation session的安全算法。這樣通信雙方得以建立initiation session以保護雙方通信數據。
Client需要對之前握手信息的完整性進行確認以保障initiation session是安全的。Client將第一條注冊消息、Ns字段、client標志IDc字段連接在一起并計算其摘要值AUTH。計算AUTH所用密鑰為雙方預共享密鑰或Client證書公鑰，根據不同情況，client需要同時發送預共享密鑰標志IDkey或本地證書CERT。第三條注冊消息由以下字段構成：client標志IDc、申請加入的組的標志IDgroup、AUTH值、IDkey或CERT，證書請求CERTREQ（可選）。第三條消息的傳輸過程由initiation session進行保護。
d)Server收到第三條消息后，根據IDkey或CERT字段對client發送的AUTH值進行驗證，同時檢查對端client是否擁有加入IDgroup所對應組的權限。驗證通過后，server將client加入相應組，并將組中rekeying session和data-sec sessions的SAs、KDs發送給client。
第四條注冊消息由以下字段構成：server標志IDs、SAs、KDs、server端AUTH（由第二條消息、Nc、IDs計算），IDkey或CERT。其傳輸過程也由initiation session進行保護。
e)Client收到第四條注冊消息后，在對AUTH成功驗證后，便可以使用SAs和KDs建立相應的rekeying session和data-sec sessions，在組中進行安全通信。至此，握手過程結束。
由于傳輸層使用UDP，握手過程中不得不考慮的問題便是握手數據包可能會丟失。這個問題的解決方法是使用類似DTLS協議的超時重傳機制[4]。
2）下拉交互
下拉交互（pull exchange）的作用是供已經加入組中的sender/receiver通過單播方式經initiation session從GCKS獲取新的安全參數，以更新rekeying session和data-sec sessions。Sender/Receiver的下拉行為（pull）通常發生在其某個session無法正常通信，且GCKS沒有多播新的安全參數的情況下。
Sender/Receiver需要通過initiation session發送一條含有需要更新的組標志IDgroup的pull消息來進行pull操作。GCKS在收到這條消息后，對IDgroup對應的組進行權限認證，驗證成功后，將組中rekeying session和data-sec sessions的SAs、KDs發送給sender/receiver。這樣，就完成了一次pull操作。
232密鑰更新子協議
在組中新加入組員或組員離開時，為了保證組通信的保密性，就必須更新組通信密鑰，組密鑰的更新過程可以通過LKH等組密鑰管理算法實現[9]。新的安全參數被封裝在一條下發消息（push）中由GCKS通過組rekeying session向sender/receiver多播下發。Push消息一般包括data-sec sessions的SAs和KDs，rekeying session較少進行更新；但當rekeying session需要進行更新時，push消息中也包括rekeying session的SA和KD。所有sender/receiver在收到push消息后，通過檢查哪個rekeying session接收此消息便可以確定要更新的是哪個組，然后通過更新SA和KD來更新相應session。
233通知子協議
在組通信過程中，sender/receiver與GCKS間可能需要傳輸一些通知或告警信息以供對方處理，如sender/receiver通知離開組、組關閉通知、傳輸超時等。如果是單播的消息，通過sender/receiver與GCKS間的initiation session進行傳輸，如sender/receiver通知離開組信息；如果是GCKS需要通知所有組員的消息，由GCKS通過rekeying session多播發送，如組關閉消息。
3SMC協議與MSEC協議族的對比
SMC協議是作為MSEC協議族的替代協議被設計的，其相對于MSEC協議族的最大優勢在于：SMC協議在達到了MSEC協議族安全性要求的基礎上，具有更強的可部署性。以下從安全性、可部署性方面對兩者進行對比分析。
31安全性對比
311SMC協議安全性分析
SMC協議組通信的安全性建立在GCKS與sender/recei-ver間initiation session安全性的基礎上。在握手建立initiation session的過程中，雙方首先在第一條和第二條握手消息中通過DH算法在兩端計算出相同的密鑰材料（key material）。在這個過程中，只要頭兩條握手消息未被竄改，DH公鑰算法就能夠確保所產生的密鑰材料的私密性，也即能保證由密鑰材料計算出的initiation session雙向加密密鑰和完整性保護密鑰的安全性。而保障頭兩條握手消息的完整性是通過第三條和第四條握手消息中的AUTH值來實現的。AUTH值由頭兩條握手消息中關鍵信息計算得出。計算有兩種方法：使用通信雙方在握手進行前所預共享的密鑰對關鍵信息計算HMAC值作為AUTH；使用握手過程中對端發送的證書對關鍵信息進行簽名并將簽名值作為AUTH。通信雙方向對方發送由頭兩條握手消息中關鍵信息計算得出的本端AUTH，并在收到對端所發送的AUTH值后與根據本地所保存的消息計算得出的AUTH值對比。如果對比結果一致則說明頭兩條消息未被竄改；否則頭兩條握手消息可能被竄改，握手過程失敗，握手過程中斷。通過這樣的握手過程就可以保證所建立的initiation session的安全性。
在建立initiation session后，sender/receiver就可以安全地通過此會話獲取rekeying session和data-sec sessions相關安全參數以建立相應會話。之后，在組中成員發生變動時，新的安全參數可以通過rekeying session安全下發。組成員變動時，GCKS的SMC GKM層首先產生新的data-sec sessions安全參數，然后根據適當的組密鑰管理算法（如LKH）用舊的data-sec sessions安全參數加密新的data-sec sessions安全參數，并經rekeying session向所有組成員多播。在使用合理組密鑰管理算法的情況下，可以保證離開的組員無法再解密組通信內容（即離開的組員不能使用自己舊的data-sec sessions安全參數解密新的data-sec sessions安全參數）、新加入的組員無法解密加入前組通信內容，從而保障組內通信數據的安全性。由于在SMC GKM層已完成了對新安全參數的加密，GCKS的rekeying session無須對GKM數據再進行加密，只需使用自己的證書對消息進行簽名以確保消息的傳輸過程中未經竄改即可。
這樣，在保障了SMC協議initiation session和rekeying session安全性的基礎上，Sender/Receiver可以安全地從GCKS獲取并更新data-sec sessions安全參數，從而實現安全組通信的目標。
由于工作在UDP之上，SMC協議通過在SMC 記錄協議中加入序列編號字段以實現抗重放攻擊。為了防止DoS攻擊，可以在握手過程中加入cookie驗證過程。這些方法與DTLS協議中相關方法一致。
312與MSEC協議族的對比
MSEC工作組制定的現有多播安全協議（GDOI[5]、MIKEY[6]等）具有完善的安全機制，能夠保障多播通信環境下的安全需求。
由3.1.1節可見，在多播通信環境下部署SMC協議可以保障多播通信數據的保密性，其在安全性上的表現和MSEC協議族一致，都能夠保障多播通信的安全性。
32可部署性對比
如2.2節所述，MSEC協議族目前主要支持的ESP和AH這兩種協議均在IP層實現，需要運行于操作系統的內核中，這種實現方式由于不能提供標準的數據安全API調用接口而使得程序可移植性較差。同時由于不同操作系統對ESP和AH的實現可能不同，導致基于MSEC協議族的應用程序可移植性較差。
SMC協議只是在傳輸層和應用層間增加了一個SMC層以實現安全多播的功能，并提供了標準的API接口供上層調用。SMC協議的實現以一個獨立功能模塊的形式獨立于傳輸層與應用層，無須對上下層進行任何修改，因此基于SMC協議的應用程序具有更強的可部署性，應用范圍也會更加廣泛。
33SMC協議驗證
為了測試SMC協議在多播環境中的實際運行效果，搭建了一個含有五臺運行了Red Hat Linux 9.0的計算機局域網作為實驗環境，SMC協議的實現采用了LKH組密鑰管理算法，分為服務器端的實現和客戶端實現。實驗環境五臺計算機中一臺安裝服務器端實現，另外四臺計算機安裝SMC協議的客戶端實現。
實驗中，首先運行服務器端以初始化組安全參數，然后運行另外四臺客戶端先后加入組中。以其中一臺客戶端作為發送者向另三臺客戶端不斷發送信息，同時服務器端對組安全參數定時進行更新；最后，三臺接收者先后離開組。
在測試中，每加入一個新的客戶端時，服務器端就會更新一次組安全參數并進行下發，保障了多播通信能夠順利進行，接收者能夠接收并解密發送者所發送的信息。新加入客戶端由于無法獲得加入前的組安全參數，保障了其加入前的傳輸信息不會被泄露。在將四臺客戶端全部加入組后，服務器定時通過多播更新組安全參數，實驗結果同樣證明客戶端可以實時更新組密鑰并使用最新的組安全密鑰進行數據的加/解密。最后，每離開一個接收者時，服務器端也會更新一次組安全參數并進行下發，余下的所有客戶端機器使用更新后的組安全參數進行數據的收發。離開后的客戶端使用舊的組安全參數無法再解密多播信息，保證了其離開后組播數據的安全性。
從測試中可看出，組內通信的保密性是可以保證的。在更新組安全參數時，新的安全參數根據SMC協議進行下發并更新，從而保障了組內通信數據的前向保密性和后向保密性。
4結束語
本文從分析各主流安全協議在多播組通信環境下部署的優缺點入手，綜合各協議在可部署性、可移值性、協議安全性的優點，并在充分考慮新協議可能遭受的安全威脅的基礎上，設計出一個新的、專用于多播組通信環境下的安全協議。這個協議同IETF MSEC工作組多播安全協議相比，其主要優點在于安全性未被削弱的情況下具有更強的可移植性和可部署性，因此該協議可以在多種應用環境下取代現有多播安全協議。
參考文獻：
[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.
