資訊與網路安全技術：第十四章 Kerberos 認證系統  上一頁    

 

14-6 Kerberos V5 認證系統

內容：

隨著 Kerberos 漸漸普遍，系統亦不斷的擴張下，第四版本已漸不符新環境的需求，Kerberos V5 因而被發展出來，且已被發佈為 RFC 1510，許多應用系統也已率先安裝該版本，用來處理客戶與系統之間的認證問題。

14-6-1 Kerberos V5 系統簡介

制定 V5 的主要目的是為了解決 V4 兩個缺點：環境與技術上的缺點 [86]，以下分別說明之：

  • 加密系統：版本 V4 係使用非標準化的 DES 加密系統，也沒有讓客戶選擇的餘地；既然 DES 加密系統的安全性已漸不符所需，V5 可以讓客戶依安全性的考量，選擇不同的加密系統。

  • 網路協定：版本 V4 僅適用於 TCP/IP 網路上製作，而 V5 允許 Kerberos 安裝在不同的網路系統之中，譬如 OSI 網路。

  • 訊息格式：版本 V4 僅利用一般編碼方式來製作訊息格式，有些電腦系統為了合乎這種格式，而必須修改內部製作程序；然而，V5 利用標準化的 ASN.1 編碼方式來製作訊息，如此便可不受電腦系統的限制。

  • 門票壽命：版本 V4 係利用 8 個位元來表示門票的壽命，而計算單位是 5 分鐘，所以最長時間為 5 × 28分鐘（大約 21 小時）；在某些應用上，這個時間顯然不足夠。V5 則是依設定的起始和結束時間表示門票的壽命，所以使用者可任意設定。

  • 認證移轉：在版本 V4 上，服務伺服器的門票不能移轉，也就是說，欲要求不同伺服器服務時，需重新認證身份。V5 則具有認證轉移的功能，只需認證一次，便能在不同伺服器要求服務。

  • 領域之間確認：版本 V4 係利用 Kerberos 伺服器之間的信任關係來建立領域之間的認證。而V5 則是利用樹狀結構的階層從屬關係建立領域之間的確認，此架構較適合與目前『網域名稱系統』（DNS）相結合。

14-6-2 Kerberos V5 運作程序

大致上，版本 V5 的運作程序與 V4 相同，祇不過在訊息方面增加一些參數；V5 的運作程序如圖 14-12 所示（請先參考 V4 的運作程序，圖 14-9），在此先討論增加的那些參數：

  • 領域（Realm）：版本 V4 僅利用身份識別碼（ID）辨別使用者身份，V5 則增加領域的標示，如某一個使用者的識別為『Realm/Principal』（圖中表示為 Realm、ID）。

  • 選項（Options）：為了讓使用者有不同演算法與門票功能的選擇，V5 增加選項欄位供通訊雙方協議。

  • 時間參數（Times）：作為設定或表示門票的有效期限。發起者可利用此參數來要求所需的有效期限；門票發行者（AS 或 TGS）可將此參數設定於門票之內，以限制門票的使用期間。其中包含三個參數值：

        • From：門票起始時間。

        • Till：門票到期時間。

        • Rtime：門票需重新設定的時間。

  • 亂數（Nonce）：作為預防重播使用。發起者可隨意設定 Nonce 的值，回應者再依照發起者的值回傳。如此，回應者可以判斷該 Nonce 值的訊息是否回應過，發起者也可瞭解回應者是針對哪一個訊息作回應。譬如，訊息 (1) 中加入了 Nonce，則訊息 (2) 便依照該數值回應給使用者。

圖 14-12 Kerberos V5 協定之運作程序

版本 V5 將各種訊息都給予一個特殊的名稱（如圖 14-12 所示），並把『認證伺服器』（Authentication Server, AS）所授與通往『門票核准伺服器』（Ticket- Granting Server, TGS）的門票，稱之為『門票核准票』（Ticket-Granting Ticket, TGT），亦將TGS 所發行通往應用伺服器的門票，稱之為『服務門票』（Service Ticket, ST）。我們以圖 14-12 來說明其特殊功能：

  • 認證身份與取得 TGT 門票：此運作程序是使用者與 AS 之間利用 KRB_AS_REQ 與 KRB_AS_REP 兩個訊息來達成。訊息 (1) 中，使用者的要求身份確認（ID、Realm）、協議門票的功能（Option）、以及希望所申請 TGT 票中的有效期限（Times）；在訊息 (2) 中，如果 AS 伺服器同意對方的要求，則給予 TGT 門票，並載入該票的有效期間（Times），其中 Options 欄位可協議門票是『代理門票』（Proxy Ticket）、『前向轉送門票』（Forward Ticket）、或一般 TGT 門票。門票格式為：

