《信息安全引論》課件chapter9

1、 第9章 Web Security 目前，所有的工商企業(yè)、大多數(shù)政府機構以及許許多多的個人都建起了自己的網(wǎng)站，這些網(wǎng)站都可以通過互聯(lián)網(wǎng)進行訪問。企業(yè)對利用網(wǎng)絡開展電子商務情有獨鐘。但現(xiàn)實是互聯(lián)網(wǎng)與Web服務對于各種攻擊非常脆弱。伴隨著企業(yè)對這種安全現(xiàn)實的蘇醒與擔憂，對于Web安全的需求則迅速擴張。Web安全可以隨便寫一本書，本章只討論Web安全的一般要求，重點講述web security協(xié)議族：SSL協(xié)議(SSLV2、SSLV3)、TLS協(xié)議和SET協(xié)議。Web Security 第1節(jié) Web 安全考慮 第2節(jié) SSL第3節(jié) SET小結 本章介紹了Web安全需要考慮的一些問題，介紹了這些問題

2、的解決方案，主要介紹了SSL協(xié)議與SET協(xié)議。講述了SSL協(xié)議的細節(jié)，講述了SET協(xié)議的交易過程。這里還有許多可以改進的地方，需要增加銀行處理的圖，對講解順序進行重新組織?？梢钥紤]直接從現(xiàn)實的處理過程講解。思考題 (1) 基于本章所學習的內(nèi)容，在SSL協(xié)議中，接收者能不能記錄下按不正常順序到達的記錄包？如果可以，解釋需要怎樣做。如果不可以，請解釋為什么？ (2) 你認為SET協(xié)議與SSL協(xié)議，還有沒有安全漏洞？如有，試提出一種彌補方法。結束語 到此為止本門課程結束了，感謝大家的配合我們在一起度過了愉快的一學期。你們也即將畢業(yè)走向工作崗位了。祝你們都能夠找一個理想的工作。希望你們通過自己的努力能

3、夠成為科學的巨匠、祖國的棟梁。希望你們中間能夠涌現(xiàn)出一批政治家、科學家、企業(yè)家。好像早上8、9點鐘的太陽，希望寄托在你們身上。茍富貴，勿相忘。今后無論你們在工作還是學習中有需要我?guī)椭脑挘乙欢ń弑M全力。同學們，再見！第1節(jié) Web Security Considerations www基本上是一種運行在互聯(lián)網(wǎng)或者TCP/IP內(nèi)部網(wǎng)絡中的B/S應用。所有的安全措施都與Web Security相關，但Web對網(wǎng)絡安全提出了一些新的挑戰(zhàn)。比如： (1) 互聯(lián)網(wǎng)是雙向的，因此運行在互聯(lián)網(wǎng)上的Web服務器易于受到攻擊； (2) Web已經(jīng)成為展示公司與產(chǎn)品窗口，成為公司對外交流的出口，成為進行交易的支

4、承平臺。如果Web收到破壞將會造成財產(chǎn)的損失和聲譽下降。Web Security Considerations (3) Web服務器可以作為進入公司內(nèi)部復雜的計算機系統(tǒng)的跳板，一旦Web服務器被攻破，攻擊者就可以訪問與服務器相連的數(shù)據(jù)與系統(tǒng)。 (4) 未經(jīng)過訓練的、粗心大意的用戶一般是Web服務的主要用戶。這些用戶沒有必要的安全意識，意識不到可能存在的安全風險，也沒有采取有效應對措施所需要的工具和知識。Web 安全威脅 完整性修改用戶數(shù)據(jù)、特洛伊木馬瀏覽器、修改存儲、修改傳輸?shù)男畔⒘髁棵艽a學校驗機密性竊聽、盜竊服務器信息、盜竊用戶數(shù)據(jù)、獲得網(wǎng)絡配置信息、獲得用戶與服務器對話信息加密、Web代理

