一文完全搞懂加密、數字簽名和數字證書！

微信搜索🔍「編程指北」，關注這個寫乾貨的程序員，回覆「資源」，便可獲取後臺開發學習路線和書籍

前言

這本是 2020 年一個平平無奇的週末，小北在家裏刷着 B 站，看着喜歡的 up 主視頻。

在一旁玩手機的女友忽然問」你知道數字證書是來幹啥的不，爲啥瀏覽器提示證書不可信？」

你要說這個，那我可來勁了，因而乎從加密、數字簽名一直講到了數字證書。。。終於把女友講睡着了，獨自寫下這篇文章。

正文

若是你能很是清晰的回答出如下問題，能夠直接拉到最下面幫我點個贊~，把時間用去陪陪女友：

1. 非對稱加密中公私鑰均可以加密，那麼何時用公鑰加密，何時用私鑰「加密」 ？
2. 什麼是數字簽名，數字簽名的做用是什麼？
3. 爲何要對數據的摘要進行簽名，而不是直接計算原始數據的數字簽名？
4. 什麼是數字證書，數字證書解決了什麼問題？

這篇文章，主要圍繞數字簽名和數字證書的原理以及它們的做用展開。

爭取作到讓不具有任何密碼學基礎知識的同窗都能聽懂，因此在這裏須要先對齊一些加密相關的概念 。

1. 什麼是加密

加密就是對明文數據按某種特殊算法進行處理，使其成爲不可讀的一段代碼，一般稱爲「密文「， 密文經過」密鑰「解密後還原出原來的明文，經過這樣的途徑能夠達到保護數據不被非法人竊取、閱讀的目的。

定義簡單吧？那來看個題，考慮如下哪些屬於加密方法：

• AES
• RSA
• MD5
• BASE64
• SM4

這幾種都是平常開發中經常使用的數據編碼技術，可是隻有 AES、RSA、SM4 才能算是加密方法。

爲何呢？一個區分的簡單方法就是看編碼後的數據是否還能還原，能還原的是加密。

MD5 其實是對數據進行有損壓縮，不管數據有多長，1KB、1Mb 仍是 1G，都會生成固定 128 位的散列值，而且 MD5 理論上是不可能對編碼後的數據進行還原的，即不可逆。

MD5 由於其具備不可逆性、單向恆定性（相同的數據屢次計算值不變）被普遍應用於文件完整性驗證、口令加密以及接下來會講到的數字簽名中。

至於 BASE64 是否算作加密方法，仁者見仁。在這裏不下結論，由於 BASE64 編碼不須要密鑰，且編碼後的字符串任何人均可以解碼出原串，因此通常不認爲是加密方法。BASE64 經常使用來作轉碼，把二進制字節序列轉化爲 ASCII 字符序列。

2. 加密算法的分類

加密算法按照加解密使用的密鑰是否相同，可分爲：

• 對稱加密（Symmetric Cryptography）
• 非對稱加密（Asymmetric Cryptography）

1. 對稱加密

對稱加密是指加密和解密時使用同一個密鑰。

2. 非對稱加密

非對稱加密是指加密和解密使用不一樣的密鑰，這兩個密鑰分別叫作「公鑰」、「私鑰」。

公鑰是能夠公開給全部人的，而私鑰須要本身保密的。

公鑰加密的數據只能用私鑰解密：

同理，私鑰「加密」的數據只能用公鑰「解密」：

你們注意到沒，我對 私鑰「加密」 這裏打了引號，爲何呢？

由於私鑰不是用來加密的，準確的說法應該是 「私鑰簽名，公鑰驗籤」。

這個問題不少同窗都存在誤解，認爲公私鑰均可以用於加密。

實際上不是的，至於爲何，後面講完簽名我會解釋的。

3. 故事開始

爲了講這個故事，小北請來了密碼學中經常使用的學術情侶，Alice 和 Bob，以及竊聽者表明 Eve。

咱們從 Alice、Bob 約會的故事展開，來說講其中暗藏着哪些危機，又是如何一步步化解的。

3.1 第一回合

九月，一個夜黑風高的晚上，Bob 想約 Alice 出來玩，因而給 Alice 發了一封郵件：

但咱們都知道網絡是不可信的，而且因爲消息在網絡中是明文傳輸的，因此黑客能夠輕易的截獲、篡改甚至冒充 Bob。

來，咱們看看黑客 Eve 是怎麼幹的：

瞧，Eve 輕易的拿到了郵件內容 （竊聽），而且修改了郵件內容 （篡改），甚至說他能夠隨時冒充 Bob 給 Alice 發送郵件 （假裝）。

若是上圖中 Eve 僞造的內容被 Alice 接收到了，那麼後果可想而知。

