原博文位址: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值加密,然後附着到原文的一段資料。數字簽名的作用就是驗證資料來源以及資料完整性!解密過程則稱為數字簽名驗證。
不過先别着急,我在梳理數字簽名流程時候有下面幾點疑惑,不知你也是否一樣?
-
如果中間人同時篡改了Email正文和數字簽名,那B收到郵件無法察覺啊。
答案:數字簽名的生成需要對方私鑰,是以數字簽名很難被僞造。萬一私鑰洩漏了呢,不好意思,你私鑰都能弄丢了那這篇文章當我白寫。(私鑰絕對保密不參與傳輸)
-
公鑰是公開的并且可以自行導入到電腦,如果有人比如C偷偷在B的電腦用自己公鑰替換了A的公鑰,然後用自己的私鑰給B發送Email,這時B收到郵件其實是被C冒充的但是他無法察覺。
答案:确實存在這種情況!解決辦法就是數字證書,一環套一環請接着看。
數字證書
上面第2點描述的安全漏洞根源在哪?就是A的公鑰很容易被替換!那麼數字證書是怎麼生成的呢?以及如何配合數字簽名工作呢?
-
首先A去找"證書中心"(certificate authority,簡稱CA),為公鑰做認證。證書中心用自己的私鑰,對A的公鑰和一些相關資訊一起加密,生成"數字證書"(Digital Certificate):
圖2.png
-
A在郵件正文下方除了數字簽名,另外加上這張數字證書
image.png
-
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根證書:
然後看下我之前從網上下載下傳的Chrome.exe,右鍵屬性,通過滑鼠點選一步驗證:
Google Inc就是google從CA中心申請的數字證書。這樣看來,這個軟體确實來源于google官方,并且檔案完整。接下來我幹點壞事,用notepad打開這個exe檔案并且篡改裡面的内容(修改二進制資料,09 改為33),儲存:
再看下數字簽名還正常嗎?
檔案被篡改導緻數字簽名無效,數字證書沒有問題。
https簡單介紹
數字簽名和數字證書可以用于檔案,當然也能用于html網頁資料。本人沒有https相關開發經驗,故不做深入探讨隻是簡單介紹下。
- http的安全缺陷
- 無法驗證服務端的身份
- 無法保證資料完整性
- 無法保證資料傳輸不被竊聽
而https就是專門解決這三個問題,https使用數字簽名+數字證書解決了前2個問題,很多大型網站比如baidu.com都會采用https協定,網址左側會出現綠色加鎖辨別:
點選可以檢視證書,另外浏覽器都會内置CA根證書,來對這些網站的伺服器證書進行校驗。
然後,再用SSL協定對傳輸通道加密,保證資料傳輸不被竊聽,這個SSL加密原理分為很多步驟不在本文讨論範圍。
總結
全文比較深入地探讨了非對稱加密,數字簽名和數字證書的原理,最後引出https的簡單介紹,如有差錯盡請指正。
作者:08_carmelo
連結:https://www.jianshu.com/p/4932cb1499bf
來源:簡書
簡書著作權歸作者所有,任何形式的轉載都請聯系作者獲得授權并注明出處。