3.2 IPSec框架

一些傳統的安全技術（如HTTPS）以及無線安全技術（如WEP/WPA），往往會采用某種固定的加密和散列函數。這種做法帶有明顯的賭博性質，因為如果某天這個加密算法曝出嚴重漏洞，那么使用這個加密算法或者散列函數的安全技術也就難免要遭到淘汰。為了避免這種在一棵樹上吊死的悲慘事件發生，IPSec并沒有定義具體的加密和散列函數。IPSec的做法是提供一個框架性的結構，但每一次IPSec會話所使用的具體算法，都是通過協商來決定的。也就是說如果我們覺得 3DES 這個算法所提供的 168 位的加密強度能夠滿足當前的需要，那么就不妨暫且使用這個協議來加密數據。但是只要有一天 3DES 出現了嚴重漏洞，或者出現了一個更好的加密協議，那么我們也可以馬上更換加密協議，使 IPSec VPN 總是使用最新最好的協議來進行加密。圖3-2所示為IPSec框架示意圖，這張圖旨在說明，不僅僅是散列函數、加密算法，還包括封裝協議和模式、密鑰有效期等內容都可以通過協商決定，在兩個IPSec對等體之間協商的協議叫做IKE，這個協議會在本章的后續部分詳細進行介紹，我們現在就以 IPSec 框架涉及的技術為主線，詳細介紹這些技術的特點和工作原理。

3.2.1 散列函數

散列函數也叫做HASH函數，主流的散列算法有MD5與SHA-1。散列函數的主要任務是驗證數據的完整性。通過散列函數計算得到的結果叫做散列值，這個散列值也常常被稱為數據的指紋（Fingerprint）。為什么散列函數會被稱為數據的指紋呢？這是因為散列函數的工作原理和日常我們對指紋采集和使用的原理幾乎一樣。在說明散列函數工作原理之前，我們不妨先來回想一下日常生活中我們是如何對指紋進行采集和使用的。

圖3-3所示為日常生活中的指紋采集和使用示意圖。

圖3-2 IPSec框架示意圖

圖3-3 日常生活中指紋的采集和使用示意圖

步驟1：公安機關預先記錄“用戶X”的指紋“指紋一”。

步驟2：在某一犯罪現場，公安機關獲取到了“嫌疑犯”的指紋“指紋二”。

步驟3：通過查詢指紋數據庫發現“指紋一”等于“指紋二”。

步驟4：由于指紋的唯一性（沖突避免），可以確定犯罪“嫌疑犯”就是“用戶X”。

以上就是日常生活中指紋的采集和使用方法。接下來我們通過圖3-4來了解一下散列函數的工作原理，看看它是如何驗證數據完整性的。

步驟1：對“重要文件”執行散列函數計算，得到散列值“散列值一”。

步驟2：現在我們收到另外一個文件“文件？”，對“文件？”進行散列函數計算得到散列值“散列值二”。

步驟 3：將“散列值一”和“散列值二”進行對比，發現“散列值一”等于“散列值二”。

步驟4：由于散列值的唯一性（沖突避免），因此可以確定“文件？”就是“重要文件”。這兩份文件的每一個比特（bit）都完全相同。

圖3-4 散列函數的工作原理

散列函數具有下面4個特點。

1．固定大小

散列函數可以接收任意大小的數據，并輸出固定大小的散列值。以 MD5 這個散列算法為例，不管原始數據有多大，通過 MD5計算得到的散列值總是 128比特，而SHA-1的輸出長度則為160比特。

2．雪崩效應

原始數據就算修改哪怕一個比特，計算得到的散列值也會發生巨大的變化。

3．單向

只可能從原始數據計算得到散列值，不可能從散列值恢復哪怕一個比特的原始數據。

4．沖突避免

幾乎不能夠找到另外一個數據和當前數據計算的散列值相同，因此散列函數能夠確保數據的唯一性。

現在我們來看一下散列算法如何驗證數據的完整性。

圖3-5所示為散列函數驗證數據完整性的方式。

圖3-5 散列函數如何驗證數據完整性

步驟 1：使用散列函數，計算需要發送的“重要文件”的散列值，得到“散列值一”。

步驟2：對需要發送的“重要文件”和步驟1計算得到的“散列值一”進行打包，然后一起發送給接收方。

