Internet安全課件講義整理

31十月20221第七章Internet安全22十月20221第七章Internet安全7.1Internet的安全要求Web和電子郵件自身存在的各種問題：Web服務(wù)器對于來自Internet的攻擊顯得十分脆弱。Web服務(wù)器的重要性日益增加。Web服務(wù)器被破壞，除了名譽受損外，經(jīng)濟上也會遭受損失。Web服務(wù)器底層軟件異乎尋常的復(fù)雜。復(fù)雜的軟件可能隱藏更多的潛在安全問題。Web服務(wù)器有可能成為進攻內(nèi)部網(wǎng)的跳板。沒有經(jīng)過訓(xùn)練的用戶不了解存在的安全風(fēng)險。電子郵件的問題主要是防止欺騙和保證內(nèi)容的隱私性。電子郵件是傳播病毒最快捷的途徑。Return7.1Internet的安全要求Web和電子郵件自身存在的7.2SSL/TLSSSL(SecureSocketLayer)是一個用來保證安全傳輸?shù)腎nternet協(xié)議。該協(xié)議通過在兩個實體(客戶和服務(wù)器)之間提供一個安全通道，來實現(xiàn)數(shù)據(jù)在Internet中傳輸?shù)谋Ｃ苄浴?994年，Netscape公司最先提出了SSL，該協(xié)議目前有三個版本：SSLv2、SSLv3和TLSv1(SSLv3.1)。1995年發(fā)布的SSLv3是主要版本。第三版的設(shè)計經(jīng)過了公開的評論并且吸收了工業(yè)界的意見。1996年Netscape公司將SSL規(guī)范提交給IETF。IETF成立了專門的TLS工作組對SSLv3進行標準化。TLS的第一個正式版本已于1999年發(fā)布，其本質(zhì)上可以看成是SSLv3.1，與SSLv3非常接近并且兼容。

