杜學(xué)凱 吳承榮 嚴(yán) 明

(復(fù)旦大學(xué)網(wǎng)絡(luò)與信息工程中心，計(jì)算機(jī)科學(xué)技術(shù)學(xué)院 上海 200433)

IPv6環(huán)境下的IPSEC通信安全審計(jì)機(jī)制研究

杜學(xué)凱 吳承榮 嚴(yán) 明

(復(fù)旦大學(xué)網(wǎng)絡(luò)與信息工程中心，計(jì)算機(jī)科學(xué)技術(shù)學(xué)院 上海 200433)

當(dāng)前IPv6網(wǎng)絡(luò)正在逐步推廣，由于IPv6地址可以滿足全球的網(wǎng)絡(luò)節(jié)點(diǎn)唯一地址的需求，所以IPv6用戶越來(lái)越多地使用點(diǎn)對(duì)點(diǎn)的安全通信技術(shù)IPSEC。然而，對(duì)于很多機(jī)構(gòu)來(lái)說(shuō)，網(wǎng)絡(luò)內(nèi)部的IPSEC通信的合法監(jiān)管逐漸變得困難，這是一個(gè)需要解決的問(wèn)題。針對(duì)于這樣的場(chǎng)景，提出一種在IPv6網(wǎng)絡(luò)中運(yùn)用基于中間人機(jī)制與密鑰托管機(jī)制的IPSEC通信安全審計(jì)方法，設(shè)計(jì)并實(shí)現(xiàn)一種在IPv6網(wǎng)絡(luò)內(nèi)部以及IPv6網(wǎng)絡(luò)之間進(jìn)行IPSEC通信安全審計(jì)的原型系統(tǒng)，并進(jìn)行IPv6網(wǎng)絡(luò)環(huán)境下的功能驗(yàn)證與性能分析。實(shí)驗(yàn)表明，該方法能夠很好得達(dá)到進(jìn)行IPv6網(wǎng)絡(luò)環(huán)境下IPSEC審計(jì)的效果。

IPv6網(wǎng)絡(luò) 安全審計(jì) 中間人機(jī)制 密鑰托管 Internet Protocol Security

0 引 言

IPv6是互聯(lián)網(wǎng)工程任務(wù)組IETF(Internet Engineering Task Force)設(shè)計(jì)的用于替代現(xiàn)行版本IP協(xié)議的下一代IP協(xié)議。IPv6服務(wù)的大規(guī)模使用對(duì)于傳統(tǒng)的網(wǎng)絡(luò)安全審計(jì)還是會(huì)帶來(lái)一定的影響的。比如，網(wǎng)絡(luò)通信加密、身份認(rèn)證、網(wǎng)絡(luò)訪問(wèn)控制、安全審計(jì)監(jiān)控、安全審計(jì)監(jiān)控、操作系統(tǒng)及平臺(tái)軟件的安全增強(qiáng)、應(yīng)用層安全保護(hù)機(jī)制、安全管理等場(chǎng)景會(huì)受到IPv6服務(wù)部署的影響。

IPSEC機(jī)制提供了端到端的網(wǎng)絡(luò)層加密通信機(jī)制。IPv6的使用一方面使得端到端加密措施成為內(nèi)生的端到端安全機(jī)制，另一方面， NAT[1]等機(jī)制在IPv6網(wǎng)絡(luò)環(huán)境中已經(jīng)不太需要，所以限制基于IPSEC的端到端加密的技術(shù)障礙已經(jīng)基本排除。

IPSEC端到端加密機(jī)制在IPv4環(huán)境中由于條件限制并未被廣泛使用，而在IPv6環(huán)境中只要PKI機(jī)制被普遍使用，通過(guò)客戶端或服務(wù)端的設(shè)定采用自動(dòng)協(xié)商機(jī)制即可實(shí)施。所以IPSEC機(jī)制將會(huì)成為IPv6網(wǎng)絡(luò)中較為普遍的通信保障方式，而這將會(huì)對(duì)網(wǎng)絡(luò)通信內(nèi)容的審計(jì)帶來(lái)挑戰(zhàn)，這正是IPv6環(huán)境中的安全審計(jì)不得不正視的問(wèn)題。因此在IPv6環(huán)境中，有必要對(duì)采用IPSEC的端到端加密機(jī)制的使用進(jìn)行管理，包括哪些通信可以使用，哪些通信不能使用，可采用的加密算法，需要采用的密鑰管理機(jī)制等等。并且在IPv6環(huán)境下的IPSEC機(jī)制的監(jiān)管中，無(wú)論采用預(yù)共享密鑰方式、公鑰方式還是證書(shū)方式，可能都需要面臨大范圍(甚至開(kāi)放環(huán)境)下的密鑰管理和使用，對(duì)原有的密鑰管理機(jī)制提出了挑戰(zhàn)，需要專(zhuān)門(mén)設(shè)計(jì)和部署。

本文根據(jù)IPv6網(wǎng)絡(luò)場(chǎng)景下IPsec數(shù)據(jù)流進(jìn)行審計(jì)機(jī)制的研究。對(duì)于基于IKE[2]網(wǎng)絡(luò)密鑰協(xié)商機(jī)制的IPsec保密通信協(xié)議，主要有幾種監(jiān)管方法，比如中間人破壞協(xié)商連接方法、旁路監(jiān)聽(tīng)存儲(chǔ)密文信息方法、旁路監(jiān)聽(tīng)實(shí)時(shí)上報(bào)方法、終端密鑰修改方法、終端DH隨機(jī)數(shù)修改方法、中間人降低協(xié)商雙方加密等級(jí)方法，和針對(duì)DH算法的中間人方法。我們根據(jù)上述幾種方法的優(yōu)點(diǎn)和缺點(diǎn)，采用了基于中間人機(jī)制與密鑰托管相結(jié)合的方法對(duì)需要進(jìn)行安全審計(jì)的IPv6網(wǎng)絡(luò)內(nèi)部IPSEC通信進(jìn)行解密，并基于這種方法實(shí)現(xiàn)了一個(gè)審計(jì)系統(tǒng)的原型。

1 基本原理

IPsec協(xié)議實(shí)現(xiàn)端到端認(rèn)證的方式主要有：PSK預(yù)共享密鑰認(rèn)證、數(shù)字簽名認(rèn)證、公鑰認(rèn)證與Kerberos認(rèn)證等。公鑰認(rèn)證由于公鑰的公開(kāi)性，容易受到篡改，而Kerberos認(rèn)證一般在基于Windows系統(tǒng)的主機(jī)上使用。所以我們主要針對(duì)預(yù)共享密鑰認(rèn)證方式、數(shù)字簽名認(rèn)證方式與公鑰認(rèn)證方式等認(rèn)證機(jī)制進(jìn)行破解，獲取密鑰，達(dá)到最終安全審計(jì)的目的。

1.1 數(shù)據(jù)分類(lèi)處理

