SSL和SET.ppt

1、第6章 安全協(xié)議,6.1 SSL協(xié)議及其應用 6.2 安全電子交易系統(tǒng),安全套接字層協(xié)議( Security Socket Layer,SSL)是用于Internet上進行保密通信的一個安全協(xié)議，它的主要目的是保證兩臺機器之間的通信安全，提供網(wǎng)絡(luò)上可信賴的服務。 SSL協(xié)議已成為Web安全方面的工業(yè)標準。目前廣泛采用的是SSLv3。,6.1 SSL協(xié)議及其應用 6.1.1 引言,SSL使用保密密鑰對將要通過SSL連接傳送的數(shù)據(jù)進行加密，它是對兩臺機器之間的整個會話進行加密的協(xié)議。 SSL的設(shè)計目標如下： 加密安全。 互用性。 可擴展性。 關(guān)聯(lián)功能。,6.1.2 SSL協(xié)議概述,1. SSL 協(xié)

2、議的結(jié)構(gòu) 由兩層組成，分別是握手協(xié)議層和記錄協(xié)議層。 SSL協(xié)議可以獨立于應用層協(xié)議，因此可以保證一個建立在SSL協(xié)議之上的應用協(xié)議能透明地傳輸數(shù)據(jù)。SSL協(xié)議在網(wǎng)絡(luò)協(xié)議棧的位置如圖6.1所示。,圖6.1 SSL協(xié)議層與TCP/IP 協(xié)議的關(guān)系圖,SSL握手協(xié)議的作用是在正式的秘密通信之前，讓服務器和客戶之間互相鑒別對方的身份并協(xié)商一種會話的加密算法和加密密鑰。 （1） 客戶端和服務器之間互相驗證身份 （2） 客戶端和服務器之間協(xié)商安全參數(shù),SSL協(xié)議提供安全連接時有以下基本屬性： 通信內(nèi)容是保密的。 雙方的驗證是使用非對稱密鑰。 連接是可靠的。,2 SSL協(xié)議中的狀態(tài) 一個SSL會話是有狀態(tài)

3、的。 （1） 待定狀態(tài)和當前狀態(tài) 待定狀態(tài)，包含當前握手協(xié)議協(xié)商好的壓縮、加密、計算MAC以及密鑰等。 當前狀態(tài)，包含記錄層正在實施的壓縮、加密、計算MAC以及密鑰等。,（2） 會話狀態(tài)和連接狀態(tài) 每個會話狀態(tài)包含以下元素： 會話標識符 壓縮算法 加密規(guī)格說明 主密鑰 是否可回復的一個標志,每個連接狀態(tài)包含下列元素： 服務器和客戶端隨機數(shù) 服務器消息驗證碼密鑰 客戶端消息驗證碼密鑰 服務器寫密鑰 客戶端寫密鑰 初始化向量 序號服務器和客戶端,3. SSL協(xié)議規(guī)范表示語言 SSL協(xié)議有自己的一套規(guī)范語言，使用規(guī)范語言可以提供一種沒有歧義的、精簡的協(xié)議描述。SSL的規(guī)范語言和C語言有點相似。 （1

4、） 基本類型 所有的數(shù)據(jù)表示都是嚴格規(guī)定的?；镜臄?shù)據(jù)大小是一個字節(jié)（8個位）。多字節(jié)的數(shù)據(jù)是八字節(jié)串聯(lián)起來，從左到右，從上到下。,（2） 混合 注釋用“/*”開始 ，用“*/”結(jié)束， 可選的組件放在“ ”里。 （3） 數(shù)值型 基本的數(shù)值型是uint8。所有大數(shù)值型都是uint8固定組成。 uint8 uint162; uint8 uint243; uint8 uint324; uint8 uint648,（4） 向量 一個向量（單維的數(shù)組）是一個同構(gòu)的數(shù)據(jù)元素流，它是給定類型的元素序列。向量有定長和變長。定長用 表示，變長用 表示。 （5） 枚舉 枚舉就是只有一系列特定的字段，且每個值都有名

5、字。 （6） 結(jié)構(gòu) 結(jié)構(gòu)類型按需要從原始類型組合而成。語法和C很相似。,struct T1 f1; T2 f2; . Tn fn; T; 這里可以用結(jié)構(gòu)名加上字段名指定一個項，如T.f2 就指定義的第二個字段。,記錄層SSL常用的數(shù)據(jù)加密算法有下列幾種。（1） No encryption Stream ciphers （2） RC4 with 40 bit key （3） RC4 with 128 bit key CBC Block Ciphers （4） RC2 with 40 bit key （5） DES with 40 bit key （6） DES with 56 bit key （

