網(wǎng)銀u盾usbkey的工作原理

1、隨著電子商務(wù)的迅速發(fā)展，信息安全已成為焦點問題之一，尤 其是網(wǎng)上支付和網(wǎng)絡(luò)銀行對信息安全的要求顯得更為突出。為了能在 因特網(wǎng)上開展安全的電子商務(wù)活動，公開密鑰基礎(chǔ)設(shè)施(PKI, Public Key Infrastructure )逐步在國內(nèi)外得到廣泛應(yīng)用。我們是否真的需要PKI , PKI究竟有什么用？下面通過一個案例 一步步地來剖析這個問題：甲想將一份合同文件通過Internet 發(fā)給 遠(yuǎn)在國外的乙，此合同文件對雙方非常重要，不能有絲毫差錯，而且 此文件絕對不能被其他人得知其內(nèi)容。如何才能實現(xiàn)這個合同的安全 發(fā)送？問題1:最自然的想法是，甲必須對文件加密才能保證不被 其他人查看其內(nèi)容，那么

2、，到底應(yīng)該用什么加密技術(shù)，才能 使合同傳送既安全乂快速呢？可以采用一些成熟的對稱加密算法，如 DES 3DES RC5等對 文件加密。對稱加密采用了對稱密碼編碼技術(shù)，它的特點是文件加密和解密使用相同的密鑰，即加密密鑰也可以用做解密密鑰， 這種方法 在密碼學(xué)中叫做對稱加密算法，問題2:如果黑客截獲此文件，是否用同一算法就可以解密 此文件呢？不可以，因為加密和解密均需要兩個組件： 加密算法和對稱密鑰，加密算法需要用一個對稱密鑰來解密，黑客并不知道此密鑰 問題3:既然黑客不知密鑰，那么乙怎樣才能安全地得到其密鑰呢？用電話通知，若電話被竊聽，通過Internet發(fā)此密鑰給乙，可能被黑客截獲，怎么辦？方

3、法是用非對稱密鑰算法加密對稱密鑰后進(jìn)行傳送。與對稱加 密算法不同，非對稱加密算法需要兩個密鑰：公開密鑰(Public Key )和私有密鑰(Private Key )。公開密鑰與私有 密鑰是一對，如果用公開密鑰對數(shù)據(jù)進(jìn)行加密，只有用對應(yīng)的私有密 鑰才能解密；如果用私有密鑰對數(shù)據(jù)進(jìn)行加密，只有用對應(yīng)的公開密 鑰才能解密。因為加密和解密使用的是兩個不同的密鑰，所以這種算法叫做非對稱加密算法(公/私鑰可由專門軟件生成)。甲乙雙 方各有一對公/私鑰，公鑰可在Internet 上傳送，私鑰白己保存。 這樣甲就可以用乙的公鑰加密問題 1中提到的對稱加密算法中的對 稱密鑰。即使黑客截獲到此密鑰，也會因為黑客

4、不知乙的私鑰，而解 不開對稱密鑰，因此也解不開密文，只有乙才能解開密文。問題4 :既然甲可以用乙的公鑰加密其對稱密鑰，為什么不 直接用乙的公鑰加密其文件呢？這樣不僅簡單，而且省去了用對稱加密算法加密文件的步驟？不可以這么做。因為非對稱密碼算法有兩個缺點：加密速度慢， 比對稱加密算法慢10100倍，因此只可用其加密小數(shù)據(jù)(如對 稱密鑰)，另外加密后會導(dǎo)致得到的密文變長。因此一般采用對稱 加密算法加密其文件，然后用非對稱算法加密對稱算法所用到的對稱密鑰問題5:如果黑客截獲到密文，同樣也截獲到用公鑰加密的 對稱密鑰，由于黑客無乙的私鑰，因此他解不開對稱密鑰， 但如果他用對稱加密算法加密一份假文件，并

5、用乙的公鑰加密一份假文件的對稱密鑰，并發(fā)給乙，乙會以為收到的是甲 發(fā)送的文件，會用其私鑰解密假文件，并很高興地閱讀其內(nèi) 容，但卻不知已經(jīng)被替換。換句話說，乙并不知道這不是甲 發(fā)給他的，怎么辦？答案是用數(shù)字簽名證明其身份。數(shù)字簽名是通過散列算法，如MD5 SHA-1等算法從大塊的數(shù)據(jù)中提取一個摘要。 而從這個摘要 中不能通過散列算法恢復(fù)出任何一點原文， 即得到的摘要不會透露出 任何最初明文的信息，但如果原信息受到任何改動，得到的摘要卻肯 定會有所不同。因此甲可以對文件進(jìn)行散列算法得到摘要， 并用白己 的私鑰加密（因為非對稱算法可逆，即用私鑰可解開公鑰加密的文 件，反之亦然），這樣即使黑客截獲也無