步驟3：接收方對收到的“重要文件”進行散列函數計算，得到“散列值二”。

步驟4：接收方將收到文件中的“散列值一”和步驟3計算得到的“散列值二”進行對比，如果兩個散列值相同，那么根據散列函數雪崩效應和沖突避免的特點，就可以確定“重要文件”的完整性，也就是這份“重要文件”在整個傳輸過程中沒有遭到過別人的篡改。

散列函數雖然能夠很好地確認數據的完整性，但是卻容易遭受中間人攻擊，我們來看看中間人攻擊是如何進行的，如圖3-6所示。

從圖3-6中可以發現，合法與非法用戶都可以對他們發送的信息進行散列函數計算，并得到散列值。因此他們也都能像圖3-5一樣把明文信息和散列值一起打包發送給接收方，而接收方也都能夠通過散列函數來校驗數據的完整性。因此，散列函數雖然能夠確認數據的完整性，卻不能確保這個數據來自于可信的源（不提供源認證），所以散列函數存在中間人攻擊的問題。

為了彌補這個漏洞，我們可以使用一個叫做密鑰化散列信息認證代碼（HMAC， Keyed-hash Message Authentication Code）的技術，這項技術不僅僅能夠實現完整性校驗，還能完成源認證的任務，圖3-7介紹了HMAC技術如何幫助OSPF動態路由協議實現對路由更新包的驗證。

圖3-6 散列函數的中間人攻擊問題

圖3-7 HMAC技術如何驗證OSPF路由更新包（發送方）

步驟1：首先，網絡管理員需要預先在要建立OSPF鄰居關系的兩臺路由器上，通過ipospf message-digest-key 1 md5 cisco命令，配臵預共享秘密“cisco”。

步驟 2：發送方把要發送的路由更新信息加上預共享秘密一起進行散列計算，得到“散列值一”，這種聯合共享秘密一起計算散列值的技術就叫做HMAC。

步驟3：發送方路由器把步驟2通過HMAC技術得到的“散列值一”和明文的路由更新信息進行封裝，一起發送給接收方（注意路由更新信息是明文發送的，絕對沒有進行任何加密處理）。

接下來的圖3-8介紹了接收方一側所執行的對HMAC驗證的步驟。

圖3-8 HMAC技術如何驗證OSPF路由更新包（接收方）

步驟1：從收到的信息中提取明文的路由更新信息。

步驟2：把步驟1提取出來的明文路由更新信息加上接收方路由器預先配臵的共享密鑰“cisco”一起進行散列計算，得到“散列值二”。

步驟3：提取出收到信息中的“散列值一”，用它和步驟2計算得到的“散列值二”進行比較，如果相同，表示路由更新信息是沒有被篡改過的，也就是完整的。同時，還可以確定這是預先配臵共享秘密的那臺比鄰路由器所發送的路由更新，因為只有這臺路由器才知道共享秘密的內容，因此也只有它才能夠通過HMAC技術制造出能夠校驗成功的散列值。

上述對OSPF路由更新的介紹，可以體現出HMAC的兩大安全特性，完整性校驗和源認證。應該說在實際運用中，基本不會單純地使用散列函數，絕大多數情況都會使用HMAC技術。例如，IPSec和HTTPS技術都采用了HMAC技術來對每一個傳輸的數據包做完整性校驗和源認證。

3.2.2 加密算法

說完了散列函數，接下來我們花一點時間來介紹加密算法。加密，顧名思義就是把明文數據轉換為密文數據。這樣一來，即使第三方截獲到了密文數據，也無法將其恢復為明文。而解密過程則正好相反，合法的接收者通過正確的解密算法和密鑰恢復密文到明文。加密算法可以分為如下兩大類：

對稱密鑰算法；

非對稱密鑰算法。

1．對稱密鑰算法

圖3-9所示為對稱密鑰算法的工作示意圖，從圖中可以看到一個很明顯的特點，加解密雙方使用相同的密鑰與算法進行加解密。因此，使用相同密鑰與算法進行加解密運算的算法就叫做對稱密鑰算法，對稱密鑰算法有如下特點。

圖3-9 對稱密鑰算法的工作示意圖

優點：

速度快；

安全；

緊湊。

缺點：

明文傳輸共享密鑰，容易出現中途劫持和竊聽的問題；