IPSEC通信過(guò)程中如果主機(jī)之間采用的是IPSEC的AH協(xié)議進(jìn)行通信，由于AH協(xié)議數(shù)據(jù)內(nèi)容沒(méi)有被加密，所以可以達(dá)到安全審計(jì)的目的，不必進(jìn)行特殊處理。而且由于IPsec的IKE協(xié)議協(xié)商過(guò)程中不同階段的處理方式不同，不能統(tǒng)一對(duì)待，所以我們首先需要對(duì)數(shù)據(jù)進(jìn)行分類(lèi)處理。

如圖1所示，分類(lèi)器的處理工作處理如下：

如果不是有關(guān)于IPsec機(jī)制的數(shù)據(jù)包，則將數(shù)據(jù)包不作處理，透明傳輸。

圖1 分類(lèi)處理原理

如果是AH協(xié)議包，則將數(shù)據(jù)包不作處理，透明傳輸。

如果是已經(jīng)協(xié)商的ESP[3]協(xié)議包，則將ESP包的IPv6地址對(duì)信息和Cookie字段值發(fā)送到一個(gè)特定的存儲(chǔ)密鑰的密鑰存儲(chǔ)中心進(jìn)行密鑰的查詢。

如果此IPv6地址的主機(jī)未進(jìn)行過(guò)密鑰托管，密鑰托管中心向運(yùn)行的IKE處理模塊發(fā)送一個(gè)未托管信息，將此通信斷開(kāi)，并將此ESP數(shù)據(jù)包信息存儲(chǔ)到一個(gè)保存警告信息的數(shù)據(jù)中心，通知管理員運(yùn)用其他監(jiān)管手段獲取其認(rèn)證和密鑰信息進(jìn)行處理。

如果此IPv6地址對(duì)的數(shù)據(jù)包進(jìn)行過(guò)密鑰托管，則向運(yùn)行的IKE處理模塊發(fā)送一個(gè)已托管信息，并將已托管的對(duì)應(yīng)于相應(yīng)地址對(duì)的密鑰發(fā)送給IKE處理模塊(通過(guò)密鑰托管中心與IKE處理模塊的保密線路)。此處還要根據(jù)具體處理后的情形進(jìn)行分類(lèi)：由于密鑰托管中心是否托管的是兩個(gè)通信主機(jī)實(shí)際在使用的密鑰對(duì)，解密ESP數(shù)據(jù)包后有兩種情況，一種是解密出正確的明文，另外一種是解密出不正確的明文。可以通過(guò)解密后數(shù)據(jù)包的傳輸層協(xié)議報(bào)頭部分的下一字段來(lái)判斷是否解密成功。(TCP報(bào)頭的頭部長(zhǎng)度字段、校驗(yàn)和字段或UDP報(bào)頭的長(zhǎng)度字段、校驗(yàn)和是否正確或在正確的范圍內(nèi))。

如果接收到的是IKE認(rèn)證協(xié)商數(shù)據(jù)包，則需要根據(jù)不同的情形進(jìn)行處理。

1.2 IKE協(xié)商處理

本節(jié)主要對(duì)圖1中IKE協(xié)商過(guò)程[4-5]的原理進(jìn)行描述。經(jīng)過(guò)分類(lèi)器的分類(lèi)，已經(jīng)將需要處理的IKE協(xié)商數(shù)據(jù)包分離出來(lái)，然后再進(jìn)行IKE協(xié)商中間人方法的處理。

如果接收到的是IKE的數(shù)據(jù)包，則根據(jù)其中相關(guān)字段的值判斷接收到的IKE數(shù)據(jù)包是否處于IKE協(xié)商的開(kāi)始階段。IKE協(xié)商的第一階段分為主模式和積極模式(野蠻模式)這兩種協(xié)商模式。我們這里只是研究了主模式的工作方式，因?yàn)榉e極模式或野蠻模式的安全性較主模式低。

在IKE第一階段的實(shí)現(xiàn)中，貫穿于整個(gè)交換的關(guān)鍵選擇是認(rèn)證，認(rèn)證方法決定了通信雙方如何交換載荷以及在何時(shí)交換。認(rèn)證的最主要目的是為了避免與未經(jīng)過(guò)認(rèn)證的用戶建立傳輸隧道連接。IKE可以接收的認(rèn)證方式包括預(yù)共享密鑰認(rèn)證(PSK)、數(shù)字簽名認(rèn)證(SIG)、公鑰加密認(rèn)證等等。我們主要研究的是預(yù)共享密鑰認(rèn)證和數(shù)字簽名認(rèn)證兩種方式，因?yàn)檫@兩種認(rèn)證方式的使用在IPsec的IKE協(xié)商過(guò)程中比較普遍，而且公鑰加密認(rèn)證的安全性比數(shù)字簽名認(rèn)證方式要低。雖然不同的認(rèn)證算法提供的安全強(qiáng)度不同，使得交換消息的內(nèi)容也各不相同，但達(dá)到的目的是完全一致的，最終都是生成安全通道SA。

如果接收到的包是處于IKE協(xié)商的第一階段的第一條信息，則可以迅速用IKE處理模塊進(jìn)行中間人方法。

如果接收到的包是處于IKE協(xié)商的第一階段的第一條信息，則分類(lèi)器向狀態(tài)及會(huì)話密鑰查詢是否該IPv6通信主機(jī)對(duì)正在進(jìn)行IKE協(xié)商的處理。如果是，則繼續(xù)進(jìn)行相應(yīng)IKE處理；如果不是，則向發(fā)送方和接收方分別發(fā)送一條協(xié)商出錯(cuò)信息，來(lái)迫使發(fā)送方重新開(kāi)始IKE協(xié)商過(guò)程。

如果接收到IKE協(xié)商第一階段的第一條信息后，轉(zhuǎn)發(fā)給接收方，接收方直接應(yīng)答了第三條信息，則代表主機(jī)雙方運(yùn)用的是AH協(xié)議進(jìn)行的最終通信，則對(duì)此處IKE協(xié)商過(guò)程不做處理。

如果接收到IKE協(xié)商第一階段的第一條信息后，轉(zhuǎn)發(fā)給接收方，接收方應(yīng)答了第二條信息，則代表主機(jī)雙方最終運(yùn)用的是ESP協(xié)議，這樣就能夠用針對(duì)于Diffie-Hellman算法[6]的IKE中間人方法進(jìn)行密鑰信息的獲得。首先判斷此次IKE協(xié)商使用的認(rèn)證方法。通過(guò)對(duì)于不同的認(rèn)證方式，可以進(jìn)行不同的處理：

對(duì)于數(shù)字簽名認(rèn)證的IKE主模式認(rèn)證方式,IKE協(xié)商的第一和第二條消息是透明傳輸?shù)?，不做任何的修改。而在第三條消息中，要進(jìn)行KE值的修改，進(jìn)行Diffie-Hellman算法的中間人方法，利用消息中的參數(shù)和中間人對(duì)主機(jī)協(xié)商的KE值，可以生成兩對(duì)密鑰素材。為IKE協(xié)商的第二階段的破解和最終ESP加密密鑰的生成創(chuàng)造條件。

