資訊與網路安全技術：第十三章 用戶認證系統  上一頁      下一頁

 

13-4 單向認證協定

內容：

  • 13-4-1 單向認證簡介

  • 13-4-2 單向共享密鑰認證：明文盤問

  • 13-4-3 單向共享密鑰認證：密文盤問

  • 13-4-4 單向共享密鑰認證：時間戳記盤問

  • 13-4-5 單向公開鑰匙認證：私有鑰匙回應

  • 13-4-6 單向公開鑰匙認證：公開鑰匙盤問

13-4-1 單向認證簡介

『單向認證』（One-way Authentication）表示只能夠確認某一方的身份而已，一般是指回應者（如伺服器）確認發起者（如使用者）身份的認證協定。單向確認大多使用於系統登入方面的應用，至於電子商務方面，因為大多需要雙方的認證，所以不適合使用單向認證；儘管如此還是有很多應用系統僅採用單向認證來辨別要求服務者的身份。以下分別來討論兩種單向認證協定。

在一般主從式（Client/Server）應用系統之下，使用者大多需要在伺服器上建立一個帳戶，作為登入伺服器時使用，系統會利用使用者密碼建立了一個與使用者共享的『共享密鑰』（Shared Secret），每一個使用者分別與伺服器享有一個獨一無二的共享密鑰，這些觀念在前一小節已詳細介紹過（如圖 13-5 所示）。接下來，我們探討雙方如何利用此共享密鑰來認證身份。

就前一節的介紹，我們不希望將密碼（無論明文或密文）直接在網路上傳輸，然而，要如何驗證雙方所持有的共享密鑰是相同的。一般是由回應者（伺服端）擔任確認的工作，以確定發起者(客戶端)是自己的用戶沒錯，至於確認對方共享密鑰的方法，大多採用『盤問/回應』（Challenge /Response）認證協定， 以下介紹幾種做法。

13-4-2 單向共享密鑰認證 ：明文盤問

圖 13-9 為明文盤問機制，雙方所持有的共享密鑰為 KAlice-Bob。首先，發起者（Alice）向回應者（Bob）聲明身份（訊號 (1)）；Bob 收到對方聲明身份之後，便發送一個『盤問』（Challenge，由亂數R所構成）資料給 Alice（訊號 (2)）；Alice 收到盤問資料之後，將共享密鑰與 R 經過某一個演算法計算（f(KAlice-Bob, R)）之後，回傳給 Bob（訊號 (3)）；最後Bob 以自己所持有的共享密鑰與 R代入相同的演算法計算，所得的值與 Alice 傳送過來的值比較是否相同，即可確定發起者是否為 Alice。

圖 13-9 明文盤問的共享密鑰認證

其中計算 f(KAlice-Bob, R) 可以是雜湊演算法（如 MD4、MD5、HMAC）或加密演算法（如 DES），主要能將共享密鑰植入亂數 R 中即可，並非真的要隱藏亂數 R，因此，只要雙方協議好採用何種演算法即可。明文盤問協定的特性如下：

  • 僅回應者可以利用共享密鑰來確認發起者的身份，而發起者祇能以對方網路位址去確定所欲通訊者的身份。

  • 攻擊者可以利用IP 位址偽裝成回應者（如 Bob），以詐騙發起者（如 Alice）。

  • 攻擊者可以由網路上竊聽到盤問明文與回應密文，並以所得到的訊息破解出共享密鑰（因為演算法是公開的）。

  • 攻擊者可以入侵到回應者的資料庫中，尋找出發起者（如 Alice）的共享密鑰；只要能取得共享密鑰，完全不需要去破解出密碼，攻擊者照樣可以偽裝成發起者或回應者（Alice 或 Bob）。

  • 如果能取得共享密鑰，也有可能由共享密鑰破解出密碼；雖然很困難，但也不能說不可能。

值得注意的是，各種證認協定都有其優劣點，鮮有十全十美的認證協定；至於應該採用何種協定來實現，完全視應用系統安全性的考量而定。也就是說，一般安全性較高的認證協定，可能需要的運作程序較複雜，至於一些簡單的系統，能省則省。

13-4-3 單向共享密鑰認證 ：密文盤問

圖 13-10 為另一種變形，回應者利用加密後的密文盤問發起者，可以稍微改善明文盤問的缺點。回應者（如 Bob）先利用共享密鑰將盤問訊息（亂數，R）加密，之後再傳送給發起者（如 Alice）；如果發起者能將其解密回原來的明文，便能確定它所持有的密鑰與回應者相同，同時可以確定發起者的身份（真的是 Alice）。密文盤問的特性如下：

  • 回應者必須採用可逆的加密演算法（KAlice-Bob[R]），而不可以使用單向加密或單向雜湊演算法；亦是，加密後的密文是可以反解密成明文。

  • 攻擊者可由網路竊取亂數的明文與密文、以及公開的加密演算法，從中可以破解出雙方共享密鑰（KAlice-Bob），這要比由單向雜湊碼中破解共享密鑰容易得多了。

  • 攻擊者無法偽裝成回應者的身份（利用網路位址），但可偽裝成發起者以騙取更多的盤問密文。

