1、Chapter 16 Web安全性密碼編碼學與網絡安全2022/7/141整理ppt第一部分 SSL/TLS協(xié)議SSL （Secure Socket Layer）是一種在兩個端實體（End Entity）之間提供安全通道的協(xié)議。它具有保護傳輸數(shù)據以及識別通信實體的功能。安全通道是透明的IETF 制定的TLS（Transport Layer Security）版本是對Nescape公司的SSL和Microsoft公司的PCT（Private Communication Technology）兩個協(xié)議的綜合和兼容。重點討論SSL協(xié)議2022/7/142整理pptSSL/TLS協(xié)議設計目標SSL V

2、2 設計目標為滿足WEB安全通信而設計提供客戶和服務器之間傳輸數(shù)據的保密性服務器認證（客戶端認證可選）SSL V3設計目標修正SSL V2中存在的多處安全問題設計一種安全磋商多種加密算法的機制2022/7/143整理pptSSL提供了什么SSL提供了通道級別的安全: 連接的兩端知道所傳輸?shù)臄?shù)據是保密的,而且沒有被篡改幾乎總是要對服務器進行認證可選的客戶端認證針對異常情況的安全通知錯誤警示關閉連接所有這些依賴于某些對系統(tǒng)的假定假定已經正確產生了密鑰數(shù)據并且該密鑰已被安全地保管2022/7/144整理pptSSL與TCP/IPSSL連接非常類似于“保密的”的TCP連接位于TCP之上，應用層之下幾乎

3、只能在TCP上運行，而不能在UDP或IP上運行，因而它依賴于可靠的傳輸協(xié)議微軟的STLP和無線應用論壇的WTLS均為意圖在數(shù)據報傳輸層（如UDP）上正確工作的變種。2022/7/145整理pptSSL變種譜系樹SSL V1（1994）未發(fā)布SSL V2（1994）第一版SSL V3（1995）TLS（19971999）PCT（1995）STLP（1996）WTLS（1998）2022/7/146整理ppt用于WEB的SSL保護使用HTTP的WEB通信新的URL https:/在瀏覽器中的表現(xiàn) NETSCAPE：工具條上會顯示一把鑰匙IE： 右下角顯示 一把鎖幾乎所有的商業(yè)WEB服務器和瀏覽器都

4、實現(xiàn)了內置的SSL協(xié)議，通過配置即可使用2022/7/147整理ppt在SSL上構建一切除了HTTP 和NNTP（SNEWS）外，還可以用于SMTP、Telnet、FTP等，也可用于保護專有協(xié)議。協(xié)議端口標準化協(xié)議實現(xiàn)OPENSSL （C語言實現(xiàn)）pureTLS (java 實現(xiàn))ApacheSSL （針對Apache服務器的實現(xiàn)）Mod_ssl 2022/7/148整理ppt兩個主要的協(xié)議SSL記錄協(xié)議建立在可靠的傳輸協(xié)議(如TCP)之上它提供連接安全性，有兩個特點保密性，使用了對稱加密算法完整性，使用HMAC算法用來封裝高層的協(xié)議SSL握手協(xié)議客戶和服務器之間相互鑒別協(xié)商加密算法和密鑰它提

5、供連接安全性，有三個特點身份鑒別，至少對一方實現(xiàn)鑒別，也可以是雙向鑒別協(xié)商得到的共享密鑰是安全的，中間人不能夠知道協(xié)商過程是可靠的2022/7/149整理pptSSL的兩個重要概念SSL連接（connection)一個連接是一個提供一種合適類型服務的傳輸（OSI分層的定義）。SSL的連接是點對點的關系。連接是暫時的，每一個連接和一個會話關聯(lián)。SSL會話（session）一個SSL會話是在客戶與服務器之間的一個關聯(lián)。會話由Handshake Protocol創(chuàng)建。會話定義了一組可供多個連接共享的密碼安全參數(shù)。會話用以避免為每一個連接提供新的安全參數(shù)所需昂貴的協(xié)商代價。2022/7/1410整理p