對(duì)于數(shù)字簽名認(rèn)證的方式，如果在認(rèn)證過(guò)程中需要證書(shū)的交換，需要去密鑰托管中心進(jìn)行證書(shū)的獲取，如果證書(shū)未經(jīng)托管備案，則分別向正在協(xié)商的兩臺(tái)主機(jī)發(fā)送IKE協(xié)商出錯(cuò)信息，阻斷兩臺(tái)主機(jī)的IKE協(xié)商過(guò)程；如果托管了證書(shū)，且如果B主機(jī)的證書(shū)有多個(gè)，則對(duì)每個(gè)證書(shū)進(jìn)行驗(yàn)證運(yùn)算，如果驗(yàn)證成功說(shuō)明找到主機(jī)的證書(shū)，如果匹配未成功說(shuō)明主機(jī)的證書(shū)沒(méi)有經(jīng)過(guò)備案，則向兩臺(tái)主機(jī)分別發(fā)送IKE協(xié)商出錯(cuò)信息阻斷協(xié)商過(guò)程。

對(duì)于預(yù)共享密鑰認(rèn)證方式的IKE主模式認(rèn)證方式，同上面的SIG認(rèn)證的方式，IKE協(xié)商的第一和第二條消息是透明傳輸?shù)?，不做任何的修改。而在第三條消息中，要進(jìn)行KE值的修改，進(jìn)行Diffie Hellman算法的中間人方法，利用消息中的參數(shù)和中間人對(duì)協(xié)商主機(jī)的KE值，為IKE協(xié)商的第二階段的破解和最終ESP加密密鑰的生成創(chuàng)造條件。

對(duì)于IKE協(xié)商過(guò)程的第二階段(快速模式)[7]的處理為：根據(jù)主模式協(xié)商建立好的認(rèn)證通道，要對(duì)協(xié)商雙方的協(xié)商數(shù)據(jù)進(jìn)行相關(guān)篡改，同時(shí)進(jìn)行再一次的針對(duì)Diffie-Hellman算法的中間人方法，獲取最終進(jìn)行ESP數(shù)據(jù)加密與認(rèn)證運(yùn)算的密鑰數(shù)據(jù)。

至此，生成ESP包加解密的IPSEC SA密鑰所需的參數(shù)能夠全部得到，IKE協(xié)商處理主模塊與協(xié)商的兩主機(jī)分別生成一對(duì)IPSEC SA密鑰(入口密鑰和出口密鑰)，此密鑰保存到IPsec密鑰托管中心，將IPv6地址對(duì)、SPI值對(duì)、IPSEC SA密鑰對(duì)和協(xié)商方向關(guān)聯(lián)起來(lái)存儲(chǔ)。

2 總體設(shè)計(jì)

基于密鑰托管和中間人機(jī)制的IPv6網(wǎng)絡(luò)通信監(jiān)控系統(tǒng)的總體框架如圖2所示。

圖2 總體框圖

這個(gè)總體框架圖繪制了對(duì)于需要安全審計(jì)的網(wǎng)絡(luò)內(nèi)部或被審計(jì)網(wǎng)絡(luò)與外網(wǎng)之間通信數(shù)據(jù)的機(jī)制和方法。當(dāng)一個(gè)數(shù)據(jù)包通過(guò)被審計(jì)通道時(shí)，所進(jìn)行的處理是首先由分類(lèi)器進(jìn)行分類(lèi)策略，選擇與數(shù)據(jù)包相匹配的策略進(jìn)行處理。比如對(duì)IKE協(xié)商的ISAKMP數(shù)據(jù)包要交由IKE處理模塊處理，對(duì)于ESP數(shù)據(jù)包或AH數(shù)據(jù)包要交由IPsec處理模塊處理。對(duì)于IPsec機(jī)制之外的數(shù)據(jù)包要根據(jù)預(yù)先制定的策略進(jìn)行處理。在策略中沒(méi)有要求的數(shù)據(jù)包要進(jìn)行透明傳輸，以達(dá)到使中間人安全審計(jì)主機(jī)作為被審計(jì)通道上的透明網(wǎng)橋的效果。IKE處理模塊和IPsec處理模塊是中間人監(jiān)管主機(jī)上的兩個(gè)進(jìn)程，這兩個(gè)是對(duì)于IPsec機(jī)制的主要處理模塊。IKE處理模塊主要是對(duì)IKE第一階段和第二階段中的DH協(xié)商使用中間人方法，使得使用IKE協(xié)商的兩臺(tái)主機(jī)能夠和中間人主機(jī)分別建立IPsec通信密鑰。IPsec處理是將通道中的ESP數(shù)據(jù)包或AH數(shù)據(jù)包根據(jù)SPI值向密鑰托管中心獲取相關(guān)的IPsec數(shù)據(jù)的相關(guān)加解密的密鑰值和HMAC散列的相關(guān)密鑰值，并將收到ESP數(shù)據(jù)包和AH數(shù)據(jù)包做相關(guān)加解密處理或散列處理后從另一端發(fā)送出去。IPsec處理模塊在處理過(guò)程中解密出明文后，將ESP數(shù)據(jù)包或AH數(shù)據(jù)包轉(zhuǎn)換為明文狀態(tài)的IPv6數(shù)據(jù)包保存起來(lái)。

框架圖中的報(bào)警/審計(jì)中心模塊的功能是接收IKE處理模塊和IPSEC處理模塊中出現(xiàn)的各種報(bào)錯(cuò)或其他提供給受審計(jì)網(wǎng)絡(luò)管理員的信息，如SPI相關(guān)的加解密密鑰未查找到、IKE處理過(guò)程中認(rèn)證未成功等。密鑰托管中心保存了IKE處理模塊和IPSEC處理模塊中所用到的認(rèn)證數(shù)據(jù)或密鑰數(shù)據(jù)，比如預(yù)共享密鑰字符串、受監(jiān)管主機(jī)的證書(shū)(根據(jù)IPv6地址匹配)、偽造的證書(shū)、受監(jiān)管主機(jī)的證書(shū)的公鑰值、ESP數(shù)據(jù)包的加解密密鑰值和散列密鑰值(根據(jù)SPI值匹配)等。安全策略中心制定了一系列與IPv6網(wǎng)絡(luò)通道中相關(guān)的協(xié)議的處理和監(jiān)管要求，當(dāng)分類(lèi)器對(duì)相關(guān)數(shù)據(jù)包處理時(shí)，要從策略中心進(jìn)行相關(guān)策略的處理。

3 詳細(xì)實(shí)現(xiàn)

3.1 密鑰素材

用于IKE協(xié)商處理模塊與ESP數(shù)據(jù)解密的密鑰素材如下：

密鑰集合：需要生成的密鑰有SKEYID、SKEYID_d、SKEYID_a、SKEYID_e和通信數(shù)據(jù)加解密密鑰KEYMAT。

簽名和散列數(shù)據(jù)：HASH_I、HASH_R、SIG_i、SIG_r、HASH(1)、HASH(2)、HASH(3)。