7.2SSL/TLSSSL(SecureSocketL7.2.1SSL結(jié)構(gòu)SSL握手協(xié)議SSL修改密碼協(xié)議SSL告警協(xié)議應(yīng)用層協(xié)議SSL記錄協(xié)議TCPIP7.2.1SSL結(jié)構(gòu)SSL握手協(xié)議SSL修改密碼協(xié)議SS7.2.2SSL會話和SSL連接兩個重要的概念：SSL連接和SSL會話。SSL連接：本質(zhì)上講就是TCP連接，不同之處在于每個連接要與一個SSL會話相關(guān)聯(lián)。SSL會話：是客戶和服務(wù)器之間的關(guān)聯(lián)，會話通過握手協(xié)議來創(chuàng)建。會話定義了加密安全參數(shù)的一個集合，該集合可以被多個SSL連接所共享。在任何一對交互實體之間可能存在多個安全連接，在交互實體之間也可以同時存在多個會話。SSL會話是有狀態(tài)的，主要的狀態(tài)有：當(dāng)前讀和當(dāng)前寫、掛起讀和掛起寫。由握手協(xié)議來協(xié)調(diào)客戶端和服務(wù)器端的會話狀態(tài)。7.2.2SSL會話和SSL連接兩個重要的概念：SSL連接會話狀態(tài)的相關(guān)參數(shù)：會話標識符對方的證書壓縮方法密碼規(guī)范(加密算法，MAC算法及加密屬性)主密鑰(48字節(jié)密鑰)可重用否：一個標志，用于指明該會話是否可以用來初始化一個新的連接。第七章-Internet安全課件連接狀態(tài)的相關(guān)參數(shù)：服務(wù)器端和客戶端隨機數(shù)(連接)服務(wù)器端寫MAC密鑰客戶端寫MAC密鑰服務(wù)器寫密鑰(對稱加密)客戶寫密鑰(對稱加密)初始向量(CBC)序列號(報文；64Bit)連接狀態(tài)的相關(guān)參數(shù)：7.2.3SSL記錄協(xié)議1、記錄協(xié)議的功能和報文格式功能：將上層傳來的數(shù)據(jù)進行分段、壓縮、MAC值計算和加密處理，并添加記錄報頭，然后交給下層協(xié)議；當(dāng)收到下層傳來的數(shù)據(jù)時，進行相反的處理，然后交給上層協(xié)議。記錄協(xié)議為高層提供兩種服務(wù)：機密性服務(wù)和報文鑒別服務(wù)。SSL可為多種TCP/IP應(yīng)用提供基本安全服務(wù)。(IANA)已經(jīng)為具備SSL功能的應(yīng)用分配了固定端口號，例如，帶SSL的HTTP(https)被分配的端口號為443，帶SSL的SMTP(ssmtp)被分配的端口號為465，帶SSL的NNTP(snntp)被分配的端口號為563。7.2.3SSL記錄協(xié)議1、記錄協(xié)議的功能和報文格式記錄協(xié)議報文格式如圖所示內(nèi)容類型(8比特)，高層協(xié)議：修改密碼規(guī)范、告警、握手和應(yīng)用數(shù)據(jù)。主要版本(8比特)次要版本(8比特)壓縮長度(16比特)數(shù)據(jù)MAC字段內(nèi)容類型主要版本次要版本壓縮長度數(shù)據(jù)(可選壓縮)MAC(0,16,20字節(jié))報文首部加密部分記錄協(xié)議報文格式如圖所示內(nèi)容類型主要版本次要版本壓縮長度2、記錄層報文的產(chǎn)生過程應(yīng)用數(shù)據(jù)分段壓縮計算MAC加密添加首部2、記錄層報文的產(chǎn)生過程應(yīng)用數(shù)據(jù)分段壓縮計算MAC加密添加首允許使用的加密算法：

分組密文流密文算法密鑰長度算法密鑰長度IDEA128RC4-4040RC2-4040RC4-128128DES-4040DES563DES168Fortezza80允許使用的加密算法：分組密文流密文算法密鑰長度算法密鑰長度7.2.4SSL修改密碼協(xié)議與告警協(xié)議1、修改密碼協(xié)議

修改密碼協(xié)議是使用SSL記錄協(xié)議的三個SSL有關(guān)協(xié)議之一，目的是使掛起狀態(tài)被復(fù)制到當(dāng)前狀態(tài)，改變了這個連接將要使用的密碼算法。這個協(xié)議由單個報文組成，而報文又由值為1的單個字節(jié)組成。2、告警協(xié)議

告警協(xié)議是用來將SSL有關(guān)的告警傳送給對方實體。和其他使用SSL的應(yīng)用一樣，告警報文按照當(dāng)前狀態(tài)被壓縮和加密。該協(xié)議的每個報文由兩個字節(jié)組成。第一個字節(jié)為告警級別(警告和致命)。第二個字節(jié)包含了指出特定告警的代碼。如果級別是致命的，SSL將立刻終止該連接，但同一會話的其他連接可以繼續(xù)，但該會話不能再建立新的連接了。7.2.4SSL修改密碼協(xié)議與告警協(xié)議1、修改密碼協(xié)議7.2.5SSL握手協(xié)議握手協(xié)議的功能和報文格式握手協(xié)議用來協(xié)商會話的安全屬性。握手協(xié)議產(chǎn)生的報文作為記錄層的數(shù)據(jù)，按照當(dāng)前活動會話的狀態(tài)被封裝、處理和傳輸。握手協(xié)議的功能主要包括：服務(wù)器與客戶間的相互身份鑒別；協(xié)商加密和MAC算法；交換加密密鑰。握手協(xié)議由一組在客戶和服務(wù)器之間交換的報文組成。握手協(xié)議報文由三個字段組成：類型(1字節(jié))；長度(3字節(jié)；字節(jié)為單位)；內(nèi)容(≥1字節(jié))(P174-177)Return7.2.5SSL握手協(xié)議握手協(xié)議的功能和報文格式Retur7.3S-HTTP7.3S-HTTP7.3.1HTTP介紹7.3.1HTTP介紹2、報文結(jié)構(gòu)HTTP有兩類報文：請求報文和響應(yīng)報文。方法URI版本請求行空格回車換行首部字段名：值首部字段名：值實體主體首部行版本狀態(tài)碼短語狀態(tài)行首部字段名：值首部字段名：值實體主體首部行請求報文響應(yīng)報文2、報文結(jié)構(gòu)HTTP有兩類報文：請求報文和響應(yīng)報文。方法URHTTP請求報文典型的HTTP請求報文如下：GET/PUBLIC/docu.htmlHTTP/1.1（請求行）Connection：close（首部行）User-agent：Mozilla/4.0Accept：text/html，audio/base，image/gif，video/mpegAccept-language：en（空行）HTTP請求報文典型的HTTP請求報文如下：HTTP響應(yīng)報文典型的HTTP響應(yīng)報文如下：HTTP/1.1200OK（狀態(tài)行）Connection：Close（從這行開始的6行都是首部行）Date：Wed，16Oct200212:36:15GMTServer：Apache/1.3.0(Unix)Last-Modified：Mon，11Aug200210:30:28GMTContent-Length：5963（文件長度的字節(jié)數(shù)）Content-Type：text/html（空行）DATADATADATA…（所請求的文件）HTTP響應(yīng)報文典型的HTTP響應(yīng)報文如下：7.3.2S-HTTP基本原理7.3.2S-HTTP基本原理1、S-HTTP消息的創(chuàng)建S-HTTP包括消息首部和加密消息主體，消息首部中可能包含了指示接收者應(yīng)如何解釋消息主體以及此后接收者應(yīng)該怎樣執(zhí)行消息主體的信息。消息發(fā)送者：客戶端/服務(wù)器。S-HTTP消息的創(chuàng)建需要以下信息：明文消息接收者支持的加密方法和密鑰素材發(fā)送者支持的加密方法和密鑰素材發(fā)送者將自己支持的加密方法和接收者支持的加密方法綜合在一起，形成雙方支持的加密方法和相關(guān)密鑰素材表，通過使用這些數(shù)據(jù)，發(fā)送者可以將明文消息轉(zhuǎn)換成S-HTTP消息。1、S-HTTP消息的創(chuàng)建S-HTTP包括消息首部和加密消息2、S-HTTP消息的恢復(fù)S-HTTP消息的恢復(fù)過程需要以下信息：S-HTTP消息接收者先前聲明所支持的加密方法和密鑰素材。接收者目前支持的加密方法和密鑰素材發(fā)送者先前聲明所支持的加密方法和密鑰素材為了恢復(fù)一個S-HTTP消息，接收者需要閱讀該消息的首部，以確定發(fā)送者對消息主體進行的密碼操作，然后對消息進行解密恢復(fù)出明文。2、S-HTTP消息的恢復(fù)S-HTTP消息的恢復(fù)過程需要以下3、S-HTTP的安全機制S-HTTP協(xié)議對消息的保護主要分為三個方面：消息簽名、消息鑒別和消息加密，一個S-HTTP消息可以被簽名、鑒別、加密或三者的任意組合，當(dāng)然也包括與HTTP兼容的明文傳輸方式。S-HTTP提供了多種密鑰管理機制S-HTTP安全機制的要點：簽名(將證書或證書鏈附加在消息中傳給對方)密鑰交換和加密(Inband公鑰,Outband秘密密鑰；對稱加密)消息完整性和發(fā)送者鑒別(MAC,MD2;MD5;SHA)challenge-response機制(防止重放攻擊)3、S-HTTP的安全機制S-HTTP協(xié)議對消息的保護主要分4、S-HTTP的協(xié)商內(nèi)容S-HTTP標準允許通信的雙方表達他們的請求或偏好，根據(jù)實現(xiàn)能力和特殊的申請請求作出合適的選擇。S-HTTP用協(xié)商首部來傳送權(quán)限和請求。下面給出了常用的協(xié)商首部字段：SHTTP-Certificate-Types字段：指出所接收的證書類型。(X.509)SHTTP-Key-Exchange-Algorithms字段：指出密鑰交換算法。(in-band、out-band)SHTTP-Signature-Algorithms字段：指出數(shù)字簽名算法。(RSA、DSS)SHTTP-Message-Digest-Algorithms字段：指出報文摘要算法。(MD5、SHA)SHTTP-Symmetric-Content-Algorithms字段：指出對稱加密算法。(DES、3DES、RC4)4、S-HTTP的協(xié)商內(nèi)容S-HTTP標準允許通信的雙方表達7.3.3S-HTTP的報文格式S-HTTP消息報文的格式與HTTP是相同的，即都是由一個請求行/狀態(tài)行、后面跟首部行和一個實體部分，所不同的是首部的內(nèi)容范圍及實體部分在典型情況下是加密的。1、請求行：為了區(qū)分S-HTTP報文、HTTP報文和所允許的特殊處理，請求行使用了特殊的安全方法“Secure”和協(xié)議標識符“Secure-HTTP/1.4”。S-HTTP和HTTP進程都使用相同的TCP端口號80。為了防止敏感信息的泄露，請求URI將由“*”替代，請求行的例子如下：Secure*Secure-HTTP/1.42、狀態(tài)行：S-HTTP響應(yīng)使用協(xié)議標識符“Secure-HTTP/1.4”。狀態(tài)行的例子如下：Secure-HTTP/1.4200OK3、首部行：S-HTTP定義了一系列新首部行。7.3.3S-HTTP的報文格式S-HTTP消息報文的格式Content-type：message/http表明S-HTTP報文封裝的是HTTP消息。Content-type：application/s-http表明S-HTTP報文封裝的是非HTTP數(shù)據(jù)。Content-Privacy-Domain首部行有兩個取值：CMS或MOSS。CMS是英文“CryptographicMessageSyntaxStandard”的縮寫，是一種類似于PEM標準的加密消息封裝格式。MOSS是英文“MIMEObjectSecurityServices”的縮寫，指明消息實體中攜帶的是MIME兼容消息。Prearranged-Key-Info首部行指明密鑰交換方法，取值有：Inband,Outband。MAC-Info首部行說明用于消息鑒別碼計算的散列函數(shù)和共享密鑰。S-HTTP報文格式的詳細描述可以參閱RFC-2660ReturnContent-type：message/http表明S-H7.4安全電子交易(SET)7.4.1概述

7.4.2SET的商業(yè)需求和主要特點

7.4.3SET協(xié)議中的參與者和交易事件序列

7.4.4雙重簽名

7.4.5支付處理

Return7.4安全電子交易(SET)7.4.1概述Return7.4.1概述安全電子交易(SecureElectronicTransaction，SET)是設(shè)計用來保護Internet上信用卡交易的安全協(xié)議。版本SETv1是在1996年2月根據(jù)MasterCard和Visa安全標準需要設(shè)計的。SET本身不是一個支付系統(tǒng)。而是一個安全協(xié)議和格式的集合，它使得用戶可以以一種安全的方式，將已經(jīng)存在的信用卡支付基礎(chǔ)設(shè)施配置在開放網(wǎng)絡(luò)(例如Internet)上。SET協(xié)議工作在應(yīng)用層。從本質(zhì)上講，SET提供了三種服務(wù)：在交易涉及的各方之間提供安全的通信信道。通過使用X.509v3數(shù)字證書來提供信任。保證機密性，信息只是在必要的時候、必要的地方才對交易各方可用。

Return7.4.1概述安全電子交易(SecureElectro7.4.2SET的商業(yè)需求和主要特點了解SET協(xié)議首先要了解它的商業(yè)背景和主要特點。1、商業(yè)需求在開放網(wǎng)絡(luò)上使用支付卡進行安全支付處理的商業(yè)需求：保證訂購信息和支付信息的機密性。保證所有傳輸數(shù)據(jù)的完整性。對卡的擁有者進行鑒別。對商家是否可以接受支付卡交易進行鑒別。使用最好的安全策略和系統(tǒng)設(shè)計技術(shù)來保護電子商務(wù)交易中的所有合法方。創(chuàng)建既不依賴于運輸層安全機制又不阻止它們使用的協(xié)議。7.4.2SET的商業(yè)需求和主要特點了解SET協(xié)議首先要了2、SET協(xié)議的特點：(1)信息機密性：必須確保持卡人的賬號和支付信息在通過網(wǎng)絡(luò)傳輸時的安全性。(2)數(shù)據(jù)完整性：SET協(xié)議保證信息內(nèi)容在傳輸過程中不被修改。(3)持卡人賬號的鑒別：SET協(xié)議提供了一種方法來鑒別持卡人是否是有效支付卡帳號的合法用戶。(4)商人的鑒別：SET也提供了持卡人鑒別商家的方法。(5)互操作性：可以在不同的硬、軟件平臺上應(yīng)用該規(guī)范。Return2、SET協(xié)議的特點：Return7.4.3SET協(xié)議中的參與者和交易事件序列1、SET協(xié)議模型中的參與者SET協(xié)議改變了傳統(tǒng)支付系統(tǒng)中參與者之間的相互作用模式。在傳統(tǒng)面對面的零售交易或郵購交易中，電子處理過程開始于商家或收單行。而在SET的交易模型中，電子處理過程則開始于持卡人。SET協(xié)議模型中的參與者包括如下成員：(1)持卡人(2)發(fā)卡行(3)商家(4)收單行(5)支付網(wǎng)關(guān)(6)證書管理機構(gòu)(CA)7.4.3SET協(xié)議中的參與者和交易事件序列1、SET協(xié)議SET協(xié)議模型中的參與者Internet支付網(wǎng)絡(luò)證書管理機構(gòu)發(fā)卡行持卡人收單行支付網(wǎng)關(guān)商家SET協(xié)議模型中的參與者Internet支付網(wǎng)絡(luò)證書管理機構(gòu)2、交易事件序列(1)消費者申請支付卡(成為持卡人)(2)消費者獲得電子身份證書(3)商家獲得電子身份證書(兩個證書)(4)消費者提出訂購請求(5)消費者鑒別商家(6)消費者發(fā)送訂購和支付信息(被加密)(7)商家請求支付認可(8)商家確認該項訂購(9)商家提供貨物或服務(wù)(10)商家請求支付Return2、交易事件序列Return7.4.4雙重簽名在介紹SET協(xié)議的細節(jié)之前，先討論SET協(xié)議引入的一個重要概念：雙重簽名。雙重簽名的目的：是為了連接兩個發(fā)送給不同接收者的報文。通常，消費者要將訂購信息(OI)發(fā)送給商家，將支付信息(PI)發(fā)送給銀行。商家不必知道消費者的信用卡號碼，銀行也不必知道消費者訂單的細節(jié)。但是，這兩個項目必須采用一種必要時可以用來解決爭執(zhí)的方式連接起來。這種連接是必需的，因為消費者可以證明這個支付是用于這次訂購而不是用于其他的貨物或服務(wù)。7.4.4雙重簽名在介紹SET協(xié)議的細節(jié)之前，先討論SET1、雙重簽名的創(chuàng)建PIMD=H(PI);OIMD=H(OI);POMD=H(PIMD||OIMD)DS=EKRc[H(H(PI)||H(OI))]其中PI是支付信息，OI是訂購信息，KRc是消費者的私有密鑰。KRcOIMDPIMDPOMDHOIEPIHH1、雙重簽名的創(chuàng)建KRcOIMDPIMDPOMDHOIEPI2、雙重簽名的驗證商家驗證雙重簽名：商家獲得了雙重簽名(DS)、OI、PI的報文摘要(PIMD)以及從消費者證書中取得消費者的公開密鑰KUc后。商家可以計算下面兩個數(shù)值：

H(PIMD||H(OI))和DKUc[DS]其中KUc是消費者的公開密鑰。如果這兩個數(shù)值相等，商人就驗證了該雙重簽名。銀行驗證雙重簽名：銀行獲得了DS、PI、OI的報文摘要(OIMD)以及消費者的公開密鑰KUc后，銀行可以計算下面兩個數(shù)值：H(H(PI)||OIMD)和DKUc[DS]如果這兩個數(shù)值相等，銀行就驗證了該雙重簽名。2、雙重簽名的驗證3、雙重簽名的使用(1)商家收到OI并通過驗證雙重簽名來鑒別OI信息。(2)銀行收到PI并通過驗證雙重簽名來鑒別PI信息。(3)消費者將OI和PI連接起來并且能夠證明這種連接關(guān)系。假設(shè)商家為了自己的利益，想要在這個交易中用另一個OI來冒充，就必須找到另一個OI，其散列碼與現(xiàn)有OIMD相匹配，這在計算上是不可行的。因此，商家不能將另一個OI與這個PI相連接。Return3、雙重簽名的使用Return7.4.5支付處理1、SET支持的交易類型持卡人注冊，商家注冊(向CA注冊)；購買請求，支付認可(檢驗持卡人卡賬號的支付能力)，支付獲取(商家向支付網(wǎng)關(guān)請求支付)；證書調(diào)查和狀態(tài)，購買調(diào)查(持卡人檢查訂購處理的狀態(tài))，認可撤消(商家更正以前的認可請求)，獲取撤消(商家糾正獲取請求中的差錯)，退款，退款撤消，支付網(wǎng)關(guān)證書請求等。這里將重點討論購買請求、支付認可和支付獲取三種交易類型的細節(jié)。7.4.5支付處理1、SET支持的交易類型2、參與者證書說明在SET協(xié)議中，處于Internet環(huán)境的參與者有持卡人、商家和支付網(wǎng)關(guān)，為了證明自己的身份，它們必須從所屬的CA處獲得證書。持卡人證書：CA在向持卡人頒發(fā)證書時，要求持卡人提供帳戶信息并通過發(fā)卡行進行驗證。如果信息屬實且符合條件，CA將生成持卡人帳戶信息摘要(HMAC)并嵌入證書中。商家證書：商家在向CA申請證書前，必須先要與收單行建立委托關(guān)系。CA在受理商家的證書申請后，通過收單行進行驗證。如果信息屬實且符合條件，CA將向商家頒發(fā)證書。商家通常需要兩個證書：簽名證書和密鑰交換證書。支付網(wǎng)關(guān)證書：支付網(wǎng)關(guān)通常需要兩個證書：簽名證書和密鑰交換證書。2、參與者證書說明3、購買請求初始階段：持卡人進行商品的瀏覽、選擇和訂購后，商家將完整的訂購表格發(fā)送給消費者，初始階段是在不使用SET協(xié)議的情況下進行的。購買請求階段：需要交換四個報文(發(fā)起請求、發(fā)起響應(yīng)、購買請求和購買響應(yīng))。卡用戶商家支付網(wǎng)關(guān)發(fā)卡行發(fā)起請求發(fā)起響應(yīng)購買請求購買響應(yīng)認可請求認可響應(yīng)認可請求認可響應(yīng)獲取請求獲取響應(yīng)清算請求請算響應(yīng)3、購買請求卡商支發(fā)發(fā)起請求發(fā)起響應(yīng)購買請求購買響應(yīng)認可請求發(fā)起請求報文：(卡用戶→商家)目的：請求商家和支付網(wǎng)關(guān)的證書(身份鑒別)。明文傳輸。報文主要內(nèi)容： {請求/響應(yīng)對ID、現(xiàn)時C、信用卡商標、發(fā)卡行標識}發(fā)起響應(yīng)報文：(商家→卡用戶)商家生成響應(yīng)，并用自己的私有密鑰對其簽名。報文主要內(nèi)容： {請求/響應(yīng)對ID、現(xiàn)時C、現(xiàn)時M、交易ID、商家簽名證書、支付網(wǎng)關(guān)密鑰交換證書}發(fā)起請求報文：(卡用戶→商家)購買請求：(卡用戶→商家)

收到響應(yīng)報文后，卡用戶通過相應(yīng)的CA簽名來驗證商家證書(簽名證書)和網(wǎng)關(guān)證書(密鑰交換證書)。然后檢驗報文的合法性。創(chuàng)建OI和PI(商家賦予的交易ID被放在OI和PI中)。OI中并不包含明顯的訂購數(shù)據(jù)，如貨物的數(shù)量和價格。它包含了在交換SET報文之前購物階段期間，商家和消費者之間交換時生成的訂購的引用。接下來，卡用戶準備購買請求報文。為了這個目的，卡用戶生成了一次性的對稱加密密鑰KS。購買請求：(卡用戶→商家)雙簽名KUbOIMDPIMDEOIPIEKs數(shù)字信封雙簽名用戶證書請求報文KUb：支付網(wǎng)關(guān)的公鑰Ks：會話密鑰雙簽名KUbOIMDPIMDEOIPIEKs數(shù)字信封雙購買響應(yīng)：(商家→卡用戶)

商人收到了購買請求報文后，進行如下處理：驗證卡用戶的證書。(簽名證書)使用消費者證書中的公開密鑰來驗證雙重簽名。處理訂購信息，并將支付信息轉(zhuǎn)交給支付網(wǎng)關(guān)。(支付認可)向卡用戶發(fā)送購買響應(yīng)報文。購買響應(yīng)：(商家→卡用戶)商家驗證消費者的購買請求

POMDKUcPOMDPIMDHOI數(shù)字信封雙簽名用戶證書請求報文HD比較將被商家發(fā)送到支付網(wǎng)關(guān)商家驗證消費者的購買請求POMDKUcPOMDPIMDHO購買響應(yīng)報文包括：響應(yīng)塊響應(yīng)塊簽名商家的簽名證書。該響應(yīng)塊確認訂購并且引用了相應(yīng)的交易號碼。商家使用簽名證書的私有密鑰對響應(yīng)塊進行簽名。當(dāng)持卡人的軟件收到了購買響應(yīng)報文時，它驗證商家的簽名證書，然后驗證響應(yīng)塊上的簽名?；陧憫?yīng)報文采取動作(顯示消息,修改數(shù)據(jù)庫訂購狀態(tài))。購買響應(yīng)報文包括：4、支付認可在收到來自持卡人的購買請求后，如果證書和雙簽名驗證通過，在向持卡人發(fā)送購買響應(yīng)報文之前，商家要請求支付網(wǎng)關(guān)認可該項交易。支付認可將保證交易得到了發(fā)卡行的批準，且保證商家可以得到支付。支付認可由兩個報文組成：認可請求和認可響應(yīng)。在完成支付認可過程后，商家才決定是否向卡用戶發(fā)購買響應(yīng)報文。4、支付認可認可請求：(商家→支付網(wǎng)關(guān)) 商家向支付網(wǎng)關(guān)發(fā)送一個認可請求報文，該報文由以下幾個部分組成：(1)與購買有關(guān)的信息：(來自消費者)PI：支付信息。雙重簽名DS：用消費者的私有密鑰簽名。OI報文摘要(OIMD)數(shù)字信封：封裝會話密鑰。(2)認可有關(guān)的信息：(由商家生成)認可數(shù)據(jù)塊：包括一個使用商家私有密鑰簽名的，并且使用商家生成的一次性對稱密鑰加密的交易ID。數(shù)字信封：通過使用支付網(wǎng)關(guān)密鑰交換證書中的公開密鑰對一次性對稱密鑰進行加密形成。

(3)證書：包括卡用戶簽名密鑰證書和商家簽名密鑰證書和商家密鑰交換證書。

用會話密鑰加密認可請求：(商家→支付網(wǎng)關(guān))用會話密鑰加密支付網(wǎng)關(guān)在收到商家發(fā)來的認可請求報文后，完成下面一些任務(wù)：驗證所有的證書。(用戶簽名證書、商家簽名證書、商家密鑰交換證書)用私鑰解密認可數(shù)據(jù)塊的數(shù)字信封以獲得對稱密鑰，然后解密認可數(shù)據(jù)塊。驗證認可數(shù)據(jù)塊中商家的簽名。用私鑰解密支付數(shù)據(jù)塊的數(shù)字信封以獲得對稱密鑰，然后解密支付數(shù)據(jù)塊(PI，DS，OIMD)。驗證支付數(shù)據(jù)塊的雙重簽名。驗證從商家那里收到的交易ID與從消費者那里收到的PI中的交易ID是否匹配。向發(fā)卡行請求和接收一個認可。支付網(wǎng)關(guān)在收到商家發(fā)來的認可請求報文后，完成下面一些任務(wù)：POMDKUcPOMDOIMDHPI數(shù)字信封雙簽名用戶證書認可請求HD比較數(shù)字信封認可數(shù)據(jù)塊商家密鑰證書商家簽名證書DKRbDKs2鑒別支付數(shù)據(jù)塊POMDKUcPOMDOIMDHPI數(shù)字信封雙簽名用戶證書認

認可響應(yīng)(支付網(wǎng)關(guān)→商家)從發(fā)卡行獲得了認可之后，支付網(wǎng)關(guān)向商家返回認可響應(yīng)報文。它包括如下內(nèi)容：與認可有關(guān)的信息。認可數(shù)據(jù)塊，使用支付網(wǎng)關(guān)的私有簽名密鑰進行簽名，并且使用支付網(wǎng)關(guān)生成的一次性對稱密鑰進行加密。數(shù)字信封，該數(shù)字信封使用商家密鑰交換證書中的公開密鑰對一次性對稱密鑰進行加密形成。獲取權(quán)標信息，這個信息將影響以后的支付。該數(shù)據(jù)塊的形式與認可數(shù)據(jù)塊相同，即簽名并加密的獲取權(quán)標加上數(shù)字信封。證書，支付網(wǎng)關(guān)的簽名證書。認可響應(yīng)(支付網(wǎng)關(guān)→商家)商家收到來自支付網(wǎng)關(guān)的認可響應(yīng)報文后，完成如下工作：驗證支付網(wǎng)關(guān)的簽名證書。用商家密鑰交換證書中的私鑰解密數(shù)字信封獲得對稱密鑰并解密認可響應(yīng)數(shù)據(jù)。用支付網(wǎng)關(guān)簽名證書中的公鑰驗證認可數(shù)據(jù)塊中的簽名。保存加密的獲取權(quán)標信息和對應(yīng)的數(shù)字信封，之后的支付獲取過程要用到這些信息。商家這時可以按照持卡人定單的要求提供貨物或服務(wù)了。

商家收到來自支付網(wǎng)關(guān)的認可響應(yīng)報文后，完成如下工作：5、支付獲取支付獲取由獲取請求和獲取響應(yīng)報文組成。獲取請求(商家→支付網(wǎng)關(guān))獲取請求報文包含商家生成、簽署并加密的獲取請求數(shù)據(jù)塊。該數(shù)據(jù)塊中包括了支付的數(shù)量和交易ID。獲取請求報文還包括以前收到的關(guān)于這個交易的加密的獲取權(quán)標(在認可響應(yīng)中)。商家的簽名證書和密鑰交換證書。5、支付獲取當(dāng)支付網(wǎng)關(guān)收到了獲取請求報文后：解密并驗證獲取請求數(shù)據(jù)塊。解密并驗證獲取權(quán)標塊。檢查獲取請求和獲取權(quán)標的一致性。創(chuàng)建清算請求并通過私有支付網(wǎng)絡(luò)發(fā)送給發(fā)卡行，這個請求引起資金被劃撥到商家的賬戶中(清算響應(yīng))。支付網(wǎng)關(guān)在獲取響應(yīng)報文中通知商家支付情況。獲取響應(yīng)報文包括由支付網(wǎng)關(guān)簽名和加密的獲取響應(yīng)數(shù)據(jù)塊。報文還包括支付網(wǎng)關(guān)的簽名證書。商家的軟件將這個獲取響應(yīng)保存下來，用于同從獲得者(收單行)那里接收的支付相匹配。當(dāng)支付網(wǎng)關(guān)收到了獲取請求報文后：SET協(xié)議的報文交互卡用戶商家支付網(wǎng)關(guān)發(fā)卡行發(fā)起請求發(fā)起響應(yīng)購買請求購買響應(yīng)認可請求認可響應(yīng)認可請求認可響應(yīng)獲取請求獲取響應(yīng)清算請求請算響應(yīng)ReturnSET協(xié)議的報文交互卡商支發(fā)發(fā)起請求發(fā)起響應(yīng)購買請求購買響應(yīng)7.5電子郵件的安全性電子郵件是因特網(wǎng)上使用最多的網(wǎng)絡(luò)應(yīng)用之一，也是惟一在所有網(wǎng)絡(luò)結(jié)構(gòu)和廠家平臺上被廣泛支持的分布式應(yīng)用。電子郵件面臨的安全問題可分為兩類：電子郵件自身的安全：存在郵件的假冒、篡改和竊聽?？赏ㄟ^鑒別和加密等安全機制解決。網(wǎng)絡(luò)的電子郵件應(yīng)用已經(jīng)成為網(wǎng)絡(luò)安全的薄弱環(huán)節(jié)，許多計算機病毒或其他惡意代碼，通過電子郵件進入內(nèi)部網(wǎng)，造成巨大危害。7.5電子郵件的安全性電子郵件是因特網(wǎng)上使用最多的網(wǎng)絡(luò)應(yīng)本節(jié)主要討論電子郵件自身的安全問題。用來保護電子郵件安全的因特網(wǎng)協(xié)議主要有三種：PEM(PrivacyEnhancedMail)：由IETF組織開發(fā)，用于因特網(wǎng)環(huán)境的安全郵件系統(tǒng)。具有數(shù)據(jù)加密、源點鑒別和完整性保護功能。PGP(PrettyGoodPrivacy)：主要由PhilZimmermann開發(fā)，是自由軟件。PGP提供了電子郵件機密性和鑒別的服務(wù)，可以用于電子郵件和文件存儲應(yīng)用。S/MIME(Secure/MultipurposeInternetMailExtension)安全通用Internet郵件擴展本節(jié)主要討論電子郵件自身的安全問題。7.5電子郵件的安全性7.5.1PGP加密軟件

PGP概述

PGP基本服務(wù)描述

PGP密鑰管理7.5.2S/MIME

MIME介紹

S/MIME的功能

S/MIME報文

7.5電子郵件的安全性7.5.1PGP加密軟件PGP概述PGP的最初版本是由PhilZimmermann開發(fā)的并作為共享軟件在網(wǎng)上發(fā)表，后經(jīng)網(wǎng)上各國程序員的不斷完善形成了現(xiàn)在的PGP加密軟件版本。PGP加密軟件為電子郵件應(yīng)用提供了機密性和鑒別服務(wù)，并可用于文件的存儲。PGP加密軟件所采取的措施主要有：選擇經(jīng)過考驗的、無專利問題困擾的加密算法作為基礎(chǔ)構(gòu)件。將所選算法有機地整合在一起，形成可靠的整體安全性。使軟件易于移植，易于使用。為了在網(wǎng)上發(fā)布，并免費提供給用戶使用，制作了包括源代碼的軟件包和相關(guān)文檔。與商業(yè)公司合作，為需要服務(wù)的用戶提供與免費PGP完全兼容的、低價格商用版本。PGP概述PGP的最初版本是由PhilZ由于采取了上述措施，PGP發(fā)展的非常迅速，已被廣泛應(yīng)用。這為具有相同想法的人提供了一個很好的借鑒。PGP成功的原因可以概括如下：作為Internet上的共享軟件，在世界范圍內(nèi)可以免費得到。軟件包括能在不同平臺上運行的多個版本。另外，低價的商用版本滿足了那些想要獲得廠家技術(shù)支持的用戶的需要。使用經(jīng)過實踐檢驗、成熟的安全算法。如RSA、DSS和Diffie-Hellman公鑰算法；CAST-128、IDEA和3DES常規(guī)加密算法；以及散列算法SHA-1。應(yīng)用范圍廣?？捎糜谖募用芎途W(wǎng)上信息的安全傳輸。公司、組織和個人都可使用。不屬于任何政府或組織。

Return由于采取了上述措施，PGP發(fā)展的非常迅速，已被廣泛應(yīng)用。這為PGP基本服務(wù)描述PGP提供五種基本服務(wù)：鑒別機密性壓縮電子郵件的兼容性分段PGP基本服務(wù)描述PGP提供五種基本服務(wù)：鑒別：(RSA和SHA-1、DSS和SHA-1)KRaHMEZZ-1MDHKUa比較源點A終點B鑒別：(RSA和SHA-1、DSS和SHA-1)KRaHME機密性:EPMECZZ-1MDPKRb源點A終點BKsDCKsKUbEPMECZZ-1MDPKRb源點A終點BKsDCKsKUb機密性與鑒別結(jié)合：先簽名，后加密。EPMECZZ-1DPKRb源點A終點BKsDCKsKUbKRaHEMHDKUa比較機密性與鑒別結(jié)合：先簽名，后加密。EPMECZZ-1DPKR壓縮：默認情況下，在簽名之后加密之前，PGP對報文進行壓縮，這樣做可以節(jié)約存儲空間。這里要注意的是壓縮算法的放置位置，可能的位置有簽名前壓縮和簽名后壓縮(一般簽名后壓縮)。在壓縮之后對報文加密可以增加加密的強度。因為壓縮過的報文比原始明文冗余更少，密碼分析更加困難。PGP使用的壓縮算法是ZIP。壓縮：4.電子郵件的兼容性使用PGP時，至少傳輸報文的一部分需要被加密:如果只使用簽名服務(wù)，那么報文摘要被加密。如果使用機密性服務(wù)，報文加上簽名(如果存在)被加密。因此，部分或全部的結(jié)果報文由任意的8bit字節(jié)流組成。但由于歷史的原因，目前很多電子郵件系統(tǒng)只轉(zhuǎn)發(fā)由ASCII正文組成的報文。為了解決這個問題，PGP提供了轉(zhuǎn)換服務(wù)。采用的方案：對PGP軟件的輸出進行radix-64轉(zhuǎn)換，每三個字節(jié)的二進制數(shù)據(jù)為一組映射成四個ASCII字符。作為選項，PGP可以配置成只將報文的簽名部分轉(zhuǎn)換成radix-64的格式，這樣可使接收報文的人不使用PGP就能閱讀報文。但必須使用PGP才能驗證簽名。4.電子郵件的兼容性第七章-Internet安全課件轉(zhuǎn)換舉例：假設(shè)有24位原始正文序列如下：輸入:001000110101110010010001001000110101110010010001 8 535017 I1yR輸出：01001001001100010111100101010010第七章-Internet安全課件5、分段和重組由于歷史的原因，電子郵件設(shè)施經(jīng)常會限制最大報文長度。例如：很多Internet可訪問設(shè)施有最大報文長度50000個字節(jié)的限制。任何超長的報文都必須劃分成更小的報文段單獨發(fā)送，否則將拒收超長的郵件報文。為了滿足這個限制，PGP自動將超長的報文劃分成合格的報文段。分段是在所有其他處理(包括radix-64轉(zhuǎn)換)完成之后進行的，這樣會話密鑰和簽名部分只在第一個報文段的開始位置出現(xiàn)一次。在接收端，PGP必須在解密步驟之前剝掉所有郵件的附加首部，并重新裝配成原來完整的報文。5、分段和重組發(fā)送流程：X←文件需要簽名嗎？需要加密嗎？壓縮X←Z(X)編碼X←R64(X)生成簽名X←簽名||X加密X←EKUb[Ks]||Ks[X]

YYNNReturn分段發(fā)送流程：X←文件需要簽名嗎？需要加密嗎？壓縮編碼生成簽名加PGP密鑰管理

PGP使用四種類型的密鑰：會話密鑰：加密報文。接收者的公開密鑰：加密一次性常規(guī)密鑰。發(fā)送者的私有密鑰：對報文散列值簽名?；诳诹畹某Ｒ?guī)密鑰：加密發(fā)送者存儲的私有密鑰。會話密鑰的生成：由隨機數(shù)產(chǎn)生器生成128位隨機數(shù)(2個64位的明文分組)，和預(yù)先選定的128位密鑰一起作為指定加密算法的輸入，產(chǎn)生的128位密文即為一次性會話密鑰。目的是產(chǎn)生不可預(yù)測的密鑰序列。PGP密鑰管理PGP使用四種類型的密鑰：公開/私有密鑰對的管理問題：允許用戶擁有多個公開/私有密鑰對。管理方法：

