文章導讀：

對稱加密非對稱加密數字證書Kerberos認證流程

Hadoop生態利用Kerberos認證機制來識別可靠的服務和節點，保障Hadoop集羣的安全，那麼Kerberos到底是什麼？為什麼要選擇它來進行認證？Kerberos認證的流程又是怎樣的呢？讓我們帶著這些問題看一下這篇文章。

Kerberos是什麼

Kerberos是一種網路認證協議，它作為一種可信任的第三方認證服務，通過對稱加密的方式執行認證服務。為客戶端、服務端的應用程序提供強大的、嚴謹的認證服務。

上面我們提到了對稱加密，我們先科普一下什麼是對稱加密和非對稱加密以及數字證書等常見概念。

對稱加密

舉個栗子：

我們都知道數字有一些特殊的意義，比如：5=我 2=愛 1=你。你看上個姑娘叫小芳，你想向她表達愛慕之情但是又不想明說。你：521小芳：對不起你是個好人。

上面其實就是對稱加密的一種方式，首先你和小芳都知道相同的加密演算法即5=我 2=愛 1=你。然後你通過該加密演算法將「我愛你」三個字加密後的結果521發送給小芳，小芳通過相同的加密演算法（5=我 2=愛 1=你）進行解密，並給你發了一張好人卡。

對稱加密：在加密和解密時使用相同的密鑰，或是使用兩個可以簡單地相互推算的密鑰。

那麼對稱加密有沒有什麼缺點呢？

舉個栗子：

你又看上了小芳的朋友小麗，展開了新一波的攻勢。你：521小麗：你上次跟小芳也是這麼說的，你真不是個好人

由於對稱加密需要雙方都知道加密的密鑰，那麼持有相同密鑰的人很容易對其他人的信息進行解密。

非對稱加密

非對稱加密比對稱密鑰相對來講比較安全一些，為了不讓小麗知道你給小芳說了什麼，你們開始停止使用共同的密鑰，這樣就不會被小麗知道你和小芳說話的內容了。然後每個人生成一個「私鑰」和一個「公鑰」，通過公鑰加密的信息可以利用私鑰進行解密。私鑰每個人自行進行保護，然後把公鑰進行分享。

舉個栗子：

你：小芳，你的公鑰給我下，我給你看個寶貝。

小芳：「你怕是個傻子吧」 給你，這是我的公鑰。

你：iwty小芳：iwty經過私鑰解密後得到內容我愛你。

非對稱密鑰看上去比對稱密鑰安全了不少，公鑰隨便給你，反正私鑰在我手裡，加密的信息通過私鑰才能解密。這時候即使小麗拿到了你給小芳發的信息，她沒有小芳的私鑰也不知道說的是什麼。

非對稱加密：需要一對密鑰，可公開的為公鑰，私有保護的為私鑰。其他用戶通過該用戶的公鑰加密的消息，只能通過該用戶的私鑰進行解密。也就是說公開了其中公鑰並不會造成什麼影響。

那麼非對稱密鑰就一定是安全的嗎？再舉個例子：

你：小芳，你的公鑰給我下，我給你看個好寶貝。小麗（冒充小芳）：「這是小麗的公鑰」，這是小芳的公鑰。你：iwty小麗：使用自己的私鑰解密後得到我愛你的真實信息。

所以這時候，怎麼證明你拿到的「小芳的公鑰」就是小芳的公鑰呢？

數字證書

前面說到，如何證明你拿到的「小芳的公鑰」就是小芳的公鑰。數字證書是什麼意思呢，就是選擇雙方信任的第三方所頒發的一個認證標識。

舉個例子：

你想對小芳表達愛慕之情，但是不要意思直接說，又怕被小麗知道。所以你找來了另外一個關鍵任務小明。你、小芳和小明之間進行了約定。小明把他的公鑰給了你，並告訴你，他會將小芳的公鑰信息用他的私鑰進行加密，加密後給你，如果你可以用小明的公鑰解開，那麼這個就是真正的小芳的公鑰，你就可以發信息了。

你：拿著小明給你的公鑰，小芳，你公鑰給我一下，我給你看個寶貝。

小芳：小明你幫我加密一下吧，然後發給了你你：用小明的公鑰解密了用小明私鑰加密的小芳的公鑰（這句有點繞），並確認是小芳的公鑰，然後發送iwty小芳：解密信息得到我愛你，並發了一張好人卡。

在上面的例子中，小明起到了關鍵性的作用，他證明瞭小芳是小芳，發給你的小芳的公鑰沒有被別人修改過。但是大家發現了什麼沒有，這裡又有一個「小明的公鑰」。那麼誰來證明「小明的公鑰」就是小明的公鑰呢？

當然，這種都是可值得信賴的第三方機構充當小明的角色，比如我們所謂的註冊中心RA和證書機構CA。但是需要注意的是，小明的角色也是可以被黑客黑掉的，黑客把小明的公鑰（根證書）換成自己的，那麼又可以為所欲為了。

Kerberos

終於到我們的主角Kerberos了，前面我們也提到了Kerberos是可信任的第三方，那麼它與數字證書的頒發機構有什麼不同呢？它是否可以被偽造，如何保證認證機制？