6、7） Triple-DES with 168 bit key （8） Idea (128 bit key) （9） Fortezza (96 bit key),6.1.3 記錄層協(xié)議,1 幀 幀是記錄層從上層接收到的任意長度、非空的、不可分的數(shù)據(jù)。 2 記錄的壓縮和解壓 3 記錄有效負荷保護和密碼規(guī)范,change_cipher_spec消息有著特殊的用途，它表示記錄加密及認證的改變，一旦握手商定了一組新的密鑰，就發(fā)送change_cipher_spec消息來指示此刻將啟用新的密鑰。,6.1.4 change_cipher_spec協(xié)議,警告類型是被SSL記錄層協(xié)議支持的一種。警告消息傳達消息

7、的嚴重性和該警告的描述。,6.1.5 警告協(xié)議,enum warning(1), fatal(2), (255) AlertLevel; enum close_notify(0), unexpected_message(10), bad_record_mac(20), decompression_failure(30), handshake_failure(40), no_certificate(41), bad_certificate(42), unsupported_certificate(43), certificate_revoked(44), certificate_expired(

8、45), certificate_unknown(46),illegal_parameter (47) (255) AlertDescription; struct AlertLevel level; AlertDescription description; Alert; 1. 關(guān)閉提示 當連接關(guān)閉時，客戶端和服務器端都必須知道，以防止切斷攻擊。,2 錯誤提示 一般有如下錯誤警告： unexpected_message bad_record_mac decompression_failure handshake_failure no_certificate bad_certificate u

9、nsupported_certificate certificate_revoked certificate_expired illegal_parameter,握手層SSL支持的密鑰交換算法有以下兩種： RSA 密鑰交換。 Diffie-Hellman密鑰交換。,6.1.6 握手層協(xié)議,1 握手協(xié)議概述 會話狀態(tài)的加密參數(shù)由握手協(xié)議產(chǎn)生，握手協(xié)議在記錄層協(xié)議的上方。圖6.2是一簡單的握手協(xié)議順序圖。 圖6.2顯示了握手協(xié)議要傳輸?shù)膬?nèi)容，但并非每一個箭頭線都表示要在網(wǎng)絡(luò)上傳輸一次，同一方向的幾個連在一起，其內(nèi)容將在一次傳輸中發(fā)送。,圖6.2 簡單的握手協(xié)議順序圖,為了避免管道傳輸延時，Chan

10、geCiphersSpec是一個獨立的SSL內(nèi)容類型，并不是一個實際的SSL握手協(xié)議消息。如果服務器和客戶端決定再繼續(xù)一個以前的會話或者復制一個已經(jīng)存在的會話（使用新的安全參數(shù)來替代），那么消息流如下（星號表示可選）：,客戶端 服務器端 ClientHello - erverHello Certificate* ServerKeyExchange* CertificateRequest* ChangeCipherSpec Application Dat,恢復一個會話: 客戶端 服務器端 ClientHello - ServerHello change cipher spec Applicati

11、on Data Application Data,2 握手協(xié)議 SSL握手協(xié)議是SSL記錄層協(xié)議的高一級客戶。這個協(xié)議是用來磋商一個會話的安全屬性。下面是握手消息結(jié)構(gòu):,Enum hello_request(0),client_hello(1),server_hello(2),certificate(11),server_key_exchange(12),certificate_request(13),server_hello_done(14),certificate_vertify(15),client_key_exchange(16),(255) HandshakeType; Struct

12、 HandshakeType msg_type; uint24 length; select(HandshakeType) case hello_request: HelloRequest; case client_hello:ClientHello; case server_hello:ServerHello;,case certificate: Certificate; case server_key_exchange: ServerKeyExchange; case certificate_request: CertificateRequest; case server_hello_do

13、ne: ServerHelloDone; case certificate_verify: CertificateVerify; case client_key_exchange: ClientKeyExchange; case finished: Finished; body; Handshake; 握手協(xié)議必須按照順序發(fā)送，否則，將會產(chǎn)生一個致命的錯誤。,（1） Hello 消息 Hello階段的消息用做在雙方之間交換安全增強能力。 Hello請求。 服務器可以在任何時刻發(fā)送Hello請求消息，但是，當握手協(xié)議正在進行時，客戶端忽略消息?？蛻舳艘部梢园l(fā)送一個ClientHello來重新開始

