U盾的工做原理

你的數字證書有一對，一份在U盾裏的私鑰，一份在銀行的公鑰(其實兩份銀行都有)
U盾的原理很相似於雙向認證的TLS(SSL)或者其它用到RSA的雙向證書驗證手段，如下步驟可能和U盾實際執行的有所區別，但本質相同：

--銀行先給你一個"衝擊"，它包含了隨機數，以及該隨機數HASH，它們都由公鑰加密，這樣就能夠保證只有你能解密這個"衝擊"
--你計算該隨機數的HASH，並和用私鑰解出的HASH，二者相同後，即可確認銀行的身份
--接下來，以一個只有你和銀行知道的算法，利這個隨機數和一些其它信息，生成"響應"和相應的HASH，再用私鑰加密後發回銀行。(此時銀行也以相同的算法計算該"響應")
--銀行用公鑰解密，並驗證HASH正確，接下來銀行比較兩個"相應"是否相同，相同的話客戶的身份也確認了

至於私鑰的保密性由U盾來完成。U盾的控制芯片被設計爲只能寫入證書，不能讀取證書，而且全部利用證書進行的運算都在U盾中進行。因此，只能從U盾讀出運算結果。

ps:

和日常登陸HTTPS網站不同的是，通常HTTPS在TLS握手時，只要驗證服務器身份成功即可完成握手。

接下來之前面的"隨機數"導出對稱加密算法的密鑰，開始加密連接