密鑰標識：為每個公開/私有密鑰對中的公開密鑰指派一個密鑰ID，該密鑰ID由公開密鑰的最低64位構(gòu)成，即KUmod264。

私有密鑰環(huán)：是一張表，用來存儲發(fā)送者的公開/私有密鑰對。其中的私有密鑰被加密。可使用用戶ID或密鑰ID進行索引。

公開密鑰環(huán)：也是一張表，用來存儲接收者的公開密鑰?？墒褂糜脩鬒D或密鑰ID進行索引。公開/私有密鑰對的管理存儲私有密鑰時的加密：口令→散列碼→密鑰

當(dāng)系統(tǒng)生成新的公開/私有密鑰對時，要求用戶輸入口令。 系統(tǒng)使用SHA-1散列算法生成該口令的160位散列碼，然后丟棄該口令。 系統(tǒng)使用160位散列碼中的128位作為密鑰，對私有密鑰進行加密，然后丟棄該散列碼。接收者公開密鑰的獲得：物理的方法、共同信任的第三方、數(shù)字證書。存儲私有密鑰時的加密：口令→散列碼→密鑰PGP報文的一般格式：數(shù)字信封簽名報文摘要的前兩個八位組接收者公開密鑰KUb的密鑰ID加密的一次性密鑰EKUb[Ks]時間戳報文摘要文件名發(fā)送者公開密鑰KUa的密鑰ID時間戳數(shù)據(jù)報文壓縮加密R64EKRaPGP報文的一般格式：數(shù)字信封簽名報文摘要的前接收者公開密鑰發(fā)送方：

