跳至內容

Kerberos

本頁使用了標題或全文手工轉換
維基百科,自由的百科全書

Kerberos/ˈkərbərəs/)是一種電腦網絡授權協定,用來在非安全網絡中,對個人通訊以安全的手段進行身份認證。這個詞又指麻省理工學院為這個協定開發的一套電腦軟件。軟件設計上採用客戶端/伺服器結構,並且能夠進行相互認證,即客戶端伺服器端均可對對方進行身份認證。可以用於防止竊聽、防止重放攻擊、保護數據完整性等場合,是一種應用對稱金鑰體制進行金鑰管理的系統。Kerberos的擴充產品也使用公開金鑰加密方法進行認證。

當有N個人使用該系統時,為確保在任意兩個人之間進行秘密對話,系統至少儲存有它與每個人的共用金鑰,所需的最少對談金鑰數為N個。

歷史

[編輯]

麻省理工學院研發Kerberos協定來保護雅典娜工程(Project Athena)提供的網絡伺服器。這個協定以希臘神話中的人物Kerberos(或者Cerberus)命名,他在希臘神話中是Hades的一條兇猛的三頭保衛神犬。目前該協定存在一些版本,版本1-3都只有麻省理工內部發行。

Kerberos版本4的主要設計者Steve Miller和Clifford Neuman,在1980年代後期發佈這個版本。這個版本主要針對雅典娜工程。版本5由John Kohl和Clifford Neuman設計,在1993年作為 RFC 1510 頒佈(在2005年由 RFC 4120 取代),目的在於克服版本4的局限性和安全問題。

麻省理工在著作權許可的情況下,製作一個Kerberos的免費實現工具,這種情況類似於BSD。在2007年,麻省理工組成一個Kerberos協會,以此推動Kerberos的持續發展。

因為使用數據加密標準(DES)加密演算法(用56 bit的金鑰),美國出口管制當局把Kerberos歸類為軍需品,並禁止其出口。一個非美國設計的Kerberos版本4的實現工具KTH-KRB由瑞典皇家工學院研製,它使得這套系統在美國更改密碼出口管理條例前(大約是在2000年),在美國境外就可以使用。瑞典的實現工具基於一個叫做eBones的版本,而eBones基於麻省理工對外發行的基於Kerberos版本4的修補程式9的Bones(跳過加密公式和對它們的函數呼叫)。這些在一定程度上決定Kerberos為什麼沒有被叫做eBones版。Kerberos版本5的實現工具,Heimdal,基本上也是由發佈KTH-KRB的同一組人發佈。

在2005年,互聯網工程任務組(IETF)Kerberos工作小組更新了規範,更新包括:

  • "Kerberos 5加密和校驗和規範"(RFC 3961)。
  • "Kerberos 5進階加密標準(AES)加密"(RFC 3962)。
  • "Kerberos網絡認證服務(版本5)"(RFC 4120)—Kerberos版本5規範的新版本。這個版本廢棄早先的 RFC 1510,用更細化和明確的解釋說明協定的一些細節和使用方法。
  • "Kerberos 5通用安全服務應用程式介面(GSS-API)機制:版本2"(RFC 4121)—通用安全服務應用程式介面(GSS-API)規範的新版本。

Windows 2000和後續的作業系統使用Kerberos為其預設認證方法。RFC 3244 "微軟Windows 2000 Kerberos變更密碼與設置密碼協定" 記錄整理一些微軟對Kerberos協定軟件套件的添加。RFC 4757 記錄整理微軟對RC4密碼的使用。雖然微軟使用Kerberos協定,卻並沒有用麻省理工的軟件。

蘋果的Mac OS X也使用Kerberos的客戶和伺服器版本。Red Hat Enterprise Linux 4和後續的作業系統使用Kerberos的客戶和伺服器版本。

基本描述

[編輯]

Kerberos使用Needham-Schroeder協定作為它的基礎。它使用一個由兩個獨立的邏輯部分:認證伺服器和票據授權伺服器組成的"可信賴的第三方",術語稱為金鑰分發中心(KDC)。Kerberos工作在用於證明用戶身份的"票據"的基礎上。

KDC持有一個金鑰資料庫;每個網絡實體——無論是客戶還是伺服器——共用一套只有他自己和KDC知道的金鑰。金鑰的內容用於證明實體的身份。對於兩個實體間的通訊,KDC產生一個對談金鑰,用來加密他們之間的相互資訊。