SKEYID需要的密鑰素材有：PSK、通信雙方的NONCE載荷的數(shù)據(jù)、通信雙方和中間人產(chǎn)生的兩個(gè)DH協(xié)商的密鑰。

SKEYID_d需要的密鑰素材有：SKEYID、通信雙方和中間人產(chǎn)生的兩個(gè)DH密鑰、通信雙方的Cookie值。

SKEYID_a需要的密鑰素材有：SKEYID、SKEYID_d、通信雙方和中間人產(chǎn)生的兩個(gè)DH密鑰、通信雙方的Cookie值。

SKEYID_e需要的密鑰素材有：SKEYID、SKEYID_a、通信雙方和中間人產(chǎn)生的兩個(gè)DH密鑰、通信雙方的COOKIE值。

簽名和HASH計(jì)算需要的素材：SKEYID、通信雙方和中間人產(chǎn)生的兩對(duì)DH公開(kāi)值、兩個(gè)階段的SA載荷的數(shù)據(jù)、通信雙方的身份認(rèn)證識(shí)別載荷ID、同一個(gè)CA的根證書(shū)簽發(fā)的兩個(gè)或多個(gè)證書(shū)文件。

上述密鑰素材將會(huì)運(yùn)用到IKE協(xié)商發(fā)起方(A主機(jī))、IKE協(xié)商接收方(B主機(jī))與IKE協(xié)商中間人處理主機(jī)(C主機(jī))的數(shù)據(jù)處理之中。

3.2 模塊劃分

整個(gè)網(wǎng)絡(luò)的IPSEC通信的安全審計(jì)系統(tǒng)主要分為五個(gè)模塊，各個(gè)模塊的功能如下：

密鑰托管中心模塊 用于存儲(chǔ)針對(duì)于通信主機(jī)IP地址對(duì)和SPI值的IPSEC SA出入口密鑰、證書(shū)、預(yù)共享密鑰等管理、查找和其他密鑰素材計(jì)算處理的模塊。主要實(shí)現(xiàn)的功能是：密鑰與密鑰素材的計(jì)算、針對(duì)特定主機(jī)IP的偽證書(shū)的存儲(chǔ)管理、數(shù)據(jù)的簽名計(jì)算和密鑰與證書(shū)的驗(yàn)證計(jì)算。

分類(lèi)器模塊 用于對(duì)受安全審計(jì)環(huán)境通道上各種數(shù)據(jù)包的分流處理。對(duì)于不同特征的數(shù)據(jù)包進(jìn)行不同的處理流程。

ESP包處理模塊 用于對(duì)受安全審計(jì)環(huán)境通道上ESP包的處理的驗(yàn)證、加解密計(jì)算處理。

IKE協(xié)商處理模塊 用于對(duì)受安全審計(jì)通道上的IKE協(xié)商過(guò)程進(jìn)行中間人方法，生成密鑰發(fā)送給密鑰管理中心，生成明文信息發(fā)送給明文信息數(shù)據(jù)庫(kù)，向密鑰托管中心交互進(jìn)行相關(guān)參數(shù)的申請(qǐng)和驗(yàn)證。

策略中心模塊 接收策略申請(qǐng)和發(fā)送策略。

3.3 分類(lèi)器模塊實(shí)現(xiàn)

當(dāng)一個(gè)數(shù)據(jù)包被中間人程序所運(yùn)行的主機(jī)接收到時(shí)，驗(yàn)證程序中的數(shù)據(jù)包分類(lèi)器首先根據(jù)此數(shù)據(jù)包的以太網(wǎng)幀頭部的以太網(wǎng)類(lèi)型字段判斷接收到的數(shù)據(jù)包是否為IPv6數(shù)據(jù)包。如果接收到的不是IPv6的數(shù)據(jù)包，則把此數(shù)據(jù)包透明傳輸?shù)絽f(xié)商接收方B主機(jī)。如果接收到的是IPv6數(shù)據(jù)包，則去掉接收到的數(shù)據(jù)包的以太網(wǎng)頭部，再判斷其IPv6頭部的發(fā)送方A地址和接收方B地址是否和所要進(jìn)行監(jiān)管的兩臺(tái)主機(jī)的地址是否一致。如果和兩臺(tái)受監(jiān)管主機(jī)的IPv6地址不一致，則將數(shù)據(jù)包透明傳輸?shù)絽f(xié)商接收方B主機(jī)。如果接收到的數(shù)據(jù)包和兩臺(tái)受監(jiān)管主機(jī)的IPv6數(shù)據(jù)包一致，則再次判斷此數(shù)據(jù)包的IPv6頭部字段的Next Header字段是否為所需要協(xié)議(ESP協(xié)議或者ISAKMP協(xié)議)，如果不是，則將此數(shù)據(jù)包透明傳輸?shù)絽f(xié)商接收方B主機(jī)。如果判斷出數(shù)據(jù)包的下一層協(xié)議是ESP協(xié)議，則將此數(shù)據(jù)包所存儲(chǔ)的內(nèi)存地址作為參數(shù)傳給ESP數(shù)據(jù)包處理單元。如果判斷出數(shù)據(jù)包的下一層協(xié)議是UDP協(xié)議，則再次判斷UDP的目的端口號(hào)是否為ISAKMP協(xié)議的端口號(hào)。如果不是ISAKMP協(xié)議的端口號(hào)，則將此數(shù)據(jù)包透明傳輸?shù)絽f(xié)議接收方B。如果接收到的是ISAKMP協(xié)議的數(shù)據(jù)包，則將此數(shù)據(jù)包所存儲(chǔ)的內(nèi)存地址作為參數(shù)傳遞給IKE協(xié)商處理單元。

3.4 IKE協(xié)商處理模塊

當(dāng)數(shù)據(jù)包進(jìn)入IKE中間人協(xié)商模塊進(jìn)行數(shù)據(jù)處理，首先判斷數(shù)據(jù)包中的ISAKMP的頭部字段的發(fā)送者和接受者的COOKIE是否都為0，如果是，則表示接收到的ISAKMP包為畸形包，直接透明傳輸給接收方主機(jī)。然后再次判斷ISAKMP頭部的版本號(hào)是否為支持的版本號(hào)，支持的版本號(hào)為1。然后判斷ISAKMP頭部的FLAG值是否規(guī)范，如果FLAG為提交類(lèi)型則將此數(shù)據(jù)包透明傳輸?shù)絽f(xié)商接收方B。如果FLAG字段的類(lèi)型為標(biāo)準(zhǔn)類(lèi)型，則根據(jù)協(xié)商的雙方的COOKIE值頭部字段從存儲(chǔ)雙方協(xié)商細(xì)節(jié)數(shù)據(jù)的雙鏈表PH1TREE中獲取第一階段協(xié)商數(shù)據(jù)結(jié)構(gòu)體PH1。如果獲得的PH1結(jié)構(gòu)體為非空，且如果本地為協(xié)商發(fā)起方并且接收方的COOKIE為0，則拋棄此數(shù)據(jù)包，否則，再次判斷變量PH1變量中的源地址和目的地址和數(shù)據(jù)包中是否一致，如果是，則轉(zhuǎn)入判斷ISAKMP頭部的交換類(lèi)型，否則拋棄此數(shù)據(jù)包。如果沒(méi)有查找到相應(yīng)的PH1結(jié)構(gòu)體，則轉(zhuǎn)入判斷ISAKMP頭部的交換類(lèi)型。