14、協(xié)議。, 客戶端Hello消息。 客戶端使用SSL版本號 struct uint32 gmt_unix_time; opaque random_bytes28; Random; 會話標識符 密碼組列表 壓縮算法列表, 消息服務器Hello。 服務器接收到一個ClientHello消息后，作為回應，將發(fā)送一個handshake_failure提示，或者一個ServerHello消息。 struct ProtocolVersion server_version; Random random; SessionID session_id; CipherSuite cipher_suite; Compr

15、essionMethod compression_method; ServerHello;,（2） 服務器密鑰交換消息（Server key exchange message） （3） 證書請求 一個非匿名的服務器可以任意要求客戶端發(fā)送一個證書給它 （4） 服務器Hello結(jié)束 服務器發(fā)送一個ServerHelloDone 消息，表明服務器Hello消息及相關(guān)的消息的結(jié)束。發(fā)送以后，服務器將等待客戶端的響應。 （5） 客戶端證書 在客戶端接收到ServerHelloDone消息后，第一個可能發(fā)送的消息就是客戶端證書。,（6） 客戶端密鑰交換消息 struct select (KeyExchan

16、geAlgorithm) case rsa: EncryptedPreMasterSecret; case diffie_hellman: ClientDiffieHellmanPublic; case fortezza_kea: FortezzaKeys; exchange_keys; ClientKeyExchange;,（7） 證書驗證 這個消息用來嚴格驗證客戶端證書。這個消息緊跟在一個具有簽名能力的客戶端證書后面。 （8） 結(jié)束 一個變化的密碼規(guī)范消息驗證了密鑰交換過程和驗證過程已經(jīng)成功后，一個結(jié)束的消息就立即發(fā)送。這個結(jié)束消息是第一個剛剛協(xié)商的安全參數(shù)保護的消息。在這個消息之后，雙方

17、就開始發(fā)送應用層數(shù)據(jù)。接收到結(jié)束消息，必須驗證內(nèi)容的正確性。,密鑰分為兩大類：數(shù)據(jù)加密密鑰(DK)和密鑰加密密鑰(KEK)。 在現(xiàn)實世界中，密鑰管理是最困難的安全問題，密鑰管理問題成為網(wǎng)絡(luò)安全的核心問題。 本小節(jié)主要討論雙方在有公鑰證書情況下的密鑰交換，使用的是RSA密鑰交換協(xié)議。,6.1.7 密鑰管理,圖6.3 共享密鑰在公開信道上交換,1. 共享密鑰在公開信道上的交換,2. 密鑰的生成與分配 SSL協(xié)議中包含對稱加密算法和非對稱加密算法，所以密鑰的生成和分配也分成兩類。,下面從握手協(xié)議和應用數(shù)據(jù)兩個方面分析SSL抵抗各種攻擊的能力及SSLv3的某些漏洞。,6.1.8 SSL安全性,1 握手

18、層協(xié)議的安全性 握手協(xié)議負責協(xié)商加密參數(shù)和有選擇地驗證通信實體。 （1） 驗證與密鑰交換 SSL有3種驗證模式：客戶端和服務器都驗證；僅服務器方驗證，客戶端不驗證；完全匿名，雙方都不驗證。 匿名密鑰交換 RSA(密鑰交換和驗證) Diffie-Hellman 密鑰交換和驗證。 FORTEZZA,（2） 版本重放攻擊 （3） 檢測對握手協(xié)議的攻擊 （4） 會話的恢復 （5） 散列算法,2. 應用數(shù)據(jù)保護,系統(tǒng)的安全性取決于最弱的密鑰交換和驗證算法，只有可以信賴的加密功能才能使用。應該謹慎使用較短的公鑰密碼、40 位的加密密鑰。證書和證書驗證至關(guān)重要，一個不誠實的CA將產(chǎn)生巨大的破壞。,根據(jù)應用場

19、合不同，SSL協(xié)議有多種應用模式。 匿名SSL連接 對等安全服務 電子商務 網(wǎng)上交易的安全方案如圖6.4所示。,6.1.9 SSL應用,6.4 網(wǎng)上交易安全方案,兩大信用卡組織Visa和MasterCard聯(lián)合開發(fā)了SET (Security Electric Transaction，安全電子交易系統(tǒng))。 安全電子交易是基于Internet的卡基支付，是授權(quán)業(yè)務信息傳輸?shù)陌踩珮藴省?6.2 安全電子交易系統(tǒng) 6.2.1 SET概述,圖6.5描述了網(wǎng)上交易的安全方案。,6.2.2 SET的基本概念,圖6.5 網(wǎng)上交易的安全方案,SET協(xié)議中的角色有： 持卡人 發(fā)卡銀行（Issuer） 收單銀行

