網銀u盾工作原理

2021-07-16 03:06:43 字數 4939 閱讀 7997

隨著電子商務的迅速發展,資訊保安已成為焦點問題之一,尤其是網上支付和網路銀行對資訊保安的要求顯得更為突出。為了能在網際網路上開展安全的電子商務活動,公開金鑰基礎設施( 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 

結構下的所有使用者(包括各種應用程式)的證書,把使用者的公鑰和使用者的其他資訊**在一起,在網上驗證使用者的身份

。 因為數字證書是公開的,就像公開的**簿一樣,

在實踐中,傳送者(即甲)會將乙份自己的數字證書的拷貝連同密文、摘要等放在一起傳送給接收者(即乙)

,而乙則通過驗證證書上權威機構的簽名來檢查此證書的有效性(

只需用那個可信的權威機構的公鑰來驗證該證書上的簽名就可以了

ps:權威機構公鑰是公開的,可驗證公鑰機構的簽名,進而證明證書中的公鑰是可信的

),如果證書檢查一切正常,那麼就可以相信包含在該證書中的公鑰的確屬於列在證書中的那個人(即甲)。

問題 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 

)的構建

網銀u盾工作原理

隨著電子商務的迅速發展,資訊保安已成為焦點問題之一,尤其是網上支付和網路銀行對資訊保安的要求顯得更為突出。為了能在網際網路上開展安全的電子商務活動,公開金鑰基礎設施 pki,public key infrastructure 逐步在國內外得到廣泛應用。我們是否真的需要 pki pki 究竟有什麼用?...

網銀u盾工作原理

隨著電子商務的迅速發展,資訊保安已成為焦點問題之一,尤其是網上支付和網路銀行對資訊保安的要求顯得更為突出。為了能在網際網路上開展安全的電子商務活動,公開金鑰基礎設施 pki,public key infrastructure 逐步在國內外得到廣泛應用。我們是否真的需要 pki pki 究竟有什麼用?...

網銀「交易密碼丟失U盾作廢」引質疑

前日,市民夏先生使用建設銀行網上銀行業務時,發現忘記了自己的usbkey u盾 交易密碼。建行客服人員告訴其忘記交易密碼,導致u盾失效,需重新購買。夏先生質疑此舉有 資源浪費 之嫌。前日,市民夏先生使用建設銀行網上銀行業務時,發現忘記了自己的usbkey u盾 交易密碼。建行客服人員告訴其忘記交易密...