專(zhuān)利名稱(chēng)：一種對(duì)網(wǎng)絡(luò)報(bào)文安全封裝的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種報(bào)文封裝的方法，尤其涉及的是，一種實(shí)現(xiàn)對(duì)網(wǎng)絡(luò)報(bào)文進(jìn)行安全封裝的方法。
背景技術(shù)：
在下一代網(wǎng)絡(luò)NGN及IP多媒體子系統(tǒng)IMS等各種基于分組網(wǎng)的業(yè)務(wù)網(wǎng)絡(luò)架構(gòu)中，報(bào)文的安全性是一個(gè)基本的需求，應(yīng)當(dāng)有一種手段可以為網(wǎng)絡(luò)報(bào)文提供源認(rèn)證、完整性、機(jī)密性和防重放等安全特性。這些特性一般采用各種簽名、哈希、加密安全算法獲得，但以什么方式組合這些基本安全算法，可以達(dá)到最好的安全性，可以滿(mǎn)足特定的應(yīng)用環(huán)境是現(xiàn)有技術(shù)沒(méi)有公開(kāi)的。
對(duì)網(wǎng)絡(luò)報(bào)文進(jìn)行安全封裝，目前采用的普遍有兩種方法網(wǎng)絡(luò)層安全技術(shù)IPsec以及傳輸層安全技術(shù)TLS技術(shù)；但他們的應(yīng)用都有一定的局限性，特別是在NGN以及IMS等基于分組網(wǎng)的業(yè)務(wù)網(wǎng)絡(luò)中，以下分別加以說(shuō)明，以使現(xiàn)有技術(shù)的缺陷一目了然。
在采用IPsec ESP(RFC 2406、RFC 2402)的方法中，由于目前業(yè)界網(wǎng)絡(luò)層的安全協(xié)議就是IPSec，在許多應(yīng)用協(xié)議安全保護(hù)中都提到了通過(guò)在網(wǎng)絡(luò)層應(yīng)用IPSec解決協(xié)議通信過(guò)程中的安全問(wèn)題，在業(yè)界NGN的安全方案，也提到通過(guò)IPSec來(lái)解決NGN的網(wǎng)絡(luò)安全問(wèn)題。IPSec是由IETF的安全協(xié)議工作組制定的一個(gè)關(guān)于IP安全和密鑰管理的協(xié)議，以確保在IP協(xié)議層上保證數(shù)據(jù)分組在Internet網(wǎng)絡(luò)中具有互操作性、高可靠性和基于密碼技術(shù)的安全服務(wù)標(biāo)準(zhǔn)，提供訪(fǎng)問(wèn)控制、無(wú)連接完整性、數(shù)據(jù)源鑒別、負(fù)荷機(jī)密性等安全服務(wù)。
IPSec的體系如圖1所示，由兩種通信安全協(xié)議驗(yàn)證頭AH和安全載荷封裝ESP，以及密鑰交換管理協(xié)議-Internet密鑰交換IKE和支撐的安全策略與聯(lián)盟數(shù)據(jù)庫(kù)組成所述驗(yàn)證頭AH將每個(gè)數(shù)據(jù)報(bào)中的數(shù)據(jù)和一個(gè)變化的數(shù)字簽名結(jié)合起來(lái)，共同驗(yàn)證報(bào)文發(fā)送方身份，使得通信一方能確認(rèn)發(fā)送數(shù)據(jù)方的身份，并能夠確認(rèn)數(shù)據(jù)在傳輸過(guò)程中數(shù)據(jù)有沒(méi)有被篡改，同時(shí)協(xié)議機(jī)制能提供防重放攻擊保護(hù)，但不提供報(bào)文數(shù)據(jù)加密服務(wù)。
所述安全載荷封裝ESP提供了一種對(duì)IP報(bào)文負(fù)荷進(jìn)行加密的機(jī)制，使得網(wǎng)絡(luò)監(jiān)聽(tīng)者即便能捕獲報(bào)文，也無(wú)法獲取其中的數(shù)據(jù)信息，同時(shí)提供驗(yàn)證頭AH所能提供的源驗(yàn)證服務(wù)、完整性保護(hù)、防重放攻擊保護(hù)等功能。
所述密鑰管理采用IKE，這是一種分散式的功能強(qiáng)大的、靈活的密鑰管理協(xié)商協(xié)議，提供安全可靠的算法和密鑰協(xié)商，幫助網(wǎng)絡(luò)不同節(jié)點(diǎn)之間達(dá)成安全的通信的協(xié)定，包括認(rèn)證方法、加密方法、采樣的密鑰、密鑰的生存時(shí)間，以及安全的密鑰交換等等。
所述安全策略SP和安全聯(lián)盟SA數(shù)據(jù)庫(kù)則為IPSec應(yīng)用的基礎(chǔ)，定義了對(duì)每一個(gè)流的安全策略即是否應(yīng)用IPSec，若應(yīng)用安全策略，則給出相應(yīng)的安全聯(lián)盟索引，而SA則給出了對(duì)應(yīng)于IPSec應(yīng)用時(shí)，使用的安全協(xié)議、工作模式、加密/認(rèn)證算法、密鑰以及密鑰的生存期等參數(shù)。
解釋域DOI則定義了安全聯(lián)盟所對(duì)應(yīng)的協(xié)議及該協(xié)議所對(duì)應(yīng)的安全聯(lián)盟參數(shù)內(nèi)容，此處則為IPSec域。
根據(jù)上面的描述，現(xiàn)有技術(shù)的IPSec工作模式中，IPSec提供兩種工作模式傳送模式和隧道模式。傳送模式仍然使用報(bào)文原有的明文IP頭作為應(yīng)用IPSec后的IP頭，保留了原報(bào)文的IP頭信息，即源、目的地址不變，所有安全相關(guān)的信息包括在A(yíng)H/ESP的協(xié)議頭中；隧道模式則對(duì)整個(gè)原始IP報(bào)文進(jìn)行IPSec處理，并用具有IPSec功能設(shè)備自己的地址作為源地址、對(duì)端具有IPSec功能設(shè)備的地址作為目的地址加入到新的頭中，對(duì)原始報(bào)文進(jìn)行IPSec處理后的安全相關(guān)信息位于A(yíng)H/ESP頭中。通常傳傳輸模式用于主機(jī)設(shè)備之間的傳送，而隧道模式更適合于網(wǎng)絡(luò)設(shè)備之間應(yīng)用完成多個(gè)主機(jī)之間的安全交互。
但現(xiàn)有技術(shù)的IPsec具有以下缺陷其應(yīng)用存在嚴(yán)重的與NAT的友好性問(wèn)題，而在實(shí)際的網(wǎng)絡(luò)環(huán)境中存在很多的NAT設(shè)備。IPsec的UDP封裝可以解決NAT問(wèn)題，但通信設(shè)備必須采用支持NAT穿越的IKE版本(相當(dāng)于IKEv2)，而且密鑰協(xié)商或安全聯(lián)盟建立需要通過(guò)IKE來(lái)完成，不支持手工配置方式來(lái)建立安全聯(lián)盟，或其它應(yīng)用層的安全聯(lián)盟建立方式，如3GPP規(guī)范中定義的IMS AKA安全聯(lián)盟建立方式。其實(shí)現(xiàn)過(guò)于復(fù)雜，要求通信設(shè)備雙方定期發(fā)送NAT保活報(bào)文，確保NAT設(shè)備上的NAT表項(xiàng)不被老化。
在采用TLS(RFC 2246)的方法中，該安全協(xié)議是建立在傳輸層協(xié)議TCP的基礎(chǔ)之上，為上層的應(yīng)用協(xié)議提供安全保障，典型的基于TCP的傳輸層協(xié)議包括SSL和PCT協(xié)議，為了避免協(xié)議的混亂、以及協(xié)議的擴(kuò)展性和兼容性，目前上述協(xié)議已發(fā)展為統(tǒng)一的IETF標(biāo)準(zhǔn)-傳輸層安全協(xié)議TLS。在很多協(xié)議的標(biāo)準(zhǔn)中都提到了通過(guò)TLS來(lái)保證協(xié)議通信的安全。
TLS提供基于PKI公鑰架構(gòu)下的安全服務(wù)，包括單向或雙向的身份認(rèn)證，要求服務(wù)器提供證書(shū)，客戶(hù)端證書(shū)可選或者通過(guò)客戶(hù)端輸入用戶(hù)名/口令方式來(lái)進(jìn)行認(rèn)證，同時(shí)提供報(bào)文的保密性服務(wù)。
TLS協(xié)議由兩層構(gòu)成，底層的TLS Record協(xié)議和高層的TLS Handshake協(xié)議，其中TLS Handshake協(xié)議又包括三個(gè)子協(xié)議TLS握手協(xié)議、TLS密碼變化協(xié)議和TLS告警協(xié)議。所述TLS Record協(xié)議提供分段、壓縮、數(shù)據(jù)認(rèn)證和加密功能，用于加密封裝各種更高級(jí)的應(yīng)用層協(xié)議，如HTTP、SIP等，建立在可靠的傳輸協(xié)議(如TCP)之上，通過(guò)對(duì)稱(chēng)加密算法對(duì)應(yīng)用層報(bào)文加密提供機(jī)密性服務(wù)和報(bào)文驗(yàn)證算法提供報(bào)文完整性服務(wù)來(lái)一起提供連接的安全性保證，整個(gè)記錄協(xié)議處理過(guò)程為現(xiàn)有技術(shù)所公開(kāi)，在此不再贅述。所述TLS Handshake協(xié)議實(shí)現(xiàn)客戶(hù)和服務(wù)器之間的一方(主要對(duì)服務(wù)器)或雙向認(rèn)證，協(xié)商記錄協(xié)議中用到的加密算法和密鑰及驗(yàn)證算法和密鑰，協(xié)商得到的會(huì)話(huà)參數(shù)供記錄協(xié)議為多個(gè)連接重復(fù)使用，避免每個(gè)連接協(xié)商新的會(huì)話(huà)參數(shù)所帶來(lái)的開(kāi)銷(xiāo)。同時(shí)協(xié)議保證協(xié)商過(guò)程是可靠的及協(xié)商得到的共享密鑰是安全的。
但是采用TLS，身份認(rèn)證密鑰協(xié)商與報(bào)文安全封裝被強(qiáng)制相關(guān)，使得應(yīng)用非常不靈活，另外TLS身份認(rèn)證和密鑰協(xié)商流程非常復(fù)雜，開(kāi)銷(xiāo)較大。在很多情況下并不需要這么復(fù)雜的認(rèn)證過(guò)程。其次，采用TLS只能用于TCP環(huán)境中，而目前UDP應(yīng)用將越來(lái)越廣泛，特別是NGN、IMS環(huán)境下，大部分協(xié)議將采用UDP協(xié)議，造成無(wú)法利用TLS的安全機(jī)制。而且，其不支持手工配置方式來(lái)建立安全聯(lián)盟，或其它應(yīng)用層的安全聯(lián)盟建立方式，如3GPP規(guī)范中定義的IMS AKA安全聯(lián)盟建立方式。
因此，現(xiàn)有技術(shù)存在缺陷，而有待于繼續(xù)改進(jìn)和發(fā)展。