網絡的發展，出現了電子商務，而且迅速地發展。電子商務有着無比的優越性：方便，高效，快速，經濟等，被人們推崇。但涉及到錢的問題，因此對安全很明感，必需要有一整套的安全措施來保障交易的安全。
傳統的安全保障措施就是用戶名和密碼，顯而易見，這是很不安全的。IC卡：是一種內置集成電路的芯片，芯片中存有與用戶身份相關的數據。IC卡由專門的設 備生產，是不可複製的硬件。IC卡由合法用戶隨身攜帶，登陸時必須將IC卡插入專用的讀卡器讀取其中的信息，以驗證用戶的身份。簡單易行,但容易被留駐內 存的***或網絡監聽等***技術竊取。
如今的網絡支付中存在着不少缺陷：(1) 網絡數據流的：在用戶和銀行交易的過程當中，被第三方經過各類方法截獲數據流，分析數據中的信息從而獲得用戶的信息。(2) ***的竊聽：用戶電腦中了病毒或者***以後，電腦被監聽，用戶和銀行交易的信息被***記錄，用戶的信息就這樣被盜了。(3) 窮舉***：擊者使用有意義的數字做爲密碼來不斷嘗試持卡人的密碼。若是持卡人的密碼是未通過改動的初始密碼或一個特殊、容易被分析的數字，則密碼很容易被 ***者窮舉出來。(4) 網絡釣魚：第三方利用銀行的身份給用戶發信息，要求用戶提供帳號和密碼，若是用戶提供了的話就泄露了本身的信息了。或者是第三方假冒銀行或者交易的網站， 對沒有認真辨別的狀況下，用戶很容易上當從而泄露本身的信息。網絡的安全隱患不只僅是這些。
U盾的出現就是解決上面所說的安全問題。U盾，即工行2003年推出的客戶證書USBkey，，是工商銀行爲客戶提供的辦理網上銀行業務的高級別安全工 具。它是一個帶智能芯片、形狀相似於閃存的實物硬件，時刻保護着您的網上銀行資金安全。從技術角度看，U盾是用於網上銀行電子簽名和數字認證的工具，它內 置微型智能卡處理器，基於PKI技術，採用1024位非對稱密鑰算法對網上數據進行加密、解密和數字簽名，確保網上交易的保密性、真實性、完整性和不能否 認性。它設備雖然小巧，但技術含量極高。該產品採用了目前國際領先的信息安全技術，核心硬件模塊採用智能卡CPU芯片，內部結構由CPU及加密邏輯、 RAM、ROM、EEPROM和I/O五部分組成，是一個具備安全體系的小型計算機。除了硬件，安全實現徹底取決於技術含量極高的智能卡芯片操做系統 (COS)，該操做系統就象DOS、WINDOWS等操做系統同樣，管理着與信息安全密切相關的各類數據、密鑰和文件，並控制各類安全服務。USBKey 具備硬件真隨機數發生器，密鑰徹底在硬件內生成，並存儲在硬件中，可以保證密鑰不出硬件，硬件提供的加解密算法徹底在加密硬件內運行。
U盾的安全措施
1.硬件PIN碼保護
U盾採用了使用以物理介質爲基礎的我的客戶證書，創建基於公鑰PKI技術的我的證書認證體系(PIN碼)。***須要同時取得用戶的U盾硬件以及用戶的 PIN碼，才能夠登陸系統。即便用戶的PIN碼泄露，U盾沒有丟失，合法用戶的身份就不會被仿冒，若是用戶U盾丟失，其餘人不知道用戶的PIN碼，這也是 沒法假冒合法用戶的身份。
2.安全的密鑰存放
U盾的密鑰存儲於內部的智能芯片中，用戶沒法從外部直接讀取，對密鑰文件的讀寫和修改都必須由U盾內部的CPU調用相應的程序文件執行，從而U盾接口的外面，沒有任何一條指令能對密鑰區的內容進行讀取、修改、更新和刪除，這樣能夠保證***沒法利用非法程序修改密鑰。
3.雙密鑰密碼體制
爲了提升交易的安全，U盾採用了雙鑰密碼體制保證安全性，在U盾初始化的時候，先將密碼算法程序燒製在ROM中，而後經過產生公私密鑰對的程序生成一對公 私密鑰，公私密鑰產生後，密鑰能夠導出到U盾外，而私鑰則存儲於密鑰區，不容許外部訪問。進行數字簽名時以及非對稱解密運算時，凡有私參與的密碼運算只 在芯片內部便可完成，全程私鑰能夠不出U盾介質，從而來保證以U盾爲存儲介質的數字證書認證在安全上無懈可擊。
4.硬件實現加密算法
U盾內置CPU或智能卡芯片，能夠實現數據摘要、數據加解密和簽名的各類算法，加解密運算在U盾內進行，保證了用戶密鑰不會出如今計算機內存中。
(二)U盾進行銀行和客戶身份的雙向認證
一、基於衝擊-響應認證模式
  USB Key內置單向散列算法（RSA），預先在USB Key和服務器中存儲一個證實用戶身份的密鑰，當須要在網絡上驗證用戶身份時，先由客戶端向服務器發出一個驗證請求。服務器接到此請求後生成一個隨機數回 傳給客戶端PC上插着的USB Key，此爲「衝擊」。USB Key使用該隨機數與存儲在USB Key中的密鑰進行RSA運算獲得一個運算結果做爲認證證據傳送給服務器，此爲「響應」。與此同時，服務器使用該隨機數與存儲在服務器數據庫中的該客戶密 鑰進行RSA運算，若是服務器的運算結果與客戶端傳回的響應結果相同，則認爲客戶端是一個合法用戶。