現實世界中，咱們天天都在經過網絡進行聊天、轉帳、瀏覽不存在網站。

若是都是這樣明文傳輸數據，顯然毫無安全感。

3.2 第二回合

既然咱們不能明文傳輸，那麼 Bob 和 Alice 提早商量好密鑰，使用對稱加密對郵件內容加密不就行了~

如今 Bob 發送的郵件都使用和 Alice 提早商量好的密鑰加密後再傳輸。

因爲沒有密鑰，Eve 就算截獲到數據也沒法獲取郵件的內容，也無法篡改和冒充 Bob。

由於篡改後的數據必須使用密鑰再次加密 Alice 才能正確解密。

那麼只要 Bob 和 Alice 可以保證 密鑰不泄露，整個通訊就是安全的。

若是密鑰泄露，被中間人截獲，那麼就等同於明文通訊。

因此咱們不能把安全性寄託在人上面。

而且這裏也存在一個問題，若是兩我的不能線下見面， 如何在網上安全的交換密鑰呢？

這彷佛是無解的，由於交換密鑰的時候咱們必須明文通訊，否則對方根本看不懂。可是明文交換即意味着可能泄露。

可是別忘了咱們的密碼學工具箱裏還有一個好東西— 「非對稱加密」。

Bob 和 Alice 各自生成一對公私鑰，由於公鑰原本就是公開的，便可以被任何人獲取，因此能夠經過網絡明文交換公鑰。

而後使用公鑰加密郵件內容後發送給對方，接收者使用本身的私鑰便可解密。完美~

3.3 第三回合

來看看，在非對稱加密體系下，Bob 如何給 Alice 發消息的。

首先 Alice 須要先生成一對公私鑰，私鑰只能 Alice 本身知道，公鑰是可讓任何人都知道的，所以可將公鑰直接發送給 Bob，就算被截獲也無所謂。

Bob 使用 Alice 的公鑰加密郵件內容，加密後的內容只能由 Alice 的私鑰解密，因此就算 Eve 截獲也是徒勞。

反之，若是 Alice 想給 Bob 回信，就須要用 Bob 的公鑰加密後發送。

這就解決了密鑰交換問題，也保證了郵件內容不會泄露。也就是說如今能夠防竊聽。

3.4 如何證實 Bob 是 Bob

不知道你注意到沒有，這裏也存在另一個問題：

Eve 也可使用 Alice 的公鑰冒充 Bob 給 Alice 發郵件啊，由於 Alice 的公鑰原本就是公開的，任何人均可以得到。

因爲 Eve 也能夠得到 Alice 公鑰，因此無法防止 Eve 僞造和篡改，而且對於 Alice 而言，她沒法分辨出郵件究竟是 Eve 發的仍是 Bob。

因此這個問題的本質就是 「Alice 如何確認郵件來自於 Bob」。

那麼在生活中，咱們如何作這件事呢？

那就是讓 Bob 在紙上簽名而且按手印，由於指紋和字跡是 Bob 獨有的，其它人很難僞造。

因此咱們須要在計算機中引入相似的機制：

即只有 Bob 本身可以產生的獨一無二的標誌，而且其它人可以驗證這個標誌確實是屬於 Bob的。

這就是咱們今天要講的主題—「數字簽名」。

還記得什麼是 Bob 獨有的嗎？

對，就是 Bob 本身的私鑰，Bob 用本身的私鑰對郵件內容計算一個「簽名」，將「簽名」和郵件內容一塊兒發送出去，接受者 Alice 可使用 Bob 的公鑰驗證這個簽名是否正確，這就叫「驗籤」。

若是不是 Bob 的私鑰計算的簽名，那麼 Alice 用 Bob 公鑰驗籤將會出錯。

能夠看到， Eve 試圖使用本身的私鑰計算簽名而後發送給 Alice， 可是 Alice 使用 Bob的公鑰進行驗籤時將會出錯！

那麼 Eve 可能篡改內容並冒充 Bob 的簽名嗎？不可能！由於內容發生改變時，對應的簽名也須要從新計算，而簽名的生成依賴於私鑰，只要 Bob 的私鑰不泄露，簽名就不會被冒充。

啊啥？你說萬一私鑰泄露了怎麼辦？那就當我沒說......

因此使用數字簽名，咱們可以鑑別消息的發送者，也就是說黑客沒法假裝發送者進行發送數據，也沒法篡改。

注意：

能夠看出咱們這裏數據是明文傳輸的，存在竊聽風險。可是咱們爲了闡述數字簽名機制是如何運轉的，故意將保證信息機密性的機制省略了。

若是想要保證數據的機密性，咱們常見的作法是，通訊雙方經過非對稱加密安全交換對稱加密的密鑰，後續通訊過程的數據都使用對稱加密保證數據機密性。