5、拒絕服務切斷用戶線程、偽造線程淹沒服務器、占滿磁盤或內(nèi)存、用DNS攻擊孤立服務器難于防范認證冒充合法用戶、偽造數(shù)據(jù)密碼學技術Web 安全威脅 Web安全威脅可以有不同的分類，第1種分為主動攻擊與被動攻擊：被動攻擊包括在服務器與瀏覽器之間搭線竊聽獲得訪問某個網(wǎng)站的訪問信息，而這個網(wǎng)站是不允許他們訪問的。主動攻擊包括冒充另一個用戶、修改客戶端和服務器之間傳遞的信息、修改網(wǎng)站信息等。第2種根據(jù)威脅的位置分為：Web服務器威脅、Web瀏覽器威脅、瀏覽器與服務器之間的網(wǎng)絡流量威脅。 BACK第2節(jié) SSL SSL是Netscape公司設計的協(xié)議，該協(xié)議有三個版本：SSLV1、SSLV2、SSLV3。其中

6、第1個版本根本就沒有投入使用，Microsoft對V2進行了改進，修補了一些安全漏洞，提出了一個類似的協(xié)議PCT。后來Netscape對協(xié)議進行了徹底的改進，得到了SSLV3。這是目前應用得最廣泛的協(xié)議。TLS則把密鑰擴展和認證使用的密碼算法結合在一起，更符合密碼學家的期望，但SSL和TLS不能互操作。SSLSSL是在用戶級進程中運行的協(xié)議。SSL/ TLS可以部署在用戶級別的進程中，不需要對操作系統(tǒng)進行修改，協(xié)議非常簡單，也不需要考慮超時和丟失數(shù)據(jù)包重傳這類問題。當然也可以運行在UDP協(xié)議之上，在SSL/TLS內(nèi)部處理超時和丟失數(shù)據(jù)包重傳問題。 SSL的目的是在TCP協(xié)議提供的可靠的數(shù)據(jù)流服

7、務的基礎上, SSL把數(shù)據(jù)分割成帶有報頭和密碼學保護的記錄，為應用程序提供可靠的、加密的、完整性保護的數(shù)據(jù)流服務。SSL協(xié)議的體系結構SSL不是一個單獨的協(xié)議，而是包括兩個協(xié)議層的四個協(xié)議組成的協(xié)議包，具體情況如圖所示SSL握手協(xié)議 SSL協(xié)議中最重要最復雜的協(xié)議就是握手協(xié)議。這個協(xié)議的任務是使服務器與客戶能夠互相認證，能夠協(xié)商加密算法與MAC算法、協(xié)商加密與在SSL記錄協(xié)議中為保護發(fā)送數(shù)據(jù)的機密性所使用的密鑰。在傳送任何數(shù)據(jù)之前，需要先執(zhí)行握手協(xié)議。握手協(xié)議包括服務器與客戶端之間的一系列信息交換，交換信息的過程如圖所示信息的格式握手協(xié)議有10種信息，所有信息的格式是相同的，格式如下：Type

8、 (1byte)Length(3byte)Content(0byte)分別說明消息的種類(共有10種)；消息長度的字節(jié)數(shù)；與消息相關的參數(shù)。SSL握手協(xié)議握手協(xié)議的信息類型信息種類參數(shù)Client_HelloServer_HelloCertificateServer_key_exchangeCertificate_requestServer_doneCerificate_verifyClient_key_exchangeFinished版本號、隨機數(shù)、會話ID、密碼套、壓縮方法(For both)X.509證書鏈參數(shù)，簽名類型、授權Null簽名參數(shù)，簽名散列值參數(shù)詳情版本號：是用戶可以理解的最

9、高SSL版本號；隨機數(shù)：用戶產(chǎn)生的隨機數(shù)，包括32位的時標和28位的隨機數(shù)；會話ID：可變長的會話標示符，0表示用戶希望在新的會話上建立一個新的連接，非0表示在原有會話上建立連接；cipher suite以用戶希望的優(yōu)先順序列出用戶可以接受的密碼算法；壓縮方法列出用戶可以支持的壓縮算法列表。握手協(xié)議 握手過程可以分為四個階段：協(xié)商安全方法(Establish Security Capability)、服務器認證與密鑰交換、客戶認證與密鑰交換、完成握手，如下圖所示。 (1)協(xié)商階段: 任務是初始化邏輯連接，協(xié)商安全方法。協(xié)商客戶由向服務器發(fā)送Client_ Hello消息而發(fā)起，消息中包含版本號

