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

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

2、，到底應(yīng)該用什么加密技術(shù)，才能 使合同傳送既安全又快速呢？可以采用一些成熟的對(duì)稱(chēng)加密算法，如 DES 3DES RC5等對(duì) 文件加密。對(duì)稱(chēng)加密采用了對(duì)稱(chēng)密碼編碼技術(shù)， 它的特點(diǎn)是文件加密 和解密使用相同的密鑰，即加密密鑰也可以用做解密密鑰， 這種方法 在密碼學(xué)中叫做對(duì)稱(chēng)加密算法，問(wèn)題2 :如果黑客截獲此文件，是否用同一算法就可以解密此文件呢？不可以，因?yàn)榧用芎徒饷芫枰獌蓚€(gè)組件： 加密算法和對(duì)稱(chēng)密鑰，加密算法需要用一個(gè)對(duì)稱(chēng)密鑰來(lái)解密，黑客并不知道此密鑰 問(wèn)題3 :既然黑客不知密鑰，那么乙怎樣才能安全地得到其 密鑰呢？用電話(huà)通知， 若電話(huà)被竊聽(tīng)，通過(guò)Internet發(fā)此密 鑰給乙，可能被黑客截獲

3、，怎么辦？方法是用非對(duì)稱(chēng)密鑰算法加密對(duì)稱(chēng)密鑰后進(jìn)行傳送。與對(duì)稱(chēng)加 密算法不同，非對(duì)稱(chēng)加密算法需要兩個(gè)密鑰：公開(kāi)密鑰(Public Key )和私有密鑰(Private Key )。公開(kāi)密鑰與私有密鑰是一對(duì)，如果用公開(kāi)密鑰對(duì)數(shù)據(jù)進(jìn)行加密，只有用對(duì)應(yīng)的私有密 鑰才能解密；如果用私有密鑰對(duì)數(shù)據(jù)進(jìn)行加密，只有用對(duì)應(yīng)的公開(kāi)密 鑰才能解密。因?yàn)榧用芎徒饷苁褂玫氖莾蓚€(gè)不同的密鑰，所以這種算法叫做非對(duì)稱(chēng)加密算法(公/私鑰可由專(zhuān)門(mén)軟件生成)。甲乙雙 方各有一對(duì)公/私鑰，公鑰可在In ternet 上傳送，私鑰自己保存。 這樣甲就可以用乙的公鑰加密問(wèn)題 1中提到的對(duì)稱(chēng)加密算法中的對(duì) 稱(chēng)密鑰。即使黑客截獲到此密鑰，

4、也會(huì)因?yàn)楹诳筒恢业乃借€，而解 不開(kāi)對(duì)稱(chēng)密鑰，因此也解不開(kāi)密文，只有乙才能解開(kāi)密文。問(wèn)題4 :既然甲可以用乙的公鑰加密其對(duì)稱(chēng)密鑰，為什么不 直接用乙的公鑰加密其文件呢？這樣不僅簡(jiǎn)單，而且省去了用對(duì)稱(chēng)加密算法加密文件的步驟？不可以這么做。因?yàn)榉菍?duì)稱(chēng)密碼算法有兩個(gè)缺點(diǎn)：加密速度慢， 比對(duì)稱(chēng)加密算法慢10100倍，因此只可用其加密小數(shù)據(jù)(如對(duì) 稱(chēng)密鑰)，另外加密后會(huì)導(dǎo)致得到的密文變長(zhǎng)。因此一般采用對(duì)稱(chēng) 加密算法加密其文件，然后用非對(duì)稱(chēng)算法加密對(duì)稱(chēng)算法所用到的對(duì)稱(chēng)密鑰問(wèn)題5:如果黑客截獲到密文，同樣也截獲到用公鑰加密的 對(duì)稱(chēng)密鑰，由于黑客無(wú)乙的私鑰，因此他解不開(kāi)對(duì)稱(chēng)密鑰， 但如果他用對(duì)稱(chēng)加密算法加密一

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

6、黑客截獲也無(wú)用。因?yàn)楹诳筒粫?huì)從摘要 內(nèi)獲得任何信息，但乙卻不一樣，他可用甲的公鑰解密，得到其摘 要（如果用甲的公鑰能夠解開(kāi)此摘要，說(shuō)明此摘要肯定是甲發(fā)的， 因?yàn)橹挥屑椎墓€才能解開(kāi)用甲的私鑰加密的信息， 而甲的私鑰只有 甲自己知道），并對(duì)收到的文件（解密后的合同文件）也進(jìn)行同 樣的散列算法，通過(guò)比較其摘要是否一樣，就可得知此文件是否被篡 改過(guò)（因?yàn)槿粽嗤?，則肯定信息未被改動(dòng)，這是散列算法的特 點(diǎn)）。這樣不僅解決了證明發(fā)送人身份的問(wèn)題，同時(shí)還解決了文件 是否被篡改問(wèn)題。問(wèn)題6 :通過(guò)對(duì)稱(chēng)加密算法加密其文件，再通過(guò)非對(duì)稱(chēng)算法 加密其對(duì)稱(chēng)密鑰，又通過(guò)散列算法證明其發(fā)送者身份和其信 息的正確性，這

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

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

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

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

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

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

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