2.基於PKI的數字證書的認證模式
PKI（Public Key Infrastructure）即公共密鑰體系，即利用一對互相匹配的密鑰進行加密、解密。一個公共密鑰（公鑰，public key）和一個私有密鑰（私鑰，private key）。其基本原理是：由一個密鑰進行加密的信息內容，只能由與之配對的另外一個密鑰才能進行解密。公鑰能夠普遍地發給與本身有關的通訊者，私鑰則須要十 分安全地存放起來。
  每一個用戶擁有一個僅爲本人所掌握的私鑰，用它進行解密和簽名；同時擁有一個公鑰用於文件發送時加密。當發送一份保密文件時，發送方使用接收方的公鑰對數據 加密，而接收方則使用本身的私鑰解密，這樣，信息就能夠安全無誤地到達目的地了，即便被第三方截獲，因爲沒有相應的私鑰，也沒法進行解密。
  衝擊響應模式能夠保證用戶身份不被仿冒，但沒法保證認證過程當中數據在網絡傳輸過程當中的安全。 而基於PKI的「數字證書認證方式」能夠有效保證用戶的身份安全和數據傳輸安全。數字證書是由可信任的第三方認證機構——數字證書認證中心 （Certficate Authority,CA）頒發的一組包含用戶身份信息（密鑰）的數據結構，PKI體系經過採用加密算法構建了一套完善的流程，保證數字證書持有人的身份 安全。而使用USB Key能夠保障數字證書沒法被複制，全部密鑰運算在USB Key中實現，用戶密鑰不在計算機內存出現也不在網絡中傳播，只有USB Key的持有人才可以對數字證書進行操做，安全性有了保障。因爲USB Key具備安全可靠，便於攜帶、使用方便、成本低廉的優勢，加上PKI體系完善的數據保護機制，使用USB Key存儲數字證書的認證方式已經成爲目前主要的認證模式。 
(三)U盾的交易過程
使用U盾前，通常都要安裝驅動，使U盾能正常工做。另外安裝數字證書認證身份。當用戶須要交易向銀行提交訂單要支付的時候，這時要驗證用戶的身份，系統提 示用戶插入U盾，並輸入U盾的密碼，系統會在後臺驗證，用戶看不到過程，一經驗證經過，用戶就可使用繼續輸入網上支付密碼和驗證碼，驗證都正確後交易就 完成 。有了U盾，交易就是很安全的，能夠說是無懈可擊。

     隨着電子商務的迅速發展，信息安全已成爲焦點問題之一，尤爲是網上支付和網絡銀行對信息安全的要求顯得更爲突出。爲了能在因特網上開展安全的電子商務活 動，公開密鑰基礎設施（ PKI, Public Key Infrastructure ）逐步在國內外獲得普遍應用。咱們是否真的需 要 PKI ， PKI 究竟有什麼用？下面經過一個案例一步步地來剖析這個問題 : 甲想將一份合同文件經過 Internet 發給遠在國外的乙，此 合同文件對雙方很是重要，不能有絲毫差錯，並且此文件絕對不能被其餘人得知其內容。如何才能實現這個合同的安全發送？ 
問題 1: 最天然的想法是，甲必須對文件加密才能保證不被其餘人查看其內容，那麼 , 到底應該用什麼加密技術，才能使合同傳送既安全又快速呢 ? 
    能夠採用一些成熟的對稱加密算法 , 如 DES 、 3DES 、 RC5 等對文件加密。對稱加密採用了對稱密碼編碼技術，它的特色是文件加密和解密使用相同的密鑰，即加密密鑰也能夠用作解密密鑰，這種方法在密碼學中叫作對稱加密算法， 

問題 2: 若是***截獲此文件，是否用同一算法就能夠解密此文件呢 ? 
    不能夠 , 由於加密和解密均須要兩個組件 : 加密算法和對稱密鑰 , 加密算法須要用一個對稱密鑰來解密 , ***並不知道此密鑰。 

問題 3: 既然***不知密鑰，那麼乙怎樣才能安全地獲得其密鑰呢？用電話通知，若電話被竊聽，經過 Internet 發此密鑰給乙，可能被***截獲，怎麼辦 ? 
    方法是用非對稱密鑰算法加密對稱密鑰後進行傳送。與對稱加密算法不一樣，非對稱加密算法須要兩個密鑰：公開密鑰（ Public Key ）和私有 密鑰（ Private Key ）。公開密鑰與私有密鑰是一對，若是用公開密鑰對數據進行加密，只有用對應的私有密鑰才能解密；若是用私有密鑰對數據進 行加密，只有用對應的公開密鑰才能解密。由於加密和解密使用的是兩個不一樣的密鑰，因此這種算法叫作非對稱加密算法 ( 公 / 私鑰可由專門軟件生 成 ) 。甲乙雙方各有一對公 / 私鑰，公鑰可在 Internet 上傳送，私鑰本身保存。這樣甲就能夠用乙的公鑰加密問題 1 中提到的對稱加密算 法中的對稱密鑰。即便***截獲到此密鑰，也會由於***不知乙的私鑰，而解不開對稱密鑰，所以也解不開密文，只有乙才能解開密文。 

