密鑰分配問題，你學會了嗎？
密鑰分配
我們上面所介紹到的很多加密機制和加密算法都是公開的，所以不存在網絡安不安全的問題，公開的就意味著不安全，因此對于安全性來說就體現在密鑰的安全保護上了，所以密鑰管理就成為一個非常重要且不可忽視的問題。密鑰管理主要包括密鑰的產生和分配、驗證以及使用問題。
密鑰分配是網絡安全中一個很重要的問題，在計算機網絡中，密鑰應該通過一個安全的鏈路進行分配。之前早期的互聯網多采用網外分配的方式，外網分配就是由信使把密鑰分配給相互通信的用戶；但是隨著用戶的增多和流量的增大，這種方式不再適用，因為每次需要更換密鑰都需要派信使更換一遍。現在更多采用的是網內分配方式，也即密鑰自動分配。
對稱密鑰的自動分配
我們上面說到了，對稱密鑰的一種分配方式是設立 密鑰分配中心 KDC(Key Distribution Center) ，KDC 是一個權威的密鑰分配中心，他能解決密鑰數量日趨增大的問題，也能解決共享密鑰之間的安全性問題。
KDC 的主要作用就是給需要通信的用戶臨時分配一個會話密鑰，這個會話密鑰的生命周期在會話開始時結束，會話結束時失效。
比如下面這個 KDC 的分配示例：
圖片
A 和 B 都是 KDC 的登記用戶，A 和 B 在 KDC 登記時就已經在 KDC 的服務器上安裝了各自和 KDC 進行通信的主密鑰(master key) 的 KA 和 KB，下面統稱主密鑰為密鑰。
首先，用戶 A 向密鑰中心 KDC 發送時用明文，來表明自己想要和主機 B 建立通信，明文中包含了 A 和 B 在 KDC 登記的身份（此時 A 是知道 B 的登記信息的）。
KDC 用隨機數產生一次一密的會話密鑰 KAB 來讓 A 和 B 這次會話使用（這個密鑰 KAB 就是給通信用戶分配的臨時密鑰），然后向 A 發送回答報文，回答報文用 A 的密鑰 KA 加密，除此之外，這個報文中還包含這次會話使用的密鑰 KAB 和請 A 轉給 B 的一條消息，這條消息用 B 的密鑰 KB 加密，因為 A 并沒有持有 KB，所以 A 并不知道這條消息的內容。
A 收到這條消息后會把 KB 加密的消息發送給 B，在 B 收到消息后就知道 A 想要和他通信，同時也知道了會話密鑰 KAB ，于是 A 和 B 就可以安全的對話了。這就是這個會話密鑰 KAB 的作用。
那可能有同學有疑惑了，假如此時還有一個 C 來冒充了 A ，把 A 發給 B 的報文截獲，然后偽造成 B 與 C 進行通信呢？
由于 C 并不知道 A 的登記密鑰 KA，所以就算截獲了報文也不知道 KAB 會話密鑰，其次 KDC 還可以在報文中增加時間戳，來防止 C 使用之前截獲的報文進行攻擊，除此之外 KDC 中的 KA 和 KB 登記信息也要定期更換才行。
目前業界比較出名的密鑰分配協議就是 Kerberos V5，它是一種基于 Ticket 的身份驗證協議，而且也是 KDC，它已經變得很普及，現在是互聯網標準。Kerberos 使用比 DES 更加安全的高級加密 AES 進行加密，下面會介紹 Kerberos V4 的工作原理，V5 和 V4 的原理是一樣的， V4 還稍微簡單些。
圖片
這里首先先認識 Kerberos 的兩個服務器，一個是鑒別服務器（Authentication Server）AS，一個是票據授予服務器（Ticket-Granting Server）TGS。
- 鑒別服務器 AS：進行用戶信息驗證，為客戶端提供 Ticket Granting Tickets（TGT）。
- 票據授予服務器 TGS：驗證 TGT 和身份，為客戶端提供 Service Tickets。
在上圖中，A 是請求服務的客戶，B 是被請求的服務器，A 通過 Kerberos 向 B 請求服務，Kerberos 需要通過下面幾個步驟鑒別的確是 A 在向 B 請求服務，而不是冒充 A 的冒充者，請求服務后，才向 A 和 B 分配會話使用的密鑰。
- A 通過明文（包括登記的身份）向鑒別服務器 AS 表明自己的身份。AS 就是 KDC 的一種，它掌握著實體登記的身份和相應的口令。當 A 向 AS 表明身份后，AS 會對 A 進行身份驗證，驗證正確后才會走到下一步。
- AS 驗證完成后，AS 會向 A 發送用 A 的對稱密鑰 KA 加密的報文，這個報文包含 A 和 TGS 通信的會話密鑰 KS 以及 AS 要發送給 TGS 的 Ticket 票據，這個 Ticket 是用 TGS 的對稱密鑰 KTG 加密的。當報文到達 請求者 A 時，A 就會根據口令和適當的算法生成 KA 密鑰，密鑰 KA 會對 AS 發送過來的報文進行解密（A 并不會保存 KA 密鑰），解密過后就提取出會話密鑰 KS（這是 A 和 TGS 通信要使用的）以及要轉發給 TGS 的 Ticket （這是用 KTG 加密的）。總的來說這一步就是 AS 把消息發送給 A，A 根據口令生成解密密鑰 KA，然后解密報文提取 KTG 加密報文的過程。
- 此后 A 需要向票據服務器 TGS 發送報文，包括上一步 A 提取的會話密鑰 Ks，還有 AS 發給 A 的 KTG 加密報文，還有 A 需要告訴 TGS 通信的目標 B ，還有能預防重放攻擊的 Ks 加密的時間戳 T。
- TGS 發送兩個 Ticket，每一個都包含 A 和 B 通信的會話密鑰 KAB。給 A 的 Ticket 用 Ks 加密，發給 B 的票據用 KB 加密。
- 然后 A 向 B 轉發 TGS 發給 A 的 Ticket，同時發送用會話密鑰 KAB 加密的時間戳 T。
- B 把時間戳 T + 1 來證實收到了 Ticket，同時這個時間戳也會用 KAB 加密。
在這之后，A 和 B 就可以使用 TGS 給出的會話密鑰 KAB 進行對話了。
公鑰的分配問題
公鑰分配的問題主要談論的就是公鑰分配的權威性問題，如果用戶 A 擁有 B 的公鑰，就可以實現安全通信，這就好像用戶 A 假如擁有攻擊者 C 的公鑰也就能實現安全通信了，其實不然，這個公鑰需要有權威機構認證的，這個權威認證機構就是CA(Certification Authority) ，它由政府出資建立，每個實體都需要有 CA 發來的證書，CA 包含公鑰和標識擁有者的信息，證書會由 CA 數字簽名，擁有 CA 頒發的證書后才能夠實現安全通信。