TicketTGS = EKtgs [Flages || KA, TGS || RealmA || IDA || Times || Authen_Data]

  • 索取服務門票：使用者在 TGT 門票的有效期間內，都可以向 TGS 伺服器要求前往應用伺服器的服務門票（ST）；該運作程序是由 KRB_TGS_REQ 與 KRB_TGS_RSP 兩個訊息來完成。訊息 (3) 內有包含著協商安全機制的選項（Options）、有效期間（Times）、以及 TGT 門票。TGT 伺服器由認證碼（Authen_1A）與 TGT 票內所描述的使用者身份相符之後，並檢視使用者所提出的安全機制（Options）與所要求的應用伺服器（IDB）相符時，便發給前往該伺服器的服務門票（ST、訊號 (4)）。其中：

TicketB = EKb [Flages || KA, B || RealmA || IDA || Times || Authen_Data]

Authen_1A = EKa, tgs [IDA || RealmA || TS1]

  • 要求服務：當使用者持有某一應用伺服器的服務門票（ST）之後，則在該門票的有效期間，都可以向該伺服器要求服務（訊號 (5)），並攜帶本身的認證訊息（Authen_2A）；該運作程序是由 KRB_AP_REQ 與 KRB_AP_RSP 兩訊號來完成。應用伺服器回應使用者要求時（訊號 (6)），可能會指明使用哪一把子鑰匙（Subkey），這必須伺服器內有儲存該使用者的鑰匙版本，一般應用上，大多使用 TGS 所分配的會議鑰匙（KA, B）。另外序號（Seq#）表示每一通訊連線的序號，是被用來防禦重播攻擊的。其中：

