資訊安全技術及應用 互連網安全性通訊協定

標籤：

一、互連網安全性通訊協定概述1.1 互連網協議體系

TCP/IP協議的體繫結構

IP資料報格式及TCP/UDP報文段格式

Web技術構成：HTTP協議、HTML標記語言。

TCP/IP協議棧中安全機制的相對位置：網路層、運輸層和應用程式層。

1.2 互連網安全性通訊協定

1、將安全機制放置在網路層：如IPSec協議，好處是對終端使用者和應用程式透明。

2、將安全機制放置在運輸層：如SSL協議，好處是對終端使用者和應用程式透明。

3、將安全機制放置在應用程式層：好處是與應用有關的安全服務被嵌入到特定的應用程式中，可根據需要制定安全服務。

4、網路安全性通訊協定是各種安全服務的整合，通過安全性通訊協定的設計和編程實現，形成更高的安全服務，在提供安全服務的同時方便使用者使用。

5、各種網路安全性通訊協定在實際使用時，需要安裝相關程式進行設定。

二、IP安全性通訊協定與VPN2.1 VPN概念與構成

VPN：以公用開放網路作為通訊平台，通過在相關網路層次中附加多種安全技術（加密、鑒別和存取控制），向使用者提供類似於專用網路效能的一種網路安全技術。

2.1.1 VPN常見的應用模式

1、內部網VPN：適用於同一企業或組織內部的遠程分公司區域網路的串連。
特點：資料通訊量較大，連線時間較長。

2、外部網VPN：適用於不同企業或組織之間的內部網的串連。
特點：安全性原則存在較大差異，對存取控制要求較高。

3、遠端存取VPN：遠程移動使用者、單機接入等。

2.1.2 VPN功能

1、資料封裝：通過構造虛擬私人網路隧道，使遠端使用者能夠用內部網的地址和協議傳遞資訊。

2、資料加密：通過對傳輸資料的加密，隱藏內部網的協議、地址和資料。

3、報文鑒別和身份鑒別：提供報文鑒別和身份鑒別。

2.1.3 隧道協議

1、隧道技術：其基本方法是在內網與公網介面處，將要傳輸的資料作為載荷封裝在一種可在公用網上傳輸的資料格式中，在目的內網與公網介面處，將資料封裝除去取出載荷。

2、隧道技術的主體是隧道協議。

3、隧道，實質上是一種封裝，是將一種協議封裝在另一種協議中傳輸，從而實現內部網路通訊協定對公用網路的透明性。

4、安全隧道：在隧道中引入密碼技術和鑒別技術，使公用網具有和內部網類似的安全性。

5、VPN使用的隧道技術涉及三種資料格式
（1）使用者資料包格式
（2）封裝格式
（3）公用網傳輸格式

6、三個資料格式對應得資料格式

（1）乘客協議：內部網使用的協議在VPN中稱為乘客協議。

（2）隧道協議：用於封裝乘客協議的封裝協議被稱為隧道協議。

（3）傳輸協議：在VPN中，內部網資料以公用網作為傳輸載體，因此，使用者資料包經隧道協議封裝後還必須以公用網的傳輸格式進行封裝。公用網使用的協議為傳輸協議。

IP協議是目前最常見的傳輸協議。IP協議具有路由器功能強大，可運行於不同的傳輸介意，應用面廣等特點。

2.2 IPSec概述

1、用網際網路進行互連，IP層適合設定安全機制。在IP層實現的安全機制也稱為IPSec。

2、IP層的安全性組件含了三個功能域：鑒別、機密性和密鑰管理。
（1）鑒別：提供報文信源鑒別和完整性鑒別。
（2）機密性：通過報文加密可防止第三方竊聽報文。
（3）密鑰管理：處理密鑰的安全交換。

3、IPSec協議運行在內網與外網相連的網路裝置上，如路由器或防火牆。

4、IPSec網路裝置一般將對進入廣域網路的所有通訊量進行加密和壓縮，對所有來自廣域網路的通訊量進行解密和解壓。這些操作對於區域網路上的工作站和伺服器是透明的。

5、IPSec優點：
（1）當在防火牆或路由器中實現IPSec時，IPSec能夠對所有穿越邊界的資料通訊量提供安全防護。同時又不會在內部引起與安全有關的處理負荷。
（2）防火牆內部的IPSec可以抵制旁路，如果從外界進來的所有通訊量必須使用IP，並且防火牆是從Internet進入內部的唯一入口。
（3）IPSec在運輸層（TCP，UDP）以下，因此對於應用程式時透明的。
（4）IPSec對終端使用者是透明的，沒有必要對使用者進行安全培訓，給每個使用者下發密鑰，或在使用者離開組織是取消其密鑰。