隨著參與者數量的增加，密鑰數量急劇膨脹（（n×（n-1））/2）；

因為密鑰數量過多，對密鑰的管理和存儲是一個很大的問題；

不支持數字簽名和不可否認性。

對稱密鑰算法的主流協議：

1．DES；

2．3DES；

3．AES；

4．RC4。

我們先來討論對稱密鑰算法的優點。它的首要優點就是速度快。作一個比較直觀的比較，想必大多數讀者都有使用壓縮軟件的經歷，而對稱密鑰算法加密的速度應該比壓縮的速度稍快（不同的算法有差異）。另外，現在無線網絡的使用也很普及，絕大部分用戶所使用的都是最新的無線安全技術WPA2，而WPA2就是使用AES來加密的。無線用戶在上網沖浪時，似乎并不會感覺到由于加密造成的網絡延時。而且只要他們的路由器或者交換機配上硬件加速模塊，那就基本上能夠實現線速加密，因此速度是對稱密鑰算法的一大優勢。

現在我們來介紹對稱密鑰算法緊湊性的特點，DES是一個典型的塊加密算法。所謂塊加密，顧名思義就是把需要加密的數據包預先切分成為很多個相同大小的塊（DES的塊大小為64比特），然后使用DES算法逐塊進行加密。如果不夠塊邊界，就添加數據補齊塊邊界，這些添加的數據就會造成加密后的數據比原始數據略大。以一個1500個字節大小的數據包為例，通過DES塊加密后，最多（極限值）會增加8個字節（64個比特）的大小。所以可以認為對稱密鑰算法加密后的數據是緊湊的。

圖3-10所示為DES的兩種塊加密方式。

圖3-10 DES的兩種塊加密方式

接下來我們再來說說DES 的兩種塊加密方式：電子代碼本（Electronic Code Book， ECB）和密碼塊鏈接（Cipher Block Chaining，CBC）。對于ECB 這種加密方式來說，所有的塊都是使用相同的DES密鑰進行加密的。這種加密方式有一個問題，那就是相同的明文塊加密后的結果也肯定相同。雖然中間截獲數據的攻擊者并不能解密數據，但是他們至少知道通信的雙方正在反復加密相同的數據包。為了解決這個問題，CBC技術孕育而生，使用CBC技術加密的數據包，會隨機產生一個明文的初始化向量（IV）字段，這個IV字段會和第一個明文塊進行異或操作，然后使用DES算法對異或后的結果進行加密，所得到的密文塊又會和下一個明文塊進行異或操作，然后再加密。這個操作過程就叫做CBC。由于每一個數據包都使用隨機產生的IV字段進行了擾亂，因此就算傳輸的明文內容一樣，加密后的結果也會出現本質差異，并且整個加密的塊是鏈接在一起的，任何一個塊解密失敗，剩余部分都無法進行解密了，這就增加了中途劫持者解密數據的難度。

說完了對稱密鑰算法的優勢，我們再來討論一下它的缺點。對稱密鑰算法的首要問題是，如何把相同的密鑰發送給通信的雙方。在這里，采用明文的方式傳輸密鑰顯然是非常不明智的，因為如果明文傳輸的密鑰被中間人獲取，那么中間人就能夠解密使用這個密鑰所加密的數據，這也就與直接采用明文傳送數據沒有什么區別了。第二個問題是，使用相同的一個密鑰來加密去往所有用戶的數據顯然是非常不安全的。因此，我們希望兩兩用戶之間共享一個唯一的密鑰，并且在一次加密任務完成以后更新這個密鑰。我們可以試想一下，假如只有4個用戶要傳送信息，且兩兩之間共享一個密鑰的話，這個環境中就一共需要使用6個密鑰（（n×（n-1））/2）；依此類推，5個用戶需要10個密鑰，那么100個用戶？1000個用戶呢？密鑰數量將是一個不折不扣的天文數字。問題是，我們所討論的都是互聯網的加密解決方案。說得夸張一些，用戶數上萬也很正常。因此，對稱密鑰算法需要使用的密鑰數量過多，不好管理與存儲是一個比較嚴重的問題。另外，對稱密鑰算法也不支持數字簽名技術（該技術我們將在后文中進行詳細地介紹）。由于這一系列的缺點，我們一般不會在一套加密解決方案中單純地使用對稱密鑰算法。

