IPSec的基本知識

來源：ITer的Climb Road

01—IPSec 基本原理

IPSec 是一項標準的安全技術，它通過在數據包中插人一個預定義頭部的方式，來保障 OSI 上層協議數據的安全。IPSec 主要用于保護網絡層(IP)數據，因此它提供了網絡層的安全性。

它對 VPN 流量提供了如下3 個方面的保護。

私密性：數據私密性也就是對數據進行加密。這樣一來，即使第三方能夠捕獲加密后的數據，也不能將其恢復成明文。

完整性：完整性確保數據在傳輸過程中沒有被第三方算改。

源認證：源認證也就是對發送數據包的源進行認證，確保是合法的源發送了此數據包。

如上圖所示，不難看出IPSec 技術在原始IP 頭部和 IP 負載之間插入了一個IPSec 頭部，這樣可以對原始的IP負載實現加密，同時還可以實現對IPSec 頭部和原始IP 負載的驗證，以確保數據的完整性。

02—IPSec框架

一些傳統的安全技術(如HTTPS)以及無線安全術(如WEP/WPA)，往往會采用某種固定的加密和散列函數。這種做法帶有明顯的賭博性質，因為如果某天這個加密算法曝出嚴重漏洞，那么使用這個加密算法或者散列函數的安全技術也就難免要遭到淘汰。

為了避免這種在一棵樹上吊死的悲慘事件發生，IPSec 并沒有定義具體的加密和散列函數。IPSec 的做法是提供一個框架性的結構，但每一次IPSec 會話所使用的具體算法，都是通過協商來決定的。也就是說如果我們覺得 3DES 這個算法所提供的 168 位的加密強度能夠滿當的需要，那么就不妨暫且使用這個協議來加密數據。但是只要有一天 3DES 出現了嚴重漏洞，或者出現了一個更好的加密協議，那么我們也可以馬上更換加密協議，使 IPSec VPN 總是使用最新最好的協議來進行加密。

下圖所示為 IPSec 框架示意圖，這張圖在說明不僅僅是散列函數加密算法，還包括封裝協議和模式、密鑰有效期等內容都可以通過協商決定，在兩個IP Sec 對等體之間協商的協議叫做IKE，下面以 IPSec 框架涉及的技術為主線，詳細介紹這些技術的特點和工作原理。

03—散列函數

散列函數也叫做 HASH 函數，主流的散列算法有MD5與SHA-1。散列函數的主要任務是驗證數據的完整性。通過散列函數計算得到的結果叫做散列值，這個散列值也常常被稱為數據的指紋(Fingerprint)。

如上圖所示：文件內容為111，通過MD5、SHA1算法之后，分別得到了不同的散列值。

散列函數特點：

1.固定大小

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

2.雪崩效應

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

3.單向

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

4.沖突避免

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

散列函數雖然能夠很好地確認數據的完整性，但是卻容易遭受中間人攻擊。合法與非法用戶都可以對他們發送的信息進行散列函數計算，并得到散列值。因此他們也都能把文件和散列值一起打包發送給接收方，而接收方也都能夠通過散列函數來校驗數據的完整性。因此，散列函數雖然能夠確認數據的完整性，卻不能確保這個數據來自于可信的源(不提供源認證)，所以散列函數存在中間人攻擊的問題。

為了彌補這個漏洞，我們可以使用一個叫做密鑰化散列信息認證代碼 (HMACKeyed-hash Message Authentication Code)的技術，這項技術不僅僅能夠實現完整性校驗，還能完成源認證的任務。

04—加密算法

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

對稱密鑰算法

非對稱密鑰算法

1.對稱密鑰算法

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

對稱密鑰算法有如下特點：

優點：速度快、安全、緊湊

缺點：

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

隨著參與者數量的增加，密鑰數量急劇膨脹 ((n x (n-1)) /2)；

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

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

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

DES、3DES、AES、RC4

2.非對稱密鑰算法加密

在使用非對稱密鑰技術之前，所有參與者，不管是用戶還是路由器等網絡設備，都需要預先使用非對稱加密算法(如 RSA)產生一對密鑰。

非對稱加密需要4個密鑰。通信雙方各自準備一對公鑰和私鑰。其中公鑰是公開的，由信息接受方提供給信息發送方。公鑰用來對信息加密。私鑰由信息接受方保留，用來解密。公鑰是公開的，就不存在保密問題。也就是說非對稱加密完全不存在密鑰配送問題！

假設小明想約小紅出來玩：

1、小明確定了自己的私鑰 mPrivateKey，公鑰 mPublicKey。自己保留私鑰，將公鑰mPublicKey發給了小紅；

2、小紅確定了自己的私鑰 hPrivateKey，公鑰 hPublicKey。自己保留私鑰，將公鑰 hPublicKey 發給了小明；

3、小明發送信息 “周六早10點T1樓下見”，并且用小紅的公鑰 hPublicKey 進行加密。

4、小紅收到信息后用自己的私鑰 hPrivateKey 進行解密。然后回復 “收到，不要遲到” 并用小明的公鑰mPublicKey加密。

