一種安全組播密鑰管理機制的制作方法
【專利摘要】本發(fā)明公開了一種安全組播密鑰管理機制，包括：client向server發(fā)起注冊；server收到client的報文驗證通過后，向client發(fā)送組密鑰分發(fā)報文；client向server回復(fù)確認(rèn)報文；server向client發(fā)送組策略分發(fā)報文；client向server回復(fù)確認(rèn)報文；client在獲得組密鑰和組策略后，生成IPSecSA、IPSecSP等步驟。本發(fā)明不僅能夠?qū)崿F(xiàn)組密鑰的生成、分發(fā)與管理，還為組播訪問控制提供安全策略，最終實現(xiàn)組播的安全傳輸。且在部署時無需改變組播轉(zhuǎn)發(fā)機制與組播路由，封裝后的數(shù)據(jù)仍然是組播報文，組播單點發(fā)送、多點接收的帶寬節(jié)約機制能夠得到完整保留。
【專利說明】一種安全組播密鑰管理機制
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及通信【技術(shù)領(lǐng)域】，尤其涉及安全組播加密傳輸和組播密鑰管理的方法?！颈尘凹夹g(shù)】
[0002]組播技術(shù)是一種新的、高效的網(wǎng)絡(luò)傳輸方案，它是一種介于單播和廣播之間的面向組的數(shù)據(jù)傳輸方式，不僅能夠?qū)崿F(xiàn)單點發(fā)送、多點接收，還有實現(xiàn)感興趣的主機能夠接收、不感興趣的主機不會收到組播報文。組播能夠?qū)崿F(xiàn)靈活的信息批量發(fā)送，減少冗余流量，有效節(jié)約網(wǎng)絡(luò)帶寬、降低網(wǎng)絡(luò)負(fù)載。
[0003]組播相對于單播，信息源只需要發(fā)送一份數(shù)據(jù)到網(wǎng)絡(luò)中，在組播樹的分支節(jié)點處才會出現(xiàn)信息復(fù)制，而非信息源對每個接收者的一對一信息傳送，很大程度上減少信息源的負(fù)載及網(wǎng)絡(luò)的開銷。
[0004]組播通信不同于單播通信，組播信息只有加入組播組的用戶才能收到，并非網(wǎng)絡(luò)中所有用戶都會收到組播信息，有效地減少網(wǎng)絡(luò)負(fù)擔(dān)，并且提高信息傳輸?shù)陌踩浴?br> [0005]在公網(wǎng)上實現(xiàn)安全的數(shù)據(jù)傳輸，IPSec VPN無疑是當(dāng)今最成熟且最被認(rèn)可的技術(shù)，遺憾的是，IPSec VPN是針對單播數(shù)據(jù)設(shè)計的，其數(shù)據(jù)流是點對點的封裝，無法做到點到多點的安全傳輸。若非要將IPSec用于組播數(shù)據(jù)的加密，只能先將組播數(shù)據(jù)封裝到GRE隧道中，再對每一條GRE隧道做IPSec封裝。這樣能保證組播數(shù)據(jù)安全傳送(加密性、完整性、不可否認(rèn)性、抗重放)，代價卻是大大增加了帶寬，不僅報文數(shù)量由一條組播報文變成了多條單播報文復(fù)本，GRE頭與IPSec頭(AH頭/ESP頭)的封裝也增大了帶寬開銷。

【發(fā)明內(nèi)容】

[0006]為了克服現(xiàn)有技術(shù)的上述缺點，本發(fā)明提供了一種安全組播密鑰管理機制。
[0007]本發(fā)明解決其技術(shù)問題所采用的技術(shù)方案是:一種安全組播密鑰管理機制，包括如下步驟:
步驟一、選定SKDC server,并在server上配置組播參數(shù)；Server啟動后,通過配置信息生成初始的組密鑰材料與IPSec SPI ；
步驟二、在組播成員網(wǎng)絡(luò)中所有需要參與組播通信的設(shè)備上運行SKDC client,并為client配置參數(shù)；
步驟三、client向server發(fā)起注冊；
步驟四、server收到client的報文,對client的合法性驗證通過后，向client發(fā)送組密鑰分發(fā)報文；
步驟五、client向server回復(fù)ACK確認(rèn)報文；
步驟六、server向client發(fā)送組策略分發(fā)報文；
步驟七、client向server回復(fù)ACK確認(rèn)報文；
步驟八、client在獲得組密鑰和組策略后，生成IPSec SA、IPSec SP0
[0008]與現(xiàn)有技術(shù)相比，本發(fā)明的積極效果是:本發(fā)明提出了一種安全組播密鑰管理與分發(fā)機制，不僅能夠?qū)崿F(xiàn)組密鑰的生成、分發(fā)與管理，還為組播訪問控制提供安全策略，最終實現(xiàn)組播的安全傳輸。本發(fā)明在部署時無需改變組播轉(zhuǎn)發(fā)機制與組播路由，封裝后的數(shù)據(jù)仍然是組播報文，組播單點發(fā)送、多點接收的帶寬節(jié)約機制能夠得到完整保留。
【專利附圖】