根據(jù)ISAKMP頭部的交換類(lèi)型值，判斷所發(fā)送的IKE協(xié)商數(shù)據(jù)包處于協(xié)商的哪一個(gè)階段。如果處于第一階段主模式，則將數(shù)據(jù)包交由第一階段處理單元處理。如果處于第二階段的快速模式，則將數(shù)據(jù)包交由第二階段處理單元處理。

在第一階段處理單元中，首先判斷接收到的ISAKMP包的MSG_ID是否為0，因?yàn)橹髂Ｊ诫A段的MSG_ID字段值必須為0。然后判斷從PH1TREE雙鏈表中獲得的主模式階段結(jié)構(gòu)體是否為空，如果是，則該報(bào)的接受者的COOKIE值必定為0，根據(jù)協(xié)商連接標(biāo)識(shí)(A或B)和I_COOKIE從PH1TREE中查找PH1變量，如果查找到的主模式數(shù)據(jù)結(jié)構(gòu)PH1依舊是空并且數(shù)據(jù)包中的接收方的COOKIE值為0，則進(jìn)入到主模式開(kāi)始處理流程單元。如果在此單元處理的第一次從PH1TREE中獲得主模式信息結(jié)構(gòu)體PH1時(shí)不為空，然后判斷PH1中的ETYPE變量和數(shù)據(jù)包中的字段是否匹配，如果匹配，則將數(shù)據(jù)包交由主模式后期處理流程單元處理，如果不匹配，則向用戶打印警告信息。

在第二階段處理單元中，首先判斷之前第一階段的結(jié)構(gòu)體PH1是否為空，如果為空，則打印出錯(cuò)信息，如果不為空，則判斷PH1結(jié)構(gòu)體的連接狀態(tài)是否為已建立狀態(tài)，如果已經(jīng)建立連接狀態(tài)，然后通過(guò)第一階段的結(jié)構(gòu)體PH1查詢相關(guān)的第二階段結(jié)構(gòu)體PH2，如果查詢到的第二階段結(jié)構(gòu)體PH2為空，則將數(shù)據(jù)包傳遞給快速模式開(kāi)始處理流程單元進(jìn)行處理；否則，判斷其ISAKMP包頭部的FLAG字段是否為提交類(lèi)型，如果是，則將數(shù)據(jù)包傳遞給快速模式后期處理流程單元處理，否則向用戶打印警告信息。

在主模式或者快速模式下的處理過(guò)程中，首先要根據(jù)存儲(chǔ)的連接狀態(tài)和接收到的ISAKMP包中的信息判斷接收到的數(shù)據(jù)包是否合理，然后根據(jù)協(xié)商數(shù)據(jù)包所處的狀態(tài)判斷接收到的ISAKMP數(shù)據(jù)包應(yīng)該交由什么狀態(tài)的消息處理函數(shù)處理。處理過(guò)程中包括相應(yīng)的接收函數(shù)和發(fā)送函數(shù)。在接收和發(fā)送工作完成后，將協(xié)商過(guò)程中改變的狀態(tài)和協(xié)商好的參數(shù)等信息保存到連接信息存儲(chǔ)變量中。

中間人程序在主模式狀態(tài)處理過(guò)程中包括6個(gè)接收處理過(guò)程和6個(gè)發(fā)送處理過(guò)程。每一個(gè)處理步驟包括一個(gè)接收處理過(guò)程和一個(gè)發(fā)送處理過(guò)程。

第一次接收到發(fā)送方A發(fā)送的協(xié)商包1后，對(duì)數(shù)據(jù)包中的參數(shù)不作修改，并且將協(xié)商發(fā)起方A發(fā)送的SA載荷保存起來(lái)，在這個(gè)過(guò)程中，要建立協(xié)商發(fā)起方A和中間人主機(jī)之間的連接狀態(tài)變量，并且根據(jù)預(yù)設(shè)的值將連接狀態(tài)變量進(jìn)行相應(yīng)初始化。

第一次向協(xié)商接收方B發(fā)送數(shù)據(jù)時(shí)，首先要建立協(xié)商接收方B主機(jī)和中間人主機(jī)之間的連接狀態(tài)變量，并且根據(jù)預(yù)設(shè)的值將連接狀態(tài)變量進(jìn)行相應(yīng)的初始化處理，并且將協(xié)商發(fā)起方A主機(jī)之前發(fā)送的數(shù)據(jù)包1直接傳送給協(xié)商接收方B主機(jī)。

第二次接收到協(xié)商接收方B主機(jī)發(fā)送的協(xié)商包2后，修改協(xié)商接收方B主機(jī)和中間人主機(jī)之間的連接狀態(tài)，不對(duì)其中的參數(shù)修改。

第二次向協(xié)商發(fā)起方A發(fā)送數(shù)據(jù)，首先要修改協(xié)商發(fā)起方A主機(jī)和中間人主機(jī)之間的連接狀態(tài)變量，然后將之前接受到的協(xié)商接收方發(fā)送的協(xié)商包2之間傳送給協(xié)商發(fā)起方A主機(jī)。

第三次接收到協(xié)商發(fā)起方A主機(jī)發(fā)送的協(xié)商包3后，修改協(xié)商發(fā)起方A主機(jī)和中間人主機(jī)之間的連接狀態(tài)信息，然后將數(shù)據(jù)包中保存的Diffie-Hellman公開(kāi)值和隨機(jī)值NONCE載荷數(shù)據(jù)保存到協(xié)商發(fā)起方與中間人主機(jī)之間的連接狀態(tài)變量中，并且修改協(xié)商發(fā)起方A主機(jī)和中間人主機(jī)之間的連接狀態(tài)變量，產(chǎn)生兩個(gè)Diffie-Hellman公開(kāi)值，一個(gè)是用于中間人回送給協(xié)商發(fā)起方A的DH1，另外一個(gè)是用于中間人主機(jī)發(fā)送給協(xié)商接收方B主機(jī)的DH2，這兩個(gè)值的產(chǎn)生實(shí)現(xiàn)了對(duì)于Diffie-Hellman算法的中間人方法。然后將DH1保存到中間人主機(jī)與協(xié)商發(fā)起方A主機(jī)的連接共享變量中，DH2值保存到中間人主機(jī)與協(xié)商接收方B主機(jī)之間的連接共享變量中。

第三次向協(xié)商接收方B主機(jī)發(fā)送協(xié)商包3，并且將其中的Diffie-Hellman算法值修改為DH2，然后發(fā)送給協(xié)商接收方B主機(jī)。

