第6章網絡空間安全協議(編輯修改稿)

　

【文章內容簡介】 包進行處理的 SA提供了完整性認證服務，才會有該字段。 ? ESP協議有兩種工作模式（以應用于 IPv4的數據包為例）：傳輸模式 (Transport Mode)和隧道模式 (Tunnel Mode) ? AH頭位于 IPv6頭和一些上層協議頭之間，如果存在擴展包頭，則 AH必須位于逐跳選項頭、選路擴展頭和分段擴展頭之后。 AH的驗證范圍與 ESP有所區別，包括了整個 IPv6數據包。 ? AH可以工作在傳輸模式及隧道模式下，下圖分別顯示了在傳輸模式和隧道模式中增加 AH時IPv6數據包的變化 。 ? IPsec 安全關聯 (security association, SA) 指定由通信主機識別的安全屬性。單個 SA 保護單一方向的數據，此保護針對單個主機或一組（多播）地址。由于多數通信為對等通信或客戶機 /服務器通信，因此，必須存在兩個 SA 來保證兩個方向的通信安全。 ? 以下三個元素唯一地標識 IPsec SA： ? 安全協議（ AH 或 ESP） ? 目標 IP 地址 ? security parameter index, SPI（安全參數索引）（任意 32 位的值，與 AH 或 ESP 包一起傳輸。） ? IPSec進行加密可以有兩種工作模式，意味著 SA也有兩種工作模式即傳輸模式和隧道模式。 1. 傳輸模式的 SA 在該模式下，經過 IPSec處理的 IP數據報格式如圖： 如果安全協議為 ESP，則 SA只為高層協議提供安全服務；如果選擇了 AH，則可將安全服務范圍擴展到 IP頭的某些在傳輸過程中不變的字段。 ? 隧道模式的 SA將在兩安全網關之間或者主機與安全網關之間建立一個 IP隧道。在這種模式下， IP數據包有兩個 IP頭。一個是用來指明IPSec數據包源地址的外部 IP頭，；另一個是用于指明 IP數據包的目的地址的內部 IP頭。 ? 如果選擇的安全協議為 ESP，則 SA只為內部 IP頭、高層協議頭和數據提供安全服務；如果選擇使用 AH，則可將安全范圍擴大到外部 IP頭中某些在傳輸過程中不變的字段。 ? 密鑰管理（ IKE）并非 IPSec專有，其他協議也可以用 IKE進行具體的安全服務。在IPSec模型中，使用 IPSec保護一個數據報之前，必須先建立一個 SA， SA可以手工創建，也可以自動建立。在自動建立 SA時，要使用 IKE協議。 IKE代表 IPSec與 SA進行協商，并將協商好的 SA填入 SAD中。 ? IKE協議主要是對密鑰交換進行管理，它主要包括四個功能： 協商服務：對使用的協議、加密算法和密鑰進行協商。 身份認證服務：對參與協商的身份進行認證，確保身份的合法性。 密鑰的管理：對協商的結果進行管理。 安全交換：產生和交換所有密鑰的信息。 ? IKE是一種混合型協議，它建立在以下三個協議基礎上： ISAKMP：它是一種密鑰交換框架，獨立于具體的密鑰交換協議。在這個框架上，可以支持不同的密鑰交換協議。 OAKLEY：描述了一系列的密鑰交換模式，以及每種模式所提供服務的細節，如身份保護和認證等。 SKEME：描述了一種通用的密鑰交換技術。這種技術提供了基于公鑰的身份認證和快速密鑰刷新。 VPNIPSec拓撲結構 ? 用戶在使用圖 VPNIPSec拓撲結構中的 IPSec安全隧道時，應按以下步驟進行： （ 1）用戶終端與 VPN虛擬專用網上的安全網關進行物理聯接； （ 2）用戶終端通過 DHCP動態主機分配方式，動態獲取一個專用的 IP地址。注意：此 IP地址在通過安全隧道通信之前要做動態變動。此 IP地址在未變動前，先作為用戶外出包的源地址和進入用戶的進入包的目的地址； 3）進入 IKE的初始化階段，一個部門和輸入數據的信息，首先通過 IPSec的安全性參考 SPI索引，自動選擇AH協議或者 ESP協議，選擇加密算法、密鑰和密鑰的相應生存周期，進行了以上初始化定義后。 （ 4）進行安全關聯 SA處理。在 IKE第一階段，終端與網關之間只有一對交互數據包，在 IKE的第二階段會生成滿足雙方請求相應的四對交互數據包； （ 5）經過 IKE的兩個階段后，就建成動態的專用安全隧道，此后進入和輸出的數據包都要通過不同的 SPI進行標識； （ 6）安全隧道建成后，安全網關又通過 DHCP為用戶終端分配一個防竊取的 IP地址，供用戶及對方使用。 傳輸層安全協議 SSL/TSL ? SSL(Secure Sockets Layer 安全套接層 ),及其繼任者 傳輸層安全 （ Transport Layer Security， TLS）是為 網絡通信 提供安全及 數據完整性 的一種安全協議。 TLS與 SSL在 傳輸層 對網絡連接進行加密。 SSL協議建立在運輸層和應用層之間，是提供客戶和服務器雙方網絡應用安全通信的開放式協議。 SSL協議是一個分層協議，由兩層組成： SSL握手協議和 SSL記錄協議。其中記錄協議在握手協議的下端。 其中 Handshake Protocol用來協商密鑰，協議的大部分內容就是通信雙方如何利用它來安全的協商出一份密鑰。 Record Protocol則定義了傳輸的格式 。 SSL握手協議是位于 SSL記錄協議之上的主要子協議，包含兩個階段。 第一階段用于交換密鑰等信息，通信雙方通過相互發送 HELLO消息進行初始化。通過 HELLO消息，就有足夠的信息確定是否需要一個新的密鑰。 如果本次會話是建立在一個已有的連接上，雙方則進入握手協議的第二階段；如果本次會話是一個新會話，則需要產生新的密鑰，雙方需要進入密鑰交換過程。此時服務器方的 SERVER—HELLO消息將包含足夠的信息使客戶方產生一個新的密鑰。 第二階段用于用戶身份認證。通常服務器方向客戶方發出認證請求消息，客戶方在收到該請求后，發出自己的證書，并等待服務器的應答。服務器如果收到客戶的證書，則返回成功的消息，否則返回錯誤的消息。至此，握手協議結束。 (1)信息類型：該字段為 8位。指示封裝在數據段中的信息類型。 (2)主要版本：該字段為 8位。表明所使用 SSL協議的主要版本號。 (3)次要版本：該字段為 8位。表明所使用 SSL協議的次要版本號。對于 SSL ，值為 0。 (4)壓縮長度：該字段為 16位。以字節為單位表示數據段的長度。 (5)數據段：上層協議處理的數據。 發送方記錄層的工作過程如下 (接收方過程反之 )： ? 分段：把從高層接收到的數據進行分段，使其長度不超過 214個字節。 ? 壓縮：該操作是可選的。 SSL記錄協議不指定壓縮算法，但壓縮必須是無損的。實際情況中，有時使用壓縮算法后，使得數據擴大了。因此必須保證不能增加 210字節以上的長度。對壓縮后的數據計算SSL記錄驗證碼即 MAC。記錄可使用專用公式進行計算。 ? 用當前握手協議協商的一套加密參數中指定的 MAC算法計算壓縮后數據的 MAC；用加密算法加密壓縮數據和記錄驗證的 MAC，形成密文結構。而且加密不能增加 210字節以上的內容長度 。 ? SSL最初的幾個版本（ SSL 、 、 SSL ）由網景公司設計和維護，從 ，SSL協議由因特網工程任務小組（ IETF）正式接管，并更名為 TLS（ Transport Layer Security），發展至今已有 TLS 、 、 本。新版本的 TLS（ Transport Layer Security，傳輸層安全協議）是 IETF（ Inter Engineering Task Force， Inter工程任務組）制定的一種新的協議，它建立在 SSL ，是SSL 。目前市面上所有的 Https都是用的是 TLS，而不是 SSL。 圖 典型的 TLS TLS與 SSL的差異 ? 1）版本號： TLS記錄格式與 SSL記錄格式相同，但版本號的值不同， TLS的版本 。 2）報文鑒別碼： TLS的 MAC算法及MAC計算的范圍不同。 TLS使用了 RFC2104定義的HMAC算法。 ，兩者差別在于 ，填充字節與密鑰之間采用的是連接運算，而 HMAC算法采用的是異或運算。但是兩者的安全程度是相同的。 3）偽隨機函數： TLS使用了稱為 PRF的偽隨機