簽名報文：使用用戶ID作為索引從私有密鑰環(huán)中查找發(fā)送者的私有密鑰；輸入口令解密私有密鑰；構(gòu)造報文簽名。

加密報文：生成一次性密鑰加密報文；使用接收者的用戶ID在公開密鑰環(huán)中索引，找出接收者的公開密鑰；構(gòu)造數(shù)字信封。發(fā)送方：接收方：

解密報文：使用報文數(shù)字信封部分的密鑰ID作為索引，從私有密鑰環(huán)中查找接收者的私有密鑰；輸入口令恢復(fù)私有密鑰；利用私有密鑰恢復(fù)Ks利用Ks解密報文。

鑒別報文：使用報文簽名部分的密鑰ID作為索引，從公開密鑰環(huán)中查找發(fā)送者的公開密鑰；恢復(fù)傳輸?shù)膱笪恼?；計算報文摘要比對鑒別。Return接收方：Return7.5.2S/MIMES/MIME(Secure/MultipurposeInternetMailExtension)是MIME電子郵件標準在安全方面的擴充，用來保護電子郵件的安全。S/MIME所提供的安全服務(wù)：報文鑒別、報文機密性和不可抵賴。S/MIME除了用于保護電子郵件外，還可以用于其他利用MIME進行傳輸?shù)膮f(xié)議(如HTTP)。S/MIME與上一節(jié)介紹的PGP之間的區(qū)別在于S/MIME繼承了MIME多用途的特點。Return7.5.2S/MIMES/MIME(Secure/MulMIME介紹1、RFC822RFC822定義了使用電子郵件發(fā)送正文報文的格式。RFC822標準中，報文=信封+內(nèi)容。信封包含了完成傳輸和交付的所有信息;內(nèi)容組成了要交付給接收者的對象。內(nèi)容=首部+主體。RFC822規(guī)定了郵件內(nèi)容中的首部(header)格式，而對郵件的主體(body)部分則讓用戶自由撰寫。用戶寫好首部后，郵件系統(tǒng)將自動地將信封所需的信息提取出來并寫在信封上，而用戶不需要填寫電子郵件信封上的信息。首部與主體之間通過一個空行分隔。MIME介紹1、RFC822首部行通常由一個關(guān)鍵詞、一個冒號和關(guān)鍵詞的參數(shù)組成，格式允許長的行被分割成多個行。最常用的關(guān)鍵詞是From，To，Subject和Date。一個例子：Date：Tue，16Jan200410:37:17(EST)From：“xyz”<xyz@>Subject：TheSyntaxinRFC822TO：abc@CC：def@Hello．ThisSectionbeginstheactualmessagebody，whichisdelimitedfromthemessageheadingbyablankline．在RFC822首部經(jīng)常發(fā)現(xiàn)的另一個字段是Message-ID，這個字段包含了與此報文相關(guān)聯(lián)的惟一的標識符。首部行通常由一個關(guān)鍵詞、一個冒號和關(guān)鍵詞的參數(shù)組成，格2、MIME概述MIME是對RFC822標準的擴充。目的：解決使用SMTP或其他郵件傳輸協(xié)議傳遞郵件時存在的一些問題和局限，如不能傳輸可執(zhí)行文件或其他二進制對象、不能處理超過一定長度的郵件報文等。MIME標準包括了如下一些內(nèi)容：定義了五個新的、可包含在RFC822報文首部的字段，這些字段提供了有關(guān)報文主體的說明信息。定義了一組內(nèi)容格式，標準化了對多媒體電子郵件的支持。定義了傳送編碼，使得任何格式的內(nèi)容都可以被轉(zhuǎn)換成一種獨立于不同郵件系統(tǒng)的形式。2、MIME概述MIME定義的五個首部字段是：MIME-Version(版本)：指示使用的MIME版本。Content-Type(內(nèi)容類型)：描述了包含在報文主體中的數(shù)據(jù)，使接收報文的用戶代理可以選擇合適的機制為用戶表示數(shù)據(jù)，或者以合適的方法來處理數(shù)據(jù)。Content-Transfer-Encoding(內(nèi)容傳送編碼)：指示轉(zhuǎn)換類型，這種轉(zhuǎn)換可以將報文主體轉(zhuǎn)換成可以進行郵件傳輸?shù)男问?。Content-ID(內(nèi)容ID，可選)：在多個上下文中，用來惟一標識MIME實體的標識符。Content-Description(內(nèi)容描述，可選)：對于報文主體中對象的正文描述，在該對象不可讀的情況下，這個字段非常有用(如音頻、視頻數(shù)據(jù))。MIME定義的五個首部字段是：3、MIME內(nèi)容類型和傳送編碼內(nèi)容類型MIME標準中定義了多種不同的內(nèi)容類型(7個主類型和15個子類型)。主內(nèi)容類型說明了數(shù)據(jù)的一般屬性，而子類型則說明了本種類型數(shù)據(jù)的特定形式。其中Multiparttype(多部分類型)指示報文主體包含了多個獨立的部分。Content-Type首部字段包括了稱為boundary(邊界)的參數(shù)，定義了在報文的不同部分之間的分隔符。每個邊界開始于一個新行，由兩個連字符跟著一個分隔符組成。--xxxx最后一個部分結(jié)束邊界還有兩個連字符作為后綴。--xxxx--在報文主體的每個部分，可以存在可選的普通的MIME首部。3、MIME內(nèi)容類型和傳送編碼第七章-Internet安全課件傳送編碼MIME標準的另一個主要部分是對報文主體傳送編碼的定義，目的是提供跨越大范圍環(huán)境的可靠交付。在所定義的傳送編碼中最常用的是quoted-printable和base64。quoted-printable用來處理主要由可打印ASCII字符組成的8位組數(shù)據(jù)。Base64(也稱為radix-64編碼)是將任意二進制數(shù)據(jù)轉(zhuǎn)換成一種不會被郵件傳輸系統(tǒng)破壞的編碼形式，在PGP中也使用這種方法。Return傳送編碼ReturnS/MIME的功能就一般功能來講，S/MIME與PGP非常類似。兩者都提供了對報文進行簽名和加密的功能。但從整體上看，PGP是以整個郵件為對象進行安全防護，而S/MIME則是滲透到郵件內(nèi)部的安全標準。1、功能目前的S/MIME版本提供了如下安全服務(wù)：

