摘要：王蒙沒(méi)那么淺地談?wù)勁c二四加密算法和密鑰管理介紹密鑰交換機(jī)制之前先普及一些加密算法基本知識(shí)以及為什么要有密鑰管理機(jī)制。證書(shū)證書(shū)，顧名思義，就是頒發(fā)的證書(shū)。公鑰基礎(chǔ)設(shè)施公鑰基礎(chǔ)設(shè)施，簡(jiǎn)稱(chēng)是目前網(wǎng)絡(luò)安全建設(shè)的基礎(chǔ)與核心。

**玫瑰與荊棘共生，香菇與毒菇同長(zhǎng)，真實(shí)與假冒比翼騰飛?！趺?br>**

沒(méi)那么淺地談?wù)凥TTP與HTTPS【二】

四、加密算法和密鑰管理

介紹密鑰交換機(jī)制之前先普及一些加密算法基本知識(shí)以及為什么要有密鑰管理機(jī)制。

1. 加密算法

加密算法就是將普通信息（明文）轉(zhuǎn)換成難以理解的數(shù)據(jù)（密文）的過(guò)程；

解密算法則是其相反的過(guò)程：由密文轉(zhuǎn)換回明文；

加解密包含了這兩種算法，一般加密即同時(shí)指稱(chēng)加密與解密的技術(shù)。

加解密的具體運(yùn)作由兩部分決定：一個(gè)是算法，另一個(gè)是密鑰。

密鑰是一個(gè)用于加解密算法的秘密參數(shù)，通常只有通信者擁有。

1） 對(duì)稱(chēng)密鑰加密

對(duì)稱(chēng)密鑰加密是密碼學(xué)中的一種加密法，是以轉(zhuǎn)換其中一個(gè)數(shù)字、字母或僅字符串隨機(jī)字母，一個(gè)秘密密鑰會(huì)以特定的方式變更消息里面的文字或字母，例如更換字母相對(duì)位置（例如hello變成lohel）。只要寄件者與收件者知道秘密密鑰，他們可以加密和解密并使用這個(gè)數(shù)據(jù)。

2.）公開(kāi)密鑰加密

公開(kāi)密鑰加密（也稱(chēng)為非對(duì)稱(chēng)加密）是密碼學(xué)中的一種加密法，非對(duì)稱(chēng)密鑰，是指一對(duì)加密密鑰與解密密鑰，某用戶(hù)使用加密密鑰加密后所獲得的數(shù)據(jù)，只能用該用戶(hù)的解密密鑰才能夠解密。如果知道了其中一個(gè)，并不能計(jì)算出另外一個(gè)。因此如果公開(kāi)了其中一個(gè)密鑰，并不會(huì)危害到另外一個(gè)。因此公開(kāi)的密鑰為公鑰；不公開(kāi)的密鑰為私鑰。

2. 單純使用加密算法存在的問(wèn)題

通信雙方使用加密算法之后，需要密鑰來(lái)解密和加密信息，而雙方如何得到、交換密鑰，并且不會(huì)被第三方竊取，或者說(shuō)密鑰就算被竊取也不會(huì)導(dǎo)致密文被解密讀取呢？

1）單純對(duì)稱(chēng)加密算法的困境：

如果“單純用對(duì)稱(chēng)加密”，瀏覽器和網(wǎng)站之間勢(shì)必先要交換“對(duì)稱(chēng)加密的密鑰”。

如果這個(gè)密鑰直接用【明文】傳輸，很容易就會(huì)被第三方（有可能是“攻擊者”）偷窺到；如果這個(gè)密鑰用密文傳輸，那就再次引入了“如何交換加密密鑰”的問(wèn)題——這就變成“先有雞還是先有蛋”的循環(huán)邏輯了。

2）單純非對(duì)稱(chēng)加密算法的困境：

基于“加密和解密采用不同的密鑰”的特點(diǎn)，可以避開(kāi)前面提到的“循環(huán)邏輯”的困境。大致的步驟如下：