而且「簽名」的做用自己也不是用來保證數據的機密性，而是用於驗證數據來源的防止數據被篡改的，也就是確認發送者的身份。

通常而言，咱們不會直接對數據自己直接計算數字簽名，爲何呢？

由於數字簽名屬於非對稱加密，非對稱加密依賴於複雜的數學運算，包括大數乘法、大數模等等，耗時比較久。

若是數據量大的時候計算數字簽名將會比較耗時，因此通常作法是先將原數據進行 Hash 運算，獲得的 Hash 值就叫作「摘要」。

「摘要」就像人的指紋同樣，能夠表明一我的，只要內容發生了改變，計算出來的摘要也應該變化。

「摘要」最好是不可逆轉的，通常使用開頭提到的 MD5 做爲 Hash 函數，MD5 輸出的結果固定位 128 位。

爲何「摘要」最好是不可逆轉的？

由於既然 Alice 能夠用 Bob 公鑰解開簽名，那麼理論上其它人，好比 Eve 也可使用 Bob 公鑰解開簽名拿到數據。

因此咱們最好對數據的「摘要」進行簽名，這樣，Eve 就算解開簽名，拿到的也是「摘要」，若是摘要是不可逆轉的，也就是沒法從摘要反推出原文，也就達到了保密的做用。

發送者使用私鑰對「摘要」計算數字簽名。那麼接收者如何驗證呢？

接受者 Alice 收到後，取下數字簽名，同時用 Bob 的公鑰解密，獲得「摘要1」，證實確實是 Bob 發的。