數(shù)據(jù)加密數(shù)據(jù)簽名

純簽名(Clear-signed)

簽名且加密S/MIME的功能就一般功能來講，S/MIM2、S/MIME支持的加密算法散列函數(shù)算法：必須支持MD5和SHA-1；但應(yīng)該使用SHA-1。數(shù)字簽名算法：發(fā)送和接收代理都必須支持DSS算法，應(yīng)該支持RSA算法。密鑰加密算法：發(fā)送和接收代理都必須支持Diffie-Hellman算法，應(yīng)該支持RSA算法。常規(guī)加密算法：發(fā)送代理應(yīng)該支持40bit的RC2算法、128bit的RC2算法和三重DES算法；接收代理應(yīng)該支持128bit的RC2算法和三重DES算法。但符合標準的實現(xiàn)必須支持40bit的RC2，該算法為弱加密算法，符合聯(lián)邦出口控制標準。2、S/MIME支持的加密算法S/MIME定義了發(fā)送和接收方協(xié)商各種加密算法的過程，下面是發(fā)送方代理在決策時使用的規(guī)則：已知能力：如果發(fā)送代理從預(yù)想的接收者那里獲得了解密能力的列表，它應(yīng)該選擇能使用的列表中的第一個(最高優(yōu)先級)能力。未知能力但已知使用了加密：如果發(fā)送代理沒有接收者的能力清單，但曾經(jīng)從接收者哪里收到過加密報文，那么就采用收到的最后一個簽名和加密報文所使用的加密算法對報文進行處理。S/MIME定義了發(fā)送和接收方協(xié)商各種加密算法的過程，下面是未知能力且未知S/MIME版本：如果發(fā)送者以前沒有和接收者進行過安全通信，也不知道對方的能力:如果發(fā)送者愿意冒著接收者可能不能解密報文的危險，那么發(fā)送代理應(yīng)該使用3DES。如果不愿意冒著接收者可能不能解密報文的危險，那么發(fā)送代理必須使用RC2/40。報文需要發(fā)送給多個接收者，但卻不能選擇共同的加密算法．那么發(fā)送代理將需要發(fā)送多個報文。Return未知能力且未知S/MIME版本：如果發(fā)送者以前沒有和接收者進S/MIME報文S/MIME報文由MIME實體和PKCS對象組成，PKCS是RSA實驗室發(fā)布的公開密鑰加密規(guī)約的集合。S/MIME增加了一些新的MIME內(nèi)容類型。所有新的應(yīng)用類型都使用了指定的PKCS對象。S/MIME報文S/MIME報文由MIME實

