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

密鑰分配

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

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

對稱(chēng)密鑰的自動(dòng)分配

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

KDC 的主要作用就是給需要通信的用戶(hù)臨時(shí)分配一個(gè)會(huì )話(huà)密鑰，這個(gè)會(huì )話(huà)密鑰的生命周期在會(huì )話(huà)開(kāi)始時(shí)結束，會(huì )話(huà)結束時(shí)失效。

比如下面這個(gè) KDC 的分配示例：

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

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

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

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

那可能有同學(xué)有疑惑了，假如此時(shí)還有一個(gè) C 來(lái)冒充了 A ，把 A 發(fā)給 B 的報文截獲，然后偽造成 B 與 C 進(jìn)行通信呢？

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

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

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

鑒別服務(wù)器 AS：進(jìn)行用戶(hù)信息驗證，為客戶(hù)端提供 Ticket Granting Tickets（TGT）。

票據授予服務(wù)器 TGS：驗證 TGT 和身份，為客戶(hù)端提供 Service Tickets。

在上圖中，A 是請求服務(wù)的客戶(hù)，B 是被請求的服務(wù)器，A 通過(guò) Kerberos 向 B 請求服務(wù)，Kerberos 需要通過(guò)下面幾個(gè)步驟鑒別的確是 A 在向 B 請求服務(wù)，而不是冒充 A 的冒充者，請求服務(wù)后，才向 A 和 B 分配會(huì )話(huà)使用的密鑰。

A 通過(guò)明文（包括登記的身份）向鑒別服務(wù)器 AS 表明自己的身份。AS 就是 KDC 的一種，它掌握著(zhù)實(shí)體登記的身份和相應的口令。當 A 向 AS 表明身份后，AS 會(huì )對 A 進(jìn)行身份驗證，驗證正確后才會(huì )走到下一步。

AS 驗證完成后，AS 會(huì )向 A 發(fā)送用 A 的對稱(chēng)密鑰 KA 加密的報文，這個(gè)報文包含 A 和 TGS 通信的會(huì )話(huà)密鑰 KS 以及 AS 要發(fā)送給 TGS 的 Ticket 票據，這個(gè) Ticket 是用 TGS 的對稱(chēng)密鑰 KTG 加密的。當報文到達 請求者 A 時(shí)，A 就會(huì )根據口令和適當的算法生成 KA 密鑰，密鑰 KA 會(huì )對 AS 發(fā)送過(guò)來(lái)的報文進(jìn)行解密（A 并不會(huì )保存 KA 密鑰），解密過(guò)后就提取出會(huì )話(huà)密鑰 KS（這是 A 和 TGS 通信要使用的）以及要轉發(fā)給 TGS 的 Ticket （這是用 KTG 加密的）?？偟膩?lái)說(shuō)這一步就是 AS 把消息發(fā)送給 A，A 根據口令生成解密密鑰 KA，然后解密報文提取 KTG 加密報文的過(guò)程。

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

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

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

B 把時(shí)間戳 T + 1 來(lái)證實(shí)收到了 Ticket，同時(shí)這個(gè)時(shí)間戳也會(huì )用 KAB 加密。

在這之后，A 和 B 就可以使用 TGS 給出的會(huì )話(huà)密鑰 KAB 進(jìn)行對話(huà)了。

公鑰的分配問(wèn)題

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

審核編輯：黃飛

?