問題 4 ：既然甲能夠用乙的公鑰加密其對稱密鑰，爲何不直接用乙的公鑰加密其文件呢？這樣不只簡單，並且省去了用對稱加密算法加密文件的步驟？ 
    不能夠這麼作。由於非對稱密碼算法有兩個缺點 : 加密速度慢 , 比對稱加密算法慢 10 ～ 100 倍 , 所以只可用其加密小數 據 ( 如對稱密鑰 ) ，另外加密後會致使獲得的密文變長。所以通常採用對稱加密算法加密其文件 , 而後用非對稱算法加密對稱算法所用到的對稱密 鑰。 

問題 5 ： 若是***截獲到密文，一樣也截獲到用公鑰加密的對稱密鑰，因爲***無乙的私鑰，所以他解不開對稱密鑰，但若是他用對稱加密算法加密一份假文 件 , 並用乙的公鑰加密一份假文件的對稱密鑰，併發給乙，乙會覺得收到的是甲發送的文件，會用其私鑰解密假文件 , 並很高興地閱讀其內容，但殊不知已 經被替換。換句話說，乙並不知道這不是甲發給他的，怎麼辦 ? 
    答案是用數字簽名證實其身份。數字簽名是經過散列算法 , 如 MD5 、 SHA-1 等算法從大塊的數據中提取一個摘要。而從這個摘要中不能 經過散列算法恢復出任何一點原文，即獲得的摘要不會透露出任何最初明文的信息，但若是原信息受到任何改動，獲得的摘要卻確定會有所不一樣。所以甲能夠對文件 進行散列算法獲得摘要，並用本身的私鑰加密 ( 由於非對稱算法可逆，即用私鑰可解開公鑰加密的文件，反之亦然 ) ，這樣即便***截獲也無用。由於*** 不會從摘要內得到任何信息，但乙卻不同，他可用甲的公鑰解密，獲得其摘要 ( 若是用甲的公鑰可以解開此摘要，說明此摘要確定是甲發的，由於只有甲的公 鑰才能解開用甲的私鑰加密的信息 , 而甲的私鑰只有甲本身知道 ) ，並對收到的文件 ( 解密後的合同文件 ) 也進行一樣的散列算法，經過比較其摘 要是否同樣 , 就可得知此文件是否被篡改過  ( 由於若摘要相同，則確定信息未被改動，這是散列算法的特色 ) 。這樣不只解決了證實發送人身份的問 題，同時還解決了文件是否被篡改問題。 

問題 6 ： 經過對稱加密算法加密其文件，再經過非對稱算法加密其對稱密鑰 , 又經過散列算法證實其發送者身份和其信息的正確性，這樣是否就萬無一失了 ? 
    回答是否認的。問題在於乙並不能確定他所用的所謂甲的公鑰必定是甲的 , 解決辦法是用數字證書來綁定公鑰和公鑰所屬人。 
    數字證書是一個經證書受權中心數字簽名的包含公開密鑰擁有者信息以及公開密鑰的文件 , 是網絡通訊中標識通訊各方身份信息的一系列數據，它提供 了一種在 Internet 上驗證身份的方式，其做用相似於司機的駕駛執照或平常生活中的×××，人們能夠在交往中用它來識別對方的身份。 
    最簡單的證書包含一個公開密鑰、名稱以及證書受權中心的數字簽名。通常狀況下證書中還包括密鑰的有效時間、發證機關 ( 證書受權中心 ) 名 稱、該證書的序列號等信息。它是由一個權威機構—— CA 機構，又稱爲證書受權 (Certificate Authority) 中心發放 的。 CA 機構做爲電子商務交易中受信任的第三方，承擔公鑰體系中公鑰的合法性檢驗的責任。 CA 中心爲每一個使用公開密鑰的用戶發放一個數字證書，數 字證書的做用是證實證書中列出的用戶合法擁有證書中列出的公開密鑰。 CA 機構的數字簽名使得***者不能僞造和篡改證書， CA 是 PKI 的核心， 負責管理 PKI 結構下的全部用戶（包括各類應用程序）的證書，把用戶的公鑰和用戶的其餘信息捆綁在一塊兒，在網上驗證用戶的身份。 
    由於數字證書是公開的，就像公開的電話簿同樣，在實踐中，發送者（即甲）會將一份本身的數字證書的拷貝連同密文、摘要等放在一塊兒發送給接收者（即 乙），而乙則經過驗證證書上權威機構的簽名來檢查此證書的有效性（只需用那個可信的權威機構的公鑰來驗證該證書上的簽名就能夠了），若是證書檢查一切正 常，那麼就能夠相信包含在該證書中的公鑰的確屬於列在證書中的那我的（即甲）。 