10、、一個隨機數(shù)、一個會話ID、密碼套(Cipher Suite)與壓縮方法。其中隨機數(shù)由32比特的時標與隨機數(shù)生成器所生成的28字節(jié)的隨機數(shù)所握手協(xié)議組成，該隨機數(shù)作為Nonce防止重放攻擊。會話ID是一個可變的會話標示符，ID=0表示希望在新的會話上建立一個新的連接，ID0表示希望update 連接參數(shù)或在現(xiàn)有會話上建立一個新的連接。Cipher Suite 包括客戶端所支持的密碼算法，以及各算法所采用的密鑰交換算法，最優(yōu)先的算法放在最前面。發(fā)出Client_Hello消息后，客戶端等待服務器的Server_Hello消息。服務器返回的消息與客戶發(fā)送的消息內(nèi)容相同，但遵循下面的約定：握手協(xié)議版

11、本號中包含用戶建議的較低的版本和服務器所支持的最高版本，這里的隨機數(shù)要獨立于用戶的隨機數(shù)。如果用戶的會話ID0，服務器的會話ID填相同的值，如果用戶會話ID=0，服務器的會話ID就填一個新的數(shù)，作為新的會話ID。Cipher Suite 中填上服務器從用戶建議的加密與壓縮算法中所選擇的加密與壓縮算法。 (2) 對服務器的認證與密鑰交換：如果需要認證，服務器發(fā)送它的證書、密鑰交換信息以及如果需要認證用戶時的發(fā)送證書請求。第2階段握手協(xié)議要發(fā)送的最后一個消息是Server_done, 是Server_Hello 及有關消息結束標志。發(fā)出這個消息后，服務器等待用戶的響應。 (3) 認證用戶與密鑰交換

12、：收到Server_done消息后，用戶驗證服務器的證書是否有效、有關的參數(shù)可否接受。如果一切OK，就返回服務器一個消息或多個消息。如果服務器請求證書，用戶應該返回自己的證書、以及密鑰交換的信息，并附帶上如何驗證自己的證書的有關信息。握手協(xié)議 (4) 完成握手階段：這個階段完成建立一個安全連接的任務。用戶發(fā)送一個Change_cipher_ spec消息，并將掛起的Cipher Spec復制到當前的Cipher Spec中，接著立即發(fā)送一個基于協(xié)商的算法、密鑰以及有關的信息計算出的Finished 消息，標志著從客戶方面，一切OK。服務器收到這個消息后也發(fā)送一個類似的消息，標志著服務器也已經(jīng)做

13、好一切準備。這樣握手協(xié)議全部完成，可以開始進行應用層的數(shù)據(jù)交換了。Change Cipher Spec 協(xié)議 這是在SSL協(xié)議中要利用 SSL Record Protocol的三個協(xié)議之一，也是SSL協(xié)議族中最簡單的協(xié)議，這個協(xié)議只有一個消息，只有一個值1。這個消息的用途是將掛起狀態(tài)能夠復制到當前狀態(tài)，用于更新本次連接所用的Cipher Suite。Alert Protocol Alert協(xié)議向?qū)Φ鹊膶嶓w傳達SSL有關的Alert。本協(xié)議的每個信息由兩個字節(jié)組成，第1個字節(jié)表示消息的嚴重程度，1表示值得警惕的，2表示致命的。如果安全及別是致命的，SSL就會立即中斷這個連接，其它連接則不受影響，

