密鑰分配問題,你學(xué)會了嗎?
密鑰分配
我們上面所介紹到的很多加密機制和加密算法都是公開的,所以不存在網(wǎng)絡(luò)安不安全的問題,公開的就意味著不安全,因此對于安全性來說就體現(xiàn)在密鑰的安全保護上了,所以密鑰管理就成為一個非常重要且不可忽視的問題。密鑰管理主要包括密鑰的產(chǎn)生和分配、驗證以及使用問題。
密鑰分配是網(wǎng)絡(luò)安全中一個很重要的問題,在計算機網(wǎng)絡(luò)中,密鑰應(yīng)該通過一個安全的鏈路進行分配。之前早期的互聯(lián)網(wǎng)多采用網(wǎng)外分配的方式,外網(wǎng)分配就是由信使把密鑰分配給相互通信的用戶;但是隨著用戶的增多和流量的增大,這種方式不再適用,因為每次需要更換密鑰都需要派信使更換一遍。現(xiàn)在更多采用的是網(wǎng)內(nèi)分配方式,也即密鑰自動分配。
對稱密鑰的自動分配
我們上面說到了,對稱密鑰的一種分配方式是設(shè)立 密鑰分配中心 KDC(Key Distribution Center) ,KDC 是一個權(quán)威的密鑰分配中心,他能解決密鑰數(shù)量日趨增大的問題,也能解決共享密鑰之間的安全性問題。
KDC 的主要作用就是給需要通信的用戶臨時分配一個會話密鑰,這個會話密鑰的生命周期在會話開始時結(jié)束,會話結(jié)束時失效。
比如下面這個 KDC 的分配示例:
圖片
A 和 B 都是 KDC 的登記用戶,A 和 B 在 KDC 登記時就已經(jīng)在 KDC 的服務(wù)器上安裝了各自和 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 轉(zhuǎn)給 B 的一條消息,這條消息用 B 的密鑰 KB 加密,因為 A 并沒有持有 KB,所以 A 并不知道這條消息的內(nèi)容。
A 收到這條消息后會把 KB 加密的消息發(fā)送給 B,在 B 收到消息后就知道 A 想要和他通信,同時也知道了會話密鑰 KAB ,于是 A 和 B 就可以安全的對話了。這就是這個會話密鑰 KAB 的作用。
那可能有同學(xué)有疑惑了,假如此時還有一個 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 的兩個服務(wù)器,一個是鑒別服務(wù)器(Authentication Server)AS,一個是票據(jù)授予服務(wù)器(Ticket-Granting Server)TGS。
- 鑒別服務(wù)器 AS:進行用戶信息驗證,為客戶端提供 Ticket Granting Tickets(TGT)。
- 票據(jù)授予服務(wù)器 TGS:驗證 TGT 和身份,為客戶端提供 Service Tickets。
在上圖中,A 是請求服務(wù)的客戶,B 是被請求的服務(wù)器,A 通過 Kerberos 向 B 請求服務(wù),Kerberos 需要通過下面幾個步驟鑒別的確是 A 在向 B 請求服務(wù),而不是冒充 A 的冒充者,請求服務(wù)后,才向 A 和 B 分配會話使用的密鑰。
- A 通過明文(包括登記的身份)向鑒別服務(wù)器 AS 表明自己的身份。AS 就是 KDC 的一種,它掌握著實體登記的身份和相應(yīng)的口令。當(dāng) A 向 AS 表明身份后,AS 會對 A 進行身份驗證,驗證正確后才會走到下一步。
- AS 驗證完成后,AS 會向 A 發(fā)送用 A 的對稱密鑰 KA 加密的報文,這個報文包含 A 和 TGS 通信的會話密鑰 KS 以及 AS 要發(fā)送給 TGS 的 Ticket 票據(jù),這個 Ticket 是用 TGS 的對稱密鑰 KTG 加密的。當(dāng)報文到達 請求者 A 時,A 就會根據(jù)口令和適當(dāng)?shù)乃惴ㄉ?KA 密鑰,密鑰 KA 會對 AS 發(fā)送過來的報文進行解密(A 并不會保存 KA 密鑰),解密過后就提取出會話密鑰 KS(這是 A 和 TGS 通信要使用的)以及要轉(zhuǎn)發(fā)給 TGS 的 Ticket (這是用 KTG 加密的)。總的來說這一步就是 AS 把消息發(fā)送給 A,A 根據(jù)口令生成解密密鑰 KA,然后解密報文提取 KTG 加密報文的過程。
- 此后 A 需要向票據(jù)服務(wù)器 TGS 發(fā)送報文,包括上一步 A 提取的會話密鑰 Ks,還有 AS 發(fā)給 A 的 KTG 加密報文,還有 A 需要告訴 TGS 通信的目標 B ,還有能預(yù)防重放攻擊的 Ks 加密的時間戳 T。
- TGS 發(fā)送兩個 Ticket,每一個都包含 A 和 B 通信的會話密鑰 KAB。給 A 的 Ticket 用 Ks 加密,發(fā)給 B 的票據(jù)用 KB 加密。
- 然后 A 向 B 轉(zhuǎn)發(fā) TGS 發(fā)給 A 的 Ticket,同時發(fā)送用會話密鑰 KAB 加密的時間戳 T。
- B 把時間戳 T + 1 來證實收到了 Ticket,同時這個時間戳也會用 KAB 加密。
在這之后,A 和 B 就可以使用 TGS 給出的會話密鑰 KAB 進行對話了。
公鑰的分配問題
公鑰分配的問題主要談?wù)摰木褪枪€分配的權(quán)威性問題,如果用戶 A 擁有 B 的公鑰,就可以實現(xiàn)安全通信,這就好像用戶 A 假如擁有攻擊者 C 的公鑰也就能實現(xiàn)安全通信了,其實不然,這個公鑰需要有權(quán)威機構(gòu)認證的,這個權(quán)威認證機構(gòu)就是CA(Certification Authority) ,它由政府出資建立,每個實體都需要有 CA 發(fā)來的證書,CA 包含公鑰和標識擁有者的信息,證書會由 CA 數(shù)字簽名,擁有 CA 頒發(fā)的證書后才能夠?qū)崿F(xiàn)安全通信。