問題 7 ： 至此彷佛很安全了。但仍存在安全漏洞，例如：甲雖將合同文件發給乙 , 但甲拒不認可在簽名所顯示的那一時刻簽署過此文件 ( 數字簽名就至關於書面合同的文字簽名 ) ，並將此過錯歸咎於電腦，進而不履行合同，怎麼辦 ? 
    解決辦法是採用可信的時鐘服務 ( 由權威機構提供 ) ，即由可信的時間源和文件的簽名者對文件進行聯合簽名。在書面合同中，文件簽署的日期和 簽名同樣均是十分重要的防止文件被僞造和篡改的關鍵性內容 ( 例如合同中通常規定在文件簽署之日起生效 ) 。在電子文件中，因爲用戶桌面時間很容易改 變 ( 不許確或可人爲改變 ) ，由該時間產生的時間戳不可信賴，所以須要一個第三方來提供時間戳服務（數字時間戳服務（ DTS ）是網上安全服務項 目，由專門的機構提供）。此服務能提供電子文件發表時間的安全保護。 
    時間戳產生的過程爲 : 用戶首先將須要加時間戳的文件用哈希編碼加密造成摘要，而後將該摘要發送到 DTS ， DTS 在加入了收到文件摘要 的日期和時間信息後再對該文件加密（數字簽名），而後送回用戶。所以時間戳 (time-stamp) 是一個經加密後造成的憑證文檔，它包括三個部分： 需加時間戳的文件的摘要， DTS 收到文件的日期和時間， DTS 的數字簽名。因爲可信的時間源和文件的簽名者對文件進行了聯合簽名 , 進而阻止了 文檔簽名的那一方 ( 即甲方 ) 在時間上欺詐的可能性 , 所以具備不能否認性。 
問題 8: 有了數字證書將公 / 私鑰和身份綁定 , 又有權威機構提供時鐘服務使其具備不能否認性 , 是否是就萬無一失了 ? 不 , 仍然有問 題。乙仍是不能證實對方就是甲，由於徹底有多是別人盜用了甲的私鑰 ( 如別人趁甲不在使用甲的電腦 ), 而後以甲的身份來和乙傳送信息 , 這怎麼 解決呢 ? 
    解決辦法是使用強口令、認證令牌、智能卡和生物特徵等技術對使用私鑰的用戶進行認證，以肯定其是私鑰的合法使用者。 
    解決這個問題以前咱們先來看看目前實現的基於 PKI 的認證一般是如何工做的。以瀏覽器或者其餘登記申請證書的應用程序爲例說明，在第一次生成 密鑰的時候會建立一個密鑰存儲，瀏覽器用戶會被提示輸入一個口令，該口令將被用於構造保護該密鑰存儲所需的加密密鑰。若是密鑰存儲只有脆弱的口令保護或根 本沒有口令保護，那麼任何一個可以訪問該電腦瀏覽器的用戶均可以訪問那些私鑰和證書。在這種場景下 , 又怎麼可能信任用 PKI 建立的身份呢 ? 正 由於如此，一個強有力的 PKI 系統必須創建在對私鑰擁有者進行強認證的基礎之上，如今主要的認證技術有：強口令、認證令牌、智能卡和生物特徵（如指 紋，眼膜等認證）。 
    以認證令牌舉例 : 假設用戶的私鑰被保存在後臺服務器的加密容器裏，要訪問私鑰，用戶必須先使用認證令牌認證（如用戶輸入帳戶名、令牌上顯示的通行碼和 PIN 等），若是認證成功，該用戶的加密容器就下載到用戶系統並解密。 