14、但不能在該會話基礎上建立新的連接。第2個字節(jié)說明具體的警報信息。比如是信息完整性錯誤，還是信息機密性錯誤等。SSL Record Protocol 記錄協(xié)議是為SSL連接提供服務的，主要提供下面兩種服務: (1) 利用握手協(xié)議所達成的算法、密鑰等，用對稱加密算法對SSL的載荷進行機密性保護；(2)利用握手協(xié)議所達成的密鑰等，生成有關消息的認證碼，提供完整性保護。SSL記錄協(xié)議的完整過程如下圖所示。用于機密性保護的可選算法有IDEA、RC2-40、DES-40、DES、3DES、RC4-40、RC4-128, 用于完整性保護的算法有SHA-1。SSL記錄協(xié)議的作用SSL的記錄有4種類型：用戶數(shù)據(jù)

15、、握手消息、警告消息和概念、密碼規(guī)格消息?；緟f(xié)議主要是為用戶與服務器之間通信服務的。主要是記錄下握手過程中所達成的各種安全參數(shù)，然后當正式進行數(shù)據(jù)通信時，根據(jù)所協(xié)商的各種算法與參數(shù)，進行相應的操作，為SSL連接提供有關信息的機密性與完整性服務。SSL 接下來還有一些密碼學計算，包括如何計算Master Secret、如何生成有關的密碼學參數(shù)，因為這些都非常簡單，沒有什么難于理解的，我們就不再講了，有興趣的同學可以查找有關的資料看一下，沒有興趣的話，可以到需要的時候再去查找有關資料。SSL的會話重用機制 有關SSL的兩個重要概念是SSL會話和SSL連接。 會話：一個SSL會話是服務器和客戶端之

16、間的一次商談并達成的協(xié)議。會話是由握手協(xié)議創(chuàng)造的。會話定義了一系列可以被許多連接所共用的密碼學安全參數(shù)。避免每次連接都進行昂貴的安全參數(shù)的協(xié)商。類似一次商務談判。 連接：連接是在OSI分層模型中所定義的、提供適當服務的一次傳輸。類似談判過程的一次接觸。連接是一個對等關系，連接是變化的，每一個連接都與一個會話相關聯(lián)。會話重用機制 任何兩個參與實體之間可能存在多個安全連接。理論上任何兩個參與實體之間也可能同時存在多個會話，但實際上這個特性沒有被使用。實際上有許多狀態(tài)與一個會話相關聯(lián)。一旦一個會話建立起來，就存在一個當前的讀和寫的狀態(tài)，這個會話狀態(tài)結束，就會調(diào)用新的會話狀態(tài)。一個會話狀態(tài)包括：會話標

17、示符、Peer Certific-ate、壓縮方法、密碼規(guī)范、主秘密、是否可重用等。一個連接狀態(tài)包括：服務器與用戶的隨機數(shù)、服務器(用戶)寫MAC秘密、服務器(用戶)寫密鑰、初始向量、序列號等。SSL的會話重用機制 會話密鑰是用開銷比較大的公開密鑰技術建立起來的，為了降低開銷，SSL允許在一個會話密鑰的基礎上建立多個連接，這種機制稱為會話的重用。這主要是因為SSL能夠與HTTP1.0協(xié)議協(xié)同工作，而HTTP 1.0協(xié)議允許在相同的客戶和服務器之間打開大量的TCP連接。雖然SSL允許會話重用，但是服務器上的會話都是無狀態(tài)的。如果服務器希望重用會話，就需要給用戶發(fā)送一個不保密的ID，并把ID和會話

18、密鑰存起來。協(xié)議細節(jié) 如果Alice在消息1中出現(xiàn)了已經(jīng)保存的會話ID，那么就可以繞過握手過程的公鑰操作部分。只有在Alice和Bob都記住了相同的主密鑰的前提下，這種簡化的握手過程才能繼續(xù)。如果Bob沒有識別出這個會話ID，就會在消息2中返回另一個ID，或者忽略Alice的消息。沒有先前狀態(tài)下的會話重用與雙方都記住了ID的情況下的會話重用情況如下兩圖所示。沒有先前狀態(tài)下的會話重用雙方都記住了ID的情況下的會話重用BACK第3節(jié) SET SET 是由Master卡公司與Visa卡公司于1996年設計的、用于保護在互聯(lián)網(wǎng)進行的信用卡交易的公開的加密與安全標準規(guī)范。其中IBM、Microsoft、

