密鑰分配

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

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

對(duì)稱密鑰的自動(dòng)分配

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

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

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

圖片

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

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

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

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

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

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

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

圖片

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

• 鑒別服務(wù)器 AS：進(jìn)行用戶信息驗(yàn)證，為客戶端提供 Ticket Granting Tickets（TGT）。
• 票據(jù)授予服務(wù)器 TGS：驗(yàn)證 TGT 和身份，為客戶端提供 Service Tickets。

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

1. A 通過明文（包括登記的身份）向鑒別服務(wù)器 AS 表明自己的身份。AS 就是 KDC 的一種，它掌握著實(shí)體登記的身份和相應(yīng)的口令。當(dāng) A 向 AS 表明身份后，AS 會(huì)對(duì) A 進(jìn)行身份驗(yàn)證，驗(yàn)證正確后才會(huì)走到下一步。
2. AS 驗(yàn)證完成后，AS 會(huì)向 A 發(fā)送用 A 的對(duì)稱密鑰 KA 加密的報(bào)文，這個(gè)報(bào)文包含 A 和 TGS 通信的會(huì)話密鑰 KS 以及 AS 要發(fā)送給 TGS 的 Ticket 票據(jù)，這個(gè) Ticket 是用 TGS 的對(duì)稱密鑰 KTG 加密的。當(dāng)報(bào)文到達(dá) 請(qǐng)求者 A 時(shí)，A 就會(huì)根據(jù)口令和適當(dāng)?shù)乃惴ㄉ?KA 密鑰，密鑰 KA 會(huì)對(duì) AS 發(fā)送過來的報(bào)文進(jìn)行解密（A 并不會(huì)保存 KA 密鑰），解密過后就提取出會(huì)話密鑰 KS（這是 A 和 TGS 通信要使用的）以及要轉(zhuǎn)發(fā)給 TGS 的 Ticket （這是用 KTG 加密的）?？偟膩碚f這一步就是 AS 把消息發(fā)送給 A，A 根據(jù)口令生成解密密鑰 KA，然后解密報(bào)文提取 KTG 加密報(bào)文的過程。
3. 此后 A 需要向票據(jù)服務(wù)器 TGS 發(fā)送報(bào)文，包括上一步 A 提取的會(huì)話密鑰 Ks，還有 AS 發(fā)給 A 的 KTG 加密報(bào)文，還有 A 需要告訴 TGS 通信的目標(biāo) B ，還有能預(yù)防重放攻擊的 Ks 加密的時(shí)間戳 T。
4. TGS 發(fā)送兩個(gè) Ticket，每一個(gè)都包含 A 和 B 通信的會(huì)話密鑰 KAB。給 A 的 Ticket 用 Ks 加密，發(fā)給 B 的票據(jù)用 KB 加密。
5. 然后 A 向 B 轉(zhuǎn)發(fā) TGS 發(fā)給 A 的 Ticket，同時(shí)發(fā)送用會(huì)話密鑰 KAB 加密的時(shí)間戳 T。
6. B 把時(shí)間戳 T + 1 來證實(shí)收到了 Ticket，同時(shí)這個(gè)時(shí)間戳也會(huì)用 KAB 加密。

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

公鑰的分配問題

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