協定內容

[編輯]

協定的安全主要依賴於參加者對時間的鬆散同步和短周期的叫做Kerberos票據的認證聲明。 下面是對這個協定的一個簡化描述,將使用以下縮寫:

  • AS(Authentication Server)= 認證伺服器
  • KDC(Key Distribution Center)= 金鑰分發中心
  • TGT(Ticket Granting Ticket)= 票據授權票據,票據的票據
  • TGS(Ticket Granting Server)= 票據授權伺服器
  • SS(Service Server)= 特定服務提供端

客戶端用戶傳送自己的用戶名到KDC伺服器以向AS服務進行認證。KDC伺服器會生成相應的TGT票據,打上時間戳,在本地資料庫中尋找該用戶的密碼,並用該密碼對TGT進行加密,將結果發還給客戶端用戶。該操作僅在用戶登入或者kinit申請的時候進行。 客戶端收到該資訊,並使用自己的密碼進行解密之後,就能得到TGT票據了。這個TGT會在一段時間之後失效,也有一些程式(session manager)能在用戶登陸期間進行自動更新。 當客戶端用戶需要使用一些特定服務(Kerberos術語中用「principal」表示)時,該客戶端就傳送TGT到KDC伺服器中的TGS服務。當該用戶的TGT驗證通過並且其有權訪問所申請的服務時,TGS服務會生成一個該服務所對應的ticket和session key,並行還給客戶端。客戶端將服務請求與該ticket一併傳送給相應的伺服器端即可。具體的流程請看下面的描述。

其在網絡通訊協定中屬於顯示層

簡單地說,用戶先用共用金鑰從某認證伺服器得到一個身份證明。隨後,用戶使用這個身份證明與SS通訊,而不使用共用金鑰。

具體流程[1]

[編輯]

(注意:此流程使用了對稱加密;此流程發生在某一個Kerberos領域中;小寫字母c,d,e,g是客戶端發出的訊息,大寫字母A,B,E,F,H是各個伺服器發回的訊息。)