第1步 網(wǎng)站服務(wù)器先基于“非對(duì)稱(chēng)加密算法”，隨機(jī)生成一個(gè)“密鑰對(duì)”（為敘述方便，稱(chēng)之為“k1 和 k2”）。因?yàn)槭请S機(jī)生成的，目前為止，只有網(wǎng)站服務(wù)器才知道 k1 和 k2。
第2步 網(wǎng)站把 k1 保留在自己手中，把 k2 用【明文】的方式發(fā)送給訪(fǎng)問(wèn)者的瀏覽器。 因?yàn)?k2 是明文發(fā)送的，自然有可能被偷窺。不過(guò)不要緊。即使偷窺者拿到 k2，也【很難】根據(jù) k2 推算出 k1 （這一點(diǎn)是由“非對(duì)稱(chēng)加密算法”從數(shù)學(xué)上保證的）。
第3步 瀏覽器拿到 k2 之后，先【隨機(jī)生成】第三個(gè)對(duì)稱(chēng)加密的密鑰（簡(jiǎn)稱(chēng) k）。 然后用 k2 加密 k，得到 k（k 是 k 的加密結(jié)果） 瀏覽器把 k 發(fā)送給網(wǎng)站服務(wù)器。 由于 k1 和 k2 是成對(duì)的，所以只有 k1 才能解密 k2 的加密結(jié)果。 因此這個(gè)過(guò)程中，即使被第三方偷窺，第三方也【無(wú)法】從 k 解密得到 k
第4步 網(wǎng)站服務(wù)器拿到 k 之后，用 k1 進(jìn)行解密，得到 k 至此，瀏覽器和網(wǎng)站服務(wù)器就完成了密鑰交換，雙方都知道 k，而且【貌似】第三方無(wú)法拿到 k 然后，雙方就可以用 k 來(lái)進(jìn)行數(shù)據(jù)雙向傳輸?shù)募用堋?/blockquote>

乍看以上步驟很?chē)?yán)密，即使被第三方偷窺，第三方也難以從 k 解密得到 k。

但這種方法有一個(gè)致命的缺陷，就是無(wú)法防止數(shù)據(jù)篡改，也無(wú)法識(shí)別假冒的身份。

攻擊方法如下：

第1步 這一步跟原先一樣——服務(wù)器先隨機(jī)生成一個(gè)“非對(duì)稱(chēng)的密鑰對(duì)”k1 和 k2（此時(shí)只有網(wǎng)站知道 k1 和 k2）
第2步 當(dāng)網(wǎng)站發(fā)送 k2 給瀏覽器的時(shí)候，攻擊者截獲 k2，保留在自己手上。 然后攻擊者自己生成一個(gè)【偽造的】密鑰對(duì)（以下稱(chēng)為 pk1 和 pk2）。 攻擊者把 pk2 發(fā)送給瀏覽器。
第3步 瀏覽器收到 pk2，以為 pk2 就是網(wǎng)站發(fā)送的。 瀏覽器不知情，依舊隨機(jī)生成一個(gè)對(duì)稱(chēng)加密的密鑰 k，然后用 pk2 加密 k，得到密文的 k 瀏覽器把 k 發(fā)送給網(wǎng)站。 （以下是關(guān)鍵）
發(fā)送的過(guò)程中，再次被攻擊者截獲。 因?yàn)?pk1 pk2 都是攻擊者自己生成的，所以攻擊者自然就可以用 pk1 來(lái)解密 k 得到 k 然后，攻擊者拿到 k 之后，用之前截獲的 k2 重新加密，得到 k，并把 k 發(fā)送給網(wǎng)站。
第4步 網(wǎng)站服務(wù)器收到了 k 之后，用自己保存的 k1 可以正常解密，所以網(wǎng)站方面不會(huì)起疑心。 至此，攻擊者完成了一次漂亮的偷梁換柱，而且讓雙方都沒(méi)有起疑心?！　?/blockquote>