1、安全化MIME實體安全化MIME實體的一般步驟：S/MIME按照MIME報文準備的一般規(guī)則來準備MIME實體；(一個MIME實體可以是一個完整的報文(除了RFC822首部)；也可以是multipart類型的一個或多個子部分。)將準備好的MIME實體轉(zhuǎn)換成規(guī)范形式，這種轉(zhuǎn)換使得在生成簽名和驗證簽名時惟一地、無二義性地表示該MIME實體。將該MIME實體加上一些與安全有關(guān)的數(shù)據(jù)，如算法標識符和證書，經(jīng)過S/MIME處理生成稱為PKCS的對象。PKCS對象被看作報文內(nèi)容并包裝成MIME(提供合適的MIME首部)。

1、安全化MIME實體2、創(chuàng)建EnvelopedData報文application/pkcs7-mime子類型可用于三類S/MIME處理，每類處理都有惟一的smime類型參數(shù)。準備一個加密的MIME實體的步驟如下：為選定的常規(guī)加密算法(RC2/40或三重組DES)生成會話密鑰。使用會話密鑰加密MIME實體。對每個不同的接收者．使用對應(yīng)的公開RSA密鑰對會話密鑰進行加密(數(shù)字信封)。為每個不同的接收者準備稱為RecipientInfo(接收者信息)的數(shù)據(jù)塊，該塊中包含了發(fā)送者的公開密鑰證書、用來加密會話密鑰算法的標識以及加密的會話密鑰。2、創(chuàng)建EnvelopedData報文生成的加密數(shù)據(jù)放在RecipientInfo塊后(拼接)，使用base64對RecipientInfo塊和加密數(shù)據(jù)進行編碼。簡單的報文例子如下(去掉了RFC822首都)：Content-Type:application/pkcs7-mime;smime-type=enveloped-data;name=smime.p7mContent-Transfer-Encoding:base64Content-Disposition:attachment;filename=smime.p7mrfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT67n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9Hf8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF40GhIGfHfQbnj756YT64V生成的加密數(shù)據(jù)放在RecipientInfo塊后(拼接)，使3、創(chuàng)建signedData報文準備一個簽名的MIME實體的過程如下：選擇散列算法(SHA-1或MD5)。計算需要簽名內(nèi)容的散列碼。使用發(fā)送者的私有密鑰加密散列碼(簽名)。準備稱為SignerInfo(簽名者信息)的數(shù)據(jù)塊，該數(shù)據(jù)塊包含了簽名者的公開密鑰證書、散列算法標識符、用來加密(簽名)散列碼的算法標識符及加密(簽名)的散列碼。使用base64進行編碼。3、創(chuàng)建signedData報文報文例子如下：Content-Type:application/pkcs7-mime;smime-type=signed-data;name=smime.p7mContent-Transfer-Encoding:base64Content-Disposition:attachment;filename=smime.p7m

