前言

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

• 能夠證明簽名，蓋章者是誰，無法抵賴
• PDF合同在簽章后不能被更改

在紙質(zhì)合同中，由于簽名字跡的不可復制性，蓋章的唯一性以及紙質(zhì)合同對涂改的防范措施（比如金額用大寫）可以保證上述兩點，從而具備法律效應，那么PDF合同如何保障呢？兩個重要的概念就是數(shù)字簽名和數(shù)字證書。這項技術(shù)廣泛運用于文件認證，數(shù)據(jù)傳輸?shù)取?br> 為了弄懂這些，我花了2天時間從加密算法開始，到數(shù)字簽名和CA證書，最后再重新認識下https的原理。

非對稱加密

兩種算法：對稱加密和非對稱加密。

• 對稱加密：加密和解密的密鑰一樣，比如用123加密就是用123解密，但是實際中密碼都是普通數(shù)據(jù)在互聯(lián)網(wǎng)傳輸?shù)?，這樣一點密碼被中間人截取并破解，加密直接被攻破。
• 非對稱加密：把密鑰分為公鑰和私鑰，公鑰是公開的所有人都可以認領(lǐng)，私鑰是保密的只有一個人知道。假設(shè)A要發(fā)送一封Email給B，他不想讓任何其他人在傳輸中看到Email的內(nèi)容，做法就是使用B的公鑰對Email加密，只有B的私鑰能夠解密（B的私鑰唯一性保證信件不會泄露）。
  某天出意外了，有黑客冒充A給B發(fā)送Email，并且也用B的公鑰加密，導致B無法區(qū)分這封郵件是否來自A。怎么辦？此時A可以用自己的私鑰加密，那么B收到郵件后如果用A的公鑰可以解密郵件，那么證明這封信肯定來自于A。
  OK，通過這個例子我想你們基本明白非對稱加密了！我總結(jié)了下面幾點：
  公鑰加密：對內(nèi)容本身加密，保證不被其他人看到。
  私鑰加密：證明內(nèi)容的來源
  公鑰和私鑰是配對關(guān)系，公鑰加密就用私鑰解密，反之亦然，用錯的密鑰來嘗試解密會報錯。

數(shù)字簽名

接著聊上面發(fā)郵件的例子，假設(shè)A用自己的私鑰對Email加密發(fā)送，這存在下面問題：

• 對文件本身加密可能是個耗時過程，比如這封Email足夠大，那么私鑰加密整個文件以及拿到文件后的解密無疑是巨大的開銷。
  數(shù)字簽名可以解決這個問題：
  1.A先對這封Email執(zhí)行哈希運算得到hash值簡稱“摘要”，取名h1
  2.然后用自己私鑰對摘要加密，生成的東西叫“數(shù)字簽名”
  3.把數(shù)字簽名加在Email正文后面，一起發(fā)送給B
  （當然，為了防止郵件被竊聽你可以用繼續(xù)公鑰加密，這個不屬于數(shù)字簽名范疇）
  4.B收到郵件后用A的公鑰對數(shù)字簽名解密，成功則代表Email確實來自A，失敗說明有人冒充
  5.B對郵件正文執(zhí)行哈希運算得到hash值，取名h2
  6.B 會對比第4步數(shù)字簽名的hash值h1和自己運算得到的h2，一致則說明郵件未被篡改。

  
  
  圖1.png

其實就是利用算法（不一定是非對稱算法）對原文hash值加密，然后附著到原文的一段數(shù)據(jù)。數(shù)字簽名的作用就是驗證數(shù)據(jù)來源以及數(shù)據(jù)完整性！解密過程則稱為數(shù)字簽名驗證。
幾點疑惑：

1. 如果中間人同時篡改了Email正文和數(shù)字簽名，那B收到郵件無法察覺啊。
   答案：數(shù)字簽名的生成需要對方私鑰，所以數(shù)字簽名很難被偽造。萬一私鑰泄漏了呢，不好意思，你私鑰都能弄丟了那這篇文章當我白寫。（私鑰絕對保密不參與傳輸）