2．非對稱密鑰算法

圖3-11所示為非對稱密鑰的產生和維護。

如圖3-11所示，在使用非對稱密鑰技術之前，所有參與者，不管是用戶還是路由器等網絡設備，都需要預先使用非對稱密鑰算法（例如RSA）產生一對密鑰，其中包括一個公鑰和一個私鑰。公鑰可以放在服務器上共享給屬于這個密鑰系統的所有用戶與設備，而私鑰需要由持有者嚴格保護，確保只有持有者才能唯一擁有。

非對稱密鑰算法的特點是一個密鑰加密的信息，必須使用另一個密鑰來解密。也就是說公鑰加密私鑰解密，私鑰加密公鑰解密。公鑰加密的數據，無法再使用公鑰解密，私鑰加密的數據，也無法再使用私鑰解密。我們可以使用非對稱密鑰算法來加密數據和對數據進行數字簽名。

圖3-11 非對稱密鑰的產生和維護

圖3-12所示為使用非對稱密鑰算法實現數據加密。

圖3-12 使用非對稱密鑰算法實現數據加密

首先我們通過圖3-12，來介紹如何使用非對稱密鑰算法來完成加密數據。

步驟1：“用戶一”（發起方）需要預先獲取“用戶二”（接收方）的公鑰。

步驟2：“用戶一”使用“用戶二”的公鑰對重要的信息進行加密。

步驟 3：中途截獲數據的攻擊者由于沒有“用戶二”的私鑰而無法對數據進行解密。

步驟4：用戶二使用自己的私鑰對加密后的數據（由用戶二公鑰加密）進行解密，使用公鑰加密私鑰解密的方法實現了數據的私密性。

但是由于非對稱密鑰算法運算速度極慢（和對稱密鑰算法相比有上千倍的差距），因此基本不可能使用非對稱密鑰算法對實際數據進行加密。在實際運用中，我們主要使用非對稱密鑰算法的這個特點來對密鑰進行加密，以進行密鑰交換。具體操作方式將在本章的后續部分進行詳細介紹。

非對稱密鑰算法的第二個用途就是實現數字簽名，在介紹數字簽名前，我們不妨先來討論一下實際生活中的簽名。為什么要簽名呢？簽名的目的無非是對某一份文件進行確認。例如，欠條。張三欠李四10000元錢，欠款人張三在欠條上簽名確認。簽名的主要作用就是張三對這張欠條進行確認，事后不能抵賴（不可否認性）。到底最后誰會看這個簽名呢？李四很明顯沒有必要反復去確認簽名。一般都是在出現糾紛后，例如，張三抵賴不還的時候，李四就可以把欠條拿出來，給村長或者法官這些有權威的第三方來進行驗證，如果他們確認此欠條上的簽名確實來自張三無疑，張三就不能再否認欠李四錢這一既定事實了。

圖3-13所示為使用非對稱密鑰算法實現數字簽名。

了解了實際生活中簽名的工作原理后，我們可以通過圖3-13來看看數字簽名是如何工作的。

步驟1：重要明文信息通過散列函數計算得到散列值。

步驟2：“用戶一”（發起者）使用自己的私鑰對步驟1計算的散列值進行加密，加密后的散列就叫做數字簽名。

步驟3：把重要明文信息和數字簽名一起打包發送給“用戶二”（接收方）。

步驟4：“用戶二”從打包文件中提取出重要明文信息。

步驟5：“用戶二”使用和“用戶一”相同的散列函數對步驟4提取出來的重要明文信息計算散列值，得到的結果簡稱“散列值1”。

步驟6：“用戶二”從打包文件中提取出數字簽名。

步驟7：“用戶二”使用預先獲取的“用戶一”的公鑰，對步驟6提取出的數字簽名進行解密，得到明文的“散列值2”。

步驟8：比較“散列值1”和“散列值2”是否相等。如果相等，數字簽名校驗成功。

圖3-13 使用非對稱密鑰算法實現數字簽名

數字簽名校驗成功能夠說明哪些問題呢？第一，保障了傳輸的重要明文信息的完整性。因為散列函數擁有沖突避免和雪崩效應兩大特點。第二，可以確定對重要明文信息進行數字簽名的用戶為“用戶一”，因為我們使用“用戶一”的公鑰成功解密了數字簽名，只有“用戶一”才能使用他的私鑰加密散列產生數字簽名，才能夠使用“用戶一”的公鑰進行解密。通過數字簽名的實例說明，數字簽名和前面已經講過的HMAC技術一樣，可以提供如下兩大安全特性：