發(fā)明內(nèi)容
本發(fā)明的目的在于提供一種對(duì)網(wǎng)絡(luò)報(bào)文安全封裝的方法，實(shí)現(xiàn)網(wǎng)絡(luò)報(bào)文的獨(dú)立安全封裝，可以非常靈活的應(yīng)用；同時(shí)也不存在NAT穿越問(wèn)題，其與傳輸層協(xié)議無(wú)關(guān)，無(wú)論TCP還是UDP都可適用。
本發(fā)明的技術(shù)方案包括一種對(duì)網(wǎng)絡(luò)報(bào)文安全封裝的方法，其包括以下步驟A、產(chǎn)生應(yīng)用層報(bào)文；B、封裝頭，產(chǎn)生一隨機(jī)數(shù)作為初始序列號(hào)，每發(fā)送一個(gè)報(bào)文序列號(hào)進(jìn)行變化，并將序列號(hào)以及報(bào)文長(zhǎng)度字節(jié)作為封裝頭附加到報(bào)文中；C、負(fù)載填充；D、對(duì)報(bào)文加密，將應(yīng)用層報(bào)文以及后面的附加填充字段一起用加密算法和加密密鑰進(jìn)行加密運(yùn)算；E、消息認(rèn)證碼計(jì)算，將完整性檢測(cè)的會(huì)話(huà)密鑰附加到封裝頭前面對(duì)整個(gè)報(bào)文進(jìn)行哈希計(jì)算，并將輸出字節(jié)附加到填充字段后面，作為報(bào)文消息認(rèn)證碼；F、將安全封裝后的信令報(bào)文封裝IP/UDP頭進(jìn)行發(fā)送。
所述的方法，其中，所述步驟D的加密不對(duì)封裝頭進(jìn)行，并且所述會(huì)話(huà)密鑰只參與報(bào)文哈希計(jì)算，不作為報(bào)文的一部分。
所述的方法，其中，所述步驟D的加密算法為AES算法。
所述的方法，其中，所述步驟B中的有序變化為在每發(fā)送一個(gè)報(bào)文時(shí)，序列號(hào)加一。
所述的方法，其中，所述步驟C中，其最后一字節(jié)表示填充長(zhǎng)度。
所述的方法，其中，還包括安全驗(yàn)證流程，包括步驟A1、接受網(wǎng)絡(luò)報(bào)文數(shù)據(jù)包；B1、映射安全關(guān)聯(lián)，根據(jù)源目的IP地址端口號(hào)信息，獲取所協(xié)商或者手工配置的相關(guān)的會(huì)話(huà)密鑰、加密認(rèn)證算法，安全封裝格式信息；C1、對(duì)序列號(hào)進(jìn)行檢查，根據(jù)源目的IP地址端口號(hào)信息，獲取本會(huì)話(huà)的序列號(hào)窗口，如果本數(shù)據(jù)包序列號(hào)落入窗口之內(nèi)，則接收，否則丟棄該數(shù)據(jù)包；D1、對(duì)完整性進(jìn)行檢測(cè)，邊界點(diǎn)利用密鑰協(xié)商階段獲得的完整性檢測(cè)會(huì)話(huà)密鑰以及數(shù)據(jù)報(bào)文信息完成檢測(cè)，如果數(shù)據(jù)包完整性檢測(cè)成功，則繼續(xù)進(jìn)行下面處理，否則丟棄該數(shù)據(jù)包；E1、對(duì)數(shù)據(jù)包進(jìn)行利用相應(yīng)的密鑰和加密算法進(jìn)行解密；F1、加密數(shù)據(jù)長(zhǎng)度應(yīng)該與填充長(zhǎng)度與源數(shù)據(jù)包長(zhǎng)度之和相同，之后去掉填充字節(jié)；G1、將報(bào)文進(jìn)行相應(yīng)的應(yīng)用層處理。
本發(fā)明所提供的一種對(duì)網(wǎng)絡(luò)報(bào)文安全封裝的方法，由于采用應(yīng)用層封裝方式，所以與網(wǎng)絡(luò)地址轉(zhuǎn)換設(shè)備N(xiāo)AT無(wú)關(guān)，不存在NAT友好性問(wèn)題；并且引入了序列號(hào)窗口的設(shè)計(jì)，可以防止重放攻擊，或者重放性拒絕服務(wù)攻擊，因此增強(qiáng)了安全性；本發(fā)明方法的安全封裝與安全關(guān)聯(lián)協(xié)商無(wú)關(guān)，因此其應(yīng)用更為靈活。