2. 公鑰是公開的并且可以自行導入到電腦，如果有人比如C偷偷在B的電腦用自己公鑰替換了A的公鑰，然后用自己的私鑰給B發(fā)送Email，這時B收到郵件其實是被C冒充的但是他無法察覺。
   答案：確實存在這種情況！解決辦法就是數(shù)字證書

數(shù)字證書

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

1. 首先A去找"證書中心"（certificate authority，簡稱CA），為公鑰做認證。證書中心用自己的私鑰，對A的公鑰和一些相關(guān)信息一起加密，生成"數(shù)字證書"（Digital Certificate）：

   
   
   圖2.png

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

   
   
   image.png

3. B收到Email后用CA的公鑰解密這份數(shù)字證書，拿到A的公鑰，然后驗證數(shù)字簽名，后面流程就和圖1的流程一樣了，不再贅述。
   幾點疑惑：

• 假設(shè)數(shù)字證書被偽造了呢？
  答案：是的，傳輸中數(shù)字證書有可能被篡改。因此數(shù)字證書也是經(jīng)過數(shù)字簽名的，上文說道數(shù)字簽名的作用就是驗證數(shù)據(jù)來源以及數(shù)據(jù)完整性！B收到郵件后可以先驗證這份數(shù)字證書的可靠性，通過后再驗證數(shù)字簽名。
• 要是有1萬個人要給B發(fā)郵件，難道B要保存1萬份不同的CA公鑰嗎？
  答案：不需要，CA認證中心給可以給B一份“根證書”，里面存儲CA公鑰來驗證所有CA分中心頒發(fā)的數(shù)字證書。CA中心是分叉樹結(jié)構(gòu)，類似于公安部->省公安廳->市級派出所，不管A從哪個CA分支機構(gòu)申請的證書，B只要預存根證書就可以驗證下級證書可靠性。
• 如何驗證根證書可靠性？
  答案：無法驗證。根證書是自驗證證書，CA機構(gòu)是獲得社會絕對認可和有絕對權(quán)威的第三方機構(gòu)，這一點保證了根證書的絕對可靠。如果根證書都有問題那么整個加密體系毫無意義。

舉個栗子

上面一直在說虛擬場景，下文舉個實際例子看看數(shù)字簽名+數(shù)字證書如何驗證文件的來源，以及文件的完整性。比如下載文件：我們開發(fā)中一般是服務(wù)端給文件信息加上md5,客戶端下載完成后校驗md5來判斷文件是否損壞，這個其實就是簡單的校驗機制，而很多正規(guī)企業(yè)比如google都會給官方軟件簽署數(shù)字簽名和證書，而windows已經(jīng)預置了很多CA根證書：

image.png

然后看下我之前從網(wǎng)上下載的Chrome.exe，右鍵屬性，通過鼠標點擊一步驗證：

image.png

Google Inc就是google從CA中心申請的數(shù)字證書。這樣看來，這個軟件確實來源于google官方，并且文件完整。接下來我干點壞事，用notepad打開這個exe文件并且篡改里面的內(nèi)容（修改二進制數(shù)據(jù)，09 改為33），保存：

image.png

再看下數(shù)字簽名還正常嗎？

image.png

文件被篡改導致數(shù)字簽名無效，數(shù)字證書沒有問題。

https簡單介紹

數(shù)字簽名和數(shù)字證書可以用于文件，當然也能用于html網(wǎng)頁數(shù)據(jù)。本人沒有https相關(guān)開發(fā)經(jīng)驗，故不做深入探討只是簡單介紹下。

• http的安全缺陷

1. 無法驗證服務(wù)端的身份
2. 無法保證數(shù)據(jù)完整性
3. 無法保證數(shù)據(jù)傳輸不被竊聽

而https就是專門解決這三個問題，https使用數(shù)字簽名+數(shù)字證書解決了前2個問題，很多大型網(wǎng)站比如baidu.com都會采用https協(xié)議，網(wǎng)址左側(cè)會出現(xiàn)綠色加鎖標識：

image.png

點擊可以查看證書，另外瀏覽器都會內(nèi)置CA根證書，來對這些網(wǎng)站的服務(wù)器證書進行校驗。
然后，再用SSL協(xié)議對傳輸通道加密，保證數(shù)據(jù)傳輸不被竊聽，這個SSL加密原理分為很多步驟不在本文討論范圍。