詳解kerberos認證原理
前言
Kerberos協(xié)議是一個專注于驗證通信雙方身份的網絡協(xié)議，不同于其他網絡安全協(xié)議的保證整個通信過程的傳輸安全，kerberos側重于通信前雙方身份的認定工作，幫助客戶端和服務端解決“證明我自己是我自己”的問題，從而使得通信兩端能夠完全信任對方身份，在一個不安全的網絡中完成一次安全的身份認證繼而進行安全的通信。由于整個Kerberos認證過程較為復雜繁瑣且網上版本較多，特整理此文以便復習與分享。
什么是Kerberos協(xié)議
kerberos是一種計算機網絡認證協(xié)議，他能夠為網絡中通信的雙方提供嚴格的身份驗證服務，確保通信雙方身份的真實性和安全性。不同于其他網絡服務，kerberos協(xié)議中不是所有的客戶端向想要訪問的網絡服務發(fā)起請求，他就能夠建立連接然后進行加密通信。而是在發(fā)起服務請求后必須先進行一系列的身份認證，包括客戶端和服務端兩方的雙向認證，只有當通信雙方都認證通過對方身份之后，才可以互相建立起連接，進行網絡通信。即kerberos協(xié)議的側重在于認證通信雙方的身份，客戶端需要確認即將訪問的網絡服務就是自己所想要訪問的服務而不是一個偽造的服務器，而服務端需要確認這個客戶端是一個身份真實，安全可靠的客戶端，而不是一個想要進行惡意網絡攻擊的用戶。本文將詳細概述kerberos認證原理，講述通信雙方是如何一步步確認對方身份完成認證的。
Kerberos協(xié)議的組成角色
在古希臘神話故事中，kerberos是一只具有三顆頭顱的地獄惡犬，他守護在地獄之外，能夠識別所有經此路過的亡靈，防止活著的入侵者闖入地獄。而真正的kerberos協(xié)議中也存在三個角色，分別是
客戶端（client）：發(fā)送請求的一方
服務端（Server）：接收請求的一方
密鑰分發(fā)中心（Key Distribution Center，KDC），而密鑰分發(fā)中心一般又分為兩部分，分別是：
AS（Authentication Server）：認證服務器，專門用來認證客戶端的身份并發(fā)放客戶用于訪問TGS的TGT（票據授予票據）
TGS（Ticket Granting Ticket）：票據授予服務器，用來發(fā)放整個認證過程以及客戶端訪問服務端時所需的服務授予票據（Ticket）
在整個kerberos認證過程中，三個角色缺一不可，下面便來介紹一下整個kerberos的認證原理~
Kerberos認證解決“如何證明我就是我的問題”
上面說到了kerberos協(xié)議當中總共有三個不同的角色，客戶端和服務端就不用多說了，一個是請求的發(fā)起者一個是請求的接收者，那么KDC是做什么的呢？答案是這樣的~在kerberos協(xié)議中，通信的雙方在通信之前必須相互證明自己的身份是可靠并且具有訪問權限的（后面會說為什么是要具有訪問權限的），那么雙方都要如何證明自己呢？口說無憑，客戶端的請求中攜帶自己的身份信息直接給服務端，服務端是沒有理由直接信任這段信息就是真實的信息的，同理，服務端返回自己的身份信息給客戶端，客戶端也同樣是無法辨別該服務器是否是自己想要訪問的服務器。
舉個例子，A現(xiàn)在想要去訪問B完成一個任務。但是AB兩人之間是從來沒有見過面的，他們只知道對方的名字叫A，B。此時如果A直接去找B告訴B我就是A，那么B是有理由不相信A的，因為即使A是一個冒充的他也分辨不清，B同理也得不到A的認可，他們陷入了一個無法證明我就是我的困境。于是他們就想到了一個辦法，AB找到了一個他倆共同信任的人C，且這個C既認識A又認識B，所以只要C告訴B，這個A確實就是真正的A那么B就會信任這個A，同理B經過C的認可后，A也會相信B的身份。此后，A在訪問B之前會先去找C，C會交給A一個憑證，代表此時的A已經得到了C的認證，這時A拿著憑證再去找C，便可以得到C的確認了。
在上面的例子中，A，B分別是客戶端和服務端，C擔任的角色便是KDC，全稱Key Distribution Center，中文名叫做密鑰分發(fā)中心。KDC中包含一個叫做TGS（票據授予中心）的組件，我們便可以理解為他就是一個發(fā)放身份認證票據的服務中心，在KDC認證了（其實是KDC中的AS認證的）客戶端的身份后，他會給客戶端發(fā)放用于訪問網絡服務的服務授予票據（Ticket）。由于整個kerberos通信過程都采用對稱加密的方式，密鑰的獲取也是從KDC中得
到，所以KDC叫做密鑰分發(fā)中心。
所以整個kerberos認證流程可以簡化描述如下：
客戶端在訪問每個想要訪問的網絡服務時，他需要攜帶一個專門用于訪問該服務并且能夠證明自己身份的票據，當服務端收到了該票據他才能認定客戶端身份正確，向客戶端提供服務。所以整個認證流程可簡化為兩大步：
客戶端向KDC請求獲取想要訪問的目標服務的服務授予票據（Ticket）；
客戶端拿著從KDC獲取的服務授予票據（Ticket）訪問相應的網絡服務；
簡化認證流程圖：
Kerberos認證流程
上面說到了簡化版的Kerberos認證流程，基本上分為兩步。第一步，客戶端向KDC請求獲得他想要訪問的服務的服務授予票據（可以想象成去動物園，想去買一張能夠進入動物園的門票）。第二步，拿著這張服務授予票據（Ticket）去訪問服務端的服務。
大致的過程確實可以看作這兩步，但其中還存在一些問題：
問題1. KDC怎么知道你（客戶端）就是真正的客戶端？憑什么給你發(fā)放服務授予票據（Ticket）呢？
問題2. 服務端怎么知道你帶來的服務授予票據（Ticket）就是一張真正的票據呢？
這就需要開始細節(jié)的描述一下整個Kerberos認證的過程了~上面提到整個流程可以簡化為兩大步，但其實在第一步中共做了兩件事，這兩件事解決了上述問題中的問題1；然后第二步解決了問題2，最終結束認證過程建立通信。所以整個Kerberos認證流程可以細化為三個階段也可以
理解為三次通信!接下來從三個階段三次通信的角度細說認證過程。
在具體描述整個認證流程之前，我們需要知道幾個Kerberos認證的前提條件：
kerberos協(xié)議他是一個“限權”的認證協(xié)議，kerberos中會自帶一個數(shù)據庫，這個數(shù)據庫會由創(chuàng)建kerberos的運維人員提前在庫中添加好整個系統(tǒng)中擁有使用kerberos認證權限的用戶和網絡服務。在后續(xù)的認證中也是根據數(shù)據庫中是否存在該用戶和服務來判斷該對象是否能夠通過認證服務的。（拿上面的例子來說就是上帝先讓C在AB相識之前同時認識A和B，以便后面幫助AB互相認證）
所有使用kerberos協(xié)議的用戶和網絡服務，在他們添加進kerberos系統(tǒng)中時，都會根據自己當前的密碼（用戶密碼，人為對網絡服務隨機生成的密碼）生成一把密鑰存儲在kerberos數(shù)據庫中，且kerberos數(shù)據庫也會同時保存用戶的基本信息（例如用戶名，用戶IP地址等）和網絡服務的基本信息（IP，Server Name）
kerberos中存在的三個角色，只要是發(fā)生了兩兩之間的通信，那么都需要先進行身份的認證
第一次通信
為了獲得能夠用來訪問服務端服務的票據，客戶端首先需要來到KDC獲得服務授予票據（Ticket）。由于客戶端是第一次訪問KDC，此時KDC也不確定該客戶端的身份，所以第一次通信的目的為KDC認證客戶端身份，確認客戶端是一個可靠且擁有訪問KDC權限的客戶端，過程如下：
①?客戶端用戶向KDC以明文的方式發(fā)起請求。該次請求中攜帶了自己的用戶名，主機IP，和當前時間戳；
② KDC當中的AS（Authentication Server）接收請求（AS是KDC中專門用來認證客戶端身份的認證服務器）后去kerberos認證數(shù)據庫中根據用戶名查找是否存在該用戶，此時只會查找是否有相同用戶名的用戶，并不會判斷身份的可靠性；
③?如果沒有該用戶名，認證失敗，服務結束；
如果存在該用戶名，則AS認證中心便認為用戶存在，此時便會返回響應給客戶端，其中包含兩部分內容：
第一部分內容稱為TGT，他叫做票據授予票據，客戶端需要使用TGT去KDC中的TGS（票據授予中心）獲取訪問網絡服務所需的Ticket（服務授予票據），TGT中包含的內容有kerberos數(shù)據庫中存在的該客戶端的Name，IP，當前時間戳，客戶端即將訪問的TGS的Name，TGT的有效時間以及一把用于客戶端和TGS間進行通信的Session_key(CT_SK)。整個TGT使用TGS密鑰加密，客戶端是解密不了的，由于密鑰從沒有在網絡中傳輸過，所以也不存在密鑰被劫持破解的情況。
第二部分內容是使用客戶端密鑰加密的一段內容，其中包括用于客戶端和TGS間通信的Session_key(CT_SK),客戶端即將訪問的TGS的Name以及TGT的有效時間，和一個當前時間戳。該部分內容使用客戶端密鑰加密，所以客戶端在拿到該部分內容時可以通過自己的密鑰解密。如果是一個假的客戶端，那么他是不會擁有真正客戶端的密鑰的，因為該密鑰也從沒在網絡中進行傳輸過。這也同時認證了客戶端的身份，如果是假客戶端會由于解密失敗從而終端認證流程。
至此，第一次通信完成。
第二次通信
此時的客戶端收到了來自KDC（其實是AS）的響應，并獲取到了其中的兩部分內容。此時客戶端會用自己的密鑰將第二部分內容進行解密，分別獲得時間戳，自己將要訪問的TGS的信息，和用于與TGS通信時的密鑰CT_SK。首先他會根據時間戳判斷該時間戳與自己發(fā)送請求時的時間之間的差值是否大于5分鐘，如果大于五分鐘則認為該AS是偽造的，認證至此失敗。如果時間戳合理，客戶端便準備向TGS發(fā)起請求，其次請求的主要目的是為了獲取能夠訪問目標網絡服務的服務授予票據Ticket（進入動物園需要的門票）。在第二次通信請求中，客戶端將攜帶三部分內容交給KDc中的TGS，第二次通信過程具體如下所述：
客戶端行為：
①?客戶端使用CT_SK加密將自己的客戶端信息發(fā)送給KDC，其中包括客戶端名，IP，時間戳；
②?客戶端將自己想要訪問的Server服務以明文的方式發(fā)送給KDC；
③?客戶端將使用TGS密鑰加密的TGT也原封不動的也攜帶給KDC；
TGS行為：
①?此時KDC中的TGS（票據授予服務器）收到了來自客戶端的請求。他首先根據客戶端明文傳輸過來的Server服務IP查看當前kerberos系統(tǒng)中是否存在可以被用戶訪問的該服務。如果不存在，認證失敗結束。如果存在，繼續(xù)接下來的認證。
② TGS使用自己的密鑰將TGT中的內容進行解密，此時他看到了經過AS認證過后并記錄的用戶信息，一把Session_KEY即CT_SK，還有時間戳信息，他會現(xiàn)根據時間戳判斷此次通信是否真是可靠有無超出時延。
③?如果時延正常，則TGS會使用CK_SK對客戶端的第一部分內容進行解密（使用CT_SK加密的客戶端信息），取出其中的用戶信息和TGT中的用戶信息進行比對，如果全部相同則認為客戶端身份正確，方可繼續(xù)進行下一步。
④?此時KDC將返回響應給客戶端，響應內容包括：
第一部分：用于客戶端訪問網絡服務的使用Server密碼加密的ST（Servre Ticket），其中包括客戶端的Name，IP，需要訪問的網絡服務的地址Server IP，ST的有效時間，時間戳以及用于客戶端和服務端之間通信的CS_SK（Session Key）。
第二部分：使用CT_SK加密的內容，其中包括CS_SK和時間戳，還有ST的有效時間。由于在第一次通信的過程中，AS已將CT_SK通過客戶端密碼加密交給了客戶端，且客戶端解密并緩存了CT_SK，所以該部分內容在客戶端接收到時是可以自己解密的。
至此，第二次通信完成。
第三次通信
此時的客戶端收到了來自KDC（TGS）的響應，并使用緩存在本地的CT_SK解密了第二部分內容（第一部分內容中的ST是由Server密碼加密的，客戶端無法解密），檢查時間戳無誤后取出其中的CS_SK準備向服務端發(fā)起最后的請求。
客戶端：
①?客戶端使用CK_SK將自己的主機信息和時間戳進行加密作為交給服務端的第一部分內容，然后將ST（服務授予票據）作為第二部分內容都發(fā)送給服務端。
服務端：
①?服務器此時收到了來自客戶端的請求，他會使用自己的密鑰，即Server密鑰將客戶端第二部分內容進行解密，核對時間戳之后將其中的CS_SK取出，使用CS_SK將客戶端發(fā)來的第一部分內容進行解密，從而獲得經過TGS認證過后的客戶端信息，此時他將這部分信息和客戶端第二部分內容帶來的自己的信息進行比對，最終確認該客戶端就是經過了KDC認證的具有真實身份的客戶端，是他可以提供服務的客戶端。
此時服務端返回一段使用CT_SK加密的表示接收請求的響應給客戶端，在客戶端收到請求之后，使用緩存在本地的CS_ST解密之后也確定了服務端的身份（其實服務端在通信的過程中還會使用數(shù)字證書證明自己身份）。
至此，第三次通信完成。此時也代表著整個kerberos認證的完成，通信的雙方都確認了對方的身份，此時便可以放心的進行整個網絡通信了。
總結
整個kerberos認證的過程較為復雜，三次通信中都使用了密鑰，且密鑰的種類一直在變化，并且為了防止網絡攔截密鑰，這些密鑰都是臨時生成的Session Key，即他們只在一次Session會話中起作用，即使密鑰被劫持，等到密鑰被破解可能這次會話都早已結束。
這為整個kerberos認證過程保證了較高的安全性。以下補充兩個kerberos認證的整體流圖，一個是kerberos認證的時序圖，一個是kerberos認證的示意圖，望能加深kerberos認證印象~~
示意圖：
時序圖：