6、ptSSL基礎針對RSA服務器認證的SSLSSL靈活性： 單向認證 和 雙向認證 認證加密 和 認證加密算法： RSA DSS DH FORTEZZA 連接分為兩個節(jié)段：握手階段 完成對服務器認證并建立加密密鑰數(shù)據傳輸階段 加密數(shù)據傳輸2022/7/1411整理ppt握手協(xié)議握手階段的目的客戶和服務器協(xié)商保護數(shù)據的算法（及其具體參數(shù)）確立在協(xié)商好的算法上使用的加密密鑰可選擇對客戶端進行認證 client server- 所支持的加密算法，隨機數(shù) 選中的加密算法，隨機數(shù)，服務器證書 加密后的pre_master_secret 計算相關演化密鑰 計算相關演化密鑰 握手消息的MAC值 握手消息的MA

7、C值注： 1. pre_master_secret 可以由KDF（key derivation function）演化出master_secret ,最后再通過master_secret 演化出系列加密密鑰。 2. 最后兩步防止握手本身遭受篡改（如低強度密碼算法替換等）. 3. 客戶端和服務器端隨機數(shù)的傳輸，防止重放攻擊。2022/7/1412整理ppt握手消息 client server-握手： ClientHello 握手： ServerHello Certificate ServerHelloDone ClientKeyExchange (ChangeCipherSpec) Finish

8、ed (ChangeCipherSpec) Finished2022/7/1413整理pptSSL 記錄協(xié)議實際的數(shù)據傳輸是使用SSL記錄協(xié)議實現(xiàn)的數(shù)據流分割成一系列片段并加以傳輸，每個片斷單獨保護和傳輸為實現(xiàn)完整性保護，對片段進行MAC保護為實現(xiàn)機密性保護，對片段進行加密保護傳輸?shù)氖前踩涗?2022/7/1414整理ppt記錄頭(Head)ContentType; 8位，上層協(xié)議類型Major version; Minnor version 16位，主次版本Compressed Length：16位 加密后數(shù)據的長度，不超過214+2048字節(jié)(SSL 幾乎不用壓縮,雖然支持)Encryp

9、tedData fragment; 密文數(shù)據2022/7/1415整理ppt記錄負荷（Payload）支持4種協(xié)議消息: application_data、alert、handshake、change_cipher_spec .Alert協(xié)議消息： 報警等級（warning/fatal）+ 具體報警編碼 2字節(jié)change_cipher_spec協(xié)議消息： 1字節(jié)，將掛起狀態(tài)變成當前狀態(tài)，指示在此之后的所有消息都將使用剛剛商定的密碼進行加密。handshake協(xié)議消息：類型（ 1字節(jié) ）長度（ 3字節(jié) ）消息，類型共10種2022/7/1416整理ppt記錄負荷（Payload）2022/7/

10、1417整理ppt完整SSL會話握手協(xié)議交換Hello消息，對于算法、交換隨機值等協(xié)商一致交換必要的密碼參數(shù)，以便雙方得到統(tǒng)一的premaster secret交換證書和相應的密碼信息，以便進行身份認證產生master secret把安全參數(shù)提供給SSL記錄層檢驗雙方是否已經獲得同樣的安全參數(shù)2022/7/1418整理ppt2022/7/1419整理ppt第一階段：建立起安全協(xié)商客戶發(fā)送一個client_hello消息，包括以下參數(shù)：版本、隨機數(shù)(32位時間戳+28字節(jié)隨機序列)、會話ID、客戶支持的密碼算法列表(CipherSuite)、客戶支持的壓縮方法列表.然后，客戶等待服務器的serv

11、er_hello消息服務器發(fā)送server_hello消息，參數(shù)：客戶建議的低版本以及服務器支持的最高版本、服務器產生的隨機數(shù)、會話ID、服務器從客戶建議的密碼算法和壓縮方法中確定一套本次連接使用的確定方法.2022/7/1420整理pptCipherSuite指定了密鑰交換的方法，SSL支持以下一些方法：RSA，要求服務器提供一個RSA證書DH(Diffie-Hellman)，要求服務器的證書中包含了由CA簽名的DH公開參數(shù)?？蛻艋蛘咴谧C書中提供DH公開參數(shù)，或者在密鑰交換消息中提供此參數(shù)EDH(Ephemeral Diffie-Hellman)，產生臨時的密鑰，DH公開參數(shù)由發(fā)送者的私鑰進

