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