Android教程網 >> Android技術 >> 關於Android編程 >> Kerberos安全體系詳解---Kerberos的簡單實現

Kerberos安全體系詳解---Kerberos的簡單實現

編輯：關於Android編程

1. Kerberos簡介

1.1. 功能

一個安全認證協議

用tickets驗證

避免本地保存密碼和在互聯網上傳輸密碼

包含一個可信任的第三方

使用對稱加密

客戶端與服務器（非KDC）之間能夠相互驗證

Kerberos只提供一種功能——在網絡上安全的完成用戶的身份驗證。它並不提供授權功能或者審計功能。

1.2. 概念

首次請求，三次通信方

the Authentication Serverthe Ticket Granting Serverthe Service or host machine that you’re wanting access to.

圖 1?1 角色

其他知識點

每次通信，消息包含兩部分，一部分可解碼，一部分不可解碼服務端不會直接有KDC通信KDC保存所有機器的賬戶名和密碼KDC本身具有一個密碼

2. 3次通信

我們這裡已獲取服務器中的一張表（數據）的服務以為，為一個http服務。

2.1. 你和驗證服務

如果想要獲取http服務，你首先要向KDC表名你自己的身份。這個過程可以在你的程序啟動時進行。Kerberos可以通過kinit獲取。介紹自己通過未加密的信息發送至KDC獲取Ticket Granting Ticket (TGT)。

（1）信息包含

你的用戶名/ID你的IP地址TGT的有效時間

Authentication Server收到你的請求後，會去數據庫中驗證，你是否存在。注意，僅僅是驗證是否存在，不會驗證對錯。

如果存在，Authentication Server會產生一個隨機的Session key(可以是一個64位的字符串)。這個key用於你和Ticket Granting Server (TGS)之間通信。

（2）回送信息

Authentication Server同樣會發送兩部分信息給你，一部分信息為TGT，通過KDC自己的密碼進行加密，包含：

你的name/IDTGS的name/ID時間戳你的IP地址TGT的生命周期TGS session key

另外一部分通過你的密碼進行加密，包含的信息有

TGS的name/ID時間戳生命周期TGS session key

圖 2?1 第一次通信

如果你的密碼是正確的，你就能解密第二部分信息，獲取到TGS session key。如果，密碼不正確，無法解密，則認證失敗。第一部分信息TGT，你是無法解密的，但需要展示緩存起來。

2.2. 你和TGS

如果第一部分你已經成功，你已經擁有無法解密的TGT和一個TGS Session Key。

（1）請求信息

　a) 通過TGS Session Key加密的認證器部分：

你的name/ID時間戳

b) 明文傳輸部分：

請求的Http服務名（就是請求信息）HTTP Service的Ticket生命周期

c) TGT部分

Ticket Granting Server收到信息後，首先檢查數據庫中是否包含有你請求的Http服務名。如果無，直接返回錯誤信息。

如果存在，則通過KDC的密碼解密TGT，這個時候。我們就能獲取到TGS Session key。然後，通過TGS Session key去解密你傳輸的第一部分認證器，獲取到你的用戶名和時間戳。

TGS再進行驗證：

對比TGT中的用戶名與認證器中的用戶名比較時間戳（網上有說認證器中的時間錯和TGT中的時間錯，個人覺得應該是認證器中的時間戳和系統的時間戳），不能超過一定范圍檢查是否過期檢查IP地址是否一致檢查認證器是否已在TGS緩存中（避免應答攻擊）可以在這部分添加權限認證服務

TGS隨機產生一個Http Service Session Key, 同時准備Http Service Ticket(ST)。

（2）回答信息

a) 通過Http服務的密碼進行加密的信息（ST）：

你的name/IDHttp服務name/ID你的IP地址時間戳ST的生命周期Http Service Session Key

b) 通過TGS Session Key加密的信息

Http服務name/ID時間戳ST的生命周期Http Service Session Key

你收到信息後，通過TGS Session Key解密，獲取到了Http Service Session Key，但是你無法解密ST。

圖 2?2 第二次通信

2.3. 你和Http服務

在前面兩步成功後，以後每次獲取Http服務，在Ticket沒有過期，或者無更新的情況下，都可直接進行這一步。省略前面兩個步驟。

（1）請求信息

a) 通過Http Service Session Key，加密部分

你的name/ID時間戳

b) ST