上述過(guò)程，即是傳說(shuō)中的中間人攻擊（Man-In-The-Middle attack ）。

3. 失敗的原因—缺乏【可靠的】身份認(rèn)證

為什么以上方案會(huì)失?。?/p>

除了提到的“攻擊者具備篡改數(shù)據(jù)的能力”，還有另一點(diǎn)關(guān)鍵點(diǎn)——“缺乏身份認(rèn)證機(jī)制”。

正是因?yàn)椤叭狈ι矸菡J(rèn)證機(jī)制”，所以當(dāng)攻擊者一開(kāi)始截獲 k2 并把自己偽造的 pk2 發(fā)送給瀏覽器時(shí)，瀏覽器無(wú)法鑒別：自己收到的密鑰是不是真的來(lái)自于網(wǎng)站服務(wù)器。

假如具備某種【可靠的】身份認(rèn)證機(jī)制，即使攻擊者能夠篡改數(shù)據(jù)，但是篡改之后的數(shù)據(jù)很容易被識(shí)破。那篡改也就失去了意義。于是我們引入“CA認(rèn)證體系”。

五、CA認(rèn)證體系

CA

數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)（英語(yǔ)：Certificate Authority，縮寫(xiě)為CA），也稱(chēng)為電子商務(wù)認(rèn)證中心、電子商務(wù)認(rèn)證授權(quán)機(jī)構(gòu)，是PKI(公鑰基礎(chǔ)設(shè)施)的核心執(zhí)行機(jī)構(gòu)，是PKI的主要組成部分，并作為電子商務(wù)交易中受信任的第三方，承擔(dān)公鑰體系中公鑰的合法性檢驗(yàn)的責(zé)任。

從廣義上講，認(rèn)證中心還應(yīng)該包括證書(shū)申請(qǐng)注冊(cè)機(jī)構(gòu)RA（Registration Authority），RA是數(shù)字證書(shū)的申請(qǐng)注冊(cè)、證書(shū)簽發(fā)的管理機(jī)構(gòu)。

CA證書(shū)

CA 證書(shū)，顧名思義，就是CA頒發(fā)的證書(shū)。 　　

人人都可以找工具制作證書(shū)。但是個(gè)人制作出來(lái)的證書(shū)是沒(méi)什么用處的。

因?yàn)槟恪静皇恰繖?quán)威的 CA 機(jī)關(guān)，你自己搞的證書(shū)不具有權(quán)威性。 　　

PKI公鑰基礎(chǔ)設(shè)施

公鑰基礎(chǔ)設(shè)施（Public Key Infrastructure，簡(jiǎn)稱(chēng)PKI）是目前網(wǎng)絡(luò)安全建設(shè)的基礎(chǔ)與核心。

簡(jiǎn)單的說(shuō)PKI技術(shù)就是利用公鑰理論和技術(shù)建立的提供信息安全服務(wù)的基礎(chǔ)設(shè)施，該體系在統(tǒng)一的安全認(rèn)證標(biāo)準(zhǔn)和規(guī)范基礎(chǔ)上提供在線(xiàn)身份認(rèn)證，是_CA認(rèn)證、數(shù)字證書(shū)、數(shù)字簽名_以及相關(guān)_安全應(yīng)用組件模塊_的集合。

做為一種技術(shù)體系，PKI可以作為支持認(rèn)證、完整性、機(jī)密性和不可否認(rèn)性的技術(shù)基礎(chǔ)，從技術(shù)上解決網(wǎng)上身份認(rèn)證、信息完整性的抗抵賴(lài)等安全問(wèn)題，為網(wǎng)絡(luò)應(yīng)用提供可靠的安全保障，但PKI不僅僅涉及到技術(shù)層面的問(wèn)題。

證書(shū)鏈

為了盡可能的保證根證書(shū)的安全性，CA中心采取了一種樹(shù)狀的結(jié)構(gòu)：