567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj777n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjHHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh6YT64V0GhIGfHfQbnj75接收者恢復(fù)報文的簽名和驗證簽名:去除base64編碼;使用簽名者的公開密鑰來解密對散列碼的加密;接收者單獨計算報文的散列碼并且將它與解密后的散列碼相比較來驗證簽名。報文例子如下：4、創(chuàng)建簽名加密報文為了獲得既簽名又加密的報文，上述的signedData格式和EnvelopedData可以進行嵌套，因為作為MIME實體或S/MIME實體嵌套是允許的。用戶可以先簽名后加密，也可以先加密再簽名，選擇權(quán)在使用者。5、創(chuàng)建純簽名報文(ClearSigning)

純簽名的內(nèi)容類型為multipart/signed，由于該過程不涉及轉(zhuǎn)換簽名報文的形式，所以報文以一種“純的”形式發(fā)送。因此，具有MIME能力但沒有S/MIME能力的接收者能夠閱讀收到的報文。只對簽名進行編碼。4、創(chuàng)建簽名加密報文Content-Type:multipart/signed;protocol="application/pkcs7-signature";micalg=sha1;boundary=boundary42

--boundary42Content-Type:text/plainThisisaclear-signedmessage.

--boundary42Content-Type:application/pkcs7-signature;name=smime.p7sContent-Type:multipart/signed31十月202296第七章Internet安全22十月20221第七章Internet安全7.1Internet的安全要求Web和電子郵件自身存在的各種問題：Web服務(wù)器對于來自Internet的攻擊顯得十分脆弱。Web服務(wù)器的重要性日益增加。Web服務(wù)器被破壞，除了名譽受損外，經(jīng)濟上也會遭受損失。Web服務(wù)器底層軟件異乎尋常的復(fù)雜。復(fù)雜的軟件可能隱藏更多的潛在安全問題。Web服務(wù)器有可能成為進攻內(nèi)部網(wǎng)的跳板。沒有經(jīng)過訓(xùn)練的用戶不了解存在的安全風(fēng)險。電子郵件的問題主要是防止欺騙和保證內(nèi)容的隱私性。電子郵件是傳播病毒最快捷的途徑。Return7.1Internet的安全要求Web和電子郵件自身存在的7.2SSL/TLSSSL(SecureSocketLayer)是一個用來保證安全傳輸?shù)腎nternet協(xié)議。該協(xié)議通過在兩個實體(客戶和服務(wù)器)之間提供一個安全通道，來實現(xiàn)數(shù)據(jù)在Internet中傳輸?shù)谋Ｃ苄浴?994年，Netscape公司最先提出了SSL，該協(xié)議目前有三個版本：SSLv2、SSLv3和TLSv1(SSLv3.1)。1995年發(fā)布的SSLv3是主要版本。第三版的設(shè)計經(jīng)過了公開的評論并且吸收了工業(yè)界的意見。1996年Netscape公司將SSL規(guī)范提交給IETF。IETF成立了專門的TLS工作組對SSLv3進行標準化。TLS的第一個正式版本已于1999年發(fā)布，其本質(zhì)上可以看成是SSLv3.1，與SSLv3非常接近并且兼容。

