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

杜學凱 吳承榮 嚴 明

(復旦大學網絡與信息工程中心，計算機科學技術學院 上海 200433)

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

杜學凱 吳承榮 嚴 明

(復旦大學網絡與信息工程中心，計算機科學技術學院 上海 200433)

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

IPv6網絡 安全審計 中間人機制 密鑰托管 Internet Protocol Security

0 引 言

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

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

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

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

1 基本原理

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

1.1 數據分類處理

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

如圖1所示，分類器的處理工作處理如下：

如果不是有關于IPsec機制的數據包，則將數據包不作處理，透明傳輸。

圖1 分類處理原理

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

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

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

如果此IPv6地址對的數據包進行過密鑰托管，則向運行的IKE處理模塊發(fā)送一個已托管信息，并將已托管的對應于相應地址對的密鑰發(fā)送給IKE處理模塊(通過密鑰托管中心與IKE處理模塊的保密線路)。此處還要根據具體處理后的情形進行分類：由于密鑰托管中心是否托管的是兩個通信主機實際在使用的密鑰對，解密ESP數據包后有兩種情況，一種是解密出正確的明文，另外一種是解密出不正確的明文?？梢酝ㄟ^解密后數據包的傳輸層協(xié)議報頭部分的下一字段來判斷是否解密成功。(TCP報頭的頭部長度字段、校驗和字段或UDP報頭的長度字段、校驗和是否正確或在正確的范圍內)。

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

1.2 IKE協(xié)商處理

本節(jié)主要對圖1中IKE協(xié)商過程[4-5]的原理進行描述。經過分類器的分類，已經將需要處理的IKE協(xié)商數據包分離出來，然后再進行IKE協(xié)商中間人方法的處理。

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

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

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

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

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

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

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

對于數字簽名認證的方式，如果在認證過程中需要證書的交換，需要去密鑰托管中心進行證書的獲取，如果證書未經托管備案，則分別向正在協(xié)商的兩臺主機發(fā)送IKE協(xié)商出錯信息，阻斷兩臺主機的IKE協(xié)商過程；如果托管了證書，且如果B主機的證書有多個，則對每個證書進行驗證運算，如果驗證成功說明找到主機的證書，如果匹配未成功說明主機的證書沒有經過備案，則向兩臺主機分別發(fā)送IKE協(xié)商出錯信息阻斷協(xié)商過程。

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

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

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

2 總體設計

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

圖2 總體框圖

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

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

3 詳細實現

3.1 密鑰素材

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

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

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

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

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

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

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

簽名和HASH計算需要的素材：SKEYID、通信雙方和中間人產生的兩對DH公開值、兩個階段的SA載荷的數據、通信雙方的身份認證識別載荷ID、同一個CA的根證書簽發(fā)的兩個或多個證書文件。

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

3.2 模塊劃分

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

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

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

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

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

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

3.3 分類器模塊實現

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

經過主模式和快速模式的處理，中間人主機分別和協(xié)商的A、B兩個主機產生一對ESP包的數據加解密密鑰與認證密鑰，需要分別保存到相應的連接信息共享變量中。

4 實驗驗證

4.1 驗證環(huán)境

我們將進行實驗驗證的進行IPSEC通信的兩臺主機分別定義為A主機與B主機。把進行中間人方法驗證的主機定義為C主機。

A、B兩個主機的配置是大致相同的，主機配置如下所示：

機器型號：戴爾OptiPlex 990

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

IKE協(xié)商開源應用：Racoon2-20100526a.tgz

A主機驗證中間人程序有效的socket工具：SocketApp_Client(自己開發(fā)的Socket服務器端)。

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

IPv4配置：禁用。

A主機IPv6配置：2001::ba97:5aff:fe04:dff0。

B主機IPv6配置：2001::ba97:5aff:fe04:dfe4。

C主機的配置如下：

機器型號：戴爾OptiPlex 990

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

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

網絡數據包捕獲函數包：libpcap-1.5.3.tar.gz

網絡數據包構造函數包：libnet-1.1.2.1.tar.gz

IPv4配置：禁用

IPv6配置：禁用

4.2 網絡連接

在C主機上增加了一個USB網絡接口轉換器，作為連接B主機的網絡接口。而C主機主板上的網絡接口連接到A主機。其網絡連接拓撲如圖3所示。其中，接口eth0是中間人C主機主板上的網絡接口，接口eth1是C主機上增加的USB網絡連接轉化器。

圖3 網絡連接拓撲

4.3 驗證方法

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

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

4.4 驗證結果

在實驗開始時，我們在A主機運用Ping命令去測試A、B主機之間是否能通過中間人主機C去建立一個IPsec通道。通過我們實驗顯示，在A能夠通過C主機與B主機進行Ping通信后，表明一個IPsec通道已經建立。在IPSEC通道建立的過程中，C主機上接收并處理其兩個網絡接口上的協(xié)商數據包，一共產生了兩組IKE協(xié)商過程。

我們試驗了預共享密鑰認證方式的IKE協(xié)商過程與數字簽名認證的IKE協(xié)商過程，這兩種認證方式協(xié)商生成的數據大致相同，只是數字簽名認證方式的IKE協(xié)商第一階段的最后兩個數據包需要證書的交換。

如圖4所示的是C主機進行中間人處理的過程，標記的部分為中間人C主機對從兩個網絡上接收的ESP數據包進行轉換的相應操作。

圖4 中間人C主機ESP數據包轉換操作

中間人C主機與A、B兩臺主機之間產生的一組出口與入口的加密密鑰、認證密鑰。在我們實驗的過程中，使用enckey表示為ESP數據包加密密鑰輸出到日志中，authkey表示為ESP數據包的認證密鑰輸出到日志中。產生的總密鑰數量為2對。

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

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

圖6 SockApp Server端接受消息內容

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

圖7 中間人C截獲和轉換出的明文數據包

4.5 對通信效率帶來的影響測試

圖8所示的是當我們在有C主機運行時與沒有C中間人主機時運用A主機對B主機進行ping通信時產生的數據通信的時延進行分析的數據圖。斜線填充柱狀數據代表當C主機運行安全審計時A主機對B主機在進行Ping通信的時延，時延數據用左邊Y軸的坐標數據進行表示，單位為毫秒；與之作對比的灰色填充柱狀數據代表沒有C主機的情況下A主機對B主機進行正常Ping通信的時延。

圖8 性能驗證結果

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

5 結 語

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

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

[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，Fabini 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。杜學凱，碩士生，主研領域：網絡安全與SDN。吳承榮，副教授。嚴明，工程師。

TP393.08

A

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