經過以上問題的解決，就基本知足了安全發送文件的需求。下面總結一下這個過程 , 對甲而言整個發送過程以下 : 
1. 建立對稱密鑰 ( 相應軟件生成，而且是一次性的 ) ，用其加密合同，並用乙的公鑰打包對稱密鑰。 
2. 建立數字簽名，對合同進行散列算法 ( 如 MD5 算法 ) 併產生原始摘要，甲用本身的私鑰加密該摘要 ( 公 / 私鑰既可本身建立也可由 CA 提供 ) 。 
3. 最後 , 甲將加密後的合同、打包後的密鑰、加密後的摘要 , 以及甲的數字證書 ( 由權威機構 CA 簽發 ) 一塊兒發給乙。 
而乙接收加密文件後，須要完成如下動做 : 
1. 接收後，用乙的私鑰解密獲得對稱密鑰 , 並用對稱密鑰解開加密的合同 , 獲得合同明文。 
2. 經過甲的數字證書得到屬於甲的公鑰 , 並用其解開摘要 ( 稱作摘要 1) 。 
3. 對解密後的合同使用和發送者一樣的散列算法來建立摘要 ( 稱作摘要 2) 。 
4. 比較摘要 1 和摘要 2, 若相同 , 則表示信息未被篡改 , 且來自於甲。 
    甲乙傳送信息過程看似並不複雜 , 但實際上它由許多基本成分組成 , 如 : 對稱 / 非對稱密鑰密碼技術、數字證書、數字簽名、證書發放機構（ CA ）、公開密鑰的安全策略

等 , 這其中最重要、最複雜的是證書發放機構（ CA ）的構建。

1、什麼是U盾

　　U盾，即工行2003年推出並得到國家專利的客戶證書USBkey，是工行爲您提供的辦理網上銀行業務的高級別安全工具。它外形酷似U盤，像一面盾牌，時刻保護着您的網

上銀行資金安全。

　　從技術角度看，U盾是用於網上銀行電子簽名和數字認證的工具，它內置微型智能卡處理器，採用1024位非對稱密鑰算法對網上數據進行加密、解密和數字簽名，確保網上

交易的保密性、真實性、完整性和不能否認性

]

【二。工做原理】

　　U盾又做移動數字證書，它存放着你我的的數字證書，並不可讀取。一樣，銀行也記錄着你的數字證書。

　　當你嘗試進行網上交易時，銀行會向你發送由時間字串，地址字串，交易信息字串，防重放***字串組合在一塊兒進行加密後獲得的字串A，你的U盾將跟據你的我的證書對字串A進行不可逆運算獲得字串B，並將字串B發送給銀行，銀行端也同時進行該不可逆運算，若是銀行運算結果和你的運算結果一致便認爲你合法，交易即可以完成，若是不一致便認爲你不合法，交易便會失敗。

　　(理論上，不一樣的字串A不會得出相同的字串B，即一個字串A對應一個惟一的字串B;可是字串B和字串A沒法得出你的數字證書，並且U盾具備不可讀取性，因此任何人都沒法獲行你的數字證書。而且銀行每次都會發不一樣的防重放字串(隨機字串)和時間字串，因此當一次交易完成後，剛發出的B字串便再也不有效。綜上所述，理論上U盾是絕對安全的****注意是理論上發生僞造機率大約爲2的80次方分之一，可是若是有像變形金剛中的那種DNAbasecomputer的話。。)