7.2SSL/TLSSSL(SecureSocketL7.2.1SSL結(jié)構(gòu)SSL握手協(xié)議SSL修改密碼協(xié)議SSL告警協(xié)議應(yīng)用層協(xié)議SSL記錄協(xié)議TCPIP7.2.1SSL結(jié)構(gòu)SSL握手協(xié)議SSL修改密碼協(xié)議SS7.2.2SSL會話和SSL連接兩個重要的概念：SSL連接和SSL會話。SSL連接：本質(zhì)上講就是TCP連接，不同之處在于每個連接要與一個SSL會話相關(guān)聯(lián)。SSL會話：是客戶和服務(wù)器之間的關(guān)聯(lián)，會話通過握手協(xié)議來創(chuàng)建。會話定義了加密安全參數(shù)的一個集合，該集合可以被多個SSL連接所共享。在任何一對交互實體之間可能存在多個安全連接，在交互實體之間也可以同時存在多個會話。SSL會話是有狀態(tài)的，主要的狀態(tài)有：當(dāng)前讀和當(dāng)前寫、掛起讀和掛起寫。由握手協(xié)議來協(xié)調(diào)客戶端和服務(wù)器端的會話狀態(tài)。7.2.2SSL會話和SSL連接兩個重要的概念：SSL連接會話狀態(tài)的相關(guān)參數(shù)：會話標識符對方的證書壓縮方法密碼規(guī)范(加密算法，MAC算法及加密屬性)主密鑰(48字節(jié)密鑰)可重用否：一個標志，用于指明該會話是否可以用來初始化一個新的連接。第七章-Internet安全課件連接狀態(tài)的相關(guān)參數(shù)：服務(wù)器端和客戶端隨機數(shù)(連接)服務(wù)器端寫MAC密鑰客戶端寫MAC密鑰服務(wù)器寫密鑰(對稱加密)客戶寫密鑰(對稱加密)初始向量(CBC)序列號(報文；64Bit)連接狀態(tài)的相關(guān)參數(shù)：7.2.3SSL記錄協(xié)議1、記錄協(xié)議的功能和報文格式功能：將上層傳來的數(shù)據(jù)進行分段、壓縮、MAC值計算和加密處理，并添加記錄報頭，然后交給下層協(xié)議；當(dāng)收到下層傳來的數(shù)據(jù)時，進行相反的處理，然后交給上層協(xié)議。記錄協(xié)議為高層提供兩種服務(wù)：機密性服務(wù)和報文鑒別服務(wù)。SSL可為多種TCP/IP應(yīng)用提供基本安全服務(wù)。(IANA)已經(jīng)為具備SSL功能的應(yīng)用分配了固定端口號，例如，帶SSL的HTTP(https)被分配的端口號為443，帶SSL的SMTP(ssmtp)被分配的端口號為465，帶SSL的NNTP(snntp)被分配的端口號為563。7.2.3SSL記錄協(xié)議1、記錄協(xié)議的功能和報文格式記錄協(xié)議報文格式如圖所示內(nèi)容類型(8比特)，高層協(xié)議：修改密碼規(guī)范、告警、握手和應(yīng)用數(shù)據(jù)。主要版本(8比特)次要版本(8比特)壓縮長度(16比特)數(shù)據(jù)MAC字段內(nèi)容類型主要版本次要版本壓縮長度數(shù)據(jù)(可選壓縮)MAC(0,16,20字節(jié))報文首部加密部分記錄協(xié)議報文格式如圖所示內(nèi)容類型主要版本次要版本壓縮長度2、記錄層報文的產(chǎn)生過程應(yīng)用數(shù)據(jù)分段壓縮計算MAC加密添加首部2、記錄層報文的產(chǎn)生過程應(yīng)用數(shù)據(jù)分段壓縮計算MAC加密添加首允許使用的加密算法：

分組密文流密文算法密鑰長度算法密鑰長度IDEA128RC4-4040RC2-4040RC4-128128DES-4040DES563DES168Fortezza80允許使用的加密算法：分組密文流密文算法密鑰長度算法密鑰長度7.2.4SSL修改密碼協(xié)議與告警協(xié)議1、修改密碼協(xié)議

修改密碼協(xié)議是使用SSL記錄協(xié)議的三個SSL有關(guān)協(xié)議之一，目的是使掛起狀態(tài)被復(fù)制到當(dāng)前狀態(tài)，改變了這個連接將要使用的密碼算法。這個協(xié)議由單個報文組成，而報文又由值為1的單個字節(jié)組成。2、告警協(xié)議

告警協(xié)議是用來將SSL有關(guān)的告警傳送給對方實體。和其他使用SSL的應(yīng)用一樣，告警報文按照當(dāng)前狀態(tài)被壓縮和加密。該協(xié)議的每個報文由兩個字節(jié)組成。第一個字節(jié)為告警級別(警告和致命)。第二個字節(jié)包含了指出特定告警的代碼。如果級別是致命的，SSL將立刻終止該連接，但同一會話的其他連接可以繼續(xù)，但該會話不能再建立新的連接了。7.2.4SSL修改密碼協(xié)議與告警協(xié)議1、修改密碼協(xié)議7.2.5SSL握手協(xié)議握手協(xié)議的功能和報文格式握手協(xié)議用來協(xié)商會話的安全屬性。握手協(xié)議產(chǎn)生的報文作為記錄層的數(shù)據(jù)，按照當(dāng)前活動會話的狀態(tài)被封裝、處理和傳輸。握手協(xié)議的功能主要包括：服務(wù)器與客戶間的相互身份鑒別；協(xié)商加密和MAC算法；交換加密密鑰。握手協(xié)議由一組在客戶和服務(wù)器之間交換的報文組成。握手協(xié)議報文由三個字段組成：類型(1字節(jié))；長度(3字節(jié)；字節(jié)為單位)；內(nèi)容(≥1字節(jié))(P174-177)Return7.2.5SSL握手協(xié)議握手協(xié)議的功能和報文格式Retur7.3S-HTTP7.3S-HTTP7.3.1HTTP介紹7.3.1HTTP介紹2、報文結(jié)構(gòu)HTTP有兩類報文：請求報文和響應(yīng)報文。方法URI版本請求行空格回車換行首部字段名：值首部字段名：值實體主體首部行版本狀態(tài)碼短語狀態(tài)行首部字段名：值首部字段名：值實體主體首部行請求報文響應(yīng)報文2、報文結(jié)構(gòu)HTTP有兩類報文：請求報文和響應(yīng)報文。方法URHTTP請求報文典型的HTTP請求報文如下：GET/PUBLIC/docu.htmlHTTP/1.1（請求行）Connection：close（首部行）User-agent：Mozilla/4.0Accept：text/html，audio/base，image/gif，video/mpegAccept-language：en（空行）HTTP請求報文典型的HTTP請求報文如下：HTTP響應(yīng)報文典型的HTTP響應(yīng)報文如下：HTTP/1.1200OK（狀態(tài)行）Connection：Close（從這行開始的6行都是首部行）Date：Wed，16Oct200212:36:15GMTServer：Apache/1.3.0(Unix)Last-Modified：Mon，11Aug200210:30:28GMTContent-Length：5963（文件長度的字節(jié)數(shù)）Content-Type：text/html（空行）DATADATADATA…（所請求的文件）HTTP響應(yīng)報文典型的HTTP響應(yīng)報文如下：7.3.2S-HTTP基本原理7.3.2S-HTTP基本原理1、S-HTTP消息的創(chuàng)建S-HTTP包括消息首部和加密消息主體，消息首部中可能包含了指示接收者應(yīng)如何解釋消息主體以及此后接收者應(yīng)該怎樣執(zhí)行消息主體的信息。消息發(fā)送者：客戶端/服務(wù)器。S-HTTP消息的創(chuàng)建需要以下信息：明文消息接收者支持的加密方法和密鑰素材發(fā)送者支持的加密方法和密鑰素材發(fā)送者將自己支持的加密方法和接收者支持的加密方法綜合在一起，形成雙方支持的加密方法和相關(guān)密鑰素材表，通過使用這些數(shù)據(jù)，發(fā)送者可以將明文消息轉(zhuǎn)換成S-HTTP消息。1、S-HTTP消息的創(chuàng)建S-HTTP包括消息首部和加密消息2、S-HTTP消息的恢復(fù)S-HTTP消息的恢復(fù)過程需要以下信息：S-HTTP消息接收者先前聲明所支持的加密方法和密鑰素材。接收者目前支持的加密方法和密鑰素材發(fā)送者先前聲明所支持的加密方法和密鑰素材為了恢復(fù)一個S-HTTP消息，接收者需要閱讀該消息的首部，以確定發(fā)送者對消息主體進行的密碼操作，然后對消息進行解密恢復(fù)出明文。2、S-HTTP消息的恢復(fù)S-HTTP消息的恢復(fù)過程需要以下3、S-HTTP的安全機制S-HTTP協(xié)議對消息的保護主要分為三個方面：消息簽名、消息鑒別和消息加密，一個S-HTTP消息可以被簽名、鑒別、加密或三者的任意組合，當(dāng)然也包括與HTTP兼容的明文傳輸方式。S-HTTP提供了多種密鑰管理機制S-HTTP安全機制的要點：簽名(將證書或證書鏈附加在消息中傳給對方)密鑰交換和加密(Inband公鑰,Outband秘密密鑰；對稱加密)消息完整性和發(fā)送者鑒別(MAC,MD2;MD5;SHA)challenge-response機制(防止重放攻擊)3、S-HTTP的安全機制S-HTTP協(xié)議對消息的保護主要分4、S-HTTP的協(xié)商內(nèi)容S-HTTP標準允許通信的雙方表達他們的請求或偏好，根據(jù)實現(xiàn)能力和特殊的申請請求作出合適的選擇。S-HTTP用協(xié)商首部來傳送權(quán)限和請求。下面給出了常用的協(xié)商首部字段：SHTTP-Certificate-Types字段：指出所接收的證書類型。(X.509)SHTTP-Key-Exchange-Algorithms字段：指出密鑰交換算法。(in-band、out-band)SHTTP-Signature-Algorithms字段：指出數(shù)字簽名算法。(RSA、DSS)SHTTP-Message-Digest-Algorithms字段：指出報文摘要算法。(MD5、SHA)SHTTP-Symmetric-Content-Algorithms字段：指出對稱加密算法。(DES、3DES、RC4)4、S-HTTP的協(xié)商內(nèi)容S-HTTP標準允許通信的雙方表達7.3.3S-HTTP的報文格式S-HTTP消息報文的格式與HTTP是相同的，即都是由一個請求行/狀態(tài)行、后面跟首部行和一個實體部分，所不同的是首部的內(nèi)容范圍及實體部分在典型情況下是加密的。1、請求行：為了區(qū)分S-HTTP報文、HTTP報文和所允許的特殊處理，請求行使用了特殊的安全方法“Secure”和協(xié)議標識符“Secure-HTTP/1.4”。S-HTTP和HTTP進程都使用相同的TCP端口號80。為了防止敏感信息的泄露，請求URI將由“*”替代，請求行的例子如下：Secure*Secure-HTTP/1.42、狀態(tài)行：S-HTTP響應(yīng)使用協(xié)議標識符“Secure-HTTP/1.4”。狀態(tài)行的例子如下：Secure-HTTP/1.4200OK3、首部行：S-HTTP定義了一系列新首部行。7.3.3S-HTTP的報文格式S-HTTP消息報文的格式Content-type：message/http表明S-HTTP報文封裝的是HTTP消息。Content-type：application/s-http表明S-HTTP報文封裝的是非HTTP數(shù)據(jù)。Content-Privacy-Domain首部行有兩個取值：CMS或MOSS。CMS是英文“CryptographicMessageSyntaxStandard”的縮寫，是一種類似于PEM標準的加密消息封裝格式。MOSS是英文“MIMEObjectSecurityServices”的縮寫，指明消息實體中攜帶的是MIME兼容消息。Prearranged-Key-Info首部行指明密鑰交換方法，取值有：Inband,Outband。MAC-Info首部行說明用于消息鑒別碼計算的散列函數(shù)和共享密鑰。S-HTTP報文格式的詳細描述可以參閱RFC-2660ReturnContent-type：message/http表明S-H7.