完整性校驗；

源認證。

下面我們對非對稱密鑰算法的特點進行總結。

工作特點：

用一個密鑰加密的數據只能用另一個密鑰來解密；

僅用于密鑰交換（加密密鑰）和數字簽名（加密散列）。

優點：

安全；

由于不必擔心交換的公鑰被劫持，所以非對稱密鑰的分發更安全；

密鑰數目和參與者數目相同；

在交換公鑰之前不需要預先建立某種信任關系；

支持數字簽名和不可否認性。

缺點：

加密速度很慢；

密文會變長。

非對稱密鑰算法的主流協議：

1．RSA（數字簽名和數字證書的主流協議）；

2．DH（IPSec產生密鑰資源的主要協議）；

3．ECC（橢圓曲線算法）。

介紹完非對稱密鑰算法如何工作以后，我們再來談談它的優缺點。非對稱密鑰算法的優點是很突出的：由于非對稱密鑰算法的特點，公鑰是共享的，不用保障公鑰的安全性，所以密鑰交換比較簡單，并且不必擔心中途被截獲。此外，在使用非對稱密鑰算法的環境中，每增加一個用戶，只需要增加一個公鑰，密鑰的數量與參與者數量相同，也就是說一萬個用戶只需要管理和存儲一萬個公鑰，相對于對稱密鑰算法，密鑰的數量可以減少很多。另外，非對稱密鑰算法還可以支持數字簽名和不可否認性，而不可否認性的依據就是，只有私鑰的持有者才能唯一擁有這個私鑰。

說完非對稱密鑰算法的優點，我們也來看看它的嚴重缺陷。非對稱密鑰算法的主要問題就是它的加密速度奇慢。如果拿RSA這個非對稱密鑰算法和DES這個對稱密鑰算法相比，加密相同大小的數據，DES大概要比RSA快幾百倍。所以想要如圖3-12所示那樣，使用非對稱密鑰算法來加密實際的數據幾乎是不可能的。另外，使用非對稱加密算法加密后的密文會變得很長。舉一個夸張點的例子，用RSA來加密1GB的數據（當然RSA肯定沒法加密1GB的數據），加密后的密文可能變成2GB，與對稱密鑰算法相比這就太不緊湊了。由于這些缺點，與對稱密鑰算法一樣，我們在一套安全解決方案中不可能單獨使用非對稱密鑰算法。那么我們應該如何利用對稱和非對稱密鑰算法的優勢來加密實際的數據呢？我們緊接著來看一個“巧妙的加密解決方案”。

3．巧妙的加密解決方案

我們已經學習過了對稱密鑰算法和非對稱密鑰算法，你會發現兩種算法都各有其優缺點。對稱密鑰算法加密速度快，但是密鑰數量過多不好管理，并且密鑰分發不安全。非對稱密鑰算法密鑰數量少，密鑰分發方便并且不存在安全隱患，但是加密速度奇慢，不可能用于大流量數據的加密。所以在實際使用加密算法的時候，一般會讓兩種算法共同工作，發揮各自優點。下面是一個非常巧妙的聯合對稱和非對稱算法的解決方案，這種解決問題的思路被大量運用到實際加密技術中。

圖3-14所示為聯合使用兩種密鑰算法的巧妙加密解決方案（發起方處理過程）。

圖3-14 巧妙的加密解決方案（發起方處理過程）

步驟1：“用戶一”（發起方）使用本地隨機數產生器，產生用于對稱密鑰算法的隨機密鑰。如果使用的對稱密鑰算法是DES，DES的密鑰長度為56比特，也就是說隨機數產生器需要產生56個隨機的“00011101001000110000111…”用于加密數據。

步驟 2：使用步驟1 產生的隨機密鑰，對重要的明文信息通過對稱密鑰算法進行加密，并得到密文（很好地利用了對稱密鑰算法速度快和結果緊湊的特點）。

步驟3：“用戶一”（發送方）需要預先獲取“用戶二”（接收方）的公鑰，并且使用“用戶二”的公鑰對步驟1產生的隨機密鑰進行加密，得到加密的密鑰包。