一個(gè)root CA下面包含多個(gè)intermediates CA，然后根CA和次級(jí)CA都可以頒發(fā)證書(shū)給用戶(hù)，頒發(fā)的證書(shū)分別是根證書(shū)和次級(jí)證書(shū)，最后則是用戶(hù)的證書(shū)，也可以說(shuō)是中級(jí)證書(shū)。

證書(shū)信任鏈

實(shí)際上，證書(shū)之間的信任關(guān)系，是可以嵌套的。比如，C 信任 A1，A1 信任 A2，A2 信任 A3......這個(gè)叫做證書(shū)的信任鏈。

只要你信任鏈上的頭一個(gè)證書(shū)，那后續(xù)的證書(shū)，都是可以信任的。

CA認(rèn)證體系的基本使用

1. 服務(wù)方S向第三方機(jī)構(gòu)CA提交公鑰、組織信息、個(gè)人信息(域名)等信息并申請(qǐng)認(rèn)證;
2. CA通過(guò)線(xiàn)上、線(xiàn)下等多種手段驗(yàn)證申請(qǐng)者提供信息的真實(shí)性，如組織是否存在、企業(yè)是否合法，是否擁有域名的所有權(quán)等;
3. 如信息審核通過(guò)，CA會(huì)向申請(qǐng)者簽發(fā)認(rèn)證文件-證書(shū)。證書(shū)包含以下信息：申請(qǐng)者公鑰、申請(qǐng)者的組織信息和個(gè)人信息、簽發(fā)機(jī)構(gòu) CA的信息、有效時(shí)間、證書(shū)序列號(hào)等信息的明文，同時(shí)包含一個(gè)簽名;

（簽名的產(chǎn)生算法：首先，使用散列函數(shù)計(jì)算公開(kāi)的明文信息的信息摘要，然后，采用 CA的私鑰對(duì)信息摘要進(jìn)行加密，密文即簽名。）

1. 客戶(hù)端 C 向服務(wù)器 S 發(fā)出請(qǐng)求時(shí)，S 返回證書(shū)文件;
2. 客戶(hù)端 C讀取證書(shū)中的相關(guān)的明文信息，采用相同的散列函數(shù)計(jì)算得到信息摘要，然后，利用對(duì)應(yīng) CA的公鑰解密簽名數(shù)據(jù)，對(duì)比證書(shū)的信息摘要，如果一致，則可以確認(rèn)證書(shū)的合法性，即公鑰合法;
3. 客戶(hù)端驗(yàn)證證書(shū)相關(guān)的域名信息、有效時(shí)間等信息;
4. 客戶(hù)端會(huì)內(nèi)置信任CA的證書(shū)信息(包含公鑰)，如果CA不被信任，則找不到對(duì)應(yīng) CA的證書(shū)，證書(shū)也會(huì)被判定非法。

在這個(gè)過(guò)程注意幾點(diǎn)：

• 申請(qǐng)證書(shū)不需要提供私鑰，確保私鑰永遠(yuǎn)只能由服務(wù)器端掌握;
• 證書(shū)的合法性仍然依賴(lài)于非對(duì)稱(chēng)加密算法，證書(shū)主要是增加了服務(wù)器信息以及簽名;
• 內(nèi)置 CA 對(duì)應(yīng)的證書(shū)稱(chēng)為根證書(shū)，頒發(fā)者和使用者相同，自己為自己簽名，即自簽名證書(shū)（為什么說(shuō)"部署自簽SSL證書(shū)非常不安全"）
• 證書(shū)= 公鑰 + 申請(qǐng)者與頒發(fā)者信息 + 簽名;

★即便有人截取服務(wù)器A證書(shū)，再發(fā)給客戶(hù)端，想冒充服務(wù)器A，也無(wú)法實(shí)現(xiàn)。因?yàn)樽C書(shū)和url的域名是綁定的。

未完待續(xù)……

本文作者：UCloud后臺(tái)研發(fā)工程師 Hughes.Chen
博客地址：https://ulyc.github.io/