[ipsec][crypto] 有點不一樣的數字證書究竟是什麼

前言

前言是在寫完了全文以後回頭補的。本意是想徹底抽象的把證書的抽象邏輯意義表達出來，由於你能找到的大部分

資料都深陷在技術細節與行業規範裏。只有其型沒有其理，沒有什麼比理解一個事物的內在合理性更有樂趣的了。

因此忍不住表達的慾望想把他們寫出來。

無奈改了幾版，始終寫的混亂。因此，每個能讀完的人，我都對你的支持表示感謝，若是有再深刻討論的

意願，請和我聯繫。

很遺憾理解了九成，表達出來卻只剩下五成。原諒我表達欠佳。

[防扒亂入]  author: class_tong  date: 20190914

 

〇 引言

數字證書是什麼？本文的出發點就是要從個人角度回答這個問題。同時咱們引入ike和tls做爲理解概念的現實工具，一併在文中乘機引入。

用以加深理解，也用以迴歸實踐。

以下這句話是個人回答：

證書是由權威機構進行了數字簽名的一段信息，這段信息表達了一個公鑰與一個名字以及該名字的附帶屬性之間的關聯關係。該名字從屬於一個有效的名字系統。

換一個表達方式，一樣表述上述內容：

證書是這樣一段信息：權威機構A說，我保證，公鑰P是名字N的。

 

再下面這一段，是wiki的回答：

In cryptography, a public key certificate, also known as a digital certificate or identity certificate, 
is an electronic document used to prove the ownership of a public key[1]. The certificate includes information about the key, 
information about the identity of its owner (called the subject), and the digital signature of an entity 
that has verified the certificate's contents (called the issuer).

 

我認爲，我表達的雖然土，可是是正確的。也就是說，以上三個回答，表述了數字證書的同一個定義。

接下來，咱們一塊兒來理解。

 

一 講個故事

講清楚這個事，須要引入幾個前提。它們分別是以下的幾個概念：

1.權威機構，2，消息認證碼， 3.數字簽名，4.公鑰，5.名字，6.名字系統，7.證書頒發

我同時假設，你在閱讀到這裏的時候，是懂得什麼是公鑰/私鑰的。由於本文只聚焦在認證體系的相關脈絡內討論，因此3.公鑰將不作解釋。

以及：公鑰加密私鑰解密爲何可以提供機密性？私鑰加密公鑰解密爲何可以提供惟一性？也不作解釋。（因此，請自然接受他們做爲繼續閱讀下去的前提。）

 

描述一個場景：

來自艾澤拉斯的小a，與來自永爍星光之地的小b，從小就是好朋友。有一天他們雙雙入獄，而後一個越獄的故事就發生了。。。

這座監獄有500名囚犯，關押在各自獨立的500個牢房裏，彼此沒法見面，惟一的溝通方式就是寫紙條。而後經過一個不安全的紙條傳遞系統傳遞給任何人。

若是一我的要想加入整個溝通體系裏。它首先必需要有個一個名字：一個數字，一個編號，或者一個自定義的詞。

咱們統一稱其爲名字。

好比，小a。只有擁有了一個名字以後，才能在和其餘人進行了通訊以後，獲得對方的迴應。不然，對方將不知道

應該把紙條迴應給誰。一樣，想要和小a主動進行聯繫的人，若是不知道小a的名字，也沒有辦法告訴紙條傳遞系統

，該將紙條傳遞給誰。

這就是名字的意義。

這個故事是這樣的，一塊兒坐牢以前，小a和小b是好朋友（最佳損友？）。他們對彼此都充分信賴。接下來，

小b寫了一張紙條，「咱們晚上九點越獄。」，發送給小a（小a知道小b會發來消息，而且一直在等待小b的消息）。

小b爲了證實消息真的是本身發的，在紙條最後蓋了一個印章（咱們知道印章的防僞辦法是，

找到另外一張值得信賴的印章印記進行花紋對比），並將印章蓋在了內容的上方（創建強關聯，這個能夠對應理解成

散列函數的功能）。小a爲了印證消息真的來自小b，而不是監獄系統釣魚執法，他找到了老z，跟老z要了一張小b從前的印章印記。

 