19、Netscape、RSA、Terisa與Verisign公司都參與了該標準的設計工作。SET本身并不是一個支付系統(tǒng)。而是使用戶能夠在互聯(lián)網(wǎng)上部署現(xiàn)有的信用卡支付基礎設施的一整套安全協(xié)議與安全格式。本質(zhì)上，SET可提供三種服務：SET 在交易的所有參與方之間提供一個安全的通信信道；通過應用X.509V3證書解決相互之間的信任問題；因為只有在必要時和需要的場合，參與者才能獲得有關的信息，所以保證參與者的隱私。討論SET的最好方式是從SET交易中的SET要求、密鑰特性與參與者開始。對SET的要求 在互聯(lián)網(wǎng)或者其他網(wǎng)絡中用信用卡進行安全支付需要滿足下列商業(yè)的要求： (1) 要保證支付信息的機密性和訂單

20、信息的機密性； (2) 要保證所有傳輸數(shù)據(jù)的完整性； (3) 要保證持卡人是信用卡帳戶的合法用戶。這就需要進行認證。 (4) 保證一個商戶與金融機構的關系使它能夠接受信用卡交易。對SET的要求 (5) 運用最好的安全技術與最好的系統(tǒng)設計技術，保護電子商務交易中的所有合法當事人。 (6) 需要開發(fā)一種協(xié)議，該協(xié)議既不依賴于傳輸安全機制的使用也不影響傳輸安全機制的使用。 (7) 便于并鼓勵軟件供應商和網(wǎng)絡服務商之間的互操作。SET的主要特點 (1) 信息的機密性：即使在網(wǎng)絡中漫游，持卡人的帳戶信息與支付信息都是保密的，一個重要的特點是商戶不知道信用卡號，只有發(fā)卡行知道卡號，SET采用DES保證機密

21、性。 (2) 數(shù)據(jù)的完整性：用RSA數(shù)字簽名、SHA-1散列算法保證數(shù)據(jù)的完整性，確保訂單信息、個人數(shù)據(jù)、支付指令在傳輸過程中不被修改。 (3) 對持卡人帳戶的認證：SET使商戶能夠驗證持卡人是有效信用卡帳號的合法用戶。 (4) SET使持卡人能夠驗證相應的商戶與金融機構有信用卡結算關系，能夠接受信用卡付款。SET的當事人SET的當事人 (1) 持卡人：持信用卡進行消費的消費者。 (2) 商戶：向持卡人提供商品或服務的個人或組織。 (3) 發(fā)卡行：為持卡人發(fā)放信用卡的金融機構。 (4) 收款行：商戶開有帳戶、并受理信用卡認證與結算的金融機構。商店通常都可以接受許多種信用卡，但商店并不想與許多發(fā)

22、卡銀行打交道，收款行向商店提供認證，保證某個信用卡是有效的，并且SET的當事人其購物金額沒有超過其授信額度。收款行負責將購貨資金轉(zhuǎn)移給商店，并向發(fā)卡銀行進行索償。 (5) 支付網(wǎng)關：支付網(wǎng)關是由收款行或者指定的第三方維護的、處理商戶支付信息的功能設備。網(wǎng)關現(xiàn)有銀行卡支付網(wǎng)絡的中介，負責認證和支付。 (5) CA: 這是一個為持卡人、商戶和支付網(wǎng)關頒發(fā)X.509V3公鑰證書的可信賴的實體。SET的成敗取決于CA基礎設施是否可用。一般采用層次型的CA，以避免當事人都直接要根CA進行發(fā)證。SET交易過程的事件SET的雙簽名 現(xiàn)在我們看一下持信用卡在商店購物的過程，基本上是選擇好貨物之后到商店的結算柜