12、行簽名，接收者用對應的公鑰進行驗證 匿名的DH，不加鑒別。會受到中間人攻擊然后，指定以下信息加密算法和類型(流還是分組密碼算法)HMAC、MD5還是SHA-1是否可出口HashSize Key Material IV Size2022/7/1421整理ppt第二階段：服務器鑒別和密鑰交換服務器發(fā)送certificate消息，消息包含一個X.509證書，或者一條證書鏈除了匿名DH之外的密鑰交換方法都需要服務器發(fā)送server_key_exchange消息可選的，有些情況下可以不需要。只有當certificate消息沒有包含必需的數(shù)據的時候才發(fā)送此消息消息包含簽名，被簽名的內容包括兩個隨機數(shù)以及服

13、務器參數(shù)服務器發(fā)送certificate_request消息（可選）非匿名server可以向客戶請求一個證書包含證書類型和CAs服務器發(fā)送server_hello_done, 然后等待應答2022/7/1422整理ppt第二階段：服務器鑒別和密鑰交換2022/7/1423整理ppt第三階段：客戶鑒別和密鑰交換客戶收到server_done消息后，它根據需要檢查服務器提供的證書，并判斷server_hello的參數(shù)是否可以接受，如果都沒有問題的話，發(fā)送一個或多個消息給服務器。如果服務器請求證書的話，則客戶首先發(fā)送一個certificate消息，若客戶沒有證書，則發(fā)送一個no_certificat

14、e警告。 然后客戶發(fā)送client_key_exchange消息，消息的內容取決于密鑰交換的類型（如果是RSA，則含加密的PreMasterSecret）。最后，客戶發(fā)送一個certificate_verify消息（可選），其中包含一個簽名，對從第一條消息以來的所有握手消息的HMAC值(用master_secret)進行簽名2022/7/1424整理ppt第三階段：客戶鑒別和密鑰交換2022/7/1425整理ppt第四階段：結束第四階段建立起一個安全的連接客戶發(fā)送一個change_cipher_spec消息，并且把協(xié)商得到的CipherSuite拷貝到當前連接的狀態(tài)之中然后，客戶用本次連接協(xié)商

15、的算法、密鑰參數(shù)發(fā)送一個finished消息，這條消息可以檢查密鑰交換和鑒別過程是否已經成功。其中包括一個校驗值，對所有以來的消息進行校驗。服務器同樣發(fā)送change_cipher_spec消息和finished消息。握手過程完成，客戶和服務器可以交換應用層數(shù)據。2022/7/1426整理ppt第四階段：結束2022/7/1427整理ppt密鑰交換算法SSL記錄協(xié)議需要：CipherSuite, master secret, the client & server random values在hello消息中，交換隨機數(shù)以及各種算法兩類密鑰交換算法：RSA，客戶產生一個48字節(jié)的pre_mas