步驟4：對步驟2和步驟3產生的密文和密鑰包進行打包，一起發送給“用戶二”（接收方）。

圖3-15所示為接收方處理過程。

步驟1：“用戶二”首先提取出密鑰包，并且使用自己的私鑰對它進行解密，并得到明文的隨機密鑰（使用非對稱密鑰算法進行密鑰交換，有效防止密鑰被中途劫持）。

步驟2：“用戶二”提取出密文，并且使用步驟1解密得到的隨機密鑰進行解密，得到明文的重要信息。

圖3-15 巧妙的加密解決方案（接收方處理過程）

在這個巧妙的加密解決方案中，我們使用了對稱密鑰算法對大量的實際數據（重要信息）進行加密，因而很好地利用了對稱密鑰算法加密速度快、密文緊湊的優勢。同時我們又使用非對稱密鑰算法，對對稱密鑰算法使用的隨機密鑰進行加密，因而實現了安全的密鑰交換，很好地利用了非對稱密鑰不怕中途劫持的特點。這個巧妙的解決方案大量地運用在實際加密技術中，我們后面要介紹的IPSecVPN 也是先使用非對稱密鑰算法DH來產生密鑰資源，然后再使用對稱密鑰算法（DES、3DES……）來加密實際數據的。

3.2.3 封裝協議

IPSec有ESP和AH兩種封裝協議。

1．ESP協議

ESP（Encapsulation Security Payload）的IP 協議號為50，ESP 能夠為數據提供私密性（加密）、完整性和源認證3大方面的保護，并且能夠抵御重放攻擊（反復發送相同的包，接收方由于不斷地解密消耗系統資源，實現拒絕服務攻擊（DOS））。ESP只能保護IP負載數據，不對原始IP頭部進行任何安全防護。

圖3-16所示為ESP數據包的結構示意圖，下面我們分別對ESP包的各個字段逐一進行介紹。

（1）安全參數索引（SPI）

一個32 比特的字段，用來標識處理數據包的安全關聯（Security Association），關于安全關聯相關的內容我們會在本章的后續部分進行介紹。

圖3-16 ESP包結構示意圖

（2）序列號（SN）

一個單調增長的序號，用來標識一個ESP數據包。例如，當前發送的ESP包序列號是X，下一個傳輸的ESP包序列號就是X+1，再下一個就是X+2。接收方通過序列號來防止重放攻擊，原理也很簡單，當接收方收到序列號X的ESP包后，如果再次收到序列號為X的ESP包就被視為重放攻擊，采取丟棄處理。

（3）初始化向量（Initialization Vector）

我們在前面介紹過CBC這種塊加密方式，每一個需要使用CBC來加密的數據包都會產生一個隨機數，用于加密時對數據進行擾亂，這個隨機產生的數就叫做初始化向量（IV）。當然 IPSec VPN 也可以選擇不加密（加密不是必須的，雖然我們一般都會采用），如果不加密就不存在IV字段。所以在圖3-16中有兩個ESP包結構示意圖，左邊白底的ESP包沒有IV字段表示不加密，右邊深色底的存在IV字段則表示要加密。

（4）負載數據（Payload Data）

負載數據就是IPSec加密所保護的數據，它很有可能就是TCP頭部加相應的應用層數據。當然我們后面還會介紹兩種封裝模式，封裝模式的不同也會影響負載數據的內容。

（5）墊片（Padding）

Cisco 的IPSecVPN 都采用了CBC 的塊加密方式，既然采用塊加密，就需要把數據補齊塊邊界。以DES為例，就需要補齊64比特的塊邊界，追加的補齊塊邊界的數據就叫做墊片。如果不加密就不存在墊片字段。

（6）墊片長度（Pad Length）

墊片長度顧名思義就是告訴接收方，墊片數據有多長，接收方解密后就可以清除這部分多余數據。如果不加密就不存在墊片長度字段。

（7）下一個頭部（Next Header）

下一個頭部標識IPSec封裝負載數據里邊的下一個頭部，根據封裝模式的不同下一個頭部也會發生變化，如果是傳輸模式，下一個頭部一般都是傳輸層頭部（TCP/UDP）；如果是隧道模式，下一個頭部肯定是IP。關于傳輸和隧道模式我們會在本章后續部分進行介紹。這里順便提一下，從“下一個頭部”這個字段中，我們可以看到 IPv6 的影子。IPv6 的頭部就是使用很多個“下一個頭部”串接在一起的，這也說明IPSec最初是為IPv6而設計的。