圖1為現(xiàn)有技術(shù)的IPSec的體系結(jié)構(gòu)示意圖；圖2為本發(fā)明網(wǎng)絡(luò)報(bào)文封裝方法的報(bào)文前后對(duì)比圖；圖3a至圖3e為本發(fā)明網(wǎng)絡(luò)報(bào)文的安全封裝過(guò)程的報(bào)文格式示意圖；具體實(shí)施方式
以下結(jié)合附圖，將對(duì)本發(fā)明的各較佳實(shí)施例進(jìn)行更為詳細(xì)的說(shuō)明。
本發(fā)明對(duì)網(wǎng)絡(luò)報(bào)文安全封裝的方法中，并不涉及安全關(guān)聯(lián)的協(xié)商過(guò)程，其在報(bào)文安全封裝協(xié)議獲得任意長(zhǎng)的網(wǎng)絡(luò)報(bào)文后，進(jìn)行封裝、加密、認(rèn)證處理，最后形成一個(gè)經(jīng)過(guò)加密和完整性檢測(cè)的應(yīng)用層報(bào)文傳送給傳輸層進(jìn)行發(fā)送。
本發(fā)明方法的網(wǎng)絡(luò)報(bào)文的封裝格式示例說(shuō)明如下首先，對(duì)原始信令報(bào)文進(jìn)行封裝，封裝后的報(bào)文格式為struct{uint48 seq_num;
uint16 length;\\fragment的長(zhǎng)度;
opaque fragment[SignalPlaintext.length];
}SignalPlaintext;
其中，seq_num為從認(rèn)證加密開(kāi)始設(shè)置的數(shù)據(jù)報(bào)文的序列號(hào)，并從隨機(jī)數(shù)開(kāi)始計(jì)數(shù)。當(dāng)在重新登錄的時(shí)候，應(yīng)當(dāng)重新開(kāi)始計(jì)數(shù)，該序列號(hào)的設(shè)置主要用來(lái)防止重放，在重放時(shí)其無(wú)法模仿該隨機(jī)的序列號(hào)。Length為原始報(bào)文長(zhǎng)度。Fragment為原始報(bào)文內(nèi)容。
其次，進(jìn)行負(fù)載保護(hù)；對(duì)以上封裝后的報(bào)文進(jìn)行負(fù)載保護(hù)，先加密后認(rèn)證。加密認(rèn)證后的報(bào)文格式如下所示struct{uint48 seq_num;
uint16 length;
GenericCipher ciper_signal;
}SignalCiphertext;
struct{opaque content[SignalPlaintext.length];\\加密信令opaque padding[GenericCipher.padding_length];
uint8 padding_length;
opaque MAC[CipherSpec.hash_size];
}GenericCipher;
上述seq_num與length定義與原始封裝報(bào)文相同。content為加密后的報(bào)文內(nèi)容。padding為分組加密需要對(duì)報(bào)文進(jìn)行填充的填充字段，填充字段包括填充字段長(zhǎng)度附加到信令報(bào)文的后面使之成為分組加密中一個(gè)加密塊的整數(shù)倍，對(duì)于流加密也將填充。padding_len用來(lái)表示填充字節(jié)的長(zhǎng)度，用一字節(jié)來(lái)表示，最大為255字節(jié)。0x00表示沒(méi)有填充字段，填充長(zhǎng)度位為必選項(xiàng)，填充字節(jié)以及填充長(zhǎng)度字節(jié)都將進(jìn)行加密。MAC為認(rèn)證字段，其按以下計(jì)算公式來(lái)計(jì)算MAC=HMAC_hash(MAC_session_Key,SignalCiphertext.seq_num+SignalCiphertext.length+SignalCiphertext.GenericCipher.Content+SignalCiphertext.GenericCipher.padding+SignalCiphertext.GenericCipher.padding_length
);
再次，設(shè)置安全封裝頭在數(shù)據(jù)包中的位置，如圖2所示的。對(duì)于封裝后的信令報(bào)文按照下圖示意進(jìn)行IP頭和UDP頭封裝并發(fā)送。關(guān)于傳輸層協(xié)議的選擇與原來(lái)報(bào)文的選擇策略相同，當(dāng)整個(gè)數(shù)據(jù)包長(zhǎng)度包括安全封裝開(kāi)銷(xiāo)字段大于網(wǎng)絡(luò)PMTU值的時(shí)候，必須采用TCP來(lái)作為傳輸層協(xié)議，而不能采用UDP。
本發(fā)明所述對(duì)網(wǎng)絡(luò)報(bào)文安全封裝的方法步驟包括A、產(chǎn)生應(yīng)用層報(bào)文；B、封裝頭，產(chǎn)生48位隨機(jī)數(shù)SeqA作為初始序列號(hào)。以后每發(fā)送一個(gè)報(bào)文序列號(hào)加1。將序列號(hào)以及報(bào)文長(zhǎng)度字節(jié)作為封裝頭附加到報(bào)文最前面，處理后的報(bào)文格式示意如圖3a所示。
C、負(fù)載填充。假設(shè)應(yīng)用層報(bào)文有效長(zhǎng)度為578字節(jié)，采用AES加密(當(dāng)然也可以采用其他任何加密算法)，AES分組長(zhǎng)度為16字節(jié)，填充長(zhǎng)度的字節(jié)數(shù)為1。所有負(fù)載填充長(zhǎng)度的值為16-(578+1)mod16＝13字節(jié)，由于填充字段最長(zhǎng)為256字節(jié)，所有同時(shí)可選的值為13+n×16，n可以選的值為0、1、2、3到15等。為了降低數(shù)據(jù)包的長(zhǎng)度，建議選的n為0，Padding_length的值為13，所以報(bào)文后面將附加填充值為13的14填充字節(jié)。最后一字節(jié)表示填充長(zhǎng)度，此時(shí)填充后的報(bào)文格式示意如圖3b所示。
D、報(bào)文加密。將應(yīng)用層報(bào)文以及后面的14個(gè)附加填充字段共計(jì)592字節(jié)一起用AES算法和加密密鑰進(jìn)行加密運(yùn)算，加密將不對(duì)封裝頭進(jìn)行，處理后的報(bào)文格式如圖3c所示，其中signal packet以及padding和pad-len等部分經(jīng)過(guò)了加密。
E、消息認(rèn)證碼MAC計(jì)算。將完整性檢測(cè)的會(huì)話(huà)密鑰ICV_key附加到封裝頭前面對(duì)整個(gè)報(bào)文進(jìn)行SHA1哈希計(jì)算。將輸出的20字節(jié)附加到填充字段后面，作為報(bào)文MAC。會(huì)話(huà)密鑰只參與報(bào)文哈希計(jì)算，并不作為報(bào)文的一部分。處理后的報(bào)文格式如圖3d所示。
MAC=SHA1(ICV_Key,SeqA
+length+SignalPacket+Padding+Pad-len);
F、將上面安全封裝后的信令報(bào)文封裝IP/UDP頭進(jìn)行發(fā)送。最后發(fā)送的報(bào)文格式如圖3e所示。
本發(fā)明方法的安全驗(yàn)證流程是封裝的反過(guò)程。其具體處理步驟包括A1、接受數(shù)據(jù)包；B1、映射安全關(guān)聯(lián)，根據(jù)源目的IP地址端口號(hào)信息，獲取所協(xié)商或者手工配置的相關(guān)的會(huì)話(huà)密鑰、加密認(rèn)證算法，安全封裝格式等信息。
C1、對(duì)序列號(hào)檢查，根據(jù)源目的IP地址端口號(hào)信息，獲取本會(huì)話(huà)的序列號(hào)窗，如果本數(shù)據(jù)包序列號(hào)落入窗口之內(nèi)，則接收，否則丟棄該數(shù)據(jù)包。第一次會(huì)話(huà)序列窗口根據(jù)通過(guò)認(rèn)證數(shù)據(jù)序列號(hào)設(shè)置。每接收到一個(gè)正確的數(shù)據(jù)包，接受窗口進(jìn)行相應(yīng)移動(dòng)。
D1、對(duì)完整性進(jìn)行檢測(cè)。邊界點(diǎn)利用密鑰協(xié)商階段獲得的完整性檢測(cè)會(huì)話(huà)密鑰ICV_Key以及數(shù)據(jù)報(bào)文信息完成如下運(yùn)算。
MAC'=SHA1(ICV_Key,SeqA+length+SignalPacket+Padding+Pad-len);
如果MAC’＝MAC，則本次數(shù)據(jù)包完整性檢測(cè)成功，繼續(xù)進(jìn)行下面處理，否則丟棄該數(shù)據(jù)包。
E1、解密。對(duì)數(shù)據(jù)包進(jìn)行利用相應(yīng)的密鑰和加密算法進(jìn)行解密。
F1、加密數(shù)據(jù)長(zhǎng)度應(yīng)該與填充長(zhǎng)度與源數(shù)據(jù)包長(zhǎng)度之和相同。然后去掉填充字節(jié)。
G1、將報(bào)文進(jìn)行相應(yīng)的應(yīng)用層處理。
由于本發(fā)明的上述方法采用了應(yīng)用層封裝方式，由于NAT只是對(duì)網(wǎng)絡(luò)層和傳輸層有關(guān)，不存在NAT友好性問(wèn)題。其次，本發(fā)明的封裝格式引入了序列號(hào)的設(shè)計(jì)，對(duì)于利用截取的已經(jīng)合法的包進(jìn)行重放的攻擊方式，由于有以每次隨機(jī)數(shù)為基礎(chǔ)的序列號(hào)的限制，可以很容易判別丟棄，從而可以有效的防止重放攻擊，同時(shí)序列號(hào)的設(shè)置也使得偽造數(shù)據(jù)包必須首先猜測(cè)目前的序列號(hào)，從而也可以一定程度上避免拒絕服務(wù)攻擊，因此增強(qiáng)了安全性。本發(fā)明的安全封裝與安全關(guān)聯(lián)協(xié)商無(wú)關(guān)，不管采用IKE的密鑰交換方式還是用戶(hù)自定義的安全關(guān)聯(lián)協(xié)商方式，都可以采用本數(shù)據(jù)包封裝方案，因此其應(yīng)用更為靈活。
本發(fā)明方法并不涉及安全關(guān)聯(lián)的協(xié)商的過(guò)程，只是在提供了在通信雙方完成密鑰、算法等安全關(guān)聯(lián)信息(SA)協(xié)商以后的報(bào)文安全封裝方法，對(duì)于密鑰協(xié)商以及認(rèn)證過(guò)程等可以通過(guò)AKA或其他的密鑰協(xié)商流程完成，或者手工配置的方法完成，其為本領(lǐng)域技術(shù)人員所熟知，因此不再贅述。
應(yīng)當(dāng)理解的是，本發(fā)明的上述針對(duì)具體實(shí)施例的描述較為詳細(xì)，但并不能因此而認(rèn)為是對(duì)本發(fā)明專(zhuān)利保護(hù)范圍的限制，本發(fā)明的專(zhuān)利保護(hù)范圍應(yīng)以所附權(quán)利要求為準(zhǔn)。
權(quán)利要求
1.一種對(duì)網(wǎng)絡(luò)報(bào)文安全封裝的方法，其包括以下步驟A、產(chǎn)生應(yīng)用層報(bào)文；B、封裝頭，產(chǎn)生一隨機(jī)數(shù)作為初始序列號(hào)，每發(fā)送一個(gè)報(bào)文序列號(hào)進(jìn)行變化，并將序列號(hào)以及報(bào)文長(zhǎng)度字節(jié)作為封裝頭附加到報(bào)文中；C、負(fù)載填充；D、對(duì)報(bào)文加密，將應(yīng)用層報(bào)文以及后面的附加填充字段一起用加密算法和加密密鑰進(jìn)行加密運(yùn)算；E、消息認(rèn)證碼計(jì)算，將完整性檢測(cè)的會(huì)話(huà)密鑰附加到封裝頭前面對(duì)整個(gè)報(bào)文進(jìn)行哈希計(jì)算，并將輸出字節(jié)附加到填充字段后面，作為報(bào)文消息認(rèn)證碼；F、將安全封裝后的信令報(bào)文封裝IP/UDP或TCP頭進(jìn)行發(fā)送。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述步驟D的加密不對(duì)封裝頭進(jìn)行，并且所述會(huì)話(huà)密鑰只參與報(bào)文哈希計(jì)算，不作為報(bào)文的一部分。
3.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述步驟D的加密算法為AES算法。
4.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述步驟B中的變化為在每發(fā)送一個(gè)報(bào)文時(shí)，序列號(hào)加一。
5.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述步驟C中，其最后一字節(jié)表示填充長(zhǎng)度。
6.根據(jù)權(quán)利要求1所述的方法，其特征在于，還包括安全驗(yàn)證流程，包括步驟A1、接受網(wǎng)絡(luò)報(bào)文數(shù)據(jù)包；B1、映射安全關(guān)聯(lián)，根據(jù)源目的IP地址端口號(hào)信息，獲取所協(xié)商或者手工配置的相關(guān)的會(huì)話(huà)密鑰、加密認(rèn)證算法，安全封裝格式信息；C1、對(duì)序列號(hào)進(jìn)行檢查，根據(jù)源目的IP地址端口號(hào)信息，獲取本會(huì)話(huà)的序列號(hào)窗口，如果本數(shù)據(jù)包序列號(hào)落入窗口之內(nèi)，則接收，否則丟棄該數(shù)據(jù)包；D1、對(duì)完整性進(jìn)行檢測(cè)，邊界點(diǎn)利用密鑰協(xié)商階段獲得的完整性檢測(cè)會(huì)話(huà)密鑰以及數(shù)據(jù)報(bào)文信息完成檢測(cè)，如果數(shù)據(jù)包完整性檢測(cè)成功，則繼續(xù)進(jìn)行下面處理，否則丟棄該數(shù)據(jù)包；E1、對(duì)數(shù)據(jù)包進(jìn)行利用相應(yīng)的密鑰和加密算法進(jìn)行解密；F1、加密數(shù)據(jù)長(zhǎng)度應(yīng)該與填充長(zhǎng)度與源數(shù)據(jù)包長(zhǎng)度之和相同，之后去掉填充字節(jié)；G1、將報(bào)文進(jìn)行相應(yīng)的應(yīng)用層處理。
全文摘要
本發(fā)明公開(kāi)了一種對(duì)網(wǎng)絡(luò)報(bào)文安全封裝的方法，其包括產(chǎn)生應(yīng)用層報(bào)文；封裝頭，產(chǎn)生一隨機(jī)數(shù)作為初始序列號(hào)，每發(fā)送一個(gè)報(bào)文序列號(hào)加1，并將序列號(hào)以及報(bào)文長(zhǎng)度字節(jié)作為封裝頭附加到報(bào)文最前面；負(fù)載填充，其最后一字節(jié)表示填充長(zhǎng)度；對(duì)報(bào)文加密，將應(yīng)用層報(bào)文以及后面的附加填充字段一起用加密算法和加密密鑰進(jìn)行加密運(yùn)算；消息認(rèn)證碼計(jì)算，將完整性檢測(cè)的會(huì)話(huà)密鑰附加到封裝頭前面對(duì)整個(gè)報(bào)文進(jìn)行哈希計(jì)算，并將輸出字節(jié)附加到填充字段后面，作為報(bào)文消息認(rèn)證碼；將安全封裝后的信令報(bào)文封裝IP/UDP或TCP頭進(jìn)行發(fā)送。本發(fā)明方法由于采用應(yīng)用層封裝方式，所以與網(wǎng)絡(luò)地址轉(zhuǎn)換設(shè)備N(xiāo)AT無(wú)關(guān)，不存在NAT友好性問(wèn)題，增強(qiáng)了安全性。
文檔編號(hào)H04L29/06GK1859291SQ200510120668
公開(kāi)日2006年11月8日 申請(qǐng)日期2005年12月13日 優(yōu)先權(quán)日2005年12月13日
發(fā)明者劉利鋒, 鄭志彬 申請(qǐng)人:華為技術(shù)有限公司