20、商家 支付網(wǎng)關(guān) 認證中心 電子錢包,SET規(guī)范涉及的范圍包括： 加密算法的應用(例如RSA和DES)； 證書信息和對象格式； 購買信息和對象格式； 認證信息和對象格式； 劃賬信息和對象格式； 交易實體之間消息的傳輸協(xié)議。,圖6-1 加密方法示例,加密算法示例,SET提供的安全服務主要如下： 機密性 認證 完整性 關(guān)聯(lián)： 非否認：,其中證書的主要類型如下： （1） 持卡者證書 （2） 商家證書 （3） 支付網(wǎng)關(guān)證書 （4） 證書鏈確認 （5） 品牌的證書注銷列表標識,1 基本流程 SET協(xié)議的工作程序分為下面7個步驟（如圖6.6所示)。,6.2.3 支付處理流程,圖6.6 SET系統(tǒng),電子錢包及

21、電子證書核發(fā)流程如下： 持卡人填送SET協(xié)議書至發(fā)卡銀行。 發(fā)卡銀行審核通過后，寄發(fā)電子錢包及相關(guān)須知給持卡人。 發(fā)卡銀行傳送持卡人認證資料至認證中心以供其核對。 持卡人通過Internet連線到認證中心的網(wǎng)址，提出證書申請。 使用者閱讀并接受認證中心的合約書后，進入認證注冊，填寫基本資料及發(fā)卡銀行提供的密碼，并傳回認證中心確認。 認證中心將持卡人的認證資料與發(fā)卡行送來的資料核對無誤后，發(fā)出一張電子證書給持卡人。 同時認證中心提供核發(fā)電子證書的資料給發(fā)卡銀行。,證書描述了持卡人通過SET協(xié)議申請證書的流程。,圖6-3 申請證書的流程,具體過程如下： 1啟動電子錢包，發(fā)送初始請求,2CA發(fā)送響應

22、,3接收響應,接收響應過程,4CA處理請求并發(fā)送注冊表,CA處理請求并發(fā)送注冊表過程,5持卡人接收注冊表并請求證書,6CA處理請求并產(chǎn)生證書,產(chǎn)生證書過程,購買請求的過程如下圖所示。,1持卡人(cardholder)初始化請求,圖6-12 初始化請求過程,2商家發(fā)送證書,商家發(fā)送證書,3持卡人接收初始化響應并發(fā)送請求。,發(fā)送請求過程,4商家處理請求報文。,商家處理請求過程,5持卡人接收購買響應。,接收購買響應過程,商家在向持卡人發(fā)送商品以前，首先向網(wǎng)關(guān)查詢持卡人是否具有支付能力。 如下圖所示。,支付認證過程,1商家請求授權(quán)。,商家請求支付授權(quán),2支付網(wǎng)關(guān)處理授權(quán)請求。,支付網(wǎng)關(guān)處理支付授權(quán)請求

23、,3商家處理授權(quán)響應,商家處理授權(quán)響應,獲取付款,獲取付款過程,1商家請求付款。,商家請求付款過程,2支付網(wǎng)關(guān)處理付款請求 。,商家接收付款響應過程,3商家接收付款響應。,2 轉(zhuǎn)賬付款處理 多個請款（capture）消息組成一批（batch），稱為“批請款”(Batch Capture)或“請批款”。 （1） 批請款處理模型 與SET有關(guān)的批請款處理模型包括以下兩種： 商家終端數(shù)據(jù)轉(zhuǎn)賬付款； 收單行主機數(shù)據(jù)轉(zhuǎn)賬付款。,（2） SET批請款處理的支持情況 連接收單行主機的支付網(wǎng)關(guān)； 連接有關(guān)中間付款系統(tǒng)的支付網(wǎng)關(guān)； 可以處理不支持SET品牌的請款要求。 （3） 為批請款指派標識 批標識商家、支付網(wǎng)關(guān)、收單行為每個SET交易的一個特定的批請款指派一個標識。有以下兩種方式： 為每一個批請款指定一個數(shù)字； 為每一個批請款的每個項目指定惟一的數(shù)字。,（4） 批請款的訪問 商家、收單行、支付網(wǎng)關(guān)能夠打開一個批請款。 （5） 商家查詢 商家可以向收單行、支付網(wǎng)關(guān)查詢信息。（6） 不支持SET的支付卡品牌的請款處理,3 終端數(shù)據(jù)請款 當商家重新向支付網(wǎng)關(guān)提出以前的授權(quán)交易時，作為交易付款的一個請求，