6、IPSec提供的安全服務
（1）無串連完整性和存取控制。
（2）資料來源的鑒別。
（3）拒絕重放的分組。
（4）機密性（加密）。
（5）有限的通訊量機密性。

7、IPSec使用兩個協議來提供上述的安全服務：首部鑒別協議（AH）和封裝安全載荷協議（ESP）。
首部鑒別協議（AH）：對IP資料報提供鑒別服務。
封裝安全載荷協議（ESP）：對IP資料報提供鑒別和機密性服務。該協議是加密/鑒別混合協議。
AH和ESP可單獨使用，也可結合使用。

2.3 IPSec協議2.3.1 安全性關聯SA

1、安全性關聯是發送方與接送方間的一種單向關係。通常與一個或者一組給定的網路連接相關，為所承載的網路流量提供安全服務。

2、如果需要一個對等的關係用於雙向的安全交換，就要有兩個安全性關聯。一個SA可用於AH或ESP，但不能同時用於兩者。

3、每個安全性關聯可表示為一個三元組：
（1）安全參數索引（SPI）：SPI是一個32位元的值，用於區別相同目的地和協議的不同安全性關聯。SPI出現在AH和ESP的首部中，接收方根據首部中的SPI確定對於的SA。
（2）IP目的地址（IPDA）：目前只允許單播地址；這是SA的目的端點的地址，可能是終端使用者系統或者是網路系統，如防火牆或路由器。
（3）安全性通訊協定標識（SPR）：指出這個關聯是一個AH或ESP的安全性關聯。

2.3.2 安全性關聯資料庫

1、安全性原則資料庫（SPD）：定義了對從主機或安全網關出入站的IP通訊流量的處理策略。SPD包含一個策略列表，每個表項標明如何處理與該策略相匹配的資訊流，IPSec定義了三種處理方法：旁路、丟棄或者進行IPSec安全處理。

2、安全性關聯資料庫（SAD）：包含了與SA相關的各種安全參數。每個SA在SAD中都有一個對應得表項。

SAD表項涉及的主要欄位：
（1）序號計數器：用於產生AH或ESP首部中序號欄位的32位值。
（2）序號計數器溢出：一個標記，用於指示序號計數器的溢出是否可審計的事件，並禁止在該SA上繼續傳輸分組。
（3）抗重放視窗：一個32位計數器，用來確定進入AH或ESP報文分組是否是重放。
（4）AH資訊：AH使用的鑒別演算法、密鑰等資訊。
（5）ESP加密資訊：ESP密碼編譯演算法、密鑰、初始向量模式、初始向量等資訊。
（6）ESP鑒別資訊：ESP使用的鑒別演算法、密鑰等。
（7）SA生存期：一個時間段，該時間段到期後，SA必須被終止或者被一個新的SA取代。
（8）IPSec協議模式：指明該SA上通訊流量的AH或ESP模式。AH和ESP都具有隧道模式和傳輸模式。
（9）路徑MTU：不經分區可傳送的分組最大長度。

2.3.3 SA選取器

1、對於每個從提供IPSec服務的裝置發出的報文分組，裝置將檢查分組的相應欄位，並根據選取器進行SPD尋找，由此確定安全性關聯，然後根據安全性關聯完成對應的IPSec處理。

2、選取器用於過濾通訊流量，目的是將輸出的流量映射到特定的安全性關聯。

3、選取器可使用的參數：IP地址、連接埠號碼、協議等。

4、SA選取器、SPD、SAD之間的關係：

5、IPSec工作流程

（1）主機A上使用者向主機B上使用者發送一訊息。
（2）主機A上的IPSec驅動程式檢查SA選取器，查看資料包是否需要保護及需要何種保護。
（3）IPSec驅動程式通知IKE開始安全協商。
（4）主機B上IKE收到請求安全協商通知。
（5）兩台主機建立第一階段SA，各自產生共用主要金鑰。如第一階段SA已建立，則直接進入第二階段SA協商。
（6）協商建立第二階段SA對：入站SA和出站SA。
（7）主機A上的IPSec驅動程式使用出站SA對資料包進行安全處理。
（8）IPSec驅動程式將處理後的資料包交給IP層，再由IP層將資料包發給主機B。

