資訊與網路安全技術 第 十四章 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』(圖中表示為 RealmID)。

  • 選項(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) 中,使用者的要求身份確認(IDRealm)、協議門票的功能(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 V5RFC 15101993 年)並沒有將較新的演算法加入選項之中,規範內的完整性檢查的標準規範有:

  • CRC-32

  • RSA-MD4

  • RSA-MD5-DES

  • RSA-MD5

  • RSA-MD5-DES

  • DES-MAC

  • RSA-MD4-DES-k

  • DES-MAC-k

由此可見,Kerberos V5 也不例外,大多以 MACMessage 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 節介紹);另外,加入完整性檢查有 CRCCyclic Redundancy Check[3]MD4 MD5 等演算法。

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

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

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

其中 Checksum 欄位可能是 32 bitsCRC-32)或 128 bitsMD4MD5);Padding 欄位是將整個訊息補滿 64 bits 倍數的亂數。

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

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

14-7 結論

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

14-14 安全性的通訊

主講人:粘添壽博士

 

資訊與網路安全技術

資訊與網路安全技術