在舉例之前呢，我們先來瞭解幾個新名詞：

principal(安全個體)：被Kerberos成功認證的個體，有一個名字和口令Ticket：門票，用來向伺服器證明自己的身份，包括標識、會話密鑰、時間戳。KDC(key distribution center ) : 是一個網路服務，提供ticket和臨時會話密鑰AS (Authentication Server)： 認證伺服器TSG(Ticket Granting Server)： 許可證伺服器

舉個栗子，這裡我儘可能的簡化相關邏輯，便於理解：

你（Client）和小芳（Server）分別作為一個安全的個體，向KDC進行認證，添加你們的principal名稱和密碼。（密碼你知,KDC知 所以是對稱加密）

好，現在你想和小芳聯繫了，但是你要確認這個小芳是你想找的小芳。

你：hello KDC，我想聯繫下小芳，你把認證的session key給我吧。

KDC接收到請求之後，首先從資料庫裡面查找你的principal，確認你是一個認證過的安全個體。然後將一個session key進行加密，注意，這裡的session key有兩份，一份是由你的密鑰加密的，一份是由小芳的密鑰加密的。它把兩份都給了你。注意思考，這裡為什麼要把小芳密鑰加密後的session key也給你（1. 這樣kdc不用維護session key的列表 2. kdc直接發送給小芳不一定可達）你：你接收到兩個session key，我們簡化為Ckey（client 加密的key）和Skey（Server 加密的key）。這時候你用你自己的密鑰，解開了Ckey。為了表明是你現在想與小芳說話而不是別人監聽破解你的key而發送消息，這時候需要引入一個時間戳（認證時一個可接受的時間範圍，時間間隔太長認為不安全，則server端不予處理）

這時候你把你的個人信息（ClientInfo）+時間戳 通過解密後的Ckey（kdc給你的session key）加密，加上Skey 發送給小芳。

小芳：小芳接收到你的消息，首先用自己的密鑰解開Skey，獲取到session key。再利用session key解密你發送的個人信息+時間戳。通過對比時間戳，發現時間在可控範圍內，則認為你是安全的個體。可以進行通話。

你：而這個時候你可能也有點慌，這是不是小芳啊？別又是小麗。你想認證一下小芳怎麼辦呢？你需要把上一步的個人信息+時間戳利用session key進行加密，加上Skey和一個需要Server認證的flag即可。

小芳：小芳接收到你的消息，首先用自己的密鑰解開Skey，獲取到session key，再利用session key解密你發送的個人信息+時間戳。如果你需要認證，flag=true。則把你發送的時間戳用session key加密後發送給你。你：接收到小芳發來的消息，用session key進行解密，發現與之前的時間戳一致。則驗證是小芳而不是小麗。（這部分呢就是雙向認證）

那麼Kerberos比上面的流程要稍微複雜一點：

  1. Client作為一個安全個體認證到KDC之後，KDC會分發一個Ticket認購權證稱為TGT（或者描述為Client連接KDC的密鑰，經過KDC的Key加密過），需要注意的是TGT有時間限制，過期後需要重新向KDC獲取，這樣也保障了一定的安全性。
  2. Client要與Server進行通信則首先用TGT從KDC獲得一個可以訪問某一服務的Ticket（Session Key+Client Info）。這個Ticket是認證過程中最重要的一環，它的頒發機構就是雙方可信的KDC，KDC對TGT解密認證，分發Ticket。
  3. Client向Server提交Ticket，Server接受到Ticket之後，對Ticket進行解密，驗證時間戳。如需雙方驗證則發送加密時間戳到Client進行驗證，驗證成功後Client可以訪問Server。

Kerberos認證這部分確實比較複雜，可以對照圖例多過兩遍。那麼Kerberos都有哪些優點？我們來總結一下：

  1. 安全可靠：Kerberos實現了雙向認證
  2. 性能高：雖然Kerberos的認證需要Client Server 和 KDC三方認證，但是Client獲取到Ticket之後（Ticket未過期），就可以直接與Server進行認證而不需要KDC的參與。
  3. 支持HA高可用，且成為被廣泛接收的標準。支持不同平臺進行操作。

歡迎關注我：叄金大數據（不穩定持續更新~~~）

歡迎關注課程： HBase+SpringBoot實戰分散式文件存儲

參考資料：

kerberos認證原理—講的非常細緻，易懂

作者：叄金鏈接：imooc.com/article/26495來源：慕課網本文原創發佈於慕課網 ，轉載請註明出處，謝謝合作

推薦閱讀：

接手別人的代碼，死的心有嗎？

程序員都有哪些強迫行為？

網上黑程序員的現實依據是什麼？程序員真的那麼悲慘嗎？

有哪些視頻堪稱有毒？

暴露真實IP真的沒關係嗎？

有哪些程序員特有的習慣？

月薪3萬的程序員都避開了哪些坑？

雙11特輯：狂歡的背後，都有哪些關鍵性技術值得你學習？


推薦閱讀：
查看原文 >>
相關文章