2.3.4 鑒別首部AH

1、功能：AH用於為IP資料報提供無串連完整性和資料來源鑒別，並提供防重放保護。但不能防止被竊聽，只適合用於傳輸沒機密資料。

2、工作原理：在每個IP分組上添加一個鑒別首部。此首部包含一個帶密鑰的散列值，散列值根據整個資料包計算，對資料的任何改變將致使散列值無效——完整性保護。鑒別特徵使得端系統能夠鑒別使用者或應用的身份。

3、AH首部格式

（1）下個首部（Next Header）：8位，標識AH首部後面的下一個有效載荷，其值為IP協議號。
（2）有效載荷長度（Payload Length）：8位，以32位字為單位，AH首部中鑒別資料的長度。
（3）保留（Reserved）：16位。必須置0，將來使用。
（4）安全參數索引（SPI）：32位，用於標識一個安全性關聯。
（5）序號（Sequence Number）：32位，唯一標識了每個報文分組，為安全性關聯提供反重放保護。
（6）鑒別資料（Authentication Data）：長度可變，但為字長的整數倍，不足時可通過填充達到。鑒別資料包含完整性校正值ICV。

三、Web安全性通訊協定3.1 Web安全性通訊協定概述

1、目前用來保護Web頁面傳輸安全的協議主要有兩個：HTTPS和S-HTTP
（1）HTTPS：表示“Hypertext Transfer Protocol over Secure Socket Layer”。HTTPS不是獨立的協議，而是HTTP協議與SSL/TLS協議的組合。當使用HTTPS訪問頁面時，連接埠號碼為443。
（2）S-HTTP：表示“Secure Hypertext Transfer Protocol”。S—HTTP是獨立的安全超文字傳輸通訊協定 (HTTPS)，可與HTTP共存並相互相容。只有在雙方經過協商都使用S-HTTP時，才進行安全的頁面傳輸。由於HTTPS的出現，S-HTTP已基本不用。

2、SSL/TLS安全套接層協議：工作在運輸層與應用程式層之間，可為各種應用程式層協議提供安全服務。

3、SSL（Secure Socket Layer）是一個用來保證傳輸安全的Internet協議。該協議通過在兩個實體（客戶和伺服器）之間建立一個安全通道，來實現檔案在Internet中傳輸的保密性。

3.2 SSL協議概念與結構

1、SSL協議概念與結構

2、SSL握手協議：在伺服器端與用戶端在開始傳輸資料之前，相互鑒別並交換必要的資訊以建立安全工作階段狀態。

3、SSL記錄協議：為不同的高層協議提供基本的安全服務，特別是超文字傳輸通訊協定 (HTTP)。SSL記錄協議建立在可靠的傳輸協議上，用來安全封裝高層的協議。

4、修改密文協議：修改會話密文族。

5、警示協議：將SSL有關警示傳送對方實體。警示層級非為警告和致命，用來說明事件的嚴重等級。如果是致命的，SSL將立刻終止該串連。

6、SSL會話：SSL會話是客戶和伺服器之間的關聯，會話通過握手協議來建立。會話定義了加密安全參數的一個集合，該集合可以被多個串連所共用。會話可以用來避免為每個串連進行新的安全參數的協商。

7、SLL串連：等同於網路連接，只是增加了安全防護。對於SSL來說，每個串連與一個會話相聯絡。

8、工作階段狀態的一些參數：
（1）工作階段識別項：伺服器選擇的任意位元組序列，用來標識活動的或可恢複的工作階段狀態。
（2）對方的認證：對方的X509.v3認證。狀態的這個元素可以為空白。
（3）壓縮方法：在加密之前用來壓縮資料的演算法。
（4）密文規約：指明大塊資料加密演算法，用於MAC計算的散列演算法，它還定義了加密屬性。
（5）主要金鑰：48位元組客戶/伺服器之間的共用密鑰。
（6）可重用否：一個標誌，用於指明該會話是否可以用來初始化一個新的串連。

9、串連狀態的一些參數：
（1）伺服器和用戶端隨機數：伺服器和客戶為每個串連選擇的位元組序列。
（2）MAC密鑰：對發送資料進行MAC操作的密鑰。
（3）寫密鑰：對資料加密和解密的常規加密金鑰。
（4）初始化向量：當使用CBC模式的區塊編碼器時，為每個密鑰維護的初始化向量。
（5）序號：每一方為每個串連的傳輸和接收報文維持著單獨的序號。