5、小明收到信息后用自己的私鑰 mPrivateKey 進行解密。

以上過程是一次完整的request和response。通過這個例子我們梳理出一次信息傳輸的非對稱加、解密過程：

1、消息接收方準備好公鑰和私鑰

2、私鑰接收方自己留存、公鑰發布給消息發送方

3、消息發送方使用接收方公鑰對消息進行加密

4、消息接收方用自己的私鑰對消息解密

通過私鑰加密的數據只能由公鑰解密，通過公鑰加密的數據只能由私鑰解密。由于加密和解密使用不同的密鑰，因此稱為非對稱加密。

數字簽名

非對稱密鑰算法的第二個用途就是實現數字簽名，為什么要簽名呢？簽名的目的無非是對某一份文件進行確認。

例如，欠條。張三欠李四 10000 元錢，欠款人張三在欠條上簽名確認。簽名的主要作用就是張三對這張欠條進行確認，事后不能抵賴(不可否認性)。到底最后誰會看這個簽名呢？李四很明顯沒必要反復去確認簽名。一般都是在出現糾紛后，例如，張三抵賴不還的時候，李四就可以把欠條拿出來，給法官這些有權威的第三方來進行驗證，如果他們確認此欠條上的簽名確實來自張三無疑，張三就不能再否認欠李四錢這一既定事實了。

我們來看看數字簽名是如何工作的。

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

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

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

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

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

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

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

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

1. 紅紅有兩把鑰匙，一把是公鑰，另一把是私鑰。

2. 紅紅把公鑰送給他的朋友們——帕蒂、道格、蘇珊——每人一把。

3. 蘇珊要給紅紅寫一封保密的信。她寫完后用紅紅的公鑰加密，就可以達到保密的效果。

4. 紅紅收信后，用私鑰解密，就看到了信件內容。這里要強調的是，只要紅紅的私鑰不泄露，這封信就是安全的，即使落在別人手里，也無法解密。

5. 紅紅給蘇珊回信，決定采用“數字簽名”。他寫完后先用Hash函數，生成信件的散列值（digest）。

6. 然后，紅紅使用私鑰，再對這個散列值（digest）加密，生成“數字簽名”（signature）。

7. 紅紅將這個簽名，附在信件下面，一起發給蘇珊。

8. 蘇珊收信后，取下“數字簽名”（signature），用紅紅的公鑰解密，得到信件的散列值1（digest 1）。由此證明，這封信確實是紅紅發出的。

9. 蘇珊再對信件本身使用Hash函數，將得到的散列值2（digest 2），與上一步得到的散列值1（digest 1）進行對比。如果兩者一致，就證明這封信未被修改過。

10. 復雜的情況出現了。道格想欺騙蘇珊，他偷偷使用了蘇珊的電腦，用自己的公鑰換走了紅紅的公鑰。此時，蘇珊實際擁有的是道格的公鑰，但是還以為這是紅紅的公鑰。因此，道格就可以冒充紅紅，用自己的私鑰做成“數字簽名”，寫信給蘇珊，讓蘇珊用假的紅紅公鑰進行解密。

11. 后來，蘇珊感覺不對勁，發現自己無法確定公鑰是否真的屬于紅紅。她想到了一個辦法，要求紅紅去找“證書中心”（certificate authority，簡稱CA），為公鑰做認證。證書中心用自己的私鑰，對紅紅的公鑰和一些相關信息一起加密，生成“數字證書”（Digital Certificate）。

12. 紅紅拿到數字證書以后，就可以放心了。以后再給蘇珊寫信，只要在簽名的同時，再附上數字證書就行了。

13. 蘇珊收信后，用CA的公鑰解開數字證書，就可以拿到紅紅真實的公鑰了，然后就能證明“數字簽名”是否真的是紅紅簽的。

非對稱密鑰算法有如下特點：

優點：更安全、不用擔心交換的公鑰被劫持、支持數字簽名和不可否認性

缺點：

加密速度會很慢

密文會變長

非對稱密鑰算法的主流協議: RSA (數字簽名和數字證書的主流協議) DH (IPSec 產生密鑰資源的主要協議) ECC (橢圓曲線算法)

由于上述缺點，與對稱密鑰算法一樣，在一套安全解決方案中不可能單獨使用非對稱密鑰算法。那么我們應該如何利用對稱和非對稱密鑰算法的優勢來加密實際的數據呢？下面來看一個巧妙的加密解決方案。

巧妙的加密解決方案

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

步驟1：“用戶一”(發起方)使用本地隨機數產生器，產生用于對稱密鑰算法的隨機密鑰，用于加密數據。 步驟2：使用步驟1產生的隨機密鑰，對重要的明文信息通過對稱密算法進行加密，并得到密文。 步驟3：“用戶一”(發送方)需要預先獲取“用戶二”(接收方)的公鑰，并且使用“用戶二”的公鑰對步驟1產生的隨機密鑰進行加密，得到加密的密鑰包。 步驟4：對步驟2和步驟3產生的密文和密鑰包一起發送給“用戶二（接收方）。 步驟5：“用戶二”首先提取出密鑰包，并且使用自己的私鑰對它進行解密，并得到明文的隨機密鑰。

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