【附圖說明】
[0009]本發(fā)明將通過例子并參照附圖的方式說明，其中:
圖1是本發(fā)明的流程示意圖；
圖2是SKDC server與client的報文交互不例圖。
【具體實施方式】
[0010]網(wǎng)絡(luò)中某臺服務(wù)器設(shè)備為整個組播成員網(wǎng)絡(luò)(將組播網(wǎng)絡(luò)中實際的組播信息發(fā)送者與實際的組播信息接收者組成的網(wǎng)絡(luò)稱為組播成員網(wǎng)絡(luò))提供密鑰管理，并由這臺服務(wù)器設(shè)備統(tǒng)一為所有組播成員分發(fā)組密鑰和組策略。組播成員收到組密鑰和組策略后組裝成IPSec SA與IPSec SP，便可像封裝普通單播報文一樣使用IPSec加解密組播報文。
[0011]這臺服務(wù)器設(shè)備稱之為SKDC (simple key distribution center,簡單密鑰分發(fā)中心)server，主要負(fù)責(zé)如下工作:
1、組密鑰的生成、維護(hù)與分發(fā):
其中組密鑰包括的元素有:
(1)IPSec用于數(shù)據(jù)加密的加密算法、對稱密鑰；
(2)IPSec用于校驗的HASH算法、HMAC密鑰；
(3)組密鑰生存周期。
[0012]2、IPSec SPI的生成、維護(hù)與分發(fā)；
3、組策略的維護(hù)與分發(fā)；
4、組播組成員接入訪問控制；
5、組成員列表的維護(hù)。
[0013]組播成員網(wǎng)絡(luò)中所有需要組播通信的設(shè)備統(tǒng)稱為SKDC client，主要完成如下工作:
1、向server發(fā)起注冊；
2、接收server下發(fā)的組密鑰材料；
3、接收server下發(fā)的組策略；
4、根據(jù)密鑰材料和組策略生成IPSecSA、IPSec SP ；
5、根據(jù)組策略結(jié)合自身接口信息生成組播路由；
6、根據(jù)組策略生成組播訪問控制(命中訪問控制的組播數(shù)據(jù)需要進(jìn)行IPSec加密封裝，否則透傳)。
[0014]Server與client的部署是獨立的。Server既可以部署在組播成員網(wǎng)絡(luò)內(nèi)某臺參與組播通信的成員上，也可以部署在組播成員網(wǎng)絡(luò)外的設(shè)備上。client部署在所有參與組播通信的成員上。
[0015]整個系統(tǒng)中某一時刻只有一臺server在工作。
[0016]Server與client的SKDC通信報文屬于控制報文的范疇，由server與client間單播發(fā)送。
[0017]Server與client的控制報文有如下幾類:
1> Client向server的注冊報文(注冊報文中需攜帶client的數(shù)字證書)；
2、Server發(fā)向client的組密鑰分發(fā)報文；
3、Server向client的組策略分發(fā)報文；
4、Client向server的ACK確認(rèn)報文；
SKDC控制報文的通信安全由數(shù)字信封的方式保證。Server與client必須支持?jǐn)?shù)字證書，并支持非對稱加密算法用于加密、解密與簽名、驗簽。
[0018]具體實施時，為保證本發(fā)明能達(dá)到預(yù)期目的，需要server與client滿足如下要求:
(I)對server的要求:server本身可以參與組播通信，也可以不參與，即server可以是組播組成員，也可不是組播組成員server必需與所有參與組播通信的設(shè)備互聯(lián)；server必需有固定的IP地址或固定的可解析的DNS地址；server須支持?jǐn)?shù)字證書體系并擁有自己的數(shù)字證書與私鑰證書對。
[0019](2)對client的要求:client須支持?jǐn)?shù)字證書體系并擁有自己的數(shù)字證書與私鑰證書；client在運行SKDC前需獲取到server的數(shù)字證書。
[0020]一種安全組播密鑰管理機制，如圖1和圖2所示，包括如下步驟:
步驟一、選定SKDC server,并在server上配置組播的如下參數(shù):
配置管理員在整個組播成員網(wǎng)絡(luò)中選取任一臺設(shè)備用作SKDC server ;配置管理員在server上配置組播的如下參數(shù):
1、用于IPSec加密的對稱加密算法；
2、用于IPSec認(rèn)證的HASH算法；
3、組密鑰生存周期；
4、組密鑰軟過期時間裕度；
5、報文過期重發(fā)時間時隔；
6、報文過期重發(fā)次數(shù)上限；
7、組播組策略；
Server啟動后，通過配置信息生成初始的組密鑰材料與IPSec SPI。
[0021]步驟二、在組播成員網(wǎng)絡(luò)中所有需要參與組播通信的設(shè)備上運行SKDC client，并為client配置如下參數(shù):
1、SKDCserver 地址；
2、client的接入地址；
3、client所屬的組播組；
步驟三、client向server發(fā)起注冊；
步驟四、server收到client的報文,對client的合法性驗證通過后，向client發(fā)送組密鑰分發(fā)報文。組密鑰分發(fā)報文中包含用于IPSec的對稱加密算法、用于IPSec的對稱加密算法密鑰、用于IPSec的HASH算法、用于IPSec的HMAC密鑰、組密鑰生存時間、IPSecSPI 等；
步驟五、client向server回復(fù)ACK確認(rèn)報文。[0022]步驟六、server向client發(fā)送組策略分發(fā)報文。
[0023]步驟七、client向server回復(fù)ACK確認(rèn)報文。
[0024]步驟八、client在獲得組密鑰和組策略后，生成IPSec SA、IPSec SP0
[0025]第四步或第六步后若出現(xiàn)如下兩種情況:
情況一:server向client的分發(fā)報文已經(jīng)成功發(fā)出，但出于某種原因client并未收到此分發(fā)報文；
情況二:server向client的分發(fā)報文已經(jīng)成功發(fā)出，且client向server的ACK確認(rèn)報文也成功發(fā)出，但出于某種原因server并未收到此ACK報文；
貝U，server將會在過期重發(fā)時間間隔之后，重新發(fā)送分發(fā)報文(組密鑰分發(fā)報文或組策略分發(fā)報文);如若server已重發(fā)的次數(shù)達(dá)到重發(fā)次數(shù)上限，server便認(rèn)為此client已斷線，將不再維護(hù)此client的接入信息。
[0026]在第四步之后若出現(xiàn)如下情況server生成(或更新)組密鑰后，系統(tǒng)運行了time_intervall (time_intervall =組密鑰過期時間-組密鑰軟過期裕度)時長的時間，則:server發(fā)生rekey,重新生成組密鑰并分發(fā)給各個client,并要求各個client在接下來的time_interval2 (time_interval2 =組密鑰軟過期裕度)時長內(nèi)維護(hù)新舊密鑰的共存，新舊密鑰都是激活的，新舊密鑰都可用于解密報文，但僅新密鑰才能被用于加密報文，待運行time_interval2時長后,廢棄掉舊組密鑰。
[0027]在第四步之后若出現(xiàn)如下情況server出于某種原因突然出現(xiàn)網(wǎng)絡(luò)中斷故障或出現(xiàn)系統(tǒng)重啟，則server在恢復(fù)正常工作后，重新生成組密鑰并分發(fā)給各個client，并要求各client立即運行新組密鑰同時廢棄舊組密鑰。
[0028]在第八步之后若出現(xiàn)如下情況:client出于某種原因突然出現(xiàn)網(wǎng)絡(luò)中斷故障或出現(xiàn)系統(tǒng)重啟，則:client在恢復(fù)正常工作后,立即向server上報狀態(tài)或向server重新發(fā)起注冊。
【權(quán)利要求】
1.一種安全組播密鑰管理機制，其特征在于:包括如下步驟: 步驟一、選定SKDC server,并在server上配置組播參數(shù)；Server啟動后,通過配置信息生成初始的組密鑰材料與IPSec SPI ； 步驟二、在組播成員網(wǎng)絡(luò)中所有需要參與組播通信的設(shè)備上運行SKDC client，并為client配置參數(shù)； 步驟三、client向server發(fā)起注冊； 步驟四、server收到client的報文,對client的合法性驗證通過后，向client發(fā)送組密鑰分發(fā)報文； 步驟五、client向server回復(fù)ACK確認(rèn)報文； 步驟六、server向client發(fā)送組策略分發(fā)報文； 步驟七、client向server回復(fù)ACK確認(rèn)報文； 步驟八、client在獲得組密鑰和組策略后，生成IPSec SA、IPSec SP0
2.根據(jù)權(quán)利要求1所述的一種安全組播密鑰管理機制，其特征在于:在在server上配置的組播參數(shù)包括: 1)用于IPSec加密的對稱加密算法； 2)用于IPSec認(rèn)證的HASH算法； 3)組密鑰生存周期； 4)組密鑰軟過期時間裕度； 5)報文過期重發(fā)時間時隔； 6)報文過期重發(fā)次數(shù)上限； 7)組播組策略。
3.根據(jù)權(quán)利要求1所述的一種安全組播密鑰管理機制，其特征在于:為client配置的參數(shù)包括:
1)SKDC server 地址； 2)client的接入地址； 3)client所屬的組播組。
4.根據(jù)權(quán)利要求1所述的一種安全組播密鑰管理機制，其特征在于:所述組密鑰分發(fā)報文中包含用于IPSec的對稱加密算法、用于IPSec的對稱加密算法密鑰、用于IPSec的HASH算法、用于IPSec的HMAC密鑰、組密鑰生存時間、IPSec SPI等。
5.根據(jù)權(quán)利要求1所述的一種安全組播密鑰管理機制，其特征在于:在第四步或第六步之后若出現(xiàn)如下兩種情況: 情況一:server向client的分發(fā)報文已經(jīng)成功發(fā)出，但出于某種原因client并未收到此分發(fā)報文； 情況二:server向client的分發(fā)報文已經(jīng)成功發(fā)出，且client向server的ACK確認(rèn)報文也成功發(fā)出，但出于某種原因server并未收到此ACK報文； 則:server將會在過期重發(fā)時間間隔之后,重新發(fā)送分發(fā)報文；如若server已重發(fā)的次數(shù)達(dá)到重發(fā)次數(shù)上限，server便認(rèn)為此client已斷線,將不再維護(hù)此client的接入信肩、O
6.根據(jù)權(quán)利要求1所述的一種安全組播密鑰管理機制，其特征在于:在第四步之后若出現(xiàn)如下情況:server生成或更新組密鑰后,系統(tǒng)運行了 time_intervall時長的時間，則:server發(fā)生rekey,重新生成組密鑰并分發(fā)給各個client,并要求各個client在接下來的time_interval2時長內(nèi)維護(hù)新舊密鑰的共存，新舊密鑰都是激活的，新舊密鑰均用于解密報文，但僅有新密鑰被用于加密報文，待運行time_interVal2時長后，廢棄掉舊組密鑰。
7.根據(jù)權(quán)利要求1所述的一種安全組播密鑰管理機制，其特征在于:在第四步之后若出現(xiàn)如下情況server出于某種原因突然出現(xiàn)網(wǎng)絡(luò)中斷故障或出現(xiàn)系統(tǒng)重啟，則server在恢復(fù)正常工作后，重新生成組密鑰并分發(fā)給各個client，并要求各client立即運行新組密鑰，同時廢棄舊組密鑰。
8.根據(jù)權(quán)利要求1所述的一種安全組播密鑰管理機制，其特征在于:在第八步之后若出現(xiàn)如下情況=Client出于某種原因突然出現(xiàn)網(wǎng)絡(luò)中斷故障或出現(xiàn)系統(tǒng)重啟，則:client在恢復(fù)正常工作后，立即向server上報狀態(tài)或向server重新發(fā)起注冊。
【文檔編號】H04L9/08GK103546279SQ201310515942
【公開日】2014年1月29日 申請日期:2013年10月28日 優(yōu)先權(quán)日:2013年10月28日
【發(fā)明者】王龍喜, 梁霞 申請人:成都衛(wèi)士通信息產(chǎn)業(yè)股份有限公司