你真的懂網(wǎng)絡安全嗎？密鑰的分配解析

密鑰分配

我們上面所介紹到的很多加密機制和加密算法都是公開的，所以不存在網(wǎng)絡安不安全的問題，公開的就意味著不安全，因此對于安全性來說就體現(xiàn)在密鑰的安全保護上了，所以密鑰管理就成為一個非常重要且不可忽視的問題。密鑰管理主要包括密鑰的產(chǎn)生和分配、驗證以及使用問題。

密鑰分配是網(wǎng)絡安全中一個很重要的問題，在計算機網(wǎng)絡中，密鑰應該通過一個安全的鏈路進行分配。之前早期的互聯(lián)網(wǎng)多采用網(wǎng)外分配的方式，外網(wǎng)分配就是由信使把密鑰分配給相互通信的用戶；但是隨著用戶的增多和流量的增大，這種方式不再適用，因為每次需要更換密鑰都需要派信使更換一遍。現(xiàn)在更多采用的是網(wǎng)內(nèi)分配方式，也即密鑰自動分配。

對稱密鑰的自動分配

我們上面說到了，對稱密鑰的一種分配方式是設立 密鑰分配中心 KDC(Key Distribution Center) ，KDC 是一個權威的密鑰分配中心，他能解決密鑰數(shù)量日趨增大的問題，也能解決共享密鑰之間的安全性問題。

KDC 的主要作用就是給需要通信的用戶臨時分配一個會話密鑰，這個會話密鑰的生命周期在會話開始時結束，會話結束時失效。

比如下面這個 KDC 的分配示例：

A 和 B 都是 KDC 的登記用戶，A 和 B 在 KDC 登記時就已經(jīng)在 KDC 的服務器上安裝了各自和 KDC 進行通信的主密鑰(master key) 的 KA 和 KB，下面統(tǒng)稱主密鑰為密鑰。

首先，用戶 A 向密鑰中心 KDC 發(fā)送時用明文，來表明自己想要和主機 B 建立通信，明文中包含了 A 和 B 在 KDC 登記的身份（此時 A 是知道 B 的登記信息的）。

KDC 用隨機數(shù)產(chǎn)生一次一密的會話密鑰 KAB 來讓 A 和 B 這次會話使用（這個密鑰 KAB 就是給通信用戶分配的臨時密鑰），然后向 A 發(fā)送回答報文，回答報文用 A 的密鑰 KA 加密，除此之外，這個報文中還包含這次會話使用的密鑰 KAB 和請 A 轉給 B 的一條消息，這條消息用 B 的密鑰 KB 加密，因為 A 并沒有持有 KB，所以 A 并不知道這條消息的內(nèi)容。

A 收到這條消息后會把 KB 加密的消息發(fā)送給 B，在 B 收到消息后就知道 A 想要和他通信，同時也知道了會話密鑰 KAB ，于是 A 和 B 就可以安全的對話了。這就是這個會話密鑰 KAB 的作用。

那可能有同學有疑惑了，假如此時還有一個 C 來冒充了 A ，把 A 發(fā)給 B 的報文截獲，然后偽造成 B 與 C 進行通信呢？

由于 C 并不知道 A 的登記密鑰 KA，所以就算截獲了報文也不知道 KAB 會話密鑰，其次 KDC 還可以在報文中增加時間戳，來防止 C 使用之前截獲的報文進行攻擊，除此之外 KDC 中的 KA 和 KB 登記信息也要定期更換才行。

目前業(yè)界比較出名的密鑰分配協(xié)議就是 Kerberos V5，它是一種基于 Ticket 的身份驗證協(xié)議，而且也是 KDC，它已經(jīng)變得很普及，現(xiàn)在是互聯(lián)網(wǎng)標準。Kerberos 使用比 DES 更加安全的高級加密 AES 進行加密，下面會介紹 Kerberos V4 的工作原理，V5 和 V4 的原理是一樣的， V4 還稍微簡單些。

這里首先先認識 Kerberos 的兩個服務器，一個是鑒別服務器（Authentication Server）AS，一個是票據(jù)授予服務器（Ticket-Granting Server）TGS。

鑒別服務器 AS：進行用戶信息驗證，為客戶端提供 Ticket Granting Tickets（TGT）。

票據(jù)授予服務器 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 發(fā)送用 A 的對稱密鑰 KA 加密的報文，這個報文包含 A 和 TGS 通信的會話密鑰 KS 以及 AS 要發(fā)送給 TGS 的 Ticket 票據(jù)，這個 Ticket 是用 TGS 的對稱密鑰 KTG 加密的。當報文到達 請求者 A 時，A 就會根據(jù)口令和適當?shù)乃惴ㄉ?KA 密鑰，密鑰 KA 會對 AS 發(fā)送過來的報文進行解密（A 并不會保存 KA 密鑰），解密過后就提取出會話密鑰 KS（這是 A 和 TGS 通信要使用的）以及要轉發(fā)給 TGS 的 Ticket （這是用 KTG 加密的）?？偟膩碚f這一步就是 AS 把消息發(fā)送給 A，A 根據(jù)口令生成解密密鑰 KA，然后解密報文提取 KTG 加密報文的過程。

此后 A 需要向票據(jù)服務器 TGS 發(fā)送報文，包括上一步 A 提取的會話密鑰 Ks，還有 AS 發(fā)給 A 的 KTG 加密報文，還有 A 需要告訴 TGS 通信的目標 B ，還有能預防重放攻擊的 Ks 加密的時間戳 T。

TGS 發(fā)送兩個 Ticket，每一個都包含 A 和 B 通信的會話密鑰 KAB。給 A 的 Ticket 用 Ks 加密，發(fā)給 B 的票據(jù)用 KB 加密。

然后 A 向 B 轉發(fā) TGS 發(fā)給 A 的 Ticket，同時發(fā)送用會話密鑰 KAB 加密的時間戳 T。

B 把時間戳 T + 1 來證實收到了 Ticket，同時這個時間戳也會用 KAB 加密。

在這之后，A 和 B 就可以使用 TGS 給出的會話密鑰 KAB 進行對話了。

公鑰的分配問題

公鑰分配的問題主要談論的就是公鑰分配的權威性問題，如果用戶 A 擁有 B 的公鑰，就可以實現(xiàn)安全通信，這就好像用戶 A 假如擁有攻擊者 C 的公鑰也就能實現(xiàn)安全通信了，其實不然，這個公鑰需要有權威機構認證的，這個權威認證機構就是CA(Certification Authority) ，它由政府出資建立，每個實體都需要有 CA 發(fā)來的證書，CA 包含公鑰和標識擁有者的信息，證書會由 CA 數(shù)字簽名，擁有 CA 頒發(fā)的證書后才能夠實現(xiàn)安全通信。

審核編輯：黃飛

?