10、會話主要金鑰與串連中使用密鑰的關係：
（1）有會話主要金鑰產生各種串連的加密參數。
（2）客戶寫MAC密鑰，伺服器寫MAC密鑰，客戶寫密鑰，伺服器寫密鑰，客戶寫IV以及伺服器寫IV。

3.3 SSL記錄協議

1、SSL記錄協議為SSL串連提供兩種服務：
（1）機密性：握手協議定義了共用的工作階段金鑰、由該密鑰產生用於對SSL有效載荷進行常規加密的密鑰。記錄協議使用該密鑰進行加密和解密。
（2）報文完整性：用工作階段金鑰產生報文鑒別碼（MAC）密鑰，進行報文的鑒別。

2、SSL記錄協議進行的操作：

（1）記錄協議接收要傳輸的應用報文，將資料分區，可選地壓縮資料，應用MAC，加密，增加首部，然後再TCP報文段中傳輸結果單元。
（2）被接收的資料被解密、驗證、解壓和重新裝配，然後交付給高層的使用者。

3、SSL記錄協議層報文格式

（1）內容類型（8bit）：指明所攜帶的高層協議類型（如：修改密文、警示、握手和應用資料）。
（2）主要版本（8bit）：指示使用SSL的主要版本。對於SSLv3，欄位為0.
（3）壓縮長度（16bit）：明文資料片以位元組為單位的長度（如果使用壓縮就是壓縮資料片的長度）。

3.4 SSL握手協議

1、握手協議的作用：使伺服器和客戶能夠相互鑒別對方的身份、協商加密和MAC演算法以及加密金鑰。即建立交換實體之間的會話或改變會話的狀態。

2、握手協議報文由三個欄位組成：
（1）類型欄位：用來說明報文的類型，握手協議報文中的常見類型將在下面介紹。
（2）長度欄位：表示以位元組為單位的報文長度。
（3）報文體：則用來攜帶不同類型報文的參數。

四、安全電子交易協議SET

SET協議提供了三種服務：
（1）在交易涉及的各方之間提供安全的通訊通道。
（2）使用X.509v3數位憑證進行身份鑒別。
（3）保證機密性，資訊只是在必要的時候、必要的地方菜對交易各方可用。

4.1 SET協議概述

1、SET協議的特點：
（1）資訊機密性：卡使用者的帳號和支付資訊在網上傳輸時時加密的，SET防止商人得到卡使用者的信用卡號碼，該資訊值對發卡銀行有用。
（2）資料完整性：卡使用者發送給商人的支付資訊包括訂購資訊、個人資料和支付提示。SET協議保證這些資訊的內容在傳輸時不被修改。
（3）卡使用者帳號的鑒別：SET協議允許商人驗證卡使用者是否是有效卡帳號的合法使用者。
（4）商人的鑒別：SET允許卡使用者驗證商人與金融機構之間的關係及是否允許商人接受支付信用卡。
（5）互通性：可以在不同的硬、軟體平台上應用該規範。不論是持卡人還是商人，只要其SET軟體符合標準併兼容舊可以進行安全交易。
（6）與IPSec和SSL/TLS不同，SET對每種密碼編譯演算法僅提供了一種選擇。這是因為SET是滿足單個需求集合的單個應用，而IPSec和SSL/TLS是要支援一定範圍的應用。

2、SET要求的事件序列：
（1）消費者開通帳號。消費者從支援電子支付和SET的銀行處獲得信用卡帳號。
（2）消費者獲得認證。經過適當的身分識別驗證之後，消費者將收到包含帳戶資訊摘要的X.509v3數位憑證。認證將消費者的金鑰組和信用卡捆綁在一起(通過認證的擴充欄位)。
（3）商家獲得認證。接受特定信用卡的商家必須獲得兩個X.509v3認證：一個用於報文簽名，一個用於金鑰交換。商人還需要支付網關的認證。
（4）消費者提出一項訂購。消費者通過瀏覽商家的網站來選擇商品並確定價格。然後，將要購買的商品清單發送給商家，商家返回包含了商品列表、價格、總價格和訂購號碼的表格。
（5）商家被驗證。除了訂購表格之外，商家還發送自己的認證。消費者可以驗證商家的合法性。
（6）發送訂購和支付資訊。消費者將訂單、支付資訊以及認證一起發送給商家，訂單確認對訂購表格中商品的購買，支付包含了信用卡的細節，支付資訊被加密使商家不可閱讀，消費者的認證使商家可以鑒別消費者。
（7）商家請求支付認可。商家將支付資訊發送給支付網關，請求核准消費者的存款是否足以支付這次購買。
（8）商家確認該項訂購。商家將訂購的確認發送給消費者。
（9）商家提供貨物或服務。商家將貨物遞送給消費者，或者為消費者提供服務。
（10）商家請求支付。這個請求被發送給支付網關，後者處理所有的支付細節。