（8）認證數據（Authentication Data）

ESP會對從ESP頭部到ESP尾部的所有數據進行驗證，也就是做HMAC的散列計算，得到的散列值就會被放到認證數據部分，接收方可以通過這個認證數據部分對ESP數據包進行完整性和源認證的校驗。

2．AH協議

AH（Authentication Header）IP 協議號為 51，AH 只能夠為數據提供完整性和源認證兩方面的安全服務，并且抵御重放攻擊。AH 并不能為數據提供私密性服務，也就是說不加密，所以在實際部署IPSecVPN 的時候很少使用AH，絕大部分IPSecVPN都會使用ESP進行封裝。當然AH不提供私密性服務，只是它不被廣泛采用的其中一個原因，后面部分我們還會介紹AH沒有得到廣泛使用的另外一個原因。

圖3-17 AH包結構示意圖

圖 3-17 所示為AH 包結構示意圖，從圖中我們可以看到AH 與ESP 的關鍵性區別，即AH對數據驗證的范圍更廣，不僅包含原始數據，還包含了原始IP頭部，AH認證頭部的名稱就由此而得名。

圖3-18所示為AH驗證的IP頭部字段。

圖3-18 AH驗證IP頭部字段

雖然AH要驗證原始IP頭部，但并不是IP頭部的每一個字段都要進行完整性驗證。在圖3-18中，灰色部分字段就是AH不進行驗證的范圍。也就是說，AH只會對剩余的白色部分字段進行完整性校驗。可以看到IP地址字段是需要驗證的，因而不能被修改。AH這么選擇也有它自身的原因。IPSec的AH封裝最初是為IPv6設計的。而在IPv6的網絡中，地址不改變非常正常，但是我們現在使用的主要是IPv4的網絡，網絡地址轉換（NAT）技術經常被采用。一旦AH封裝的IPSec數據包穿越NAT，地址就會改變，抵達目的地之后就不能通過驗證，所以AH協議封裝的IPSec數據包不能穿越NAT，這就是AH現在沒有得到大量部署的第二大原因。

3．2.4封裝模式

IPSec有如下兩種數據封裝模式：

傳輸模式（Transport mode）；

隧道模式（Tunnel mode）。

圖3-19所示為傳輸模式的封裝示意圖。

我們先通過圖3-19來看傳輸模式是如何對數據進行封裝的，因為AH很少使用，所以封裝模式示意圖中我們都以ESP封裝協議為例來進行介紹。

傳輸模式實現起來很簡單，主要就是在原始IP頭部和IP負載（TCP頭部和應用層數據）之間插入一個ESP頭部。當然ESP還會在最后追加上ESP尾部和ESP驗證數據部分，并且對IP負載和ESP尾部進行加密和驗證處理，但原始IP頭部被完整地保留了下來。

圖3-19 傳輸模式封裝示意圖

圖3-20 所示為傳輸模式IPSec VPN 實例分析。

我們現在通過部署在Yeslab安全實驗室內部的一個IPSec VPN來說明傳輸模式是如何工作的，圖3-20 是這個IPSec VPN 的示意圖。

圖3-20 傳輸模式IPSec VPN實例分析

設計這個IPSec VPN 的主要目的是，對我的電腦訪問內部重要文件服務器的流量進行安全保護。我電腦的IP地址為10.1.1.5，服務器的IP地址為10.1.19.5。這兩個地址是實驗室網絡的內部地址，至少在Yeslab實驗室內部是全局可路由的。傳輸模式只是在原始IP頭部和IP負載中間插入了一個ESP頭部（圖例中省略了ESP尾部和ESP驗證數據部分），并且對IP負載進行加密和驗證操作。我們把實際通信的設備叫做通信點，加密數據的設備叫做加密點，在這幅傳輸模式IPSec示意圖中，實際通信和加密設備都是我的電腦（10.1.1.5）和服務器（10.1.19.5），所以加密點等于通信點。只要能夠滿足加密點等于通信點的條件就可以進行傳輸模式封裝。其實根據個人的經驗，要使用傳輸模式進行封裝，通信設備（接收方和發起方）的IP地址，必須在位于其間的網絡可路由，否則就必須使用隧道模式。通信點和加密點是很重要的一個概念，因為它直接影響著IPSec VPN 關于路由的配臵。在下一章我們還會進一步討論加密點和通信點如何影響IPSec VPN 的路由。