第四次接收到協(xié)商接收方B主機(jī)發(fā)送的協(xié)商包4，修改協(xié)商接收方B主機(jī)和中間人主機(jī)之間的連接狀態(tài)信息，然后將協(xié)商包4中的隨機(jī)值Nonce載荷數(shù)據(jù)保存到協(xié)商接收方B主機(jī)和中間人主機(jī)之間的連接狀態(tài)信息中。

第四次向協(xié)商發(fā)起方A主機(jī)發(fā)送協(xié)商包4，修改協(xié)商包4中的Diffie-Hellman算法公開(kāi)值為DH1，并且計(jì)算協(xié)商發(fā)起方A主機(jī)與中間人主機(jī)和協(xié)商接收方B主機(jī)和中間人主機(jī)之間的DH最終值，并且將兩方的DH最終值保存到相應(yīng)的連接狀態(tài)信息共享變量中。然后將所得到密鑰素材根據(jù)認(rèn)證方式的不同如預(yù)共享密鑰認(rèn)證和數(shù)字簽名認(rèn)證方式計(jì)算出SKEYID_d、SKEYID_a、SKEYID_e 和第二階段數(shù)據(jù)加解密密鑰，并且分別保存到協(xié)商發(fā)起方A主機(jī)與中間人主機(jī)和協(xié)商接收方B主機(jī)和中間人主機(jī)之間的連接信息共享變量中，最后將協(xié)商包4回送給協(xié)商發(fā)起方A主機(jī)。

第五次接收到協(xié)商發(fā)起方A主機(jī)發(fā)送的協(xié)商包5后，如果協(xié)商主機(jī)A和B之間是預(yù)共享密鑰的認(rèn)證方式，則首先運(yùn)用之前得到的協(xié)商發(fā)起方A主機(jī)和中間人主機(jī)之間的解密密鑰解密協(xié)商包5，獲取其中的身份認(rèn)證信息載荷數(shù)據(jù)，并且根據(jù)之前得到的密鑰素材重新計(jì)算協(xié)商包5后的HASH_I載荷數(shù)據(jù)值。如果協(xié)商主機(jī)A和B之間是數(shù)字簽名認(rèn)證的方式，首先要從密鑰托管中心獲取兩個(gè)受安全審計(jì)主機(jī)A和B的證書(shū)的私鑰，如果能夠拿到兩個(gè)主機(jī)的證書(shū)的私鑰，然后將重新計(jì)算協(xié)商發(fā)起方A主機(jī)發(fā)送的HASH_I值，并且用協(xié)商發(fā)起方A主機(jī)的證書(shū)的私鑰對(duì)HASH_I值進(jìn)行簽名產(chǎn)生SIG_I；如果沒(méi)有拿到其中一個(gè)主機(jī)的證書(shū)的私鑰，比如協(xié)商發(fā)起方A主機(jī)的私鑰，就要將協(xié)商發(fā)起方A主機(jī)發(fā)送的證書(shū)載荷替換成托管密鑰中心提供的一個(gè)已知私鑰的證書(shū)，然后運(yùn)用此私鑰簽名HASH_I值生成SIG_I值。最后修改協(xié)商發(fā)起方A主機(jī)和中間人主機(jī)之間的連接狀態(tài)變量。

第五次向協(xié)商接收方B主機(jī)回送協(xié)商包5，將之前過(guò)程中重新生成的數(shù)據(jù)構(gòu)造成協(xié)商包5，然后發(fā)送給協(xié)商接收方B主機(jī)，并且修改協(xié)商接收方B主機(jī)和中間人主機(jī)之間的連接狀態(tài)共享變量。

第六次接收到協(xié)商接收方B主機(jī)回送的協(xié)商包6，其處理過(guò)程與第五次接收到協(xié)商包5過(guò)程相似，但是在本環(huán)境中默認(rèn)協(xié)商接收方B主機(jī)的證書(shū)信息受到密鑰托管中心的托管。

第六次向協(xié)商發(fā)送方A主機(jī)回送協(xié)商包6，將之前過(guò)程中重新生成的數(shù)據(jù)構(gòu)造成協(xié)商包6，然后發(fā)送給協(xié)商發(fā)送方A主機(jī)，并且修改協(xié)商發(fā)送方A主機(jī)和中間人主機(jī)之間的連接狀態(tài)共享變量。

中間人程序在快速模式狀態(tài)處理過(guò)程中包括4個(gè)接收處理過(guò)程和4個(gè)發(fā)送處理過(guò)程。同主模式的處理過(guò)程相同，每一個(gè)處理步驟包括一個(gè)接收處理過(guò)程和一個(gè)發(fā)送處理過(guò)程。

由于驗(yàn)證環(huán)境中采用的是PFS前向認(rèn)證的模式，所以和主模式中的中間人處理過(guò)程類(lèi)似，快速模式中的中間人處理也要替換前兩個(gè)協(xié)商包中的DH公開(kāi)值，重新計(jì)算DH公開(kāi)值；與主模式中不同的是，IPsec SA的每個(gè)提案載荷中的頭部之后會(huì)有一個(gè)32位的隨機(jī)值(256-0xffffffff)SPI作為最終ESP加解密密鑰計(jì)算的素材，所以要將發(fā)送方A主機(jī)的多個(gè)SPI存儲(chǔ)起來(lái)，等到接收方B主機(jī)選擇的提案回送給A主機(jī)時(shí)，首先將接收方B主機(jī)產(chǎn)生的SPI儲(chǔ)存，然后將B主機(jī)選擇的IPsec SA中的提案與A主機(jī)發(fā)送的多個(gè)提案進(jìn)行匹配處理，找到相應(yīng)的A主機(jī)的SPI值進(jìn)行存儲(chǔ)。

經(jīng)過(guò)主模式和快速模式的處理，中間人主機(jī)分別和協(xié)商的A、B兩個(gè)主機(jī)產(chǎn)生一對(duì)ESP包的數(shù)據(jù)加解密密鑰與認(rèn)證密鑰，需要分別保存到相應(yīng)的連接信息共享變量中。

4 實(shí)驗(yàn)驗(yàn)證

4.1 驗(yàn)證環(huán)境

我們將進(jìn)行實(shí)驗(yàn)驗(yàn)證的進(jìn)行IPSEC通信的兩臺(tái)主機(jī)分別定義為A主機(jī)與B主機(jī)。把進(jìn)行中間人方法驗(yàn)證的主機(jī)定義為C主機(jī)。

A、B兩個(gè)主機(jī)的配置是大致相同的，主機(jī)配置如下所示：

機(jī)器型號(hào)：戴爾OptiPlex 990

操作系統(tǒng)：CentOS Linux6.5(開(kāi)發(fā)者版本)

IKE協(xié)商開(kāi)源應(yīng)用：Racoon2-20100526a.tgz

A主機(jī)驗(yàn)證中間人程序有效的socket工具：SocketApp_Client(自己開(kāi)發(fā)的Socket服務(wù)器端)。

