《信息安全 第13章安全協(xié)議.ppt》由會(huì)員分享，可在線閱讀，更多相關(guān)《信息安全 第13章安全協(xié)議.ppt（65頁珍藏版）》請?jiān)谘b配圖網(wǎng)上搜索。

第13章安全協(xié)議 主要內(nèi)容 安全協(xié)議概述IPsec協(xié)議SSL協(xié)議安全電子交易協(xié)議SET 13 1安全協(xié)議基本概念 協(xié)議協(xié)議是指兩個(gè)或多個(gè)以上參與者為完成某項(xiàng)特定的任務(wù)而采取的一系列步驟 通信協(xié)議通信協(xié)議是指通信各方關(guān)于通信如何進(jìn)行所達(dá)成的一致性規(guī)則 即由參與通信的各方按確定的步驟做出一系列通信動(dòng)作 是定義通信實(shí)體之間交換信息的格式及意義的一組規(guī)則 包括語法 語義和同步三大要素 安全協(xié)議基本概念 安全協(xié)議安全協(xié)議是指通過信息的安全交換來實(shí)現(xiàn)某種安全目的所共同約定的邏輯操作規(guī)則 網(wǎng)絡(luò)安全通信協(xié)議屬于安全協(xié)議 是指在計(jì)算機(jī)網(wǎng)絡(luò)中使用的具有安全功能的通信協(xié)議 TCP IP安全分析 由于TCP IP協(xié)議簇在早期設(shè)計(jì)時(shí)是以面向應(yīng)用為根本目的的 因此未能充分考慮到安全性及協(xié)議自身的脆弱性 不完備性 導(dǎo)致網(wǎng)絡(luò)中存在著許多可能遭受攻擊的漏洞 TCP IP安全分析 網(wǎng)絡(luò)層協(xié)議的安全隱患IP協(xié)議在實(shí)現(xiàn)通信的過程中并不能為數(shù)據(jù)提供完整性和機(jī)密性保護(hù) 缺少基于IP地址的身份認(rèn)證機(jī)制 容易遭到IP地址欺騙攻擊 傳輸層協(xié)議的安全隱患TCP協(xié)議的安全隱患 服務(wù)器端維持大量的半連接列表而耗費(fèi)一定的資源 序列號可計(jì)算UDP協(xié)議的安全隱患不確認(rèn)報(bào)文是否到達(dá)不進(jìn)行流量控制不作糾錯(cuò)和重傳 TCP IP安全分析 應(yīng)用層協(xié)議的安全隱患大部分協(xié)議以超級管理員的權(quán)限運(yùn)行 一旦這些程序存在安全漏洞且被攻擊者利用 極有可能取得整個(gè)系統(tǒng)的控制權(quán) 許多協(xié)議采用簡單的身份認(rèn)證方式 并且在網(wǎng)絡(luò)中以明文方式傳輸 TCP IP的安全體系結(jié)構(gòu) 13 2IPsec協(xié)議 IPsec IPSecurity 產(chǎn)生于IPv6的制定之中 用于提供IP層的安全性 IPsec InternetProtocolSecurity Internet協(xié)議安全 通過AH AuthenticationHeader 驗(yàn)證報(bào)頭 和ESP EncapsulatingSecurityPayload 封裝安全有效負(fù)載 兩個(gè)安全協(xié)議分別為IP協(xié)議提供了基于無連接的數(shù)據(jù)完整性和數(shù)據(jù)保密性 基本概念和術(shù)語 安全關(guān)聯(lián)為了正確封裝和提取IPsec的數(shù)據(jù)包 有必要采取一套專門的方案 將安全服務(wù) 密鑰等與要保護(hù)的通信數(shù)據(jù)聯(lián)系在一起 這樣的構(gòu)建方案稱為安全關(guān)聯(lián) SecurityAssociation SA SA是發(fā)送者和接收者兩個(gè)IPsec系統(tǒng)之間的一個(gè)單向邏輯連接 若要在一個(gè)對等系統(tǒng)間進(jìn)行源和目的的雙向安全通信 則需要兩個(gè)SA 安全關(guān)聯(lián)SA通過一個(gè)三元組 安全參數(shù)索引SPI 目的IP地址和安全協(xié)議AH或ESP 來唯一標(biāo)識(shí) 實(shí)現(xiàn)IPsec必須維護(hù)這兩個(gè)數(shù)據(jù)庫 安全策略數(shù)據(jù)庫 對所有出 入業(yè)務(wù)應(yīng)采取的安全策略安全關(guān)聯(lián)數(shù)據(jù)庫 為進(jìn)入和外出包處理維持一個(gè)活動(dòng)的SA列表 基本概念和術(shù)語 隧道把一個(gè)包封裝在另一個(gè)新包中 整個(gè)源數(shù)據(jù)包作為新包的有效載荷部分 并在前面添加一個(gè)新的IP頭 對IPsec而言 IP隧道的直接目標(biāo)就是對整個(gè)IP數(shù)據(jù)包提供完整的保護(hù) Internet安全關(guān)聯(lián)和密鑰管理協(xié)議InternetSecurityAssociationandKeyManagementProtocol ISAKMP為Internet環(huán)境下安全協(xié)議使用的安全關(guān)聯(lián)和密鑰的創(chuàng)建定義了一個(gè)標(biāo)準(zhǔn)通用框架 定義了密鑰管理表述語言通用規(guī)則及要求 基本概念和術(shù)語 解釋域DomainofInterpretation DOI是Internet編號分配機(jī)構(gòu)IANA給出的一個(gè)命名空間 為使用ISAKMP進(jìn)行安全關(guān)聯(lián)協(xié)商的協(xié)議統(tǒng)一分配標(biāo)識(shí)符 共享一個(gè)DOI的協(xié)議從一個(gè)共同的命名空間中選擇安全協(xié)議和密碼變換 共享密鑰以及交換協(xié)議標(biāo)識(shí)符等 從而能使用相同DOI的協(xié)議對該DOI下的載荷數(shù)據(jù)內(nèi)容做出統(tǒng)一的解釋 IPsec組成 AuthenticationHeader AH 驗(yàn)證報(bào)頭 協(xié)議定義了認(rèn)證的應(yīng)用方法 提供數(shù)據(jù)源認(rèn)證和完整性保證 EncapsulatingSecurityPayload ESP 封裝安全有效負(fù)載 協(xié)議定義了加密和可選認(rèn)證的應(yīng)用方法 提供可靠性保證 InternetKeyExchange IKE 密鑰的交換標(biāo)準(zhǔn) 協(xié)議 用于密鑰交換 AH協(xié)議 AH的工作原理 在每一個(gè)數(shù)據(jù)包上添加一個(gè)身份驗(yàn)證報(bào)頭 此報(bào)頭包含一個(gè)被加密的hash值 可以將其當(dāng)作數(shù)字簽名 只是它不使用證書 此hash值在整個(gè)數(shù)據(jù)包中計(jì)算 因此對數(shù)據(jù)的任何更改將導(dǎo)致hash值無效 這樣就提供了完整性保護(hù) AH報(bào)頭位置在IP報(bào)頭和傳輸層協(xié)議頭之間 AH由協(xié)議號 51 標(biāo)識(shí) AH報(bào)頭結(jié)構(gòu) 1 下一個(gè)頭 NextHeader 8位 標(biāo)識(shí)下一個(gè)使用IP協(xié)議號的報(bào)頭類型 其取值在RFC1700中定義 2 載荷長度 PayloadLength 8位 表示以32位為單位的AH頭的長度減2 3 保留 Reserved 16位 供將來使用 值為0 4 安全參數(shù)索引 SecurityParametersIndex SPI 這是一個(gè)為數(shù)據(jù)報(bào)識(shí)別安全關(guān)聯(lián)SA的32位偽隨機(jī)值 5 序列號 SequenceNumber 從1開始的32位單增序列號 不允許重復(fù) 唯一地標(biāo)識(shí)了每一個(gè)發(fā)送數(shù)據(jù)包 為安全關(guān)聯(lián)提供反重播保護(hù) 6 認(rèn)證數(shù)據(jù) AuthenticationData AD 長度可變 但必須是32位的整數(shù)倍 默認(rèn)長度為96位 包含了數(shù)據(jù)包的完整性校驗(yàn)值ICV ESP協(xié)議 ESP的作用是提供機(jī)密性保護(hù) 有限的流機(jī)密性保護(hù) 無連接的完整性保護(hù) 數(shù)據(jù)源認(rèn)證和抗重放攻擊等安全服務(wù) ESP提供和AH類似的安全服務(wù) 但增加了數(shù)據(jù)機(jī)密性保護(hù)和有限的流機(jī)密性保護(hù)等兩個(gè)額外的安全服務(wù) ESP可以單獨(dú)使用 也可以和AH結(jié)合使用 一般ESP不對整個(gè)數(shù)據(jù)包加密 而是只加密IP包的有效載荷部分 不包括IP頭 但在端對端的隧道通信中 ESP需要對整個(gè)數(shù)據(jù)包加密 ESP數(shù)據(jù)包格式 認(rèn)證覆蓋范圍 保密性覆蓋范圍 08162431 安全參數(shù)索引 序列號 認(rèn)證數(shù)據(jù) 載荷數(shù)據(jù) 變長 下一個(gè)頭 填充項(xiàng)長度 填充項(xiàng) 1 安全參數(shù)索引 SPI 32位整數(shù) 它和IP頭的目的地址 ESP協(xié)議一起用以唯一標(biāo)識(shí)對這個(gè)包進(jìn)行ESP保護(hù)的SA 2 序列號 SequenceNumber 從1開始的32位單增序列號 不允許重復(fù) 唯一地標(biāo)識(shí)了每一個(gè)發(fā)送數(shù)據(jù)包 3 載荷數(shù)據(jù) 長度不固定 所包含的是由下一個(gè)頭字段所指示的數(shù)據(jù) 如整個(gè)IP數(shù)據(jù)包 上層協(xié)議TCP或UDP報(bào)文等 4 填充項(xiàng) Padding 如果加密算法要求明文是某個(gè)數(shù)字的整數(shù)倍 則通過填充可將明文擴(kuò)充到所需要的長度 另外 通過填充可以隱藏載荷數(shù)據(jù)的實(shí)際長度 從而對流量提供部分的保密性 5 填充項(xiàng)長度 PaddingLength 8位 表明填充項(xiàng)字段中填充以字節(jié)為單位的長度 6 下一個(gè)頭 NextHeader 識(shí)別下一個(gè)使用IP協(xié)議號的報(bào)頭 如TCP或UDP 7 認(rèn)證數(shù)據(jù) AuthenticationData 長度不固定 存放的是完整性校驗(yàn)值ICV IKE協(xié)議 IKE的基礎(chǔ)是ISAKMP Oakley和SKEME三個(gè)協(xié)議 它沿用了ISAKMP的基礎(chǔ) Oakley的模式以及SKEME的共享和密鑰更新技術(shù) 使用了兩個(gè)交換階段 階段一用于建立IKESA 階段二利用已建立的IKESA為IPsec協(xié)商具體的一個(gè)或多個(gè)安全關(guān)聯(lián) 即建立IPsecSA IKE允許四種認(rèn)證方法 分別是基于數(shù)字簽名的認(rèn)證 基于公鑰加密的認(rèn)證 基于修訂的公鑰加密的認(rèn)證和基于預(yù)共享密鑰的認(rèn)證 IPsec的工作模式 傳輸模式采用傳輸模式時(shí) 原IP數(shù)據(jù)包的首部之后的數(shù)據(jù)會(huì)發(fā)生改變 通過增加AH或ESP字段來提供安全性 但原IP首部不變 AH傳輸模式ESP傳輸模式隧道模式隧道模式的保護(hù)對象是整個(gè)IP包 在AH或ESP字段加入到IP分組后 還要加上一個(gè)新的首部 原數(shù)據(jù)包加上安全字段成為新數(shù)據(jù)包的載荷 因此得到了完全的安全性保護(hù) AH隧道模式ESP隧道模式 AH傳輸模式 除變長字段外都要認(rèn)證 AH傳輸模式下IPv4封包 原IPv4封包 IP頭 TCP UDP頭 數(shù)據(jù) 原IP頭 TCP UDP頭 數(shù)據(jù) AH頭 ESP傳輸模式 加密 ESP傳輸模式下IPv4封包 原IPv4封包 IP頭 TCP UDP頭 數(shù)據(jù) 原IP頭 TCP UDP頭 數(shù)據(jù) ESP頭 ESP尾部 ESP認(rèn)證數(shù)據(jù) 認(rèn)證 AH隧道模式 除新IP頭變長字段外都要認(rèn)證 原IPv4封包 IP頭 TCP UDP頭 數(shù)據(jù) AH傳輸模式下IPv4封包 新IP頭 AH頭 原IP頭 TCP UDP頭 數(shù)據(jù) ESP隧道模式 加密 ESP傳輸模式下IPv4封包 原IPv4封包 IP頭 TCP UDP頭 數(shù)據(jù) 新IP頭 TCP UDP頭 數(shù)據(jù) ESP頭 ESP尾部 ESP認(rèn)證數(shù)據(jù) 認(rèn)證 原IP頭 IPsec的應(yīng)用 目前IPsec最主要的應(yīng)用就是構(gòu)建安全的虛擬專用網(wǎng) 虛擬專用網(wǎng) VirtualPrivateNetwork VPN 是一條穿過公用網(wǎng)絡(luò)的安全 穩(wěn)定的隧道 通過對網(wǎng)絡(luò)數(shù)據(jù)的封包和加密傳輸 在一個(gè)公用網(wǎng)絡(luò) 通常是因特網(wǎng) 建立一個(gè)臨時(shí)的 安全的連接 從而實(shí)現(xiàn)在公網(wǎng)上傳輸私有數(shù)據(jù) 達(dá)到私有網(wǎng)絡(luò)的安全級別 基于IPsec的VPN IPSecVPN的不足 最早出現(xiàn)的具有加密功能的VPN是IPSecVPN 雖然IPSecVPN簡單高效 但在實(shí)現(xiàn)遠(yuǎn)程接入時(shí)存在以下一些弱點(diǎn) 網(wǎng)絡(luò)的互聯(lián)性不好客戶端使用和維護(hù)困難訪問權(quán)限管理粒度較粗 SSLVPN產(chǎn)生的背景 對于IPSecVPN在實(shí)現(xiàn)遠(yuǎn)程接入方面存在的問題 SSLVPN可以很好地給予解決 網(wǎng)絡(luò)互聯(lián)性 SSL工作在TCP層 不會(huì)受NAT和防火墻的影響 客戶端的維護(hù) 借助瀏覽器 實(shí)現(xiàn)客戶端的自動(dòng)安裝和配置 訪問權(quán)限管理 解析應(yīng)用層協(xié)議 進(jìn)行高細(xì)粒度地訪問控制 13 3SSL協(xié)議 SSL協(xié)議是一個(gè)傳輸層安全協(xié)議 SSL協(xié)議由Netscape公司于1994年11月提出并率先實(shí)現(xiàn) 即SSLV2 0Internet Draft版本1996年3月推出了SSLV3 0Internet Draft版本 最終被IETF所采納 并制定為傳輸層安全標(biāo)準(zhǔn) 工作在傳輸層之上 應(yīng)用層之下 其底層是基于傳輸層可靠的流傳輸協(xié)議 如TCP SSL協(xié)議簡介 SSL 英文 SecureSocketLayer 中文 安全套接字 協(xié)議 SSL協(xié)議是一種工作在TCP層之上的 用于安全傳輸數(shù)據(jù)的加密協(xié)議 SSL協(xié)議可以提供以下功能 加密的數(shù)據(jù)傳輸支持用數(shù)字簽名驗(yàn)證通訊雙方的身份抗攻擊 如重播 replay 中間人 man in middle 等 面向應(yīng)用程序的API接口 便于SSL協(xié)議在客戶端和服務(wù)器端部署 SSL協(xié)議簡介 工作模型 SSL協(xié)議在使用方面的特點(diǎn) SSL協(xié)議對上層應(yīng)用提供端到端的 有連接的加密傳輸服務(wù) SSL協(xié)議采用了C S架構(gòu)的通訊模式 SSL服務(wù)器端作為一種TCP服務(wù) 監(jiān)聽443號端口 接收建立SSL連接的請求報(bào)文 SSL協(xié)議簡介 協(xié)議架構(gòu) SSL協(xié)議包含兩層 握手層 負(fù)責(zé)建立SSL連接記錄層 負(fù)責(zé)對報(bào)文進(jìn)行加解密 SSL協(xié)議簡介 記錄層 SSL記錄層提供下列功能 保證數(shù)據(jù)傳輸?shù)乃矫苄?對傳輸數(shù)據(jù)進(jìn)行加密和解密 保證數(shù)據(jù)傳輸?shù)耐暾?計(jì)算和驗(yàn)證報(bào)文的消息驗(yàn)證碼 對傳輸數(shù)據(jù)的壓縮 目前壓縮算法為空 對上層提供可靠保序的有連接服務(wù) 加密數(shù)據(jù) 報(bào)文類型 版本 長度 長度 字節(jié) 1字節(jié) 2字節(jié) 2字節(jié) MAC 報(bào)文類型 密鑰改變協(xié)議 20 告警協(xié)議 21 握手協(xié)議 22 應(yīng)用層數(shù)據(jù) 23 版本 TLS1 0 3 1 SSL3 0 3 0 長度 記錄層報(bào)文的長度 包括加密數(shù)據(jù)和MAC值的字節(jié)數(shù) MAC 整個(gè)記錄報(bào)文的消息驗(yàn)證碼 包括從報(bào)文類型開始的所有字段 SSL記錄層的報(bào)文格式 SSL協(xié)議簡介 握手層 SSL握手層提供下列功能 協(xié)商加密能力協(xié)議版本 加密套件 壓縮算法 協(xié)商密鑰參數(shù) 塊加密 初始化向量 IV 加密密鑰 HMAC密鑰 流加密 流初始狀態(tài) HMAC密鑰 驗(yàn)證對方身份 可選 建立并維護(hù)SSL會(huì)話 SSL協(xié)議簡介 握手過程 SSL握手協(xié)議提供了三種握手過程 無客戶端身份認(rèn)證的全握手過程全握手過程是指一個(gè)完整的SSL連接建立過程 在其中需要協(xié)商出新的會(huì)話參數(shù) 無客戶端認(rèn)證 是指在該過程中服務(wù)器端并不驗(yàn)證客戶端的身份 有客戶端身份認(rèn)證的全握手過程服務(wù)器端可以通過此過程利用數(shù)字簽名來驗(yàn)證用戶的真實(shí)身份 會(huì)話恢復(fù)過程由于SSL全握手過程涉及到較多的復(fù)雜計(jì)算 耗時(shí)較多 為提高建立SSL連接的效率 SSL協(xié)議提供了會(huì)話恢復(fù)機(jī)制 使得后面建立的SSL連接可以利用以前連接的會(huì)話參數(shù) 避免了重新協(xié)商的過程 SSL協(xié)議簡介 無客戶端認(rèn)證的全握手過程 client server ClientHello ServerHello ServerCertificate ServerKeyExchange ServerHelloDone ChangeCipherSpec Finished ApplicationData 客戶端支持的最高版本 加密套件列表 壓縮算法列表 客戶端隨機(jī)數(shù) 會(huì)話ID 0 服務(wù)器同意的版本 加密套件 壓縮算法 會(huì)話ID 服務(wù)器端隨機(jī)數(shù) 服務(wù)器的證書 服務(wù)器端密鑰交換的附加信息 通知對方服務(wù)器端握手消息發(fā)完 客戶端產(chǎn)生的PreMasterKey密鑰參數(shù) 通知對方本端開始啟用加密參數(shù) 通知對方本端開始啟用加密參數(shù) 發(fā)送客戶端計(jì)算握手過程的驗(yàn)證報(bào)文 發(fā)送自己計(jì)算握手過程驗(yàn)證報(bào)文 傳送應(yīng)用層數(shù)據(jù) ClientKeyExchange Finished ApplicationData ChangeCipherSpec SSL協(xié)議簡介 有客戶端認(rèn)證的全握手過程 SSL協(xié)議簡介 會(huì)話恢復(fù)過程 SSL安全協(xié)議主要提供三方面的服務(wù) 客戶和服務(wù)器的合法性認(rèn)證加密數(shù)據(jù)以隱藏被傳送的數(shù)據(jù)保護(hù)數(shù)據(jù)的完整性 SSL安全通信過程 1 接通階段 客戶機(jī)通過網(wǎng)絡(luò)向服務(wù)器打招呼 服務(wù)器回應(yīng) 2 密碼交換階段 客戶機(jī)與服務(wù)器之間交換雙方認(rèn)可的密碼 一般選用RSA密碼算法 也有的選用Diffie Hellmanf和Fortezza KEA密碼算法 3 會(huì)談密碼階段 客戶機(jī)與服務(wù)器間產(chǎn)生彼此交談的會(huì)談密碼 4 檢驗(yàn)階段 客戶機(jī)檢驗(yàn)服務(wù)器取得的密碼 5 客戶認(rèn)證階段 服務(wù)器驗(yàn)證客戶機(jī)的可信度 6 結(jié)束階段 客戶機(jī)與服務(wù)器之間相互交換結(jié)束的信息 SSL協(xié)議的分層結(jié)構(gòu) SSL協(xié)議具有兩層結(jié)構(gòu) 其底層是SSL記錄協(xié)議層 SSLRecordProtocolLayer 簡稱記錄層 其高層是SSL握手協(xié)議層 SSLHandshakeProtocolLayer 簡稱握手層 會(huì)話與連接 Connection 連接 一個(gè)在傳輸層協(xié)議上的傳輸媒介 它提供一個(gè)適當(dāng)?shù)姆?wù) 連接建立在會(huì)話的基礎(chǔ)上 每個(gè)連接與一個(gè)會(huì)話相關(guān)聯(lián) 并對應(yīng)到一個(gè)會(huì)話 Session 會(huì)話 SSL會(huì)話建立客戶與服務(wù)器之間的一個(gè)關(guān)聯(lián) Association 每一組客戶端與服務(wù)器之間就是一個(gè)SSLsession 這些會(huì)話定義一組以密碼為基礎(chǔ)的安全性參數(shù) 這些參數(shù)能夠由多個(gè)連接來共同使用 會(huì)話 SSL握手協(xié)議 Handshake協(xié)議用來讓客戶端及服務(wù)器確認(rèn)彼此的身份 協(xié)助雙方選擇連接時(shí)所使用的加密算法 MAC算法 及相關(guān)密鑰 Handshake由一些客戶與服務(wù)器交換的消息所構(gòu)成 每一個(gè)消息都含有以下三個(gè)字段 類型 Type 1個(gè)字節(jié) 表示消息的類型 總共有十種 長度 Length 3個(gè)字節(jié) 消息的位組長度 內(nèi)容 Content 大于或等于1個(gè)字節(jié) 與此消息有關(guān)的參數(shù) SSLHandshake協(xié)議消息類型 客戶端與服務(wù)器產(chǎn)生一條新連接所要進(jìn)行的初始交換過程包括四個(gè)階段 即建立安全能力 服務(wù)器認(rèn)證與密鑰交換 客戶端認(rèn)證與密鑰交換 完成 SSL記錄協(xié)議 SSL記錄協(xié)議為每一個(gè)SSL連接提供以下兩種服務(wù) 機(jī)密性 Confidentiality SSL記錄協(xié)議會(huì)協(xié)助雙方產(chǎn)生一把共有的密鑰 利用這把密鑰來對SSL所傳送的數(shù)據(jù)做傳統(tǒng)式加密 消息完整性 MessageIntegrity SSL記錄協(xié)議會(huì)協(xié)助雙方產(chǎn)生另一把共有的密鑰 利用這把密鑰來計(jì)算出消息認(rèn)證碼 SSL記錄協(xié)議運(yùn)作模式 SSL協(xié)議安全性分析 SSL協(xié)議自身的缺陷客戶端假冒SSL協(xié)議無法提供基于UDP應(yīng)用的安全保護(hù)SSL協(xié)議不能對抗通信流量分析針對基于公鑰加密標(biāo)準(zhǔn) PKCS 協(xié)議的自適應(yīng)選擇密文攻擊進(jìn)程中的主密鑰泄漏磁盤上的臨時(shí)文件可能遭受攻擊 SSL協(xié)議安全性分析 不規(guī)范應(yīng)用引起的問題對證書的攻擊和竊取中間人攻擊安全盲點(diǎn)IE瀏覽器的SSL身份鑒別缺陷 SSLVPN與IPSecVPN的比較 13 4安全電子交易協(xié)議SET SET協(xié)議 SecureElectronicTransaction 安全電子交易 是由VISA和MasterCard兩大信用卡公司聯(lián)合推出的規(guī)范 SET主要是為了解決用戶 商家和銀行之間通過信用卡支付的交易而設(shè)計(jì)的 以保證支付命令的機(jī)密 支付過程的完整 商戶及持卡人的合法身份 以及可操作性 SET中的核心技術(shù)主要有公鑰加密 數(shù)字簽名 數(shù)字信封 數(shù)字證書等 SET是應(yīng)用層的安全協(xié)議 SET提供的服務(wù) 給所有參與交易的每一方提供一個(gè)安全的通信管道 使用X 509v3數(shù)字證書來提供可信賴的服務(wù) 確保交易的隱密性 唯有必要的時(shí)候 才會(huì)在必要的場所提供給交易雙方所需的信息 SET交易分為三個(gè)階段 第一階段為購買請求階段 持卡人與商家確定所用支付方式的細(xì)節(jié)第二階段是支付的認(rèn)定階段 商家與銀行核實(shí) 隨著交易的進(jìn)行 他們將得到支付第三階段為收款階段 商家向銀行出示所有交易的細(xì)節(jié) 然后銀行以適當(dāng)方式轉(zhuǎn)移貨款 在整個(gè)交易過程中 持卡人只和第一階段有關(guān) 銀行與第二 第三階段有關(guān) 而商家與三個(gè)階段都要發(fā)生聯(lián)系 每個(gè)階段都要使用不同的加密方法對數(shù)據(jù)加密 并進(jìn)行數(shù)字簽名 SET交易的參與者 SET規(guī)范的交易模式中 所參與的個(gè)體包括持卡人 特約商店 發(fā)卡行 收單行 支付網(wǎng)關(guān) 認(rèn)證中心等 進(jìn)行一個(gè)SET交易所經(jīng)歷的事件 1 消費(fèi)者開立賬戶 2 消費(fèi)者收到證書 3 特約商店證書 4 消費(fèi)者訂購 5 特約商店核對 6 發(fā)送訂單及支付 7 特約商店請求支付認(rèn)證 8 特約商店核準(zhǔn)訂單 9 特約商店提供其貨物或服務(wù) 10 特約商店請求支付 雙重簽名 雙重簽名的目的在連結(jié)兩個(gè)不同接收者消息 在這里 消費(fèi)者想要發(fā)送訂單信息 OI OrderInformation 到特約商店 且發(fā)送支付命令 PI PaymentInstruction 給銀行 特約商店并不需要知道消費(fèi)者的信用卡卡號 而銀行不需要知道消費(fèi)者訂單的詳細(xì)信息 消費(fèi)者需要將這兩個(gè)消息分隔開 而受到額外的隱私保護(hù) 然而 在必要的時(shí)候這兩個(gè)消息必須要連結(jié)在一起 才可以解決可能的爭議 質(zhì)疑 這樣消費(fèi)者可以證明這個(gè)支付行為是根據(jù)他的訂單來執(zhí)行的 而不是其它的貨品或服務(wù) 雙重簽名的生成過程 SET交易分為三個(gè)階段 購買請求階段支付授權(quán)階段取得支付階段 購買請求階段 1 購買請求過程由四個(gè)消息構(gòu)成 初始請求 初始回應(yīng) 購買請求 購買回應(yīng) 初始請求消費(fèi)者在初始請求的消息中要求申請證書 然后這個(gè)消息會(huì)送到特約商店 這個(gè)消息包括消費(fèi)者所使用的信用卡的公司 也包含了由消費(fèi)者指定的回應(yīng)這組請求的一個(gè)ID 初始回應(yīng)特約商店對初始請求產(chǎn)生響應(yīng) 并且用自己的私鑰來簽名 這個(gè)響應(yīng)消息包含一個(gè)代表這次購買交易代號的ID 特約商店的簽名證書及支付網(wǎng)關(guān)證書 購買請求階段 2 購買請求 購買請求信息包括 采購相關(guān)的信息 訂單相關(guān)信息 持卡人證書 購買請求階段 3 購買回應(yīng) 核對購買請求信息并發(fā)回購買響應(yīng)消息 支付授權(quán)階段 特約商店會(huì)授權(quán)支付網(wǎng)關(guān)來處理此次交易 支付授權(quán)過程中包含了授權(quán)請求和授權(quán)回應(yīng)消息 授權(quán)請求消息包括 采購的相關(guān)消息授權(quán)的相關(guān)消息證書支付網(wǎng)關(guān)傳回一個(gè)授權(quán)響應(yīng) 內(nèi)容包括 授權(quán)相關(guān)的信息記錄信封的信息證書 取得支付階段 為了得到消費(fèi)者的付費(fèi)款項(xiàng) 特約商店必須和支付網(wǎng)關(guān)進(jìn)行支付信息的交換處理 這項(xiàng)交易過程中包含了兩個(gè)消息 分別是記錄請求消息與記錄響應(yīng)消息 SET協(xié)議的安全性分析 認(rèn)證安全完整性安全機(jī)密性安全抗否認(rèn)性隱私權(quán)的安全保護(hù)