信息安全 | 互聯網時代，如何建立信任？

上週在大前端組裡做了一次技術分享，因為現在公司在推行 “辦公全英文化”，所以這還是一場全英文的分享。全英文對自己來說是一次挑戰，雖然一個半小時全都用了英語，但自我評價還是勇氣大於實力吧🐶。

互聯網時代，如何建立信任呢❓這建立信任的基礎當然是保證信息傳輸是安全的，這樣用戶才敢在網上交流、購物、支付... 那麼，今天，我們就來一步一步看看互聯網時代信息安全的發展吧！

「本文大綱」如下：

「關鍵字」密碼學、對稱密鑰系統、非對稱密鑰系統、哈希、數字簽名、數字證書、SSL/TLS、SSH、iOS 簽名、OpenSSL、WireShark

💡：不用擔心，這裡不會講複雜的數學運算。

寫在開頭#

我們在工程裡有很多與信息安全相關的代碼，比如 RSA、AES、HMAC... 每次遇到它們，我都會感到困惑甚至頭冷，所以我想了解了解它們到底是幹什麼的。
之前自己在 iOS 簽名的問題上踩過坑，從而有了上一篇文章（iOS | 圖解 iOS 簽名背後的原理，感興趣的可以去看看），這次因為是針對大前端的分享，所以算是在上篇文章的基礎上擴展。

以上原因，就促成了這篇文章的誕生，希望互聯網時代的你們會感興趣。

本文目標#

回答並理解以下問題：

🥣信息傳輸一般使用對稱加密➕非對稱加密，為什麼？不能只使用其中一種嗎？
🥣信息安全為什麼需要數字簽名？
🥣為什麼簽名前需要做哈希操作？
🥣信息安全為什麼需要數字證書？

終極目標：當我們遇到密碼學相關問題時，不再恐懼和困惑。

什麼是信息安全？#

這是一個比較大的問題，在這裡，我想通過信息安全的三要素（簡稱CIA）來回答。

Source: comtact

CIA 的組成如下：

機密性（ Confidentiality）：指信息在存儲、傳輸、使用的過程中，不會被洩漏給非授權用戶或實體。
完整性（Integrity）：指信息在存儲、傳輸、使用的過程中，不會被非授權用戶篡改，或防止授權用戶對信息進行不恰當的篡改。
可用性（ Availability）：指確保授權用戶或實體對信息資源的正常使用不會被異常拒絕，允許其可靠而及時地訪問信息資源。
- ➕認證性（Authentication）：也可以理解為不可否認性（Non-Repudiation），指網絡通信雙方在信息交互過程中，确信參與者本身和所提供的信息真實同一性，即所有參與者不可否認或抵賴本人的真實身份，以及提供信息的原樣性和完成的操作與承諾。
- ➕可控性（Controllability）：指網絡系統和信息在傳輸範圍和存放空間內的可控程度。

參考：信息安全的 5 個安全特徵——51know

💡這裡有 2 點需要進行說明：

可用性裡還添加了兩個要素：認證性和可控性，個人認為這兩者是為可用性服務的，所以歸為一類。
本文要聊的和這 3 個要素有關：機密性、完整性和認證性，我們可以把它們仨當成3 個需求，本文的首要任務就是完成它們。另外，上對這 3 個要素的解釋比較有專業性，我再用大白話簡單介紹下：
1. ❗️機密性：A 給 B 發短信，不想讓 C看到短信內容。
2. ❗️完整性：A 給 B 發短信，不想讓 C修改短信內容。
3. ❗️認證性：A 給 B 發短信，B 可以確認發送方的身份是 A，而不是 C。

好，我們帶著3 個需求繼續往下看。

為什麼需要信息安全？#

Source: pixabay

在聊怎麼做之前，我們先想一下需要信息安全的原因，我這裡簡單總結為 “用戶需要，公司滿足”。細說的話可以分為 3 點：