首先,用戶使用客戶端(用戶自己的機器)上的程式進行登入:

  1. 用戶輸入用戶ID和密碼到客戶端。
  2. 客戶端程式執行一個單向函數(大多數為雜湊)把密碼轉換成金鑰,這個就是客戶端(用戶)的「用戶金鑰」(user's secret key)。

隨後,客戶端認證(客戶端(Client)從認證伺服器(AS)取得票據授權票據(TGT)):

  1. 客戶端向AS傳送1條明文訊息,申請基於該用戶所應享有的服務,例如「用戶Sunny想請求服務」(Sunny是用戶ID)。(注意:用戶不向AS傳送「用戶金鑰」,也不傳送密碼)該AS能夠從本地資料庫中查詢到該申請用戶的密碼,並通過相同途徑轉換成相同的「用戶金鑰」。
  2. AS檢查該用戶ID是否在於本地資料庫中,如果用戶存在則返回2條訊息:
    • 訊息A:客戶端/TGS對談金鑰(Client/TGS Session Key)(該對談金鑰用在將來客戶端與TGS的通訊(對談)上),通過「用戶金鑰」進行加密
    • 訊息B:TGT(TGT包括:訊息A中的「客戶端/TGS對談金鑰」,用戶ID,用戶網址,TGT有效期),通過「TGS金鑰」(TGS's secret key)進行加密
  3. 一旦客戶端收到訊息A和訊息B,客戶端首先嘗試用自己的「用戶金鑰」解密訊息A,如果用戶輸入的密碼與AS資料庫中的密碼不符,則不能成功解密訊息A。輸入正確的密碼並通過隨之生成的「用戶金鑰」才能解密訊息A,從而得到「客戶端/TGS對談金鑰」。(注意:客戶端不能解密訊息B,因為B是用「TGS金鑰」加密的)。擁有了「客戶端/TGS對談金鑰」,客戶端就足以通過TGS進行認證了。

然後,服務授權(客戶端從TGS取得票據(client-to-server ticket)):

  1. 當客戶端需要申請特定服務時,其向TGS傳送以下2條訊息:
    • 訊息c:即訊息B的內容(「TGS金鑰」加密後的TGT),和想取得的服務的服務ID(注意:不是用戶ID)
    • 訊息d:認證符(Authenticator)(Authenticator包括:用戶ID,時間戳),通過「客戶端/TGS對談金鑰」進行加密
  2. 收到訊息c和訊息d後,TGS首先檢查KDC資料庫中是否存在所需的服務,尋找到之後,TGS用自己的「TGS金鑰」解密訊息c中的訊息B(也就是TGT),從而得到之前生成的「客戶端/TGS對談金鑰」。TGS再用這個對談金鑰解密訊息d得到包含用戶ID和時間戳的Authenticator,並對TGT和Authenticator進行驗證,驗證通過之後返回2條訊息:
    • 訊息E:客戶端-伺服器票據(client-to-server ticket)(該票據包括:「客戶端/SS對談金鑰」(Client/Server Session Key),用戶ID,用戶網址,有效期),通過提供該服務的「伺服器金鑰」(service's secret key)進行加密
    • 訊息F:客戶端/SS對談金鑰(Client/Server Session Key)(該對談金鑰用在將來客戶端與SS的通訊(對談)上),通過「客戶端/TGS對談金鑰」進行加密
  3. 客戶端收到這些訊息後,用「客戶端/TGS對談金鑰」解密訊息F,得到「客戶端/SS對談金鑰」。(注意:客戶端不能解密訊息E,因為E是用「伺服器金鑰」加密的)。

最後,服務請求(客戶端從SS取得服務):

  1. 獲得「客戶端/SS對談金鑰」之後,客戶端就能夠使用伺服器提供的服務了。客戶端向指定SS發出2條訊息:
    • 訊息e:即上一步中的訊息E「客戶端-伺服器票據」,已通過「伺服器金鑰」進行加密
    • 訊息g:新的Authenticator(包括:用戶ID,時間戳),通過「客戶端/SS對談金鑰」進行加密
  2. SS用自己的「伺服器金鑰」解密訊息e從而得到TGS提供的「客戶端/SS對談金鑰」。再用這個對談金鑰解密訊息g得到Authenticator,(同TGS一樣)對票據和Authenticator進行驗證,驗證通過則返回1條訊息(確認函:確證身份真實,樂於提供服務):
    • 訊息H:新時間戳(新時間戳是:客戶端傳送的時間戳加1,v5已經取消這一做法),通過「客戶端/SS對談金鑰」進行加密
  3. 客戶端通過「客戶端/SS對談金鑰」解密訊息H,得到新時間戳並驗證其是否正確。驗證通過的話則客戶端可以信賴SS,並向SS傳送服務請求。
  4. SS向客戶端提供相應的服務。

缺陷

[編輯]
  • 單點故障:它需要中心伺服器的持續響應。當Kerberos服務宕機時,沒有人可以連接到伺服器。這個缺陷可以通過使用複合Kerberos伺服器和缺陷認證機制彌補。
  • Kerberos要求參與通訊的主機的時鐘同步。票據具有一定有效期,因此,如果主機的時鐘與Kerberos伺服器的時鐘不同步,認證會失敗。預設設置要求時鐘的時間相差不超過10分鐘。在實踐中,通常用網絡時間協定後台程式來保持主機時鐘同步。
  • 管理協定並沒有標準化,在伺服器實現工具中有一些差別。RFC 3244 描述了密碼更改。
  • 因為所有用戶使用的金鑰都儲存於中心伺服器中,危及伺服器的安全的行為將危及所有用戶的金鑰。
  • 一個危險客戶機將危及用戶密碼。

參考資料

[編輯]
  1. ^ William Stallings, Network Security Essentials: Application and Standards(Fourth Edition), Pearson Education, Inc. (Chapter 4 pp. 99-114)

延伸閱讀

[編輯]
  1. Novell Inc's Comment to the Proposed Settlement between Microsoft and the Department of Justice, pusuant to the Tunney Act. Civil Action No. 98-1232 (CKK): United States of America v. Microsoft Corporation. Department of Justice. 29 January 2002 [15 August 2012]. (原始內容存檔於2007-05-04). 
  2. Bryant, Bill. Designing an Authentication System: A Dialogue in Four Scenes. Humorous play concerning how the design of Kerberos evolved. MIT. February 1988 [2016-05-26]. (原始內容存檔於2007-03-29). 
  3. Hornstein, Ken. Kerberos FAQ, v2.0. Secretary of Navy. 18 August 2000 [15 August 2012]. (原始內容存檔於2002年12月3日). 

外部連結

[編輯]