【文章內(nèi)容簡介】 全解決方案8? 公積金賬戶查詢? 交易明細(xì)查詢? 定期到期查詢? 消費積分查詢網(wǎng)上賬戶查詢的安全需求比公共信息發(fā)布要更高，因此網(wǎng)上賬戶對系統(tǒng)安全也有同樣的需求，而且，除此之外，網(wǎng)上賬戶查詢的還需要解決用戶的私有信息（口令，賬戶數(shù)據(jù)）在 Inter 這個公開網(wǎng)絡(luò)上傳輸?shù)陌踩珕栴}。而這些屬于信息安全范疇。網(wǎng)上賬戶查詢的信息安全功能應(yīng)包括兩個方面：身份認(rèn)證和數(shù)據(jù)保密。 身份驗證傳統(tǒng)銀行業(yè)務(wù)的身份驗證方案主要是通過口令或 PIN 來實現(xiàn)的，它具有以下兩個特點：1. PIN 一般為 48 個數(shù)字，范圍比較窄。2. 銀行主機記錄用戶輸錯 PIN 的次數(shù)，一旦超過一定數(shù)量，就自動關(guān)閉該賬戶的服務(wù)功能。在網(wǎng)上銀行業(yè)務(wù)中，僅通過這樣的方式來進(jìn)行身份驗證，存在很大的不足：，所以口令明文傳輸容易被截獲。，口令猜 測是黑客使用最多的攻 擊手段，即使使用蠻力攻擊法，攻破 8 位的數(shù)字口令也只需很短的時間。，很難對錯誤 PIN 輸入進(jìn)行限制。網(wǎng) 絡(luò)的信道故障或者人 為的惡意行為都很容易使輸錯口令次數(shù)達(dá)到限制。 錯誤次數(shù)限制會 給合法的用戶帶來了很大的不便。因此，傳統(tǒng)的口令驗證難以成為網(wǎng)上銀行業(yè)務(wù)的唯一身份認(rèn)證技術(shù)。在網(wǎng)絡(luò)應(yīng)用中，目前采用較多的方法是動態(tài)口令（例如 Kerberos），令牌卡和數(shù)字證書認(rèn)證技術(shù)。這些技術(shù)配合口令機制，就稱為雙因子身份認(rèn)證技術(shù)。SSL 協(xié)議是采用最為廣泛的數(shù)字證書身份認(rèn)證技術(shù)。它不但可以解決身份認(rèn)證，也解決了數(shù)據(jù)保密問題，所以目前大部分網(wǎng)上應(yīng)用，包括網(wǎng)上銀行都采用 SSL 技術(shù)來實現(xiàn)身份認(rèn)證。網(wǎng)上銀行安全解決方案9簡單地說，SSL 就是在傳輸數(shù)據(jù)前，服務(wù)器和客戶雙方通過數(shù)字證書進(jìn)行“握手”，驗證對方的數(shù)字證書是否合法，并且約定一個臨時的會話密鑰，對接下來要傳輸?shù)臄?shù)據(jù)進(jìn)行加密。SSL 不支持客戶證書，客戶可以通過驗證服務(wù)器的證書來判斷服務(wù)器的合法性，服務(wù)器則無法驗證客戶的證書，通常服務(wù)器仍然通過口令驗證客戶的身份，由于口令在傳輸時已經(jīng)被加密，所以安全性有了很大的提高。SSL 對 進(jìn)行了擴展，支持客戶證書，這時服務(wù)器就可以驗證客戶的證書，只有那些擁有合法證書的用戶才能繼續(xù)保持與服務(wù)器的連接，如果配合口令驗證，就成為雙因子身份認(rèn)證。采用數(shù)字證書的安全體現(xiàn)在私鑰的安全，只要私鑰不被竊取，數(shù)字證書就是安全的，而通過蠻力攻擊法攻破私鑰的可能性是不存在的。下表是數(shù)字證書同傳統(tǒng)口令模式的身份驗證在性能上的比較：口令方式 數(shù)字證書方式用戶登錄時口令在公開網(wǎng)絡(luò)上傳輸，有可能泄密私鑰由用戶保存，只需公布其公鑰。私鑰永遠(yuǎn)不會在公開網(wǎng)絡(luò)上傳輸，而且從公鑰無法推導(dǎo)出私鑰口令一旦泄密，所有安全機制即失效用戶私鑰可以存放在 USBKEY 中并有口令保護(hù)，安全性更高服務(wù)器需要維護(hù)龐大的用戶口令列表并負(fù)責(zé)口令保存的安全服務(wù)器使用數(shù)字證書驗證用戶身份，不保存用戶的私鑰，所以用戶私鑰不可能在服務(wù)器端泄露與傳統(tǒng)方法一致，易于理解 技術(shù)較新，普通用戶理解略有難度對于企業(yè)銀行，由于數(shù)據(jù)安全性要求較高，所以應(yīng)該采用數(shù)字證書身份認(rèn)證加上口令認(rèn)證的雙因子身份認(rèn)證技術(shù)。每個企業(yè)用戶應(yīng)該申請一張數(shù)字證書，當(dāng)企業(yè)用戶上網(wǎng)進(jìn)行賬戶查詢時，通過 SSL 建立安全連接。網(wǎng)上銀行系統(tǒng)首先驗證該用戶的數(shù)字證書是否為合法證書。然后將查詢請求和口令一起發(fā)送給業(yè)務(wù)前置機，由銀行業(yè)務(wù)主機對口令再次進(jìn)行認(rèn)證。企業(yè)用戶的身份驗證過程和 CA 不可分割。當(dāng)服務(wù)器通過 SSL 獲得用戶證書后，服務(wù)器應(yīng)用程序還要到 CA 服務(wù)器檢索該證書是否在廢止證書列表之中。圖 2 顯示了企業(yè)用戶身份驗證的完整過程。圖 2 是網(wǎng)上銀行企業(yè)用戶的口令驗網(wǎng)上銀行安全解決方案10證方式。對于個人用戶，考慮到使用的方便性更為重要，可以采用 方式對口令加密進(jìn)行身份驗證，因此用戶不需要申請證書，只需要記住口令就行。 數(shù)據(jù)加密Web 應(yīng)用數(shù)據(jù)加密的方案除了 SSL 以外，并沒有太多可供選擇的方案。除了采用數(shù)字證書身份認(rèn)證方案以外，SSL 的另一個優(yōu)點是在建立握手以后，對客戶和服務(wù)器之間的所有數(shù)據(jù)均采用對稱算法進(jìn)行加密，對稱算法的加密效率比較高，所以對性能不會造成很大的影響。另外 SSL 采用了會話密鑰的機制，每次握手時約定一個會話密鑰，會話結(jié)束，密鑰立刻失效，最大程度上保證了數(shù)據(jù)的保密性。由于采用了 SSL 技術(shù)，Web 應(yīng)用的開發(fā)也大為簡化，Web 服務(wù)器應(yīng)用程序可以把與查詢狀態(tài)有關(guān)的信息都保存在 Cookie 中，而不必?fù)?dān)心 Cookie 的安全問題。圖 2 用戶身份驗證示意圖遞交口令的Web 服務(wù)器的用戶的表單的的銀行業(yè)務(wù)主機的 CA 服務(wù)器的建立 SSL 握手的1．SSL 服務(wù)器代理驗證用戶證書本身的合法性2。證書提交 CA服務(wù)器，檢驗是否已經(jīng)作廢3。銀行業(yè)務(wù)主機再對口令進(jìn)行驗證網(wǎng)上銀行安全解決方案11 網(wǎng)上支付和轉(zhuǎn)賬網(wǎng)上支付和轉(zhuǎn)賬在查詢的基礎(chǔ)上進(jìn)一步給用戶提供了方便，用戶可以在網(wǎng)上進(jìn)行支付、轉(zhuǎn)賬從而達(dá)到交易的目的，就目前而言，國內(nèi)很多網(wǎng)上銀行系統(tǒng)已經(jīng)開通了如下支付和轉(zhuǎn)賬業(yè)務(wù)：? 定期賬戶轉(zhuǎn)活期? 活期賬戶轉(zhuǎn)定期? 活期賬戶轉(zhuǎn)活期? 信用卡賬戶轉(zhuǎn)信用卡賬戶? 公用事業(yè)費代繳? 企業(yè)轉(zhuǎn)賬? 證券資金賬戶轉(zhuǎn)賬? 特約商戶網(wǎng)上支付和查詢相比，支付和帳戶轉(zhuǎn)帳的安全需求更高，除了必須具備查詢所需要的安全性之外，還需要應(yīng)該提供數(shù)據(jù)完整性和不可否認(rèn)性。 數(shù)據(jù)完整性所謂數(shù)據(jù)完整性就是指用戶在支付指令和轉(zhuǎn)賬指令中所填寫的數(shù)據(jù)必須保持完整，不能在公開網(wǎng)絡(luò)上被其他用戶無意或惡意地修改。SSL 由于對整個數(shù)據(jù)鏈路進(jìn)行了加密，所以在一定程度上能夠保證完整性，但是公開網(wǎng)絡(luò)上的數(shù)據(jù)加密對完整性的保護(hù)只是局部的，一旦數(shù)據(jù)被解密后依然存在著被更改的可能。所以正確的方案應(yīng)該采用數(shù)字簽名機制，由用戶使用自己的數(shù)字證書對支付指令或轉(zhuǎn)賬指令進(jìn)行簽名，同時簽名數(shù)據(jù)被永久保存，只有這樣才能真正避免數(shù)據(jù)完整性被破壞，簽名是對用戶私鑰對數(shù)據(jù)摘要（又稱指紋）的加密，數(shù)據(jù)發(fā)生變化時，數(shù)據(jù)摘要也必定發(fā)生變化。如果將原先的數(shù)字簽名解密，就很容易發(fā)現(xiàn)兩段數(shù)據(jù)摘要不符。 不可否認(rèn)性不可否認(rèn)性是指指令發(fā)出者不能在事后否認(rèn)曾經(jīng)發(fā)出該指令。這對于規(guī)范業(yè)務(wù)，避免法律糾紛起著很大的作用。傳統(tǒng)地，不可否認(rèn)性是通過手工簽名完成的，在網(wǎng)上銀行，不可否認(rèn)性是由數(shù)字簽名機制實現(xiàn)的。網(wǎng)上銀行安全解決方案12由于私鑰很難攻擊，其他人（包括銀行）不可能得到私有密鑰。所以用私鑰對交易指令的摘要簽名后，就保證了該用戶確實是發(fā)出了該指令。將簽名數(shù)據(jù)作為業(yè)務(wù)數(shù)據(jù)的憑證，在業(yè)務(wù)成功后就開始保障不可否認(rèn)性。不可否認(rèn)性可以保證每個帳戶用戶的轉(zhuǎn)帳過程具有法律效力。對于個人銀行業(yè)務(wù)來說，轉(zhuǎn)賬金額比較小，風(fēng)險相對較低，所以在雙方都認(rèn)可的情況下，沒有數(shù)字簽名的支付和轉(zhuǎn)賬的指令也是可以接受的。但是對于企業(yè)用戶和進(jìn)行證券轉(zhuǎn)賬的個人用戶來說，轉(zhuǎn)賬金額大，風(fēng)險大，指令必須附帶簽名數(shù)據(jù)，在簽名數(shù)據(jù)驗證通過以后才能真正進(jìn)行支付或轉(zhuǎn)賬。有四種方案可以實現(xiàn)用戶簽名：1. 專用客戶端軟件：例如電子錢包，這類軟件通常是一個瀏覽器的插件（PlugIn） ，在用戶填好支付指令或轉(zhuǎn)賬指令并發(fā)送給服務(wù)器以后，服務(wù)器用某種協(xié)議規(guī)范化該指令，并作為喚醒消息的參數(shù)返回給用戶，這時插件被激活，用戶的指令在插件程序中再次被顯示，此時用戶可以對這段指令進(jìn)行數(shù)字簽名。許多 SET 應(yīng)用的實現(xiàn)采用了這種方案，這種方案的主要缺點是效率比較低，同一段數(shù)據(jù)需要被來回傳送兩次。另外不同的應(yīng)用可能需要開發(fā)不同的插件，對用戶和系統(tǒng)開發(fā)者來說都增加了額外的負(fù)擔(dān)。2. 表單簽名技術(shù)：Netscape 公司發(fā)明的一種技術(shù)，在其瀏覽器中已經(jīng)支持，通過調(diào)用 Java 腳本實現(xiàn)對表單域內(nèi)容的簽名，這種方案雖然沒有方案 1 的缺點，但是其實現(xiàn)與瀏覽器相關(guān)。而且簽名