需要信息安全這件事，是一個很普遍的認識，尤其在銀行、電商等涉及金錢、用戶隱私的領域。
從網絡使用者的角度分析，如果他們的信息安全無法被保障，他們怎麼還敢在網上購物、支付、貸款以及輸入賬戶密碼等私人信息呢？
對一家公司來說，它如果無法保障用戶的信息安全，那就會失去用戶的信任，也就相當於失去了用戶，這樣的公司還談什麼發展呢？

所以互聯網時代，信息安全是極其必要的。下面我們就來看看怎麼做吧！

怎麼做到信息安全#

❗️銘記我們的 3 個需求：機密性、完整性、認證性。

Source: electronicdesign

講到信息安全，那當然就少不了密碼學的登場，因為密碼學的三個基本安全目標（機密性、完整性、可用性）就是針對上面的 3 個需求，可不巧了嘛～

首先，我們可以從下面的視頻了解一下密碼學的發展史：

簡單了解：The History of Cryptography｜Explained For Beginners——Binance Academy, Youtube
詳細了解：
- Secret Codes: A History of Cryptography (Part 1)——The Generalist Papers, Youtube
- More Secret Codes: A History of Cryptography (Part 2)——The Generalist Papers, Youtube

好了，現在你應該對密碼學有一個大致的認識了，下面我們來看看密碼學裡的三大常見算法。

三大常見的密碼學算法#

它們分別是對稱密鑰算法、非對稱密鑰算法、哈希算法。

對稱加密算法#

Source: preyproject

如上圖黃框內所示，對稱加密的過程就是，發送方通過密鑰（Secret Key）加密明文，得到密文並發送給接收方，接收方通過相同的密鑰解密密文，即可得到明文。

💡對稱加密的特點：加 / 解密所用的密鑰是同一把（Same Key）。

Q1: 你能想到哪些常見的對稱加密算法呢？

DES、3DES、AES、IDEA、SM1、SM4、RC2、RC4。

其中，除了 RC4 是流密碼算法（每次只加解密 1 位或 1 字節）外，其他都屬於分組密碼算法（平均拆分為 N 組後再進行加密，最後按順序組合）。

這裡列出這些算法名的目的，是想讓你在遇到這些術語時，可以明確知道它們是幹什麼的，從而有的放矢，對數學原理感興趣的話可以自行深入探索。

參考：密碼學基礎（一）常見密碼算法分類——Blog

Q2: 看到上面這張圖，你是否會有這樣的疑問：密鑰該如何發送給接收方？這樣接收方在收到密文後，才能進行解密呀。

這是一個好問題，如果在真實世界中，我們可以通過暗中碰頭交接密鑰，但在互聯網世界，黑客可以輕易的劫獲你的通信，所以對稱加密算法最大的難點就是密鑰分發問題。

如何解決呢？這就有了下面的非對稱加密算法。

非對稱加密算法#

Source: preyproject

如上圖黃框內所示，非對稱加密的過程與對稱加密大體相似。

💡唯一的區別，也就是非對稱加密算法的特點：加 / 解密所用的密鑰不一樣（Different Key）。

與對稱加密裡的對稱密鑰一樣，非對稱加密裡的私鑰（Secret Key / Private Key）也是非常隱私、非常重要的，不能隨便給別人，而公鑰（Public Key）就可以隨意分發了。

如果想讓和發送方進行加密通信，可以把公鑰發給發送方，給發送方用來加密，自己（也就是接收方）收到密文後，用私鑰解密即可。

Q1: 你能列舉一些常見的非對稱加密算法嗎？

RSA、ECC、DSA、ECDSA、SM2。

Q2: 既然非對稱加密解決了密鑰分發問題，那是不是就沒對稱加密什麼事了？

其實不然，非對稱加密也有缺點，它的缺點就是加密速度遠慢於對稱加密（對稱加密的本質是位運算，非對稱加密的本質是幂運算和模運算）。

所以，這就引出了本文的目標問題 1：信息傳輸一般使用對稱加密➕非對稱加密，為什麼？不能只使用其中一種嗎？

我們會在 “信息傳輸的加密方式” 這一節再聊，下面再接著介紹最後一種常見的密碼學算法 —— 哈希算法。