好的，咱們梳理一下，如今這裏邊有三我的a, b, z，一個附帶印章的紙條，一個印章印記。

因而，小a在選擇是否越獄以前，必須先回答以下幾個問題：

1，紙條內容（包括印章）在傳遞中沒有被篡改。  

2，紙條印章與老z給的印章吻合。

3，這個吻合的印章花紋，確實屬於小b。

4，老z提供的印記真的是可信的。

假設老z被證實了可信，便會將對小b的信任傳遞給小a，也就是說由於：z信任b，而a信任z，

因此，a便可以信任z提供的消息真實，也就是3能夠成立。那麼，這裏便隱含了新的問題：

5，老z如何證實他拿到b的印記時，真的是屬於a的。

 

解決問題1，用到的方法是消息認證或數字簽名，也就是前邊穿幫了的散列函數。

解決問題2，用到的方法是數字簽名，也就是私鑰加密，公鑰解密。可是公鑰的得到已經牽扯到了數字證書。

解決問題3，4，用到的方法是數字證書。咱們能夠將數字證書的結構進行拆解，使其分別解決問題3,4

[防扒亂入]  author: class_tong  date: 20190914 

問題5，表明的是數字證書的頒發過程。

爲了進一步說明問題， 咱們如今改變場景佈置。約定問題4是成立的，老z在整個監獄內擁有絕對的權威，全部人

都信任他，他手裏拿着全部人的印章印記。他親自完成了證書的頒發過程（也就是親眼見到每個人在他的印記本上作印記蓋章）

好了，咱們如今又引進了新的概念，證書頒發。

而，在新的場景佈置下，老z就是權威機構。

 

而保證每一個人名字背後都只對應着一我的的系統，就是名字系統。名字和人的對應關係是多對一的關係，即一我的能夠同時

擁有多個名字。且對應關係不可修改。

 

如今，咱們跳出這個例子，其實多我的也能夠共同擁有一個名字，可是這多我的會被名字系統理解爲一個單一實體，

因此，其實仍是一個多對一的關係。總之名字系統解決的是名字的惟一性問題，爲後面的討論作準備。

 

終於。我用土話編一個穿幫的故事成功的引出了這七個概念。我相信懂的人都看的懂，不懂的人怕是更加不懂了。。。

 

二 不講故事

再梳理一次，上邊的故事概念，正經八百的。

密碼工程分兩大塊：加密和認證（are you sure?)，咱們這裏，只討論認證，不討論加密。

另外，名字和名字系統經過上面的故事，也講的很清楚（不明不白的）了，也不討論了。

 

1 認證

認證分爲消息認證和源認證兩個。咱們設想迷茫的小a，收到消息以後，最擔憂的其實就是這兩件事情

（1）消息內容是否是真實的。（2）消息源是否是真實的。

這裏須要注意前文中一個重要的設定，小a預期小b的消息。

因此，消息內容是否是真實指的是，小a拿到的內容是否是就是小b想傳遞的。

同時，消息源是否是真實的是指，寫消息這我的，是否是就是小a內心所想的那個（入獄前就認識的那個）小b。

 

1.1 消息認證

前文已經提到，作消息認證，咱們用到了HASH。準確的說就是散列函數。經過對消息體和祕鑰的散列函數，從而

