轉！！通俗理解數字加密，數字簽名，數字證書和https

原博文地址：https://www.jianshu.com/p/4932cb1499bf

 

前言

最近在開發關於PDF合同文檔電子簽章的功能，大概意思就是在一份PDF合同上簽名，蓋章，使其具備法律效應。簽章有法律效應必須知足兩個條件：

• 可以證實簽名，蓋章者是誰，沒法抵賴
• PDF合同在簽章後不能被更改

在紙質合同中，因爲簽名字跡的不可複製性，蓋章的惟一性以及紙質合同對塗改的防範措施（好比金額用大寫）能夠保證上述兩點，從而具有法律效應，那麼PDF合同如何保障呢？兩個重要的概念就是數字簽名和數字證書。這項技術普遍運用於文件認證，數據傳輸等。
爲了弄懂這些，我花了2天時間從加密算法開始，到數字簽名和CA證書，最後再從新認識下https的原理。

非對稱加密

加密我瞭解的很少，只知道有這麼兩種算法：對稱加密和非對稱加密。

• 對稱加密：加密和解密的密鑰同樣，好比用123加密就是用123解密，可是實際中密碼都是普通數據在互聯網傳輸的，這樣一點密碼被中間人截取並破解，加密直接被攻破。
• 非對稱加密：把密鑰分爲公鑰和私鑰，公鑰是公開的全部人均可以認領，私鑰是保密的只有一我的知道。假設A要發送一封Email給B，他不想讓任何其餘人在傳輸中看到Email的內容，作法就是使用B的公鑰對Email加密，只有B的私鑰可以解密（B的私鑰惟一性保證信件不會泄露）。
  某天出意外了，有黑客冒充A給B發送Email，而且也用B的公鑰加密，致使B沒法區分這封郵件是否來自A。怎麼辦？此時A能夠用本身的私鑰加密，那麼B收到郵件後若是用A的公鑰能夠解密郵件，那麼證實這封信確定來自於A。
  OK，經過這個例子我想大家基本明白非對稱加密了！我總結了下面幾點：
  公鑰的做用：對內容自己加密，保證不被其餘人看到。
  私鑰的做用：證實內容的來源
  公鑰和私鑰是配對關係，公鑰加密就用私鑰解密，反之亦然，用錯的密鑰來嘗試解密會報錯。

數字簽名

接着聊上面發郵件的例子，假設A用本身的私鑰對Email加密發送，這存在下面問題：

• 對文件自己加密多是個耗時過程，好比這封Email足夠大，那麼私鑰加密整個文件以及拿到文件後的解密無疑是巨大的開銷。
  數字簽名能夠解決這個問題：
  1.A先對這封Email執行哈希運算獲得hash值簡稱「摘要」，取名h1
  2.而後用本身私鑰對摘要加密，生成的東西叫「數字簽名」
  3.把數字簽名加在Email正文後面，一塊兒發送給B
  （固然，爲了防止郵件被竊聽你能夠用繼續公鑰加密，這個不屬於數字簽名範疇）
  4.B收到郵件後用A的公鑰對數字簽名解密，成功則表明Email確實來自A，失敗說明有人冒充
  5.B對郵件正文執行哈希運算獲得hash值，取名h2
  6.B 會對比第4步數字簽名的hash值h1和本身運算獲得的h2，一致則說明郵件未被篡改。

  
  
   

  

  圖1.png

看完這個過程，是否是以爲數字簽名不過如此。其實就是利用算法（不必定是非對稱算法）對原文hash值加密，而後附着到原文的一段數據。數字簽名的做用就是驗證數據來源以及數據完整性！解密過程則稱爲數字簽名驗證。
不過先彆着急，我在梳理數字簽名流程時候有下面幾點疑惑，不知你也是否同樣？

1. 若是中間人同時篡改了Email正文和數字簽名，那B收到郵件沒法察覺啊。
   答案：數字簽名的生成須要對方私鑰，因此數字簽名很難被僞造。萬一私鑰泄漏了呢，很差意思，你私鑰都能弄丟了那這篇文章當我白寫。（私鑰絕對保密不參與傳輸）
2. 公鑰是公開的而且能夠自行導入到電腦，若是有人好比C偷偷在B的電腦用本身公鑰替換了A的公鑰，而後用本身的私鑰給B發送Email，這時B收到郵件實際上是被C冒充的可是他沒法察覺。
   答案：確實存在這種狀況！解決辦法就是數字證書，一環套一環請接着看。