23、臺，直接將信用卡交給商店，商店刷卡，我們輸入密碼，完成結算。這樣商店就會知道我們的信用卡號碼，甚至能知道我們的密碼，而銀行則知道我們在哪個商店購物，甚至知道我們買了什么東西。但實際上只要能夠付款，商店其實沒有必要知道我們的信用卡號，銀行也沒有必要知道我們在哪里購物，購了什么東西。SET的雙簽名 這是我們所希望的。而SET協(xié)議的設計人員注意到這個問題，并發(fā)明了雙簽名機制，利用雙簽名機制很好地解決了這個問題。雙簽名機制是SET協(xié)議一個重要的創(chuàng)新。雙簽名的目的是要把準備發(fā)送給兩個接收者的信息連接起來。而且又使得兩個接收者只能看到自己應該看到的信息。有些同學可能說，那直接把兩個信息分別發(fā)給這兩個接收者

24、不就得了？假如這樣的話，大家想一想會出現(xiàn)什么問題？SET的雙簽名 用戶雖然付過款、并購買貨物，但卻沒有付款與所購貨物綁定的證據(jù)。這樣商店可以不為你的商品質(zhì)量負責。因此我們要求用戶必須要能把這兩個信息關聯(lián)起來。這就是雙簽名的作用。用戶既獲得了相應的隱私保護，也獲得了相應的質(zhì)量保證。我們再來看一看連接的必要性，假設客戶將訂單信息和支付信息都發(fā)給商店，出現(xiàn)的問題就是，一旦以后發(fā)生爭議，用戶拿不出你曾經(jīng)給該商店的并由商店把支付信息轉(zhuǎn)交給銀行的進行收款的證據(jù)，如果商店能夠SET的雙簽名截獲該客戶的另一個訂單信息，商店可以說該支付信息支付的是另一個訂單的貨款，而本次訂單客戶并沒有付款。 下面的圖說明了SE