16、ter_secret，然后通過服務器的公鑰傳遞給服務器Diffie-Hellman，雙方協(xié)商得到的密鑰被用作pre_master_secret對于各種密鑰交換算法，從pre_master_secret計算得到Master_secret，然后從內存中刪除Master_secret總是48字節(jié)長，而pre_master_secret長度不定，取決于密鑰交換算法2022/7/1428整理ppt密鑰導出2022/7/1429整理pptMaster_secret的產生SSL 3.0Master_secret =MD5(pre_master_secretSHA-1(Apre_master_secret|

17、ClientHello.random ServerHello.random) MD5(pre_master_secretSHA-1(BBpre_master_secret| ClientHello.random ServerHello.random) MD5(pre_master_secretSHA-1(CCCpre_master_secret| ClientHello.random ServerHello.random) TLS 1.0master_secret = PRF(pre_master_secret, “master secret” , ClientHello.random, +

18、ServerHello.random)0.47* PRF(secret, label, seed)為偽隨機函數(shù)2022/7/1430整理ppt偽隨機函數(shù)PRF(secret, label, seed)P_hash(secret, seed) =+HMAC_hash(secret, A(1) + seed)+HMAC_hash(secret, A(2) + seed)+HMAC_hash(secret, A(3) + seed)+ .這里A()定義如下：A(0) = seed A(i) = HMAC_hash(secret, A(i-1)偽隨機函數(shù)PRF(secret, label, seed)

19、 =P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed); 這里，S1和S2為secret的各一半，如果secret為奇數(shù)個字節(jié)，則S1和S2共享一個字節(jié)2022/7/1431整理ppt最終需要的密鑰導出2022/7/1432整理ppt密鑰導出公式Key_block=MD5(master_secret|SHA-1(A+master_secret + server_random + client_random ) |MD5(master_secret|SHA-1(BB+master_secret + server_random + clien

20、t_random ) |MD5(master_secret|SHA-1(CCC+master_secret + server_random + client_random ) |MD5(master_secret|SHA-1(DDDD+master_secret + server_random + client_random ) |2022/7/1433整理pptMAC計算使用共享的密鑰MAC_write_secrethash(MAC_write_seret|pad_2|hash(MAC_write_secret|pad_1|seq_num|SSLCompressed.type|SSLComp

21、ressed.length|SSLCompressed.fragment)其中：MAC_write_secret : 共享的保密密鑰hash : 密碼散列函數(shù)（MD5或SHA-1）pad_1 : 0 x36重復48次(MD5)；或40次(SHA-1)pad_2 : 0 x5C重復48次(MD5)；或40次(SHA-1)seq_num : 該消息的序列號SSLCompressed.type : 更高層協(xié)議用于處理本分段SSLCompressed.length : 壓縮分段的長度SSLCompressed.fragment : 壓縮的分段(無壓縮時為明文段)注：非常類似HMAC2022/7/143

22、4整理ppt報警(Alert)協(xié)議用來一方向另一方報告例外情況,兩個級別:warning/fatal如果是Fatal級別的報警,則應終止連接.報警種類： unexpected_message bad_record_mac decryption_failed record_overflow decompression_failure handshake_failure no_certificate bad_certificate unsupported_certificate certificate_revoked certificate_expired certificate_unknown

23、illegal_parameter unknown_ca access_denied decode_error decrypt_error export_restriction protocol_version insufficient_security internal_error user_cancelled no_renegotiation2022/7/1435整理ppt會話恢復整個握手協(xié)議開銷巨大,如果集成會話恢復機制,則可以在客戶和服務器通信過一次的情況下,可以跳過握手階段而直接進行數(shù)據傳輸.通過使用上一次握手中確立的pre_master_secret,則可以避免許多計算開銷?；謴驮?/p>

24、許根據共同的master_secret，來產生新的密鑰。通過客戶使用ClientHello中的Session_id，申請會話恢復，服務器通過使用ServerHello中相同的Session_id，來同意會話恢復，接下來就會跳過其余步驟而使用保存的master_secret來產生新的所有的加密密鑰（由于新的隨機數(shù)不同，而使得新產生的加密密鑰與以前不同）。 2022/7/1436整理ppt客戶端認證實現(xiàn)服務器對客戶端的認證服務器通過向客戶端發(fā)送CertificateRequest消息，客戶端通過Certificate和CertificateVerify消息予以應答CertificateVerify

25、消息是一個使用與其傳輸?shù)淖C書關聯(lián)的私鑰簽名的消息。2022/7/1437整理ppt臨時RSA因受出口限制，為配合客戶端，服務器會產生一個臨時的低強度密鑰，并用高強度密鑰簽名，客戶端將驗證臨時密鑰上的服務器簽名，并使用它來打包pre_master_Secret.服務器向客戶端發(fā)送消息 ServerKeyExchange2022/7/1438整理ppt再握手是在當前受保護的連接上進行的一次新的SSL握手，因而傳輸過程中的握手消息是經過加密的一旦新的握手完成，將使用新的會話狀態(tài)來保護數(shù)據客戶端可以簡單的通過發(fā)送一條ClientHello消息來初始化一次新的握手服務器端可以通過HelloRequest

26、消息來初始化一次新的握手2022/7/1439整理pptSSL的安全性保護master_secret保護服務器的私鑰使用良好的隨機數(shù)證書鏈檢查算法選擇（強度）2022/7/1440整理pptSSL實現(xiàn)OpenSSL, 最新0.9.8, 實現(xiàn)了SSLv2,SSLv3, TLSv1.0Openssl a command line tool.ssl(3) the OpenSSL SSL/TLS library.crypto(3) the OpenSSL Crypto library.URL: SSLeay.au/ftp/Crypto/Internet號碼分配當局已經為具備SSL功能的應用分配了固定的

27、端口號例如帶SSL的HTTP(https)被分配以端口號443帶SSL的SMTP(ssmtp)被分配以端口號465帶SSL的NNTP(snntp)被分配以端口號5632022/7/1441整理pptWindows 2000和XP下的IPSec文章 /infocus/1519 /infocus/1526 /infocus/1528實現(xiàn)特點 與IETF兼容 支持Kerberos、基于證書的認證、基于共享密鑰的認證 一些不受IPSec保護的流量：廣播包、組播包、RSVP包、IKE包、Kerberos包 與L2TP結合起來提供安全的VPN遠程訪問 不能與NAT協(xié)同工作 仍然面臨一些攻擊：DOS，其他層

28、上協(xié)議的攻擊對比FreeBSD的實現(xiàn)：/doc/en_US.ISO8859-1/books/handbook/ipsec.html2022/7/1442整理pptSET協(xié)議Secure Electronic Transaction2022/7/1443整理ppt第三部分 SET協(xié)議Secure Electronic Transaction,SET 安全電子交易協(xié)議1996年,由Visa和MasterCard兩大國際信用卡組織聯(lián)合開發(fā)的電子商務交易參考標準（復雜、開放）。為在Internet上從事在線交易而設立的一個開放的以信用卡交易為特征的規(guī)范。得到IBM、HP、Microsoft、Verif

29、one、RSA、Terisa、GTE、Verisign等公司的支持，成為事實上的工業(yè)標準，并為IETF所認可。SET本身不是一個支付系統(tǒng)，而是一個安全協(xié)議和格式集。實現(xiàn)交易參與者行為的安全性、一致性、廣泛性支持產品包括IBM的Net.Commerce、CommercePoint，Verifone的vWallet、vPos、vGate，Microsft的MS-Wallet等其他產品還包括：CyberCash、GlobalSet、TrinTech、DigiCash、OpenMarket等。2022/7/1444整理pptSET協(xié)議的發(fā)展歷史1996年， Visa MasterCard 作為主要制定

30、者發(fā)起并公布。1997年出版規(guī)范，長達971頁。1998年出現(xiàn)SET兼容的產品。SET協(xié)議標準組織SETCo 在1998和1999年提出許多協(xié)議擴展。目前因各種原因，該協(xié)議因其復雜性，而受到冷落，前途比較渺茫。其設計思想值學習和探討。2022/7/1445整理ppt電子商務（Electronic Commerce，EC）是指利用簡單、快捷、低成本的電子通信方式，買賣雙方從事的商貿活動（不謀面或少謀面）。內容： 電子方式為特征 商貿活動電子方式：電話、傳真、EMAIL、Internet、EDI等。最終模式應是建立在Internet上活動流：網絡上信息流、商流、資金流、部分物流的實現(xiàn)。具體活動：交

31、易方匹配、洽談、訂貨、合同、支付、發(fā)票、報關、納稅、售后服務等。涉及的機構：消費者、商家、金融機構、政府機構、認證機構、配送中心等。特征：普遍性、方便性、整體性、安全性、協(xié)調性等。2022/7/1446整理ppt電子商務發(fā)展階段20世紀6090年代，基于EDI（電子數(shù)據交換）的電子商務是指業(yè)務文件按照一個公認的標準從一臺計算機傳輸?shù)搅硪慌_計算機上的電子傳輸方式。依賴于專用網絡和專用EDI軟件標準： 美國X12 聯(lián)合國UN/EDIFACT20世紀90年代以后，基于Internet的電子商務Dell公司的網絡直銷Amazon公司的網上書店eBay公司的個人拍賣網站應用模式：支付角度：支付型非支付型

32、服務角度：B2B B2C C2C B2G C2G 2022/7/1447整理ppt電子商務分類支付角度電子商務業(yè)務支付型非支付型NON-SET支付SET支付稅務申報、電子選舉、在線報表、安全政務等電子銀行、代繳代付、電子證券、網上購物等支付卡交易、電子銀行、網上購物等2022/7/1448整理ppt電子商務安全需求與措施安全性需求有效性機密性完整性可靠性/不可抵賴性/鑒別可審查性措施加密技術 對稱加密/公鑰加密密鑰管理技術 數(shù)字證書數(shù)字簽名安全電子商務協(xié)議 安全電子郵件/SSL/SET 2022/7/1449整理pptSET協(xié)議安全支付商業(yè)需求提供付款和訂購信息的保密性確保傳送數(shù)據的完整性為持

33、卡人是否為信用卡帳號合法用戶提供認證為商家提供認證確保交易各方利益創(chuàng)建不依賴于傳輸安全機制也不妨礙其使用的協(xié)議在軟件和網絡提供者之間提供功能設施和互操作性2022/7/1450整理pptSET協(xié)議中安全特性和實現(xiàn)SET協(xié)議中安全考慮信息保密性帳號和支付信息等的傳輸安全，加密技術認證持卡人帳號和商家認證，通過數(shù)字證書機制，確認參與者的真實身份防止抵賴 數(shù)字簽名技術數(shù)據完整性防止客戶發(fā)送給商家的信息被篡改 ，數(shù)字簽名和HASH、MAC手段授權安全實現(xiàn)在消費者端 實現(xiàn) 安全電子錢包在商家 實現(xiàn) 安全電子商家在銀行等金融機構 實現(xiàn)安全支付網關，完成SET協(xié)議和銀行金融系統(tǒng)相關標準（如ISO8583）的

34、轉換。 2022/7/1451整理pptSET 協(xié)議規(guī)范概述規(guī)范涉及的內容：加密算法的應用證書消息和對象格式購買消息和對象格式請款消息和對象格式交易實體之間消息協(xié)議SET 規(guī)范描述了系統(tǒng)設計考慮、證書管理、支付系統(tǒng)正式的協(xié)議定義、傳輸機制以及增加的擴展（支持硬件設備、特殊消息等）。大量采用已經存在的、相關的、用于支持的國際標準。2022/7/1452整理pptSET組件2022/7/1453整理ppt涉及的實體和概念持卡人（Cardholder）商家（Merchant）發(fā)卡行（Issuer）收單行（Acquirer）支付網關（Payment Gateway）支付卡品牌（Brand）認證中心（C

35、ertificate Authority，CA）2022/7/1454整理ppt雙簽名目的在于（持卡人）將商家訂單信息（Order Information，OI）和 收單行支付信息（Payment Instructions， PI）連接起來一起發(fā)送（保證商家只能看到OI，收單行只能看到PI ），但是又要保證OI和PI的一致性關聯(lián)性，而采用的一種組合簽名方法。首先分別計算OI的HASH值和PI的HASH值，二者連接后再次執(zhí)行HASH，然后簽名。即： DSEKRcH( H(PI) | H(OI) )2022/7/1455整理ppt雙簽名2022/7/1456整理ppt證書類型持卡者證書保證簽署支付

36、者和正確的支付卡帳號一致，帳號信息通過HASH方法作為持卡者證書中的一部分內容。商家證書需要兩個密鑰對參與SET交易，一個是簽名密鑰和證書，一個是密鑰交換密鑰和證書。支付網關證書需要兩個密鑰對參與SET交易，一個是簽名密鑰和證書，一個是密鑰交換密鑰和證書。收單行證書發(fā)卡行證書證書鏈確認證書注銷列表檢查2022/7/1457整理ppt發(fā)證機構涉及的發(fā)證機構根CA（RCA）、支付卡品牌CA（BCA）、區(qū)域CA（GCA）、持卡者CA（CCA）、商家CA（MCA）、支付CA（PCA）信任層次RCABCAGCACCAMCAPCACardholderMerchantPayment Gateway2022/7/1458整理ppt支付處理支付處理是SET規(guī)范中最為關鍵的描述部分支付處理的基本步驟和流程持卡者注冊（Cardholder Registration) 顧客開通帳號