數字證書

上面第2點描述的安全漏洞根源在哪？就是A的公鑰很容易被替換！那麼數字證書是怎麼生成的呢？以及如何配合數字簽名工做呢？

1. 首先A去找"證書中心"（certificate authority，簡稱CA），爲公鑰作認證。證書中心用本身的私鑰，對A的公鑰和一些相關信息一塊兒加密，生成"數字證書"（Digital Certificate）：

   
   
    

   

   圖2.png

2. A在郵件正文下方除了數字簽名，另外加上這張數字證書

   
   
    

   

   image.png

3. B收到Email後用CA的公鑰解密這份數字證書，拿到A的公鑰，而後驗證數字簽名，後面流程就和圖1的流程同樣了，再也不贅述。
   和數字簽名同樣我在梳理這個流程時有下面幾點疑惑：

• 假設數字證書被僞造了呢？
  答案：是的，傳輸中數字證書有可能被篡改。所以數字證書也是通過數字簽名的，是否是感受很繞貌似陷入了「雞生蛋蛋生雞」，我保證這是最後一個蛋- - ！上文說道數字簽名的做用就是驗證數據來源以及數據完整性！B收到郵件後能夠先驗證這份數字證書的可靠性，經過後再驗證數字簽名。
• 要是有1萬我的要給B發郵件，難道B要保存1萬份不一樣的CA公鑰嗎？
  答案：不須要，CA認證中心給能夠給B一份「根證書」，裏面存儲CA公鑰來驗證全部CA分中心頒發的數字證書。CA中心是分叉樹結構，相似於公安部->省公安廳->市級派出所，無論A從哪一個CA分支機構申請的證書，B只要預存根證書就能夠驗證下級證書可靠性。
• 如何驗證根證書可靠性？
  答案：沒法驗證。根證書是自驗證證書，CA機構是得到社會絕對承認和有絕對權威的第三方機構，這一點保證了根證書的絕對可靠。若是根證書都有問題那麼整個加密體系毫無心義。

舉個栗子

上面一直在說虛擬場景，下文舉個實際例子看看數字簽名+數字證書如何驗證文件的來源，以及文件的完整性。好比下載文件：咱們開發中通常是服務端給文件信息加上md5,客戶端下載完成後校驗md5來判斷文件是否損壞，這個其實就是簡單的校驗機制，而不少正規企業好比google都會給官方軟件簽署數字簽名和證書，而windows已經預置了不少CA根證書：

 

image.png

而後看下我以前從網上下載的Chrome.exe，右鍵屬性，經過鼠標點擊一步驗證：

 

image.png

Google Inc就是google從CA中心申請的數字證書。這樣看來，這個軟件確實來源於google官方，而且文件完整。接下來我乾點壞事，用notepad打開這個exe文件而且篡改裏面的內容（修改二進制數據，09 改成33），保存：

 

image.png

再看下數字簽名還正常嗎？

 

image.png

文件被篡改致使數字簽名無效，數字證書沒有問題。

https簡單介紹

數字簽名和數字證書能夠用於文件，固然也能用於html網頁數據。本人沒有https相關開發經驗，故不作深刻探討只是簡單介紹下。

• http的安全缺陷

1. 沒法驗證服務端的身份
2. 沒法保證數據完整性
3. 沒法保證數據傳輸不被竊聽

而https就是專門解決這三個問題，https使用數字簽名+數字證書解決了前2個問題，不少大型網站好比baidu.com都會採用https協議，網址左側會出現綠色加鎖標識：

 

image.png

點擊能夠查看證書，另外瀏覽器都會內置CA根證書，來對這些網站的服務器證書進行校驗。
而後，再用SSL協議對傳輸通道加密，保證數據傳輸不被竊聽，這個SSL加密原理分爲不少步驟不在本文討論範圍。

總結

全文比較深刻地探討了非對稱加密，數字簽名和數字證書的原理，最後引出https的簡單介紹，若有差錯盡請指正。

做者：08_carmelo 連接：https://www.jianshu.com/p/4932cb1499bf 來源：簡書 簡書著做權歸做者全部，任何形式的轉載都請聯繫做者得到受權並註明出處。