哈希算法#

Source: hackmd.io

從上圖可以看出，哈希算法可以將任意數據，轉換成一串固定長度的編碼，我們一般把這串編碼叫做哈希值或者摘要。

💡哈希算法的特點：

“唯一” 標識性：相同的輸入，輸出一定相同；不同的輸入，輸出大概率不同。（因為大概率，所以唯一加了雙引號）
不可逆：不能通過輸出推導出輸入。

我們可以將哈希值理解為原始數據的 “指紋”。在犯罪現場，雖然我們不可以通過指紋直接推導出對應的人是啥樣（不可逆），但是我們可以通過比對現場和犯罪嫌疑人（或者指紋庫）的指紋，找到兇手！

💡結合上面兩個特點，哈希算法一般有 2 個用途：

1）驗證數據是否被修改

我們在下載某些軟件時，會看到下載鏈接附近還附加了一個哈希值（MD5），有什麼用呢？

其實這個哈希值就像原始下載包 A 的一個 “指紋”。如果我們下載的包在下載過程中途被人改動了，變成了假包 B，我們計算一下假包 B 的哈希值 B-hash（MD5），和圖中原始包 A 的哈希值 A-hash 做對比，如果 B-hash 和 A-hash 不一致，那還說什麼，B 包 “有鬼”。

此外，後面的數字簽名技術裡也會用到哈希函數，我們待會再聊。

2）存儲用戶隱私

一個平台的數據庫裡需要存儲用戶的賬戶名、密碼，這裡如果密碼是明文存放的，那可就危險了，保不定數據庫出現漏洞，被黑客攻破，密碼就全部洩漏了。

所以，數據庫裡存儲的是密碼的哈希值，在用戶輸入密碼登錄時，只需要比對原始密碼和輸入密碼的哈希值即可。這也就是，為什麼我們在某個平台忘記密碼後，只能重設密碼，因為平台也不知道我們的原始密碼呀～

說到這裡，先看兩個小問答。

Q1: 你能列舉一些常見的哈希算法嗎？

MD5、SHA-1、SHA-2、SHA-3、HMAC、SM3。

Q2: SM 系列算法是由我國認定和公布的，你知道它的全稱是什麼嗎？

正是因為是由我國認定的，所以 SM 其實來源於拼音，它的全稱是商（S）用密（M）碼。

回到哈希算法的第二個用途（存儲用戶隱私），其實存在一些風險，那就是🌈彩虹攻擊。

Source: ckd3

從上圖的彩虹表可以看出，對於一些常用的密碼，其對應的哈希值（MD5）早就眾人皆知了。黑客拿到這些哈希值，也就相當於拿到原始密碼了，所以我們還需要一些措施減少彩虹攻擊的風險。這裡有一個基於彩虹表的網站cmd5，感興趣可以去看看。

比如哈希加鹽、HMAC。前者是在明文的基礎上添加一個隨機數（鹽）後，再計算哈希值；後者則更加安全，在明文的基礎上結合密鑰（提前共享的對稱密鑰），再計算哈希值。

參考：

好了，以上就是三大常見的密碼學算法了，下面基於這些基礎算法聊聊如何實現我們的 3 個需求，你還記得嗎？機密性、完整性、認證性。

信息傳輸的加密方式#

❗️實現需求 1：機密性。

🥣回答目標問題 1：信息傳輸一般使用對稱加密➕非對稱加密，為什麼？不能只使用其中一種嗎？

先來回答問題 1，從上面的學習我們已經知道兩種加密方式各有不足，又能互相彌補。

🥣所以，結合對稱加密（速度快）和非對稱加密（便於分發密鑰）的優點來實現信息安全傳輸，也就是用非對稱加密傳輸對稱密鑰，後面的通信則直接用對稱密鑰加密的方式，這是目前能想到的最佳方式。

PS: 關於密鑰交換方式，除了上面基於非對稱加密的方式外，其實還有 2 種方式來交換密鑰。

