【文章內容簡介】 使用自己的數(shù)字證書對支付指令或轉賬指令進行簽名，同時簽名數(shù)據(jù)被永久保存，只有這樣才能真正避免數(shù)據(jù)完整性被破壞，簽名是對用戶私鑰對數(shù)據(jù)摘要（又稱指紋）的加密，數(shù)據(jù)發(fā)生變化時，數(shù)據(jù)摘要也必定發(fā)生變化。如果將原先的數(shù)字簽名解密，就很容易發(fā)現(xiàn)兩段數(shù)據(jù)摘要不符。14 / 39不可否認性不可否認性是指指令發(fā)出者不能在事后否認曾經發(fā)出該指令。這對于規(guī)范業(yè)務，避免法律糾紛起著很大的作用。傳統(tǒng)地，不可否認性是通過手工簽名完成的，在網(wǎng)上銀行，不可否認性是由數(shù)字簽名機制實現(xiàn)的。由于私鑰很難攻擊，其他人（包括銀行）不可能得到私有密鑰。所以用私鑰對交易指令的摘要簽名后，就保證了該用戶確實是發(fā)出了該指令。將簽名數(shù)據(jù)作為業(yè)務數(shù)據(jù)的憑證，在業(yè)務成功后就開始保障不可否認性。不可否認性可以保證每個帳戶用戶的轉帳過程具有法律效力。另外，對于企業(yè)級的帳戶。對于個人銀行業(yè)務來說，轉賬金額比較小，風險相對較低，所以在雙方都認可的情況下，沒有數(shù)字簽名的支付和轉賬的指令也是可以接受的。但是對于企業(yè)用戶和進行證券轉賬的個人用戶來說，轉賬金額大，風險大，指令必須附帶簽名數(shù)據(jù)，在簽名數(shù)據(jù)驗證通過以后才能真正進行支付或轉賬。有四種方案可以實現(xiàn)用戶簽名：1　專用客戶端軟件：例如電子錢包，這類軟件通常是一個瀏覽器的插件（PlugIn） ，在用戶填好支付指令或轉賬指令并發(fā)送給服務器以后，服務器用某種協(xié)議規(guī)范化該指令，并作為喚醒消息的參數(shù)返回給用戶，這時插件被激活，用戶的指令在插件程序中再次被顯示，此時用戶可以對這段指令進行數(shù)字簽名。許多 SET 應用的實現(xiàn)采用了這種方案，這種方案的主要缺點是效率比較低，同一段數(shù)據(jù)需要被來回傳送兩次。另外不同的應用可能需要開發(fā)不同的插件，對用戶和系統(tǒng)開發(fā)者來說都增加了額外的負擔。15 / 392　 表單簽名技術：Netscape 公司發(fā)明的一種技術，在其瀏覽器中已經支持，通過調用 Java 腳本實現(xiàn)對 表單域內容的簽名， 這種方案雖然沒有方案 1 的缺點，但是其 實現(xiàn) 與瀏覽器相關。而且簽名數(shù)據(jù)形式比較固定，不利于開發(fā)新的應用，所以很少采用。3　 Java 方式：這種方式是采用客 戶端腳本的一類 方式，用戶在填好支付指令或轉賬指令時，點擊“發(fā)送”按鈕，瀏覽器腳本或 Applet 開始運行，調用系統(tǒng)的加密模塊對表單中的數(shù)據(jù)進行簽名，并把簽名結果一起發(fā)送給服務器應用程序。這種方案克服了第一種方案的缺點，但是需要瀏覽器支持對應的腳本語言。因為 Java 具有較大的代表性，所以稱 為 Java方式。另外用戶必須安裝具有 COM 接口的加密模塊。4　 XML Signature 方式： 這時目前最有希望的一種技術，IETF 組織正在準備將這項技術確立為標準。它通過在網(wǎng)頁中嵌入一段 XML，瀏覽器或其他客戶端程序在處理 XML 時自動將數(shù)據(jù)簽名。由于 XML 在保存和傳輸數(shù)據(jù)標準化方面的優(yōu)越性，這項技術正在成為微軟和 SUN 公司競爭的焦點。從以上方案比較可以看出，方案 3 和方案 4 與前兩種相比，機制靈活， 應用開發(fā)方便，具有較大的優(yōu)勢。因此上海格爾軟件公司的加密模塊和 SSL 代理產品對這兩種用戶簽名方式提供了支持。16 / 393 格爾網(wǎng)上銀行解決方案 SSL 代理　SSL 介紹SSL 是一種在 Web 服務協(xié)議 (HTTP) 和 TCP/IP 之間提供數(shù)據(jù)連接安全性的協(xié)議。這種安全性協(xié)議被稱為安全套接字層－Security Socket Layer (SSL)，它為 TCP/IP 連接提供數(shù)據(jù)加密、服務器身份驗證和消息完整性驗證。SSL 被視為 Inter 上 Web 瀏覽器和服務器的安全標準。SSL 提供了用于啟動 TCP/IP 安全連接的“ 信號交 換”機制。信號交換機制協(xié)調客戶和服務器使用的安全性級別，并履行連接的身份驗證。此后，SSL 的作用是加密和解密要使用的應用程序協(xié)議的字節(jié)流（例如 HTTP 數(shù)據(jù)包） 。這意味著 HTTP 請求和 HTTP 響應中的所有信息將完全被加密，包括客戶請求的 URL 地址，表單提交內容（例如信用卡號） 、 HTTP 訪問身份驗證信息以及從服務器返回到客戶的所有信息。SSL 協(xié)議保證了在 Inter 上交換信息雙方的信息安全性和可靠性。服務器證書用來在 Inter 上標識一臺服務器的身份，服務器證書是 Web 服務器 SSL 安全功能的基礎。來自第三方身份認證機構的服務器證書提供用戶驗證 Web 站點的方法。利用 SSL，Web 服務器還可以通過檢查客戶證書的內容來驗證用戶。典型的客戶證書包含用戶和證書發(fā)行機構的詳細標識信息。綜合使用客戶證書標識和 SSL，能夠實現(xiàn)身份 認證功能和防止信息篡改。17 / 39　SSL 工作流程利用 SSL，服 務器和用戶 Web 瀏覽器首先參與處理交換 – 需要證書和密鑰對 – 以決定安全通訊需要的加密等級。此交 換要求 Web 服務器和用戶瀏覽器都具有兼容的加密和解密能力。交換的最后結果是創(chuàng)建（通常由 Web 瀏覽器）會話密鑰。服務器和 Web 瀏覽器都使用會話密鑰加密和解密傳輸?shù)男畔ⅰ４藭捗荑€的加密度，或強度，用位來表示。構成會話密鑰的位數(shù)越大或越長，加密和安全的等級就越高。Web 服務器的會 話密鑰一般為 40 位長，但實際上可以更長。Web 服務器使用本質上相同的加密方法來維護與用戶的通訊鏈接的安全。建立安全鏈接后，Web 服 務器和用戶 Web 瀏覽器都使用指定的會話密鑰來加密和解密信息。例如，當經認證的用戶企圖從要求安全通道的 Web 站點下載文件時，Web 服務器使用會話密鑰加密此文件和相關的 HTTP 標題。接收到加密文件后，Web 瀏覽器將使用相同會 話密鑰的副本還原此文件。這種加密方法盡管安全，但有先天不足：在創(chuàng)建安全鏈接過程期間，會話密鑰的副本可能會在不安全的網(wǎng)絡上傳輸。這意味著要危害鏈接的計算機破壞者只需要截取和偷竊此會話密鑰就可以了。要防止這種可能性，Web 服務器可使用其他加密方法。 Web 服務器的安全套接字層 (SSL) 安全功能使用了一種稱為公共密鑰的加密技術來屏蔽此密鑰以防在傳輸期間被截取。使用了兩個附加密鑰：私人和公共密鑰。公共密鑰加密的工作方式如下： ? 用戶 Web 瀏覽器建立與 Web 服務器的安全 (HTTPS) 通訊鏈接。 ? Web 服務器向用戶發(fā)送服務器證書和公共密鑰。 （此證書使用戶能夠確18 / 39認服務器的真實性和 Web 內容的完整性。 ） ? 用戶的 Web 瀏覽器和服務器參與商議交換，以確定用于安全通訊的加密度。 ? Web 瀏覽器生成會話密鑰，再用服務器的公共密鑰加密它。然后瀏覽器把加密的會話密鑰發(fā)送給 Web 服務器。 ? 服務器用私人密鑰解密會話密鑰，并建立安全通道。 ? Web 服務 器和瀏覽器都用會 話密鑰加密和解密傳輸?shù)臄?shù)據(jù)。 會話密鑰的復雜度，或強度，是和組成會話密鑰文件的二進制位數(shù)成正比的。這意味著會話密鑰的位數(shù)越大，安全度就越大，解密就越困難。用戶要建立與 Web 服務器的安全通訊通道時，用戶瀏覽器必須確認能用于該通道安全通訊的最高級加密或最高會話密鑰強度。這意味著 Web 服務器和用戶瀏覽器都必須具有兼容的會話密鑰加密和解密能力。例如，如果將服務器配置為要求最小 128 位加密強度的會話密鑰，則若要使連接安全，用戶必須使 Web 瀏覽 器有能力處 理具有 128 位會話密鑰的信息。目前，在國內使用的瀏覽器主要是微軟公司開發(fā)的 Inter Explore 和網(wǎng)景公司開發(fā)的 Navigator 或 Communicator。這兩種瀏覽器都具備 SSL 連接的功能。但是，使用瀏覽器缺省的 SSL 功能，存在著許多缺點：1　由于國內瀏覽器受到美國出口限制，加密位數(shù)無法達到 128 位。雖然美國國會已經批準了 56 位密 碼產品出口，但是簡體中文版的 瀏覽器還是仍然只支持 40 位加密強度。而 40 位加密強度遠達不到在 電子商務中應用的安全需求。2　Inter Explore SSL 模塊的加密部分實際上是由操作系統(tǒng)加密內核CSP 提供的，而 Navigator 和 Communicator 瀏覽 器的加密模塊采用的19 / 39是網(wǎng)景公司開發(fā)的 PKCS11 模塊，這兩個模塊之間不能夠交換私鑰，所以用戶申請證書時用的是何種瀏覽器，以后就必須使用這個瀏覽器，這給用戶帶來了不便。3　由于 CSP 和 PKCS11 的接口不同，所以要兼顧兩個瀏覽器的用戶，應用系統(tǒng)必須開發(fā)兩套網(wǎng)頁，增加了應用系統(tǒng)的開發(fā)工作量。4　缺省的 CSP 和 PKCS11 模塊都不能支持 IC 卡，給用戶保存和管理密鑰增加了難度，也降低了安全性能。5　客戶的證書和私鑰保存在 CSP 或 PKCS11 模塊中，給用戶簽名和其他電子商務應用擴展帶來了很大的不便。以 SET 應用為例，目前大部分SET 系 統(tǒng)的客戶端電子錢包都是采用自己開發(fā)的加密模塊，也就是說，用戶必須再申請一張 SET 數(shù)字證書，不同的應用采用自己的加密模塊，給用戶造成了極大的不便。所以國內采用比較多的就是 SSL 代理的做法，SSL 代理通過截獲 HTTPS請求響應對，在客戶請求受保護的 URL 時建立 SSL 連接。SSL 代理產品完全符合 SSL 標準，因此和瀏覽 器，Web 服務器內置的 SSL 功能都能完全兼容。 SSL 代理的工作原理SSL 代理分為兩個部分：代理客戶端和代理服務器。代理客戶端運行在用戶的 PC 機上，與瀏覽器同在一臺機器上，代理客 戶端通過修改瀏覽器的代理設置，從而捕獲瀏覽器發(fā)出的安全連接。當用戶需要用瀏覽器的 SSL 與服務器（代理服務器或 Web Server 本身）進行連接時， 該請求被代理服務器捕獲后，代理客戶端先與服務器建立高位數(shù)加密強度（高于 128 位）的握手，再和瀏覽20 / 39器之間生成低位數(shù)的 SSL 握手，瀏覽器發(fā)出的 請求通過 40 位 SSL 到達代理客戶端，代理客戶端首先將數(shù)據(jù)解密，然后用與服務器端之間建立的 128 位SSL 連接加密，發(fā)送給服務器，類似地，服務器將 響應發(fā)送給代理客戶端，代理客戶端先將數(shù)據(jù)解密，然后通過與瀏覽器之間建立的 40 位 SSL 連接將數(shù)據(jù)發(fā)送給瀏覽器。在服務器端，代理服務器端則與低位數(shù)的 web server 運行在同一臺主機上，代理 web server 的高位數(shù)加密連接，其工作過程與代理客戶端十分類似。SSL代理的工作原理見圖 3。由于代理客戶端和瀏覽器安裝在同一臺機器上，具有相同的 IP 地址，所以數(shù)據(jù)僅到達數(shù)據(jù)鏈路層，不可能在任何網(wǎng)絡上出現(xiàn)，兩者之間即便只有 40 位的加密強度，也是足夠安全的。代理服務器和 web server 之間亦是如此。SSL 代理除了提高了傳輸密鑰的位數(shù)，同時也提高了證書非對稱密鑰的位數(shù)，根據(jù)美國的出口限制，非對稱密鑰位數(shù)不能超過 512 位。和 40 位對稱密鑰一樣，攻破 512 位非對 稱密鑰已經成為可能。圖 3SSL 代理工作原理示意圖無論是代理客戶端還是代理服務器，都只需要代理