Authen_2A = EKa, b [IDA || RealmA || TS2 || Subkey || Seq#]

14-6-3 Ticket 旗號

無論是 TGT 或 ST 門票都如圖 14-13 的格式，在 RFC 1510 中是利用 ASN.1 語法所描述；我們用圖形來描述它，或許能讓讀者更容易接受。未加密的部分包含有：版本（Version）、領域（Realm）、持有者名稱（Principal Name）；其它加密的參數已在前面介紹過，這裡不再重複。至於『門票旗號』（Ticket Flags）是作為表示該門票的屬性，以位元設定（True 或 False）表示某一功能的啟動否。較重要的旗號有：

圖 14-13 門票的格式

  • INITIAL：此旗號被設定，表示是起始門票，亦即是直接由 AS 伺服器所發出（TGT 門票），而非 TGS 伺服器所發出的。

  • PRE-AUTHENT：預先認證。此旗號如設定，表示在起始認證當中，使用者已在發佈門票之前取得 KDC 認證完成。

  • HW-AUTHENT：硬體認證。客戶端於起始認證時，會使用到硬體設備；某些客戶會利用硬體設備登入系統，如 IC 卡等，此時則需要設定此旗號。

  • RENEWABLE：可重新的。此旗號如設定，表示可以向 TGS 伺服器，申請更新另一個有效日期較長的門票。

  • MY-POSTSATE：可延長日期。可以根據此門票向 TGS 要求延長有效日期。

  • POSTDATE：已延長。此旗號如設定，表示此門票已延長過有效日期了。

  • PROXIABLE：可代理的。可依據此門票向 TGS 要求換發另一張其他網路位址的服務門票（Service Ticket）。

  • PROXY：此門票是屬於代理門票。

  • FORWARDABLE：可前向轉送的。可依據此門票向 TGS 要求換發另一張其他網路位址的門票核准票（TGT）。

  • FORWARDED：此門票已被前向轉送的。

14-6-4 安全機制選項

Kerberos V4 的加密演算法係採用非標準的 DES 模式 —『傳導式密文區塊串接』（Propagating Cipher Block Chaining, PCBC）模式，並已證明該模式不夠安全 [84]。Kerberos V5 提供選項欄位，可讓客戶依照傳輸資料安全性的需求，協議不同的密碼系統，並且這些密碼都屬於標準規範，較容易與其他應用系統銜接。Kerberos 將安全性區分為：『檢查集』（Checksum）與『加密系統』（Encryption）等兩個層次，其中檢查集僅包含完整性功能，加密系統則包含隱密性與完整性功能。

【（A）檢查集】

目前 Kerberos V5（RFC 1510，1993 年）並沒有將較新的演算法加入選項之中，規範內的完整性檢查的標準規範有：

  • CRC-32

  • RSA-MD4

  • RSA-MD5-DES

  • RSA-MD5

  • RSA-MD5-DES

  • DES-MAC

  • RSA-MD4-DES-k

  • DES-MAC-k

由此可見，Kerberos V5 也不例外，大多以 MAC（Message Authentication Code） 來製作完整性檢查的認證碼（除了 CRC-32 之外）。但為了增加複雜度，V5 將每一筆訊息之前加入一個『混亂碼』（Confounder），再經過雜湊演算法計算，同時將此混亂碼一併傳送給對方。

我們以 RSA-MD5-DES 為範例，來說明產生完整性檢查碼的方法與認證步驟。MAC 產生方法如下：

  • 選擇一個 64 位元亂數作為『混亂碼』（Cofounder）。

  • 將混亂碼放置於訊息前面，格式如下：

  • 將上述的訊息格式，經由 MD5 演算法計算後，得到一個 128 個位元的『訊息摘要』（Message Digest）。

  • 依照步驟 1 的方法，將訊息摘要附加在混亂碼之後，格式如下（192 個位元）：

  • 將通訊者所儲存於 KDC 的共享密鑰，與資料 F0F0F0F0F0F0F0F016之間作位元 XOR 運算，得到另一把新的鑰匙 K’。

  • 利用鑰匙 K’ 與起始向量為 0，將步驟 4 的訊息經由 DES 演算法的 CBC 模式計算（DES-CBC，請參考 2-7-2 節介紹），計算後得到一個 192 位元的 MAC 值，並將 MAC 值附加在訊息（M）後面一併傳送給對方（KDC 或使用者）。

接收者收到訊息之後，如何利用訊息中的 MAC 來確認訊息完整性，步驟如下：

    • 將使用者的共享密鑰與資料 F0F0F0F0F0F0F0F016之間作位元 XOR 運算，得到另一把新的鑰匙 K’（如同上述步驟 5）。

    • 利用鑰匙 K’ 向 MAC 解密，得到兩個欄位的訊息，其中X 表示混亂碼、Y 表示訊息摘要。

    • 再將上述的 X 欄位的內容，附加在所收到訊息（M’）的前面，格式如下：

    • 接著，再將上述的訊息經過 MD5 演算法計算後，得到一個 128 個位元的 MD’。如果 MD’ = Y，則訊息的完整性檢查是正確的；否則（MD’≠ Y）表示訊息可能遭受竄改或共享密鑰不正確（身份不對）。

由上述的範例可以看出，V5 的安全性比 V4 的 PCBC 安全性高許多。

【（B）加密系統】

Kerberos V5 的加密系統（Encryption）亦包含檢查碼（Checksum），所以除了提供隱密性功能，亦包含完整性檢查的功能；在 RFC 1510 上規範有下列加密系統：

  • Null

  • DES-CBC-CRC

  • DES-CBC-MD4

  • DES-CBC-MD5

基本上，還是以 DES 加密系統的 CBC 操作模式為基礎（請參考 2-7-2 節介紹）；另外，加入完整性檢查有 CRC（Cyclic Redundancy Check）[3]、MD4 與 MD5 等演算法。

接下來，我們來探討 Kerberos 加密系統的製作方法，步驟如下：

  • 選擇一個 64 位元亂數作為『混亂碼』（Cofounder）。

  • 利用該混亂碼與使用者的共享鑰匙，計算出完整性檢查碼（K5 稱為 Checksum），然而演算法可以是 CRC-32、RSA-MD4、RSA-MD5-DES 等等 V5 規範中的 Checksum 演算法。得到檢查碼之後，將訊息組合如下：

其中 Checksum 欄位可能是 32 bits（CRC-32）或 128 bits（MD4、MD5）；Padding 欄位是將整個訊息補滿 64 bits 倍數的亂數。

  • 再將上述的訊息經過 DES-CBC 演算法加密，則可得到隱密性的密文，再傳送給對方（使用者或 Kerberos 系統）。

雖然目前 Kerberos V5 並未將安全性較高的加密系統（如 ASE）或 MAC 演算法（如 SHA-1）加入規範之中，但我們相信這些系統應該漸漸會被植入 V5 系統之內。

14-7 結論

用戶認證算是比較複雜的運作系統，主要目的是要確認對方的身份、以及分配會議鑰匙；亦是，經過認證身份之後，再依照所分配的會議鑰匙來通訊。因此，一般安全性的通訊，可將通訊連線分為兩個階段，如圖 14-14 所示。第一階段係利用使用者主密鑰（KA、或稱共享密鑰）或公開鑰匙來確認身份。參與認證工作的系統可以是一個專屬系統（如 Kerberos）、或是將認證協定植入應用系統內（如 IKE 協定，第十七章介紹），由應用系統自行處理。經過第一階段處理無誤之後，使用者與應用伺服器兩者已取得會議鑰匙（KS），再進入第二階段處理。然而，第二階段主要採秘密鑰匙系統作傳輸資料，如此才可以提高傳輸效率，既然所分配的會議鑰匙可能只使用一次（或短時間使用），攻擊者欲於短時間內破解會議鑰匙，談何容易。此外，第二階段也許會採用不同的密碼系統（如 DES、ASE 或 RSA），各種密碼系統的鑰匙長度也不一樣，因此，認證系統在分配會議鑰匙時，應該會考慮到鑰匙的長度。但為了能合乎不同系統的需求，一般認證系統所分配鑰匙的長度都取較高位元（如 128 bits）；至於如何由此較長的鑰匙中，擷取出所需要會議鑰匙的長度（如 64 bits），可依照各應用系統的協定來規劃。

圖 14-14 安全性的通訊

翻轉工作室：粘添壽

 

資訊與網路安全技術

 

 

翻轉電子書系列：