專門的密鑰交換算法，如 DH (E)、ECDH (E)；
預部署方式，如 PSK、SRP。

總之，記住一點，因為對稱加密的性能好，所以大量、頻繁的通信數據都是用對稱密鑰來加密的，上面說的要交換的密鑰也都是對稱密鑰。

❗️有了加密手段，信息傳輸的機密性也就有了保障，至此，我們完成了第 1 個需求～

那如何保證信息的完整性呢？這就要看數字簽名了。

數字簽名#

❗️實現需求 2：完整性。

🥣回答目標問題 2：信息安全為什麼需要數字簽名？

🥣回答目標問題 3：為什麼簽名前需要做哈希操作？

數字簽名一般夾帶在要傳輸的數據中，用來防止數據被篡改，接下來就來說說它是怎麼做到的。

首先，它的底層核心就是剛剛提到的哈希算法和非對稱加密算法。

生成（加簽）#

簽名是由通信中的發送方生成的，發送方首先會對要傳輸的數據進行哈希，得到數據摘要（也就是哈希值），然後用私鑰對摘要進行計算，從而生成了這份數據的簽名。

驗證（驗簽）#

接收方收到數據和其簽名後，分別做如下處理：

數據：使用與發送方相同的哈希算法，計算實際數據的摘要 A；
簽名：利用發送方所用私鑰對應的公鑰，對簽名進行計算，得到原始數據的摘要 B。

比對摘要 A 和摘要 B，如果相等，則說明實際數據沒有被篡改，否則數據存在問題（是不是和哈希驗證數據完整性有些類似呢，但簽名的安全級別顯然更高，因為還引入了私鑰保駕護航呢）。

整個簽名的生成和驗證過程合在一起，就是這樣了，那麼回到目標問題 2、3，你有答案了嗎？

🥣2: 信息安全為什麼需要數字簽名？

很簡單，就是為了保證信息的完整性（❗️順手就完成了需求 2）。

🥣3: 為什麼簽名前需要做哈希操作？

先思考兩個問題：

哈希是做什麼的？它將任意數據，轉換成一串固定長度的編碼。
簽名的本質是非對稱加密，有什麼不足嗎？性能低。

所以對一大段數據進行簽名，不如對一小段數據簽名來得快，恰巧哈希算法也能很大程度上保證數據的唯一性。

但 1）加快簽名速度還只是回答的一部分，因為如果簽名前不做哈希操作，這裡還會有 2）安全上的隱患：

重排序。如果要傳輸的消息過長，超過了非對稱加密算法支持的最大長度，那麼系統只能對消息做分段簽名，從而得到多個簽名；接收方驗證的時候，則是對每個簽名分別進行驗證。但如果是這樣的話，分段後消息的順序就無法保證不被篡改了，因為每個簽名還是可以通過驗證的（有人可能會想到，多個簽名整合在一起後再生成一個簽名，但這樣可能又會受到非對稱加密算法支持的最大長度限制了）。
消息偽造。黑客通過捕獲任意簽名，倒推出明文消息，以後就可以組裝使用了（因為倒推用的的公鑰是很容易獲取的）。

參考Why hash the message before signing it with RSA?——StackExchange

至此，我們就只剩下 1 個需求❗️和 1 個目標問題🥣了～

現在，我們先思考一個問題：

Q: 接收方如何拿到驗簽所用的公鑰呢？

請接著往下看。

數字證書#

💡實現需求 3：認證性。

🥣回答目標問題 4：信息安全為什麼需要數字證書？

在了解數字證書之前，對於 “接收方如何拿到驗簽所用的公鑰呢？” 這個問題，我們可能馬上想到的是，發送方在發送數據和簽名的同時，再附帶上公鑰不就萬事俱備了嗎～如下圖：

但是這樣會引入一個新的問題Q：接收方如何確認公鑰沒有被其他人惡意替換呢？也就是公鑰的身份不明。

🎉燈燈燈～燈～～，現在該數字證書登場了。

組成內容#

我們可以先看一下數字證書的組成內容，它是由公鑰、公鑰的身份信息以及它們的簽名（另一個簽名）組成的。