( 畫外音：若是使用 Bob 的公鑰驗證簽名出錯，那麼簽名必定不是 Bob 的私鑰生成的）

再對郵件內容使用相同的散列函數計算「摘要2」，與上面獲得的「摘要1」進行對比，二者一致就說明信息未被篡改。

這樣兩步分證實發送者身份和保證數據未被篡改。

3.5 這就夠了嗎？

Bob 和 Alice 如今能夠依賴於對稱加密進行保密通訊，也能夠依賴於數字簽名驗證消息是不是對方發送的。

可是這一切的根基是創建在 Alice 持有的公鑰確實是 Bob的，反之亦然。

什麼意思呢？

試想，Eve 若是將本身的公鑰冒充 Bob 發送給 Alice，而後 Alice 保存了下來，那之後凡是 Bob 發送的消息，反而會驗證簽名失敗，被當作冒充者。
那你可能會問，爲何 Eve 能夠將本身的公鑰發送給 Alice，而 Alice 絕不知情呢？

看！咱們又回到了最初的起點，只不過此次被篡改的是公鑰，以前是消息自己。

由於 Bob 的公鑰是直接經過網絡發送給 Alice的，因此 Eve 才能夠在這一步作手腳，進行篡改，將本身的公鑰冒充 Bob 發送給 Alice，也就是發送公鑰這一步沒有作到：

• 防篡改
• 防冒充

防篡改怎麼和防冒充怎麼實現的呢？

咱們前面講了，就是靠數字簽名！ 可是數字簽名須要接受者持有發送者公鑰，才能進行驗籤。

而咱們如今處理的是分發公鑰這一步，因此.......死鎖了。這像是先有雞仍是先有蛋的問題

如今的問題就是「Bob 沒法證實它本身是 Bob」。

這個是否是似曾相識，之前去辦事的時候常常被要求出具「我媽是我媽」這類證實。可是咱們本身說「我媽就是我媽」，人家根本不會信呀，須要一個可信第三方出具證實，好比派出所。

那麼「Alice 如何才能確認 Bob 發送給本身的公鑰確實是 Bob 的，而沒有被篡改？」

在只有 Alice 和 Bob 兩人的狀況下是無法驗證的。

因此，咱們這裏也須要一個第三方幫 Bob證實 「Bob 的公鑰就是 Bob 的公鑰」，有點繞口令那感受了~

3.6 數字證書

爲了解決這個問題，就引入了「數字證書」，什麼叫數字證書呢？

百度百科：

數字證書是指在互聯網通信中標誌通信各方身份信息的一個數字認證，人們能夠在網上用它來識別對方的身份。

所以數字證書又稱爲數字標識。數字證書對網絡用戶在交流中的信息和數據等以加密或解密的形式保證了信息和數據的完整性和安全性。

看了這個描述，是否是感受仍是雲裏霧裏，仍是我用大白話來講吧~

只要你理解了前面的數字簽名，就能理解這裏的數字證書，由於我把數字證書叫作「公鑰的數字簽名」。

爲何呢？咱們引入數字證書的目的是爲了保證公鑰不被篡改，即便被篡改了也能識別出來。

而防篡改的方法就是數字簽名，可是這個簽名不能咱們本身作，緣由說過了，由於咱們的公鑰還沒分發出去，別人沒法驗證。

因此只能找可信的第三方來幫咱們簽名，即證書頒佈機構（CA），CA 會將：證書的頒佈機構、有效期、公鑰、持有者(subject)等信息用 CA 的私鑰進行簽名。

而且將簽名結果和這些信息放在一塊兒，這就叫作「數字證書」。

這樣，Bob 就能夠去 CA 申請一個證書，而後將本身的證書發給 Alice，那麼 Alice 如何驗證這個證書確實是 Bob的呢？

固然是使用 CA 的公鑰進行驗籤。

注意：

CA 的公鑰也是須要使用證書來分發的，因此 Alice 的電腦必須安裝 CA 的證書，證書裏包含了 CA 的公鑰。

收到 Bob 發過來的數字證書後，Alice 使用 CA 的公鑰進行驗證，驗證經過即證實這確實是 Bob 證書，也就可使用證書中包含的 Bob 的公鑰，按照以前討論的流程進行通訊。

那麼 Eve 是否能夠在中途篡改 Bob 的證書呢？

答案是不行，由於證書的信息使用 CA 的私鑰進行簽名，只要 Eve 修改了任何一個 Bit 都會致使最後簽名驗證不經過。

那 Eve 可不能夠修改證書信息後本身從新計算一次證書的數字簽名呢？

也不行，由於證書的數字簽名計算依賴於 CA 的私鑰，Eve 是拿不到 CA 的私鑰的。

若是拿到了，說明什麼？整個世界都是不可信的。

3.7 數字證書長啥樣

這是我電腦中的自帶的證書：

能夠看到，包含了證書持有人的公鑰和證書的簽名。

另外，證書頒發機構是有層級關係的，下級 CA 的證書是須要由上級 CA 簽名的。

換句話說必定存在根證書頒發機構，那麼他們的證書是由誰簽名的呢？

答案是自籤，本身給本身認證。

這是我電腦中的一個自籤的根證書頒發機構：

爲何根證書能夠自籤，誰來保證安全？

你把錢存在銀行，你會擔憂嗎？咱們基於對國家的信任，纔信任銀行，這就是信任鏈的基礎！咱們思考問題應該是分層的，若是不承認一個統一的基礎，一直套娃下去，那麼問題就無解。

那還有個問題，如何保證根證書的可靠性？
這是操做系統和瀏覽器預裝的，由微軟、蘋果等操做系統廠商來選擇根證書。

3.8 證書不可信？

那麼什麼狀況下瀏覽器會提示 「證書不可信」 呢？

根據咱們上面的分析，下面是可能的緣由：

1. 證書不是權威 CA 頒發

有些企業爲了貪圖便宜使用盜版的證書，沒有通過 CA 認證。也就是沒法使用瀏覽器內置 CA 公鑰進行驗證。

1. 證書過時

上面說了，證書裏有一項就是有效期，通常就是一年或者兩年的時間。若是證書過時，那麼瀏覽器就會提示「證書不可信」

1. 證書部署錯誤

多是服務器證書部署出錯，好比證書與域名不匹配，由於證書裏有一項是持有人信息的。

好了，饒了一大圈，Bob 終於能夠安全的向 Alice 發出前往紅樹林的邀請了~

附錄

QA

如今咱們來回答文章開頭提出的一些問題：

1. 非對稱加密中公私鑰均可以加密，那麼何時用公鑰加密，何時用私鑰「加密」 ？

   • 加密場景，那麼確定但願只有我才能解密，別人只能加密。即公鑰加密，私鑰解密。
   • 簽名場景，既然是簽名，就但願只能我才能簽名，別人只能驗證。即私鑰簽名，公鑰驗籤

2. 什麼是數字簽名，數字簽名的做用是什麼？

   • 數字簽名就是使用私鑰對數據摘要進行簽名，並附帶和數據一塊兒發送。
   • 能夠起到防篡改、防假裝、防否定的做用。

3. 爲何要對數據的摘要進行簽名，而不是直接計算原始數據的數字簽名？

   • 數據可能比較大，簽名是使用非對稱加密算法，比較耗時
   • 防止第三方使用公鑰解開簽名後，拿到原始數據

4. 什麼是數字證書，數字證書存在解決了什麼問題？

   • 數字證書就是由 CA 機構使用本身私鑰，對證書申請者的公鑰進行簽名認證。
   • 數字證書解決了如何安全分發公鑰的問題，也奠基了信任鏈的基礎。

絮叨

你們若是以爲寫得不錯，能夠幫幫點個關注，點贊~

大家的三連就是我創做的最大動力！

我是小北，一個天天在電腦前敲鍵盤的硬核男人，咱們下期見！