　Http服務端通過自己的密碼解壓ST（KDC是用Http服務的密碼加密的），這樣就能夠獲取到Http Service Session Key，解密第一部分。

服務端解密好ST後，進行檢查

對比ST中的用戶名（KDC給的）與認證器中的用戶名比較時間戳（網上有說認證器中的時間錯和TGT中的時間錯，個人覺得應該是認證器中的時間戳和系統的時間戳），不能超過一定范圍檢查是否過期檢查IP地址是否一致檢查認證器是否已在HTTP服務端的緩存中（避免應答攻擊）

（2）應答信息

a) 通過Http Service Session Key加密的信息

Http服務name/ID時間戳

圖 2?3 第三次通信

你在通過緩存的Http Service Session Key解密這部分信息，然後驗證是否是你想要的服務器發送給你的信息。完成你的服務器的驗證。

至此，整個過程全部完成。

3. 實現

github地址：https://github.com/wukenaihe/KerberosService

github上面的程序暫時還沒有詳細的說明。自己感覺設計的稍微有點亂。自己之所以要重新實現的原因就是現在MIT的kerberos、apache directory、Windows AD配置都相當麻煩，使用起來也非常麻煩。所以想從新設計一個簡單易用的，但是同時又考慮到靈活性(又不想依賴於spring)所以，總體感覺略亂。現在，加密通過AES方式，密碼保存用文件，序列化通過kryo.

項目中使用後，准備再添加使用說明，和程序結構。如果有任何疑問，歡迎詢問。

3.1. 項目組成及功能

子項目名

功能

依賴

ks-parent

Pom類型，定義依賴與版本

ks-common

傳輸的bean，異常體系，基本工具類

ks-parent

ks-server

KDC服務端

ks-parent、ks-common

ks-client

KDC客戶端

ks-parent、ks-common

ks-tool

KDC工具類，服務端database文件管理，客戶端密碼文件管理。可以擴展數據庫

ks-parent、ks-common

ks-example

例子

3.2. Ks-common

基礎的JavaBean，主要包含6次傳輸過程中的javabean，還有ServiceTicket與TicketGrantingTicket。

Kerberos部分錯誤通過異常進行傳輸，因此涉及到的所有異常較多。在該系統中所有的異常均為runtime異常，避免強制catch。

工具類，主要包含Kryo序列化工具（非線程安全）、安全工具類（AES、DES加密算法）、時間比較類。

3.2.1. 基礎類（com.cgs.kerberos.bean）

這裡的類均為2章中，3次通信過程中的信息封裝。所有的類均是可序列化的，在該項目中通過Kryo進行序列化。

圖 4?1通信間的信息封裝

除了第一次請求和最後一次應答，其他部分均包含能解析部分與不可解析部分。持有者不可能對不可解析部分修改，所以不可解析部分包含著進行驗證的信息及用於解密的鑰匙。

TGT包含的是客戶端信息，及一把鑰匙；主要用戶KDC驗證，請求者是否合法。ST包含客戶端信息，及一把鑰匙；主要用於請求服務器（非KDC），驗證客戶端。

1.2.2. 異常體系

圖 4?2 異常體系

異常體系主要由Kerberos的異常系列和加密算法異常體系兩部分組成。

3.2.3. 工具類

　　KryoSerializer：將對象轉化為byte[]二進制，將二進制轉化為對象。

Kryo在持久化速度和持久化後的空間上，都有無可比擬的速度。它的缺點：只能在java語言中使用、不能做兼容性。考慮到，調用該kerberos的系統使用的持久化方式為kryo，我們這裡默認的也采用kryo持久化。Bug較多，不過在該系統使用到的功能中，均無bug。

在該框架中，不需要用到對象之間的引用。同時，因為是通過網絡傳輸的，所以不能進行注冊。（會把類的全限定麼全部持久化進去）。

KryoSerializer據說是非線程安全的。

SecurityUtil：通過DES或者AES進行加密與解密。DES通過64位密碼加密，所以如果字符串少於8個，則後面加0填充，如果多余則截取前面8位。AES通過128位加密，如果字符串少於16，則後面加0填充，多余則截取。

在該項目中，使用AES進行加解密。

3.3. Ks-server

KDC中心，主要包含Authentication Server、Ticket Granting Server。Authentication Server認證請求服務器是否合法（A請求B，KDC驗證A的合法性），服務票據請求服務（Ticket Granting Server），授予服務請求票據（通過Ticket，B能確定A的合法性）。