講完了傳輸模式，我們緊接著來看一下隧道模式是如何對數據進行封裝的。

圖3-21所示為隧道模式的封裝示意圖。隧道模式把原始IP數據包整個封裝到了一個新的IP數據包中，并且在新IP頭部和原始IP頭部中間插入了ESP頭部，以此對整個原始IP數據包進行了加密和驗證處理。那么，什么樣的網絡拓撲適合使用隧道模式來封裝IP 數據包呢？站點到站點的IPSec VPN 就是一個經典的實例，我們可以分析一下站點到站點的IPSec VPN 是如何使用隧道模式來封裝數據包的。

圖3-21 隧道模式封裝示意圖

圖3-22是一個典型的站點到站點IPSec VPN示意圖，分支站點身后保護網絡為10.1.1.0/24，中心站點身后保護網絡為 10.1.2.0/24。分支站點有一臺終端電腦要通過站點到站點的IPSec VPN來訪問中心站點的數據庫服務器。這兩臺電腦就是我們所說的通信點。真正對數據進行加密的設備是兩個站點連接互聯網的路由器，假設分支站點路由器獲取的互聯網地址為202.100.1.1，中心站點的互聯網地址為61.128.1.1。那么路由器的這兩個地址就是加密點。很明顯加密點不等于通信點，因此這個時候就應該采用隧道模式來對數據進行封裝。封裝后在互聯網上傳輸的IPSec數據包如圖3-22所示，最外層頭部為加密點為源和目的IP頭部，緊接著是ESP頭部，最內層為被安全保護的原始IP數據包。

圖3-22 站點到站點隧道模式分析示意圖

圖3-23 所示為站點到站點IPSec VPN 使用傳輸模式的封裝包結構。

圖3-23 站點到站點IPSec VPN使用傳輸模式的封裝包結構

我們也可以假設如果在圖3-22所示的拓撲中，依然進行傳輸模式封裝，那么封裝后的結果如圖3-23所示。如果將這樣封裝的數據包直接發送到互聯網，那么它一定會被互聯網路由器丟棄，因為10.1.1.0/24和10.1.2.0/24都是客戶內部網絡，在互聯網上不可路由。為了讓站點到站點的流量能夠通過IPSecVPN 加密后穿越互聯網，我們需要在兩個站點間制造一個“隧道”，把站點間的流量封裝到這個隧道內，并穿越互聯網。這個隧道其實就是通過插入全新的 IP 頭部和ESP頭部來實現的。再次重復一遍使用隧道模式的條件：只要加密點不等于通信點我們就應該采用隧道模式封裝，或者說通信點的IP地址在其間的網絡是不可路由的，就應該采用隧道模式封裝。

3.2.4 密鑰有效期

長期使用相同密鑰來加密數據是不明智的，我們應該周期性地更新密鑰， Cisco的IPSec VPN 用于加密實際數據的密鑰，默認每一個小時（3600 秒）就要更新一次。我們也可以根據自身的情況對密鑰有效期進行調整。但是這種調整應該遵循一個簡單的原則，那就是密鑰加密的數據越多，這個密鑰的有效期就應該越短；加密的數據越少，它的有效期就可以越長。

Cisco 的 IPSec VPN 雖然默認每小時更換一次密鑰，但下一個小時使用的密鑰，是由當前這個小時使用的密鑰，通過一系列的算法衍生得出的。也就是說這些密鑰之間存在推演關系。這樣的密鑰更新就不能叫做完美向前保密 PFS（Perfect Forward Secrecy）。PFS 要求每一次密鑰更新，都需要重新產生全新的密鑰，和以前使用的密鑰不存在任何衍生關系。Cisco 的IPSec VPN 一旦啟用了PFS 技術，就會在每一個小時結束的時候，展開一次全新的DH交換（本章后續內容將會詳細介紹這種算法），產生全新的密鑰用于下一個小時加密。關于PFS的配臵我們會在后面部分介紹。