IPSec

IPSec原理與特性

IPSec的架構

IPSec提供的服務

安全連結

傳輸與通道模式

AH協定

ESP協定

Key交換與管理協定

參考課本第十三章

IPSec原理與特性

對IP層級的所有訊息進行加密與確認的工作。

所有基於IP層以上所有的應用都可以獲得良好的保護。

IP層以上的所有應用都不需要經過修改，即可獲得安全性的保障。

不需要教育終端使用者了解相關安全機制。

可以輕鬆實現VPN

可以保護、確認routing訊息，使router不會受欺騙而阻斷通訊

IPSec的架構

相關RFC:1825 1826 1827 1828 1829 (1995年8月)

架構總覽

ESP協定

AH協定

加密演算法

認證演算法

DOI

key管理

ESP:安全承載封裝

封包的加密與確認

AH：確認性標頭

加密演算法：用在ESP中

確認演算法：用在ESP與

AH中

DOI：解釋區，其他文件

可以利用此處來交

互參照

IPSec提供的服務

存取控制、connectionless的完整性、確認資料來源、拒絕重送的封包、保密性、限制訊息傳輸的保密性

安全連結（一）

SA（Security Associations)：一個介於傳送者與接收者之間的單向關係（亦即不可逆）

如果要建立雙向通訊的話，就要兩個安全連結

AH與ESP就是要提供安全服務給SA的

SA由以下三個參數定義：

SPI：指定給SA的一串位元。

IP目的端位址：SA的目的端IP位址

安全協定ID：指出此連結是AH或ESP安全連結

通常用IP標頭中的目的端IP位址與AH或ESP標頭中的SPI來辨識出一個安全連結。

安全連結（二）

SA參數：存在SPD（安全連結資料庫）中

序號計數器：32位元，產生AH與ESP標頭所需要的序號

序號計數器溢出：一個flag，用來決定是否要處理序號計數器的overflow

抵擋重送視窗：用來判斷收到的AH或ESP是不是一個重送的封包

AH與ESP資訊

SA有效期限

IPSec協定模式：通道、傳輸或任意模式

MTU（最大傳輸單位）

安全連結（三）

選擇SA：可以透過以下的項目由SPD中選擇SA

Destination IP

Source IP

使用者ID

資料敏感度

傳輸層協定

IPSec協定

Dest 與 Source port

IPv6種類、訊息標籤

IPv4服務類型(TOS)

傳輸與通道模式

AH與ESP都支援傳輸與通道模式

傳輸模式：適合保護主機間通訊

保護上層的協定，保護IP的payload部份

通道模式：適合保護兩個網路間通訊

保護整個封包

AH與ESP欄位加入後，整個封包被重新封裝成一個新的IP封包。

外部封包的dest與source IP、port可能與內部封包完全不一樣。

安全性較高，內部網路可以不用IPSec

參考課本表 13.2

AH協定

可以提供資料完整性與確認性，可以防止 address spoofing attack與重送攻擊

原理：利用MAC（訊息確認碼），雙方要分享一把private key

資料欄位請參考課本圖13.4

Sequence number配合「抵擋重送視窗」用來防止重送攻擊（圖13.4）

確認性欄位會紀錄「整體確認值」ICV

HMAC-MD5-96 HMAC-SHA-1-96 只取前96 bit

用IP標頭的欄位、AH標頭、上層協定的完整資料來計算

ESP協定

提供保密性服務與選擇性的確認性服務

ESP格式請參照課本圖13.7

支援的加密演算法

DES-CBC模式

三把key的Triple-DES

RC5

IDEA

三把key的Triple-IDEA

CAST

Blowfish

確認演算法同AH協定

Key管理

key管理方式：手動、自動

key管理協定：ISAKMP/Oakley

Oakley key交換協定：根據Diffie-Hellman演算法發展出來的key交換協定

ISAKMP：網路安全連結與key管理協定，用來管理SA。本身不限定key交換演算法，只是一組訊息類型組成的，不過最早的版本中，指定的key交換演算法就是Oakley。

Oakley key交換協定

特性：

利用「cookie」機制來預防塞爆攻擊：傳送第一個訊息時附上一個cookie（亂數產生），並要求對方回應。

允許雙方協調出「群組」

利用「臨時亂數」預防重送攻擊

可以用Diffie-Hellman模式以及類似的橢圓曲線法公開交換key

可以確認Diffie-Hellman的交換程序：可用「數位簽章、public key加密法、傳統加密法」來確認

ISAKMP key管理協定

ISAKMP訊息由一個標頭與一個或多個承載組成

標頭格式：

發起者與回應者的cookie 64位元

後續承載(8位元）:指定下一個承載類型，0就結束

主要與次要版本

交換類型

號誌（Flags），共有八位元，目前只定義：加密位元與交付位元（commit bit）

加密位元設定就表示後面的承載已經被加密

訊息ID(32位元）

訊息長度(32位元）

承載類型：參考課本表格13.3

IPSec

tjm

1998-09-08T14:53:16