圖 13-10 密文盤問的共享密鑰認證

13-4-4 單向共享密鑰認證 ：時間戳記盤問

前面兩種認證協定最大的缺點，是需要一個盤問的明文（R）在網路上傳輸；如果能利用雙方都認定的亂數，並且可以隨時改變其數值，以取代這個亂數便能解決一部份問題。有一種可能，倘若雙方時序能達到同步的話（接近於同步，至少不要相差太遠），便能利用隨時變動的『時間戳記』（Timestamp）來取代亂數 R，其運作情形如圖 13-11 所示。圖 13-11 (a) 係採用加密演算法，發起者（如 Alice）將共享密鑰作為加密鑰匙，向當時的時間戳記加密，再傳送給回應者（如 Bob），回應者同樣利用共享密鑰向該訊息解密，再比較加密後的時間戳記與自己當時的時間戳記之間的差異，倘若兩者相差在容許的範圍之內，表示回應者可以確認發起者的身份（Alice）。

圖 13-11 (b) 係採用雜湊演算法將共享密鑰植入時間戳記裡。發起者將時間戳記與共享密鑰一起加入雜湊演算法中計算，之後將所得到的雜湊值與時間戳記傳送給回應者。回應者首先比較所收到的時間戳記是否在可容許範圍，如果可以的話，再以同樣的演算法計算出雜湊值，其中會用到發起者的時間戳記與自己擁有的共享密鑰；如果收到的與自己計算的雜湊值相同的話，便可以確定發起者的身份。

圖 13-11 時間戳記的共享密鑰認證

當然囉！攻擊者也可以將它的時序調整到回應者可以接受的範圍，再來攫取時間戳記的密文，這種破解技巧大多與前面兩種協定相同。但簡化的協定比較難觀察出正從事於身份認證的訊息（只有一筆訊息），這對整個運作程序而言，比較有隱密性的功能。另一方面，加入時間戳記亦可防禦重播攻擊，接下來會介紹到。

13-4-5 單向公開鑰匙認證 ：私有鑰匙回應

許多系統利用公開鑰匙認證對方的身份，圖 13-12 就是利用公開鑰匙達成單向認證的運作協定；執行該協定之前，發起者（如 Alice）必須擁有公開鑰匙配對 {KRa, KUa}，其中前者為私有鑰匙，後者為公開鑰匙，回應者（如 Bob）必須取得 Alice 的公開鑰匙（KUa）。公開鑰匙的單向認證有下列兩種實現方法。  

圖 13-12 (a) 為私有鑰匙回應的運作程序。Alice 發送帳戶名稱之後（訊號 (1)），Bob 利用一個亂數 R 來盤問 Alice（訊號 (2)），接下來，Alice 利用自己的私有鑰匙向該盤問訊息簽署（EKRa[R]，假設使用加密方法），再回傳給 Bob，最後Bob 再利用對方的公開鑰匙（KUa）驗證該簽署碼是否正確，如果正確的話，則表示對方確實是 Alice 無誤。

基本上，盤問訊息都是 32 位元的亂數，大多無需採用加密演算法，僅採用數位簽章技巧（如 DSS）即可，所以發起者將 32 位元的亂數簽署後得到一個簽署碼，再回傳給回應者，而回應者則利用另外一把鑰匙認證該簽署碼是否正確。

圖 13-12 公開鑰匙的單向認證協定

13-4-6 單向公開鑰匙認證 ：公開鑰匙盤問

圖 13-12 (b) 是公開鑰匙認證的另一種變形。回應者（如 Bob）利用發起者的公開鑰匙（KUa），向亂數 R 加密之後（EKUa[R]），再以此密文來盤問發起者（如 Alice）；如果發起者能用自己的私有鑰匙向該密文解密回明文的話，則回應者便能確定它的身份無誤（真的是 Alice）。這種認證協定必須採用可逆的加密演算法，不可以採用單向的數位簽章技巧，否則發起者無法將盤問密文解密回原來的明文。

看起來，公開鑰匙認證協定好像比較安全，問題是如果分配與儲存公開鑰匙。如果回應者（伺服器）系統內儲存許多使用者的公開鑰匙，攻擊者只要入侵到系統內修改這些公開鑰匙，便可以達到欺騙回應者（伺服器）的手段，何況這些公開鑰匙也不是什麼機密。因此，利用公開鑰匙達到單向認證，通常需要其他機制的輔助才行，譬如，數位憑證或 PKI 系統等等（第七、九章介紹）。

翻轉工作室：粘添壽

 

資訊與網路安全技術

 

 

翻轉電子書系列：