B主機(jī)驗(yàn)證中間人程序有效的socket工具：SocketApp_Server(自己開(kāi)發(fā)的Socket客戶端)。

IPv4配置：禁用。

A主機(jī)IPv6配置：2001::ba97:5aff:fe04:dff0。

B主機(jī)IPv6配置：2001::ba97:5aff:fe04:dfe4。

C主機(jī)的配置如下：

機(jī)器型號(hào)：戴爾OptiPlex 990

操作系統(tǒng)：CentOS Linux6.5(開(kāi)發(fā)者版本)

針對(duì)IKE協(xié)商和ESP數(shù)據(jù)傳輸中間人程序：Racoon2-20100526a_1005.tgz

網(wǎng)絡(luò)數(shù)據(jù)包捕獲函數(shù)包：libpcap-1.5.3.tar.gz

網(wǎng)絡(luò)數(shù)據(jù)包構(gòu)造函數(shù)包：libnet-1.1.2.1.tar.gz

IPv4配置：禁用

IPv6配置：禁用

4.2 網(wǎng)絡(luò)連接

在C主機(jī)上增加了一個(gè)USB網(wǎng)絡(luò)接口轉(zhuǎn)換器，作為連接B主機(jī)的網(wǎng)絡(luò)接口。而C主機(jī)主板上的網(wǎng)絡(luò)接口連接到A主機(jī)。其網(wǎng)絡(luò)連接拓?fù)淙鐖D3所示。其中，接口eth0是中間人C主機(jī)主板上的網(wǎng)絡(luò)接口，接口eth1是C主機(jī)上增加的USB網(wǎng)絡(luò)連接轉(zhuǎn)化器。

圖3 網(wǎng)絡(luò)連接拓?fù)?/p>

4.3 驗(yàn)證方法

分別對(duì)受監(jiān)管主機(jī)A和主機(jī)B上的IKE協(xié)商工具Racoon2進(jìn)行配置，使兩臺(tái)主機(jī)選擇建立IKE協(xié)商通道的方法，比如預(yù)共享密鑰身份驗(yàn)證方式和數(shù)字簽名身份驗(yàn)證的方式。當(dāng)兩臺(tái)主機(jī)之間的配置包括IKE SA、密鑰生存時(shí)間、預(yù)共享密鑰、證書(shū)文件位置、打開(kāi)PFS開(kāi)關(guān)等。

當(dāng)確定好兩臺(tái)主機(jī)之間IKE協(xié)商參數(shù)后，在主機(jī)A上使用Ping6 2001::ba97:5aff:fe04:dfe4命令去訪問(wèn)B主機(jī)，當(dāng)兩者通信開(kāi)始后，A主機(jī)和B主機(jī)就開(kāi)始IKE協(xié)商并且建立好受監(jiān)管主機(jī)A和B之間的IPsec連接通道，當(dāng)受監(jiān)管主機(jī)A和B之間的連接通道建立好之后，然后用A主機(jī)上的SocketApp Client 端去訪問(wèn)B主機(jī)上的SocketApp Server端，并且循環(huán)發(fā)送字符串信息，Server端在收到字符串信息后也回復(fù)相同的字符串信息。如果訪問(wèn)過(guò)程中A、B主機(jī)通信的內(nèi)容都準(zhǔn)確無(wú)誤到達(dá)對(duì)方并且在中間人主機(jī)上能夠解密出A、B主機(jī)通信的明文信息的話，就表明針對(duì)IPsec協(xié)議的透明中間人方法模型有效并且傳輸信息不受干擾。

4.4 驗(yàn)證結(jié)果

在實(shí)驗(yàn)開(kāi)始時(shí)，我們?cè)贏主機(jī)運(yùn)用Ping命令去測(cè)試A、B主機(jī)之間是否能通過(guò)中間人主機(jī)C去建立一個(gè)IPsec通道。通過(guò)我們實(shí)驗(yàn)顯示，在A能夠通過(guò)C主機(jī)與B主機(jī)進(jìn)行Ping通信后，表明一個(gè)IPsec通道已經(jīng)建立。在IPSEC通道建立的過(guò)程中，C主機(jī)上接收并處理其兩個(gè)網(wǎng)絡(luò)接口上的協(xié)商數(shù)據(jù)包，一共產(chǎn)生了兩組IKE協(xié)商過(guò)程。

我們?cè)囼?yàn)了預(yù)共享密鑰認(rèn)證方式的IKE協(xié)商過(guò)程與數(shù)字簽名認(rèn)證的IKE協(xié)商過(guò)程，這兩種認(rèn)證方式協(xié)商生成的數(shù)據(jù)大致相同，只是數(shù)字簽名認(rèn)證方式的IKE協(xié)商第一階段的最后兩個(gè)數(shù)據(jù)包需要證書(shū)的交換。

如圖4所示的是C主機(jī)進(jìn)行中間人處理的過(guò)程，標(biāo)記的部分為中間人C主機(jī)對(duì)從兩個(gè)網(wǎng)絡(luò)上接收的ESP數(shù)據(jù)包進(jìn)行轉(zhuǎn)換的相應(yīng)操作。

圖4 中間人C主機(jī)ESP數(shù)據(jù)包轉(zhuǎn)換操作

中間人C主機(jī)與A、B兩臺(tái)主機(jī)之間產(chǎn)生的一組出口與入口的加密密鑰、認(rèn)證密鑰。在我們實(shí)驗(yàn)的過(guò)程中，使用enckey表示為ESP數(shù)據(jù)包加密密鑰輸出到日志中，authkey表示為ESP數(shù)據(jù)包的認(rèn)證密鑰輸出到日志中。產(chǎn)生的總密鑰數(shù)量為2對(duì)。

圖5 SockApp Client端發(fā)送消息內(nèi)容

圖5顯示了我們自己編寫(xiě)了一對(duì)Socket數(shù)據(jù)包傳輸程序在A、B主機(jī)之間進(jìn)行驗(yàn)證通信，A、B主機(jī)相互之間發(fā)送UDP數(shù)據(jù)包，發(fā)送的數(shù)據(jù)信息為隨機(jī)輸入的一串字符串“dsfsdfdsfdsf”，并且此字符串?dāng)?shù)據(jù)在兩個(gè)Socket程序之間是循環(huán)相互發(fā)送的。如圖6所示，A、B兩臺(tái)主機(jī)之間發(fā)送與接收數(shù)據(jù)成功。

圖6 SockApp Server端接受消息內(nèi)容

中間人C主機(jī)在分別接收到A主機(jī)與B主機(jī)發(fā)送的信息后進(jìn)行ESP數(shù)據(jù)包的轉(zhuǎn)換操作，同時(shí)，C主機(jī)會(huì)將解密的明文數(shù)據(jù)包轉(zhuǎn)換成PCAP格式的文件。我們通過(guò)Wireshark軟件打開(kāi)明文數(shù)據(jù)包的PCAP文件后，在明文數(shù)據(jù)包的Data字段找到了一組十六進(jìn)制的數(shù)據(jù)，如圖7所示，轉(zhuǎn)換為十進(jìn)制后為我們的Socket程序發(fā)送的字符串信息“dsfsdfdsfdsf”，以上實(shí)驗(yàn)證明了我們的原型系統(tǒng)具有對(duì)IPsec加密通信的數(shù)據(jù)進(jìn)行審計(jì)的功能。

