【文章內(nèi)容簡介】 ：商家是否可用另一個 OI來代替？? 那么它就必須找到另一個散列數(shù)據(jù)與已經(jīng)存在的 OIMD相匹配的 OI， 這被認(rèn)為是不可行的。因此，商家不能將另一個 OI與這個 PI相連接。60基于 SET的 CA的分級結(jié)構(gòu) 根 CA品牌 CA地區(qū) CA持卡人 CA 商家 CA 支付網(wǎng)關(guān) CA持卡人 商家 支付網(wǎng)關(guān)61?書 P131– 購買請求 ：用戶與商家確定所用支付方式的細(xì)節(jié)；– 支付授權(quán)：商家會與銀行核實，隨著交易的進展，他們將得到付款– 支付獲?。荷碳蚁蜚y行出示所有交易的細(xì)節(jié)，然后銀行以適當(dāng)方式轉(zhuǎn)移貨款。 SET規(guī)范定義的交易類型 62??購買請求由持卡人和商家之間交換的 4個消息組成：?⑴ 發(fā)起請求 ： 持卡人軟件請求網(wǎng)關(guān)證書的一個拷貝；表明該交易中將使用何種品牌的支付卡。?⑵ 發(fā)起響應(yīng)：– 唯一的 交易標(biāo)識符 。– 商家 證書 以及支付網(wǎng)關(guān)的證書– 商家的私鑰對該信息進行數(shù)字簽名后發(fā)送給持卡人。?⑶ 購買請求 ：– 收到發(fā)起響應(yīng)消息之后，持卡人軟件驗證商家和支付網(wǎng)關(guān)的證書。– 持卡人軟件使用 OI和 PI來產(chǎn)生一個雙向簽名。– 最后，持卡人軟件生成一個購買請求消息。– 持卡人生成了一次性的對稱加密密鑰Ｋ s。63SET消息PI雙向簽名OIMDDES加密RSA加密KsKUb請求報文數(shù)字信封SET密文PIMDOI持卡人證書雙向簽名PI＝ 支付信息OI＝ 訂購信息PIMD＝ PI報文摘要OIMD＝ OI報文摘要Ks＝ 臨時的對稱密鑰KUb＝ 銀行的公開密鑰交換的密鑰① 與購買相關(guān)的信息。這個信息將被商家轉(zhuǎn)發(fā)給支付網(wǎng)關(guān) ② 與訂購有關(guān)的信息。商家需要這個信息 ③ 持卡人的證書。 64?(4)購買響應(yīng) ：– ① 通過持卡人的ＣＡ簽名來驗證持卡人的證書。– ② 使用消費者的公開簽名密鑰來驗證雙向簽名。這樣可以確保訂購信息在傳輸過程中沒有被篡改，并且它使用了持卡人的私有簽名密鑰進行了簽名。– ③ 處理訂購信息，并將支付信息轉(zhuǎn)交給支付網(wǎng)關(guān)進行認(rèn)可。– ④ 最后，商家生成一個購買響應(yīng)消息，它表明商家已經(jīng)收到持卡人的請求。– 一旦收到了商家的購買響應(yīng)，持卡人軟件就驗證商家的證書以及消息內(nèi)容的數(shù)字簽名。在此時刻，持卡人軟件基于這些消息將采取一些行動，諸發(fā)向持卡人顯示一個消息，或者用訂單的狀態(tài)來更新數(shù)據(jù)庫。65HOIMDRSA解密KUC請求報文SET密文數(shù)字信封PIMDOI持卡人證書雙向簽名POMDPOMDH||比較OI=訂購信息OIMD＝ OI報文摘要POMD＝ 支付訂購報文摘要H＝ 散列函數(shù)（ SHA－ 1）KUC＝ 顧客的公開簽名密鑰66??① 授權(quán)請求：商家軟件生成并數(shù)字簽發(fā)一個授權(quán)請求，其中包括授權(quán)的數(shù)量、來自 OI的交易標(biāo)識符以及其他的關(guān)于交易的信息。然后，使用支付網(wǎng)關(guān)的公鑰對這一信息生成一個數(shù)字信封。授權(quán)請求和持卡人的 PI（ 它也以數(shù)字信封的形式傳給支付網(wǎng)關(guān)）被傳送給支付網(wǎng)關(guān)。?② 授權(quán)響應(yīng)：當(dāng)收到授權(quán)請求時，支付網(wǎng)關(guān)解密并驗證消息（也就是證書和 PI） 的內(nèi)容。如果一切都是合法的，那么支付網(wǎng)關(guān)會生成一個授權(quán)響應(yīng)消息；然后用商家的公鑰對之生成一個數(shù)字信封并將它傳送加商家。?一旦收到了支付網(wǎng)關(guān)的授權(quán)響應(yīng)消息，商家就解密數(shù)字信封并驗證里面的數(shù)據(jù)。如果本購買是授權(quán)過的，則商家通過發(fā)送貨物或者完成在訂單內(nèi)指明的服務(wù)來完成對持卡人訂單的處理。Payment processing67? ?① 回復(fù)請求：商家軟件生成回復(fù)請求，它包括交易的最終數(shù)量、交易標(biāo)識符以及其他的關(guān)于交易的信息。然后使用支付網(wǎng)關(guān)的公鑰對這一消息生成數(shù)字信封并傳送給支付網(wǎng)關(guān)。?② 回復(fù)響應(yīng)：接收到回復(fù)請求并驗證了它的內(nèi)容之后，支付網(wǎng)關(guān)將生成一個回復(fù)響應(yīng)?；貜?fù)響應(yīng)包括與該請求交易的支付有關(guān)的信息。然后使用商家的公鑰對這一響應(yīng)生成數(shù)字信封并將之傳送回商家。?一旦收到了支付網(wǎng)關(guān)的回復(fù)響應(yīng)，商家軟件就解密數(shù)字信封，驗證簽名和消息數(shù)據(jù)，用于同從收單行那里接收的支付相匹配。Payment processing68SET協(xié)議與 SSL協(xié)議的比較? 在認(rèn)證要求方面 ，– 早期的 SSL并沒有提供商家身份認(rèn)證機制，雖然在 可以通過數(shù)字簽名和數(shù)字證書可實現(xiàn)瀏覽器和 Web 服務(wù)器雙方的身份驗證，但仍 不能實現(xiàn)多方認(rèn)證 ；– 相比之下， SET的安全要求較高，所有參與 SET交易的成員（持卡人、商家、發(fā)卡行、收單行和支付網(wǎng)關(guān)）都必須申請數(shù)字證書進行身份識別。? 在安全性方面，– SET協(xié)議規(guī)范了 整個商務(wù)活動的流程 ，從持卡人到商家，到支付網(wǎng)關(guān)，到認(rèn)證中心以及信用卡結(jié)算中心之間的信息流走向和必須采用的加密、認(rèn)證都制定了嚴(yán)密的標(biāo)準(zhǔn)，從而最大限度地保證了商務(wù)性、服務(wù)性、協(xié)調(diào)性和集成性。– 而 SSL只對持卡人與商店端的 信息交換進行加密保護，可以看作是用于 傳輸?shù)哪遣糠值募夹g(shù)規(guī)范 。從電子商務(wù)特性來看，它并不具備商務(wù)性、服務(wù)性、協(xié)調(diào)性和集成性。因此 SET的安全性比 SSL高。 69? 在網(wǎng)絡(luò)層協(xié)議位置方面 ， SSL是基于傳輸層的通用安全協(xié)議，而 SET位于應(yīng)用層，對網(wǎng)絡(luò)上其他各層也有涉及。? 在應(yīng)用領(lǐng)域方面， SSL主要是和 Web 應(yīng)用一起工作，而 SET是為信用卡交易提供安全，因此如果電子商務(wù)應(yīng)用只是通過Web 或是電子郵件，則可以不要 SET。但如果電子商務(wù)應(yīng)用是一個涉及多方交易的過程，則使用 SET更安全、更通用些。? 總之：? SSL協(xié)議實現(xiàn)簡單，獨立于應(yīng)用層協(xié)議，大部分內(nèi)置于瀏覽器和 Web 服務(wù)器中，在電子交易中應(yīng)用便利。但它是一個面向連接的協(xié)議，只能提供交易中客戶與服務(wù)器間的雙方認(rèn)證，不能實現(xiàn)多方的電子交易中。? SET在保留對客戶信用卡認(rèn)證的前提下增加了對商家身份的認(rèn)證，安全性進一步提高。由于兩協(xié)議所處的網(wǎng)絡(luò)層次不同，為電子商務(wù)提供的服務(wù)也不相同， 因此在實踐中應(yīng)根據(jù)具體情況來選擇獨立使用或兩者混合使用。? 70SET協(xié)議小結(jié)? 1作用? 2組成? 3雙向簽名? 4購買請求報文及驗證71?因特網(wǎng)與因特網(wǎng)與 TCP/IP安全安全?SSL協(xié)議協(xié)議?SET協(xié)議協(xié)議?IPSec協(xié)議協(xié)議72IPSec 協(xié)議 － 1 概述? 思考：是否 SSL協(xié)議和 SET協(xié)議足夠？? 思考：若某幾個節(jié)點采用一種協(xié)議 A進行通信，但是又不想重建物理網(wǎng)絡(luò)和軟件配置，應(yīng)該怎么辦？73? VPN的主要隧道協(xié)議? 第二層隧道協(xié)議–PPTP、 L2F、 L2TP? 第三層隧道協(xié)議–GRE、 IPSec? 高層隧道協(xié)議–Socks、 SSLVPN74IPSec 協(xié)議 － 1 概述?基本思想：?為 IP層以及上層提供安全保護。?在發(fā)送 IP數(shù)據(jù)包 之前 ，對 IP包的一些重要部分進行 加密和驗證計算 ，由接收端對這部分進行解密和驗證，從而實現(xiàn)安全傳輸?shù)哪康摹?5幀頭應(yīng)用數(shù)據(jù)應(yīng)用數(shù)據(jù)應(yīng)用數(shù)據(jù)應(yīng)用數(shù)據(jù)TCP頭TCP頭TCP頭IP頭IP頭應(yīng)用層傳輸層網(wǎng)絡(luò)層數(shù)據(jù)鏈路層沒有 IPSec的數(shù)據(jù)封裝 76應(yīng)用層傳輸層網(wǎng)絡(luò)層IPSec封裝數(shù)據(jù)鏈路層 幀頭IPSec頭應(yīng)用數(shù)據(jù)應(yīng)用數(shù)據(jù)應(yīng)用數(shù)據(jù)應(yīng)用數(shù)據(jù)TCP頭TCP頭TCP頭IP頭IP頭應(yīng)用數(shù)據(jù)TCP頭IP頭IPSec頭 IPSec尾IPSec尾有 IPSec數(shù)據(jù)封裝77IPSec 協(xié)議 － 1 概述? 提供了一種 端到端 的安全解決方案。 ? IPSec協(xié)議數(shù)據(jù)包和普通的 IP數(shù)據(jù)包相似– 好處？– 這些數(shù)據(jù)包可以很容易的通過任何 IP網(wǎng)絡(luò)而不需要對中間的設(shè)備做任何的改變。? 需要知道加密的唯一設(shè)備就是端點。這個大大的降低了實現(xiàn)和管理的成本。78IPSec 協(xié)議 － 1 概述?提供三種不同的形式的保護 ?(1)認(rèn)證?(2)數(shù)據(jù)完整性驗證 ?(3)保密79IPSec 協(xié)議 － 2 IPSec的安全體系結(jié)構(gòu) ?IPSec由 三個基本要素 來提供以上三種保護形式– 驗證頭 (AH)– 封裝安全載荷 (ESP)– 互聯(lián)網(wǎng)密鑰管理協(xié)議 (IKMP)一套協(xié)議中兩個不同的機制?？蓡为毷褂?，可組合使用。80IPSec 協(xié)議 － 2 IPSec的安全體系結(jié)構(gòu) 體系結(jié)構(gòu)安全封裝載荷 (ESP) 認(rèn)證頭 (AH)認(rèn)證算法加密算法解釋域 DOI密鑰管理81IPSec 協(xié)議 － 3 IPSec服務(wù) 服務(wù)類型 AH ESP(只加密 )ESP(加密并認(rèn)證 )訪問控制 Y Y Y無連接完整性 Y N Y數(shù)據(jù)源的鑒別 Y N Y拒絕重放攻擊 Y Y Y保密性 N Y Y有限的通信流保密性N Y Y82IPSec 協(xié)議 － 4 IPSec的工作模式 1傳輸模式傳輸模式?主要對 IP包的 部分信息 提供安全保護，即對 IP數(shù)據(jù)包的上層協(xié)議數(shù)據(jù)提供安全保護。?當(dāng)采用 AH傳輸模式 時，主要為 IP數(shù)據(jù)包提供 認(rèn)證保護；?而采用 ESP傳輸模式 時，主要對 IP數(shù)據(jù)包的上層信息提供 加密和認(rèn)證 雙重保護。?這是一種 端到端 的安全， IPSec在端點執(zhí)行加密認(rèn)證、處理，在安全通道上傳輸， 因此主機必須配置 IPSec。83首部 有效載荷IP 數(shù)據(jù)報 傳輸網(wǎng)絡(luò)首部 有效載荷IP 數(shù)據(jù)報 部分信息端到端84IPSec 協(xié)議 － 4 IPSec的工作模式隧道模式隧道模式 ?IPSec隧道模式對 整個 IP數(shù)據(jù)包 提供保護?其基本原理是構(gòu)造新的 IP數(shù)據(jù)包?當(dāng)采用 AH遂道模式 時，主要提供 認(rèn)證 保護 (可變字段除外 )；?當(dāng)采用 ESP遂道模式 時，主要提供 加密和認(rèn)證 雙重保護。?這時，對 IPSec的處理是在 安全網(wǎng)關(guān) 執(zhí)行的，因此 兩端主機不必知道 IPSec協(xié)議的存在。85首部 有效載荷首部 有效載荷首部 有效載荷內(nèi)部 IP數(shù)據(jù)報外首部(新首部 )傳輸網(wǎng)絡(luò)首部 有效載荷內(nèi)部 IP數(shù)據(jù)報內(nèi)部 IP數(shù)據(jù)報內(nèi)部 IP數(shù)據(jù)報 安全網(wǎng)關(guān)安全網(wǎng)關(guān)外首部(新首部 )整個 IP數(shù)據(jù)包 86IPSec 協(xié)議 － 5 認(rèn)證頭協(xié)議 (A