注意：

加密公鑰數據所用的私鑰又是另外一個公私鑰組合了，它是由權威的認證機構（Certificate Authority，CA）頒發的，我們肯定是沒有 CA 私鑰的。
如何理解 CA？我們可以聯想一下，我們的身份證是由政府頒發的。

公鑰包裝在數字證書中傳遞#

現在，我們發送的內容做了一點改變：公鑰→證書。

也就是原來發送的數據 + 簽名 +公鑰，變成了數據 + 簽名 +證書。

證書裡包含了接收方驗證簽名 A 所需的公鑰，以及公鑰的身份信息和簽名 B：

身份信息的存在則可以消除公鑰身份不明的隱患（❗️也就完成了需求 3：認證性，🥣回答了目標問題 4：信息安全為什麼需要數字證書？）；
而簽名 B 則又對公鑰及其身份信息的完整性做了保證。

但也因為有了簽名 B，我們在取公鑰時，還需要先對證書裡的簽名 B 進行驗證：

而驗證簽名 B 所用的公鑰也是由 CA 頒發的，它存在於CA 證書裡。

（這裡我們可以再複習一下證書的組成內容：公鑰 + 公鑰的身份信息 + 它們的簽名。）

♻️這裡你又該有疑問了Q：接收方又從哪裡獲得這個 CA 證書呢？就算有了 CA 證書，我又要如何驗證這個 CA 證書的簽名呢？似乎進入了無限循環。

其實，CA 證書一般是在安裝系統 / 軟件時內置的，這樣我們總該信任它了吧～

接下來，我們可以再了解一下證書的信任鏈。

證書信任鏈#

根據證書在信任鏈中所處的位置，可以將證書分為三種：

根證書 Root Certificate（參考Apple 操作系統中可用的受信任根證書——Apple 官方）
中間證書 Intermediate Certificate
葉子證書 Leaf Certificate

🌰舉例：我的開發者證書 A（Apple Development）由中間證書 B（Apple Worldwide Developer Relations Certification Authority，安裝 Xcode 時內置）的 CA 簽發，中間證書 B 由根證書 C（Apple Root CA，系統內置）的 CA 簽發，而根證書 C 是由自己的 CA 簽發的，因為 C 已經在信任鏈的頂端啦，它自己說了算。

現在，你也可以看看自己的 Mac > Keychain Access > Certificates，加深理解。

這裡還有一個有趣的問題Q：證書有可能被篡改嗎？

直接修改？首先想一下直接修改證書的內容（公鑰及身份信息），這是肯定行不通的。因為黑客沒有 CA 的私鑰，它不能對證書內容重新簽名。
直接掉包？這也是不行的。因為證書裡是有發送者的身份信息的，比如說我通過瀏覽器（接收方）訪問一個網站（發送方），網站的證書裡是會有域名信息的，瀏覽器可以直接比對自己請求的域名和證書裡的域名信息，就可以知道證書有沒有被掉包了～

參考：徹底搞懂 HTTPS 的加密原理—— 知乎

擴展（規範、體系、標準）：密碼學基礎（二）數字證書、密鑰基礎知識——Blog

到這裡，我們的 3 大需求❗️和 4 大目標問題🥣全部完成了！放鬆一下～

最後，我們聊一點加餐內容：

信息安全的相關技術（SSL/TLS、SSH、iOS 簽名）
一些實踐（OpenSSL、WireShark）。

回到開篇的目標#

如果這次的分享你只能記住一點點🤏，那就試著理解下面問題的答案吧！

信息傳輸一般使用對稱加密 + 非對稱加密，為什麼？不能只用非對稱加密嗎？
為什麼需要數字簽名？
為什麼簽名前需要做哈希操作？
為什麼需要數字證書？

另外，你實現本文的終極目標了嗎？期待與你的交流～

終極目標：當我們遇到密碼學相關問題時，不再恐懼和困惑。

——寫於暴雨紅色預警⛈️、索性請假的一天，深圳

Bo2SS