圖7 中間人C截獲和轉(zhuǎn)換出的明文數(shù)據(jù)包

4.5 對(duì)通信效率帶來(lái)的影響測(cè)試

圖8所示的是當(dāng)我們?cè)谟蠧主機(jī)運(yùn)行時(shí)與沒(méi)有C中間人主機(jī)時(shí)運(yùn)用A主機(jī)對(duì)B主機(jī)進(jìn)行ping通信時(shí)產(chǎn)生的數(shù)據(jù)通信的時(shí)延進(jìn)行分析的數(shù)據(jù)圖。斜線填充柱狀數(shù)據(jù)代表當(dāng)C主機(jī)運(yùn)行安全審計(jì)時(shí)A主機(jī)對(duì)B主機(jī)在進(jìn)行Ping通信的時(shí)延，時(shí)延數(shù)據(jù)用左邊Y軸的坐標(biāo)數(shù)據(jù)進(jìn)行表示，單位為毫秒；與之作對(duì)比的灰色填充柱狀數(shù)據(jù)代表沒(méi)有C主機(jī)的情況下A主機(jī)對(duì)B主機(jī)進(jìn)行正常Ping通信的時(shí)延。

圖8 性能驗(yàn)證結(jié)果

由圖中數(shù)據(jù)我們可以分析出，C主機(jī)處理的時(shí)延對(duì)于正常Ping通信的每次響應(yīng)時(shí)間平均增加了約5.8 ms時(shí)間。據(jù)我們的估計(jì)分析，這5.8 ms時(shí)延時(shí)間是因?yàn)镃主機(jī)的硬件因素、C主機(jī)加解密處理時(shí)間、C主機(jī)網(wǎng)卡數(shù)據(jù)包處理時(shí)間造成的。所以，還需要對(duì)我們的原型系統(tǒng)進(jìn)行算法與硬件上的改進(jìn)，以減少審計(jì)處理的時(shí)延。

5 結(jié) 語(yǔ)

當(dāng)前的工作是在一種類(lèi)似透明網(wǎng)橋模式下進(jìn)行安全審計(jì)的方式，所以我們現(xiàn)在的安全審計(jì)的性能還是有一些不理想的。由于現(xiàn)在很多的研究熱點(diǎn)都集中在SDN，我們今后的網(wǎng)絡(luò)安全審計(jì)的工作會(huì)在SDN環(huán)境下進(jìn)行。

在SDN的模式下由于控制層面[8-9]與數(shù)據(jù)層面[10-11]的分離的出現(xiàn)，會(huì)對(duì)我們當(dāng)前的工作產(chǎn)生很大的跨越，也會(huì)給其他端到端的安全協(xié)議的數(shù)據(jù)安全審計(jì)帶來(lái)革命性的進(jìn)步。我們?cè)O(shè)想在SDN網(wǎng)絡(luò)環(huán)境下很多會(huì)造成延時(shí)的工作或者需要計(jì)算資源比較大的工作可以轉(zhuǎn)移到一個(gè)計(jì)算集群中進(jìn)行，集群之間的計(jì)算資源可以做安全審計(jì)的并行處理。那么在這種情況下，對(duì)于整個(gè)網(wǎng)絡(luò)的數(shù)據(jù)的安全審計(jì)的速度也會(huì)大大增加，安全審計(jì)的性能也會(huì)大大提高。

[1] NAT traversal[EB/OL]. http://en.wikipedia.org/wiki/NAT_traversal.

[2] Wei J, Tang L, Chen Z. Two Modifications for Identity Protection of Internet Key Exchange Protocols[J].Computer Engineering and Applications, 2004,40(26):33-36.

[3] Singh E G，Dhanda E S K. Quality of Service Enhancement of Wireless Sensor Network Using Symmetric Key Cryptographic Schemes[J].International Journal of Information Technology and Computer Science, 2014,6(8):32-42.

[4] Liu Z, Li Z, Lin S. Design and Implementation of 10-Gigabit IPsec ESP Protocol based on FPGA[J].Communications Technology, 2015.

[5] Zseby T，F(xiàn)abini J. Security Challenges for Wide Area Monitoring in Smart Grids[J]. e & i Elektrotechnik und Informationstechnik, 2014,131(3):105-111.

[6] Xu H, Cheng G, Yang F. Prevention of Man-In-The-Middle Attack in Diffie-Hellman Key Exchange under Specific Environment[J]. Information Security and Communications Privacy,2009(2):90-92.

[7] Zhang J. The Key Exchange System base on IKEv2 protocol[D].Shandong: Shandong University, 2014.

[8] Matsumoto S, Hitz S, Perrig A. Fleet: Defending SDNs from Malicious Administrators[C]//Proceedings of the Third Workshop on Hot Topics in Software Defined Networking,2014:103-108.

[9] Berde P, Gerola M, Hart J, et al. ONOS: Towards an Open, Distributed SDN OS[C]//Proceedings of the Third Workshop on Hot Topics in Software Defined Networking, 2014:1-6.

[10]JeyakumarV,AlizadehM,GengY,etal.MillionsofLittleMinions:UsingPacketsforLowLatencyNetworkProgrammingandVisibility[C]//Proceedingsofthe2014ACMConferenceonSIGCOMM,2014:3-14.

[11]YangT,XieG,LiY,etal.GuaranteeIPLookupPerformancewithFIBExplosion[C]//Proceedingsofthe2014ACMConferenceonSIGCOMM, 2014: 39-50.

THE RESEARCH OF IPSEC SECURITY AUDIT MECHANISM IN IPV6 ENVIRONMENT

Du Xuekai Wu Chengrong Yan Ming

(NetworkandInformationCenter,SchoolofComputerScience,FudanUniversity,Shanghai200433，China)

IPv6 network is now popularized gradually because IPv6 can satisfy the demand of possessing exclusive address of global network nodes, and more and more people use the IPSEC technology to communicate with each other. However, the lawful interception in IPSEC communication is becoming difficult for many institutions; it is a problem that needs to be solved. To address this problem, an IPSEC security audit method of combining man-in-the-middle attack and key escrow system in IPv6 network is proposed and a prototype system is also built to realize the IPSEC security audit in and between the IPv6 networks. After functional verification and performance analysis in IPv6 environment, the experiment demonstrates the efficiency of the proposed method as expected.

IPv6 network Network security audit Man-in-the-middle Key escrow scheme Internet protocol security

2015-10-23。杜學(xué)凱，碩士生，主研領(lǐng)域：網(wǎng)絡(luò)安全與SDN。吳承榮，副教授。嚴(yán)明，工程師。

TP393.08

A

10.3969/j.issn.1000-386x.2017.01.054