25、T是如何滿足這個要求的：用戶首先產(chǎn)生訂單信息和支付信息，分別對支付信息和訂單信息進行散列運算，得到其散列值H(PI)和H(OI)，把這兩個散列值連接起來，再作一次散列運算，最后客戶用自己的私鑰加密連接的散列值，就構成了一個雙簽名，DSCESCH(H(PI)|H(OI)SET的雙簽名SET的雙簽名 假設商店擁有了雙簽名，OI以及H(PI)。商店根據(jù)用戶的證書也知道用戶的公鑰PC，商店就能夠計算下面的兩個數(shù)據(jù) H(H(PI)|H(OI) 與 DPCDS 如果這兩個數(shù)據(jù)相等，用戶對訂單信息的簽名就得到了驗證。類似地，銀行有DS，PI和H(OI)以及用戶的公鑰，銀行就可以計算 H(H(PI)|H(OI

26、) 與 DPCDS 如果這兩個數(shù)據(jù)相等，用戶對付款信息的簽名就得到了驗證。SET的雙簽名 結果商店收到了訂單信息，并驗證了客戶對訂單信息的簽名；銀行收到了支付信息，并驗證了客戶對支付信息的簽名；客戶將訂單信息與支付信息連在了一起，并且以后能證明這種連接。 假設某個不誠實的商店，為了自己的利益，想用其他訂單信息代替本次交易的訂單信息，我們看將會發(fā)生什么問題？它必須找到另一個訂單信息，使其散列函數(shù)值與本訂單的散列函數(shù)值相等，而這一點是做不到的。SET支持的交易類型 SET支持多種交易類型，包括Card-holder registration, Merchant registration, Purc

27、hase request, Payment authorization, Payment capture (Allow the merchant to request payment from the payment gate-way), Certificate inquiry and status, Purchase inquiry, Authorization reversal (Allow a merchant to correct previous authorization request), Capture reversalSET支持的交易類型(Allow a merchant t

28、o correct errors in cap-ture request such as transaction amount that were entered incorrectly by a clerk), Credit (Allow a merchant to issue a credit to a cardholders account such as when goods are returned or were damaged during shipping.) Credit reversal, Payment gateway certificate request, Batch

29、 administration, Error message.SET支持的交易類型 其中有三個是最關鍵、最重要的交易類型，這包括Purchase request, Payment auth-orization and Payment capture. 我們要對這三者進行比較詳細的討論。要完成一筆交易，客戶首先要上網(wǎng)瀏覽，選擇貨物，下訂單。然后商店要給用戶發(fā)送一個完整的訂單，詳細列明用戶購買的貨物名稱、數(shù)量、單價，總值、送貨地點等詳細信息。這些過程都沒有SET的介入。交易準備階段購買請求 Purchase Request(購買請求)要交換四條信息，發(fā)起請求、發(fā)起響應、購買請求、購買響應。 為了給

30、商店發(fā)送SET信息，持卡人必須擁有商店的證書與支付網(wǎng)關的證書，客戶在發(fā)給商店的發(fā)起請求信息中，要求商店提供證書。該條信息包含用戶的信用卡種類，一個請求響應的ID號，一個Nonce以保證一定的時效。購買請求商店產(chǎn)生一個響應，并用自己的私有密鑰簽名。響應包括用戶發(fā)來的Nonce，一個新的要求用戶返回信息時使用的新的Nonce，本次購買交易的ID，除此之外，還包括商店的簽名證書和支付網(wǎng)關的密鑰交換證書。持卡人驗證這兩個密鑰，然后生成訂單信息和支付信息，訂單信息并不包含數(shù)量、價格等信息，而只包含在SET介入之前，客戶和商店之間交換的有關信息的Reference。購買請求下一步，客戶準備一個購買請求消息

31、和一個一次性的對稱加密密鑰。購買消息包含： (1)支付有關的消息：這是需要商店轉(zhuǎn)發(fā)給支付網(wǎng)關的信息，包括PI、雙簽名、H(OI)、數(shù)字信封(由支付網(wǎng)關的公鑰加密對稱密鑰而獲得)，因為在閱讀其他信息之前，必須先解密這個對稱密鑰，所以將其稱為數(shù)字信封。 (2)購買有關的消息：這是商店真正需要的信息，包括OI、雙簽名、H(PI)(供商店用于驗證雙簽名)。購買請求 (3)持卡人證書：包含持卡人的簽名驗證公鑰(這是商店與支付網(wǎng)關都需要的)。當商店受到購買請求信息時，采取如下行動： (1) 根據(jù)CA的簽名，驗證持卡人的證書。 (2) 驗證用戶雙簽名有效性。以確保訂單在傳遞過程中沒有被篡改，而且確實是用用戶

32、的私鑰簽署的。 (3) 處理訂單消息，并把支付信息轉(zhuǎn)交給支付網(wǎng)關。 (4) 給用戶返回一個購買響應。購買響應信息 購買響應信息包括訂單確認、并給客戶一個交易編號。這些信息用商店的私鑰進行簽名，并與商店的證書一起發(fā)給用戶。 持卡人的工作站收到購買響應后，驗證商店的證書，驗證簽名，并采取一些適當?shù)男袆?，比如可以將有關信息顯示給用戶，或者更新訂單狀態(tài)。Payment Authorization 在處理客戶訂單的同時，商店請求網(wǎng)關進行進行付款確認。支付確認保證發(fā)卡行同意該付款交易，也保證商店能夠收到貨款，商店可以向客戶提供貨物或服務。付款確認包括兩條信息：確認請求和確認響應。 商店向支付網(wǎng)關發(fā)送確認請求信息，包括下列內(nèi)容： (1) 支付有關的信息：包括PI，雙簽名，H(OI), 數(shù)字信封。Payment Authorization (2)有關的確認信息: 是商店生成的一些信息，包括：用商店的私鑰簽名，并用一次性的對稱密鑰加密的含有交易ID的確認信息，數(shù)字信封。 (3) 證書：