05—封裝協議

IP Sec有ESP和AH兩種封裝協議

ESP(Encapsulation Security Payload)的IP協議號為50，ESP能夠為數據提供私密性(加密)、完整性和源認證3大方面的保護，并且能夠抵御重放攻擊(反復發送相同的包，接收方由于不斷地解密消耗系統資源，實現拒絕服務攻擊(DOS))。

ESP 只能保護IP負載數據，不對原始 IP 頭部進行任何安全防護。

AH(Authentication Header)的IP 協議號為 51，AH 只能夠為數據提供完整性和源認證兩方面的安全服務，并且抵御重放攻擊。AH 并不能為數據提供私密性服務，也就是說不加密，所以在實際部署IPSe VPN 的時候很少使用AH，絕大部分IPSec VPN都會使用 ESP 進行封裝。 AH不僅能保護IP負載數據，還能對原始 IP 頭部進行驗證。

當然AH 不提供私密性服務，只是它不被廣泛采用的其中一個原因，另外一個原因是AH協議封裝的IPSec數據包不能穿越NAT。

06—封裝模式

IPSec有如下兩種數據封裝模式： 傳輸模式(Transport mode) 隧道模式(Tunnel mode)

傳輸模式(Transport mode)

因為AH少使用所以封裝模式示意圖中我們都以ESP封裝協議為例來進行介紹。

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

隧道模式(Tunnel mode)

隧道模式把原始 IP 數據包整個封裝到了一個新的 IP 數據包中，并且在新 IP 頭部和原始 IP 頭部中間插入了ESP 頭部，以此對整個原始IP 數據包進行了加密和驗證處理。

07—密鑰有效期

長期使用相同密鑰來加密數據是不明智的，應該周期性地更新密鑰，Cisco的IPSec VPN 用于加密實際數據的密鑰，默認每一個小時 (3600秒)就要更新一次。

Cisco的IPSec VPN 雖然默認每小時更換一次密鑰，但下一個小時使用的密鑰是由當前這個小時使用的密鑰，通過一系列的算法衍生得出的。也就是說這些密鑰之間存在推演關系。這樣的密鑰更新就不能叫做完美向前保密 PFS(Prfect Forward Secrecy)。

PFS 要求每一次密鑰更新，都需要重新產生全新的密鑰，和以前使用的密鑰不存在任何衍生關系。Cisco 的IPSec VPN一旦啟用了 PFS 技術，就會在每一個小時結束的時候，展開一次全新的 DH 交換算法，產生全新的密鑰用于下一個小時加密。

08—IKE（互聯網密鑰交換）協議

IPSec VPN需要預先協商加密協議、散列函數、封裝協議、封裝模式和密鑰有效期等內容。具體執行協商任務的協議叫做互聯網密交換協議 IKE。IKE主要完成如下3個方面的任務。

對建立IPSec 的雙方進行認證(要預先協商認證方式)。

通過密鑰交換，產生用于加密和 HMAC 的隨機密鑰。

協商協議參數 (加密協議、散列函數、封裝協議、封裝模式和密有效期)。

協商完成后的結果就叫做安全關聯 SA，也可以說IKE 建立了安全關聯SA。一共有兩種類型，一種叫做IKE SA，另一種叫做IPSec SA。

IKE SA維護了安全防護 (加密協議、散列函數、認證方式、密鑰有效期等)IKE 協議的細節。

IPSec SA 則維護了安全防護實際用戶流量 (通信點之間流量)的細節。

SKEME 決定了IKE的密鑰交換方式，IKE主要使用DH來實現密鑰交換。

Oakley 決定了IPSec 的框架設計，讓IPSec 能夠支持更多的協議。

ISAKMP 是 IKE 的本質協議，它決定了 IKE 協商包的封裝格式，交換過程和模式的切換。

ISAKMP是IKE的核心協議，所以經常會把IKE與ISAKMP 這兩個詞語換著使用。例如，IKE SA 也經常被說成ISAKMP SA。在配置 IPSec VPN 的時候，主要的配置內容也是ISAKMP。SKEME 和Okley 沒有任何相關的配置內容，如果一定要對IKE和ISAKMP進行區分的話，那么由于 SKEME 的存在，因此IKE 能夠決定密鑰交換的方式，但是ISAKMP只能夠為密鑰交換來交換數據包，但卻不能決定密鑰交換實現的方式。

IKE的2個階段與3個模式

IKE協商分為兩個不同的階段：第一階段和第二階段。

第一階段協商分別可以使用 6 個包交換的主模式或者3個包交換的主動模式來完成，第一階段協商的主要目的就是對建立 IPSec 的雙方進行認證，以確保只有合法的對等體 (peer) 才能夠建立 IPSec VPN。協商得到的結果就是IKE SA。

第二階段總是使用 3 個包交換的快速模式來完成，第二階段的主要目的就是根據需要加密的實際流量(感興趣流)，來協商保護這些流量的策略。協商的結果就是IPSec SA。

審核編輯：湯梓紅