6、用。因為黑客不會從摘要 內(nèi)獲得任何信息，但乙卻不一樣，他可用甲的公鑰解密，得到其摘 要（如果用甲的公鑰能夠解開此摘要，說明此摘要肯定是甲發(fā)的， 因為只有甲的公鑰才能解開用甲的私鑰加密的信息， 而甲的私鑰只有 甲白己知道），并對收到的文件（解密后的合同文件）也進(jìn)行同 樣的散列算法，通過比較其摘要是否一樣，就可得知此文件是否被篡 改過（因為若摘要相同，則肯定信息未被改動，這是散列算法的特 點）。這樣不僅解決了證明發(fā)送人身份的問題，同時還解決了文件 是否被篡改問題。問題6:通過對稱加密算法加密其文件，再通過非對稱算法 加密其對稱密鑰，乂通過散列算法證明其發(fā)送者身份和其信 息的正確性，這樣是否就萬無一

7、失了？回答是否定的。問題在于乙并不能肯定他所用的所謂甲的公鑰 一定是甲的，解決辦法是用數(shù)字證書來綁定公鑰和公鑰所屬人。數(shù)字證書是一個經(jīng)證書授權(quán)中心數(shù)字簽名的包含公開密鑰擁 有者信息以及公開密鑰的文件，是網(wǎng)絡(luò)通信中標(biāo)識通信各方身份信息 的一系列數(shù)據(jù)，它提供了一種在Internet上驗證身份的方式，其作用類似于司機(jī)的駕駛執(zhí)照或日常生活中的身份證，人們可以在交往中用它來識別對方的身份。最簡單的證書包含一個公開密鑰、名稱以及證書授權(quán)中心的數(shù) 字簽名。一般情況下證書中還包括密鑰的有效時間、發(fā)證機(jī)關(guān)（證書授權(quán)中心）名稱、該證書的序列號等信息。它是由一個權(quán)威機(jī)構(gòu) CA機(jī)構(gòu)，又稱為證書授權(quán)（Certifica

8、te Authority） 中心發(fā) 放的。CA機(jī)構(gòu)作為電子商務(wù)交易中受信任的第三方，承擔(dān)公鑰體系中公鑰的合法性檢驗的責(zé)任。CA中心為每個使用公開密鑰的用戶發(fā) 放一個數(shù)字證書，數(shù)字證書的作用是證明證書中列出的用戶合法擁有 證書中列出的公開密鑰。CA機(jī)構(gòu)的數(shù)字簽名使得攻擊者不能偽造和 篡改證書，CA是PKI的核心，負(fù)責(zé)管理PKI結(jié)構(gòu)下的所有用戶（包 括各種應(yīng)用程序）的證書，把用戶的公鑰和用戶的其他信息捆綁在一 起，在網(wǎng)上驗證用戶的身份。因為數(shù)字證書是公開的，就像公開的電話簿一樣，在實踐中， 發(fā)送者（即甲）會將一份白己的數(shù)字證書的拷貝連同密文、摘要等放 在一起發(fā)送給接收者（即乙），而乙則通過驗證證書

9、上權(quán)威機(jī)構(gòu)的簽 名來檢查此證書的有效性（只需用那個可信的權(quán)威機(jī)構(gòu)的公鑰來驗證 該證書上的簽名就可以了），如果證書檢查一切正常，那么就可以相 信包含在該證書中的公鑰的確屬于列在證書中的那個人（即甲）。問題7:至此似乎很安全了。但仍存在安全漏洞，例如：甲雖 將合同文件發(fā)給乙，但甲拒不承認(rèn)在簽名所顯示的那一時刻簽署過此 文件（數(shù)字簽名就相當(dāng)于書面合同的文字簽名 ），并將此過錯歸咎 于電腦，進(jìn)而不履行合同，怎么辦？解決辦法是采用可信的時鐘服務(wù)（由權(quán)威機(jī)構(gòu)提供），即由 可信的時間源和文件的簽名者對文件進(jìn)行聯(lián)合簽名。在書面合同中， 文件簽署的日期和簽名一樣均是十分重要的防止文件被偽造和篡改 的關(guān)鍵性內(nèi)容（