4.2 雙向簽名

1、雙向簽名的目的：串連兩個發送給不同接收者的報文。

2、雙向簽名的構造過程：消費者取得PI的散列碼和OI的散列碼，將這兩個散列碼拼接起來，再取得拼接結果的散列碼。之後，使用其私人金鑰組最後的散列碼進行簽名，就建立了雙向簽名。即：DS=ESKc[H(H(PI)||H(OI))]

3、雙向簽名的驗證過程：
(1)商家驗證雙向簽名：假設商家獲得了雙向簽名(DS)、OI和PI的報文摘要(PIMD)，以及從消費者認證中取得的公開密鑰。然後商家可以計算這兩個數值： H(PIMD||H(OI))、DPKc[DS]，如果兩個值相等，商家就驗證了該簽名。
(2)銀行驗證雙向簽名：如果銀行獲得了DS、PI和OI的報文摘要(OIMD)以及消費者的公開密鑰，那麼銀行可以計算下面的數值：H(H(PI)||OIMD)、DPKc[DS]，如果兩個值相等，銀行就驗證了該簽名。

4.3 交易處理4.3.1 購買請求

購買要求階段需要交換四個報文：發起請求、發起響應、購買請求和購買響應。

1、發起請求報文：(卡使用者→商家)
目的：請求商家和支付網關的認證(身份鑒別)。
明文傳輸。
報文主要內容：{請求/響應對ID、現時C、信用卡商標、發卡行標識}

2、發起響應報文：(商家→卡使用者)
商家產生響應，並用自己的私人金鑰組其簽名。
報文主要內容：{請求/響應對ID、現時C、現時M、交易ID、商家認證、支付網關認證}

3、購買請求：(卡使用者→商家)
收到響應報文後，卡使用者首先檢驗報文的合法性，然後通過相應的CA簽名來驗證商家認證和支付網關認證。
建立OI和PI(商家賦予的交易ID被放在OI和PI中)。接下來，卡使用者準備購買請求報文。為了這個目的，卡使用者產生了一次性的對稱式加密密鑰KS。

4、購買響應：(商家→卡使用者)
商家收到了購買請求報文後，進行如下處理：
驗證卡使用者的認證。
使用消費者認證中的公開密鑰來驗證雙向簽名。
處理訂購資訊，並將支付資訊轉交給支付網關。
等待支付網關的確認，然後向卡使用者發送購買響應報文。

4.3.2 支付認可

1、認可請求：(商家→支付網關)
商家向支付網關發送一個認可請求報文，該報文由以下幾個部分組成：
與購買有關的資訊：(來自消費者)
PI：支付資訊。
雙向簽名DS：用消費者的私人密鑰簽名。
OI報文摘要(OIMD)
數位信封：封裝工作階段金鑰。

2、認可響應：(支付網關→商家)
支付網關收到商家認可請求後，完成下列工作：
驗證所有的認證。
解密商家數位信封，然後解密認可資料區塊並驗證認可資料區塊中商家的簽名。
解密卡使用者數位信封，然後解密支付資料區塊並驗證支付資料區塊的雙向簽名。
驗證商家交易ID與消費者PI中的交易ID是否匹配。
向發卡行請求和接收一個認可。

4.3.3 支付擷取

1、擷取請求：(商家→支付網關)
商家產生、簽署和加密擷取請求資料區塊，資料區塊中包括了支付的數量和交易ID。
報文還包括以前收到的關於本交易的加密擷取權標(在認可響應中)。
商家認證。

2、擷取響應：(支付網關→商家)
支付網關收到擷取請求報文後，進行如下處理：
解密並驗證擷取請求資料區塊。
解密並驗證擷取權標塊。
檢查擷取請求和擷取權標的一致性。
建立清算請求並通過私人支付網路發送給發卡行，這個請求引起資金被劃撥到商人的賬戶中。

3、SET協議的報文互動

資訊安全技術及應用 互連網安全性通訊協定