生成消息認證碼。HASH_func(消息體+祕鑰），祕鑰就是對稱加密的祕鑰，就是一段只有a與b知道的字符串(額，從天而降的祕鑰。。。

不過這裏只是稍微引入，下一小節裏會去掉，因此上邊的故事仍是能說過去的。)

收到消息的一方，能夠從新計算這個hash，從而證實消息內容沒有篡改。

 

1.2 源認證

源認證就複雜了。

簡單的說，就是被認證的一方使用私鑰加密一段內容。把密文發送給對方。對方用公鑰解開，發現獲得的內容和明文保持一致。

便證實了，發送消息的一方，確實是擁有該公鑰所對應祕鑰的人。這個東西就叫數字簽名。通常來講，在數字簽名裏，用私鑰加密的

是明文的散列值。而後接觸明文以後。再用hash和公鑰解密的內容對比。

這時，咱們驚奇的發現，數字簽名同時完成了消息認證碼的工做，也就是作了消息認證也作了源認證。並且，還去掉上小節裏的祕鑰。

 

不過，其實這裏只是勉強說明了源認證。可是並不完全。由於，咱們設定的源認證是指：發送消息的人小b就是小a內心所想的那我的。

到目前，咱們解決了幾個問題：1 消息是可信的。2, 發送方與小a手裏的公鑰已經創建了強關聯（相信這個公鑰屬於小a內心所想的那我的，也就能

相信消息的發送方是小a內心所想的那我的）

接下來須要進一步解決的，就是：如何證實公鑰屬於小a內心所想的那我的

這個步驟將由數字證書來完成。

 [防扒亂入]  author: class_tong  date: 20190914

2 數字證書

2.1 做用

咱們如今知道，數字證書的做用就是證實：公鑰屬於你內心的那我的。

那我的要有一個代號，也就是前文提到的名字。這個名字是存在於名字系統裏的。名字系統保證了名字的有效性，惟一性和不會從新指派。

因而，在引入名字系統以後，數字證書的做用就變成了：公鑰屬於名字。（固然，你內心想的那我的的名字）

而另外一個須要強調的事情是，在咱們剛剛引入名字以前的全部推理裏。都不存在名字這樣一個概念。也就是說，前邊咱們只是證實了這樣

一件事情：小a收到了一條消息。這條消息屬於有個公鑰p所對應的私鑰。也就是說，只創建了消息與公鑰之間的關係關聯。

 

前面咱們提到了證書的做用，這也偏偏是證書存在的形式。每個證書是一個公鑰，以及這樣的一個對應關係：公鑰對應的名字。

因此，基於1）中的推論，咱們如今可以獲得新的一個推論：消息屬於公鑰對應的名字。也就是創建了消息與名字直接的關係。

也就是說，發消息的人，就是名字所表明的人。

 

2.2 額外邏輯

這仍是沒有達到目的。由於還須要判斷小a內心所想的那個名字，與咱們上一小結推理出的名字是否一致。

這個，咱們不討論。小a會引入任何一種方法來完成這件事情，從而完成邏輯閉環。好比，打開證書看一眼。無論他。

可是咱們假設這條消息是符合預期的，小a打開證書看了以後，真的寫着小b。而他內心想的也是小b。

好的。到這裏。咱們終於完成這條消息的源認證。

 

這即是整個過程當中，數字證書存在的意義。

 

3 證書頒發

以上內容裏，咱們預設了一個前提。就是小a自然的的擁有這小b的證書。

事實上，在通訊中，這是不可能的。總要有一個途徑拿到這個證書。而且徹底詳細這個證書的安全和可信性。

這即是權威機構（也就是老z）要作的事情。

老z，對這個證書預先作了數字簽名。從而保證了證書的可信性。因此只要你相信老z，就能夠詳細老z簽名的

全部證書。

如上文，老z就是權威機構，如上過程就叫作證書頒發。

 

4 其餘

除了借用名字來創建完整的信任邏輯鏈條外。還可使用別名。

事實上在x.509證書格式中，名字被稱爲subject, 別名被稱做subject alternative name

 

如，在配置strongswan時，用戶的大腦與軟件之間創建聯繫，就用的subject。

在strongswan的配置文件中，要顯示指名我想要連接的對方的ID=【x509中的subject字符串】

又如，在https中，用戶大腦與瀏覽器直接創建的聯繫，就是使用suject alternative name

也就是域名，如www.baidu.com。 在baidu的證書中，若干域名是SAN。

若是你不經過域名訪問，而是經過IP地址直接訪問。瀏覽器就會報警，說不安全的訪問。

雖然一塊兒都是對的，可是，卻缺乏了從用戶的大腦到名字的邏輯鏈條，也就是證書的做用

沒有達到。

 

寫了太多了，不得不拆成兩篇發：

下一篇，重點講ipsec和tls中的端認證機制：[ipsec][crypto] ike/ipsec與tls的認證機制比較

[防扒亂入]  author: class_tong  date: 20190914