10、例如合同中一般規(guī)定在文件簽署之日起生效 ）。在 電子文件中，由于用戶桌面時間很容易改變（不準(zhǔn)確或可人為改 變），由該時間產(chǎn)生的時間戳不可信賴，因此需要一個第三方來提 供時間戳服務(wù)（數(shù)字時間戳服務(wù)（DTS ）是網(wǎng)上安全服務(wù)項目，由 專門的機(jī)構(gòu)提供）。此服務(wù)能提供電子文件發(fā)表時間的安全保護(hù)。時間戳產(chǎn)生的過程為：用戶首先將需要加時間戳的文件用哈希 編碼加密形成摘要，然后將該摘要發(fā)送到DTS, DTS在加入了收到文件摘要的日期和時間信息后再對該文件加密（數(shù)字簽名），然后送回 用戶。因此時間戳（time-stamp） 是一個經(jīng)加密后形成的憑證文檔， 它包括三個部分：需加時間戳的文件的摘要，DTS收到文件

11、的日期和時間，DTS的數(shù)字簽名。由于可信的時間源和文件的簽名者對文 件進(jìn)行了聯(lián)合簽名，進(jìn)而阻止了文檔簽名的那一方（即甲方）在時 間上欺詐的可能性，因此具有不可否認(rèn)性。問題8:有了數(shù)字證書將公/私鑰和身份綁定，又有權(quán)威機(jī) 構(gòu)提供時鐘服務(wù)使其具有不可否認(rèn)性， 是不是就萬無一失了？不，仍 然有問題。乙還是不能證明對方就是甲，因為完全有可能是別人盜用 了甲的私鑰（如別人趁甲不在使用甲的電腦）,然后以甲的身份來 和乙傳送信息，這怎么解決呢？解決辦法是使用強(qiáng)口令、認(rèn)證令牌、智能卡和生物特征等技術(shù) 對使用私鑰的用戶進(jìn)行認(rèn)證，以確定其是私鑰的合法使用者。解決這個問題之前我們先來看看目前實現(xiàn)的基于 PKI的認(rèn)證

12、 通常是如何工作的。以瀏覽器或者其他登記申請證書的應(yīng)用程序為例 說明，在第一次生成密鑰的時候會創(chuàng)建一個密鑰存儲， 瀏覽器用戶會 被提示輸入一個口令，該口令將被用于構(gòu)造保護(hù)該密鑰存儲所需的加 密密鑰。如果密鑰存儲只有脆弱的口令保護(hù)或根本沒有口令保護(hù)，那么任何一個能夠訪問該電腦瀏覽器的用戶都可以訪問那些私鑰和證 書。在這種場景下，又怎么可能信任用 PKI創(chuàng)建的身份呢？正因為 如此，一個強(qiáng)有力的PKI系統(tǒng)必須建立在對私鑰擁有者進(jìn)行強(qiáng)認(rèn)證 的基礎(chǔ)之上，現(xiàn)在主要的認(rèn)證技術(shù)有：強(qiáng)口令、認(rèn)證令牌、智能卡和生物特征（如指紋，眼膜等認(rèn)證）以認(rèn)證令牌舉例：假設(shè)用戶的私鑰被保存在后臺服務(wù)器的加密容器里，要訪問私鑰，

13、用戶必須先使用認(rèn)證令牌認(rèn)證（如用戶輸入賬 戶名、令牌上顯示的通行碼和 PIN等），如果認(rèn)證成功，該用戶的 加密容器就下載到用戶系統(tǒng)并解密。通過以上問題的解決，就基本滿足了安全發(fā)送文件的需求。 下 面總結(jié)一下這個過程，對甲而言整個發(fā)送過程如下：1. 創(chuàng)建對稱密鑰（相應(yīng)軟件生成，并且是一次性的），用 其加密合同，并用乙的公鑰打包對稱密鑰。2. 創(chuàng)建數(shù)字簽名，對合同進(jìn)行散列算法（如MD5算法）并 產(chǎn)生原始摘要，甲用白己的私鑰加密該摘要（公/私鑰既可白己創(chuàng) 建也可由CA提供）。3. 最后，甲將加密后的合同、打包后的密鑰、加密后的摘要， 以及甲的數(shù)字證書（由權(quán)威機(jī)構(gòu)CA簽發(fā)）一起發(fā)給乙。而乙接收加密文件后，需要完成以下動作：1. 接收后，用乙的私鑰解密得到對稱密鑰，并用對稱密鑰解開加密的合同，得到合同明文。2.