楔子
現在網絡的安全性已經變得越來越重要，各位程序員在開發過程中或多或少都會遇到公鑰、私鑰、加密、簽名等一些相關名詞。這些概念比較雜亂，容易混淆，下面就來梳理一下這部分的內容。
對稱加密
在重要的信息的傳遞過程中，人們總是希望信息不會被偷看、不會被篡改，偽造等。為了達到這個要求人們一直在不斷努力着。
電報加密使用的密碼本，就是初代網絡安全所使用的加密方式，用法為：發信時將內容翻譯為密文發出，收到電報的一方，使用相同的密碼本才能解密出正確的信息，否則看到的就是一堆亂碼。
這種傳統的加密方式就叫做對稱加密。
而對稱加密所使用的算法包括：DES、3DES、AES、DESX、Blowfish、RC4、RC5、RC6，這些算法就可以看成密鑰、或者理解為上面的密碼本。這些算法也可以稱為: "對稱加密算法"或者"傳統加密算法"，一方使用算法進行加密，然后另一方使用相同的算法進行解密。
我們以《福爾摩斯探案集之跳舞的小人》一案中出現的小人為例
我們看到每一個小人都代表一個英文字符，至於小人手中的旗子則是用來分隔單詞的、也就是表示一個單詞的邊界。傳遞信息的時候，將信息用小人來代替，然后另一方看到小人的時候，再將出現的小人解析成信息。順便一提，劇中的女主是黑幫首領的女兒，犯人就是使用這些小人來向女主傳遞信息，威脅她回去。
這些小人和英文字符之間的對應關系就相當於密鑰，此時就相當於一個對稱加密。因為無論是發信人還是收信人，使用的是相同的密鑰、即：小人代表的含義都是一樣的。
但是對稱算法的安全性非常依賴於密鑰，泄漏密鑰就意味着任何人都可以對他們發送或接收的消息解密，所以密鑰的保密性對通信安全至關重要。所以福爾摩斯在解析出這些小人代表的含義之后，用這些小人發送信息將犯人引誘了出來。因此對於這種對稱加密來說，密鑰的安全是極其重要的。
那么對稱加密有哪些優缺點呢？
優點：計算量小、加密速度快、加密效率高
缺點：1.密鑰需要傳遞，難以確保密鑰安全性。2.缺乏簽名功能，即不能核對發信人身份
非對稱加密
在對稱加密中，密鑰（也就是使用的加密算法，如上文中發電報時的密碼本、小人和英文字符的對應關系）的保密性至關重要。戰爭時期，電報密碼本需要通過人工渠道傳遞，這樣發報雙方才能放心的使用。
但如今的網絡通信中，顯然不可能再使用人工渠道傳遞密鑰，只有通過網絡來傳遞才高效快捷。這樣就有了一個矛盾：密鑰是用來保證網絡傳輸安全的，這個對於網絡安全至關重要的密鑰又需要網絡來傳遞給對方。
保存密鑰最安全的方式就是不告訴任何人，不進行傳遞，但對稱加密中，解密方必須要得到對應的密鑰，這就又要求密鑰必須進行傳遞，可一旦傳遞密鑰就有丟失的風險。這個"雞生蛋、蛋生雞"的問題一直困擾着人們。直至出現了一種算法： 這套算法生成的密鑰分為兩個部分：公鑰、私鑰。
這個一分為二的密鑰對有如下特點：
公鑰和私鑰是一個算法中兩個不同、但內在又相關聯的參數集合，同時生成，但可以獨立使用。公鑰加密的數據只有對應的私鑰才可以解密（公鑰加密后公鑰也不能解密）私鑰加密的數據也只有對應的公鑰才可以解密。
常見的非對稱加密算法：RSA、DSA、ECC、Diffie-Hellman、El Gamal 等。
RSA 算法概述
對稱加密的模式我們很好理解，但非對稱加密算法的上述特點讓我們感覺很神奇，下面讓我們先來簡單看看，上述這些特點在數學上是怎樣實現的吧。在非對稱加密算法中 RSA 是使用最廣泛的一種，下面我們介紹一下 RSA。
RSA 算法是 1977 年由共同在麻省理工學院工作工作的 羅納德·李維斯特（Ron Rivest）、阿迪·薩莫爾（Adi Shamir）和倫納德·阿德曼（Leonard Adleman）一起提出的。RSA 就是他們三人姓氏開頭字母拼在一起組成的。
RSA 加密利用了"單向函數"正向求解很簡單，反向求解很復雜的特性。思想如下：
對兩個質數相乘容易，而將其合數分解很難的這個特點進行的加密算法。 n=p1*p2，已知 p1、p2 求 n 簡單，已知 n 求 p1、p2 困難。(m^e)%n=c，已知 m、e、n 求 c 簡單，已知 e、n、c 求 m 很難。
RSA 算法的安全性基於 RSA 問題的困難性，也就是基於大整數因子分解的困難性上。這種算法非常可靠，密鑰越長，它就越難破解。根據已經披露的文獻，目前被破解的最長 RSA 密鑰是 768 個二進制位。也就是說，長度超過 768 位的密鑰，還無法破解（至少沒人公開宣布）。因此可以認為，1024 位的 RSA 密鑰基本安全，2048 位的密鑰極其安全
非對稱加密的算法比對稱加密要復雜且耗時，位數越多越耗時。因此在實際使用中，一般是先用非對稱加密過程傳遞對稱加密的密鑰，之后再使用對稱加密來保證后續的通信，這樣安全性與速度就可以達到了一個平衡，HTTPS 所使用的就是這種方式，后文會介紹。
使用非對稱加密進行通信
有了非對稱加密的「公私鑰對」，這樣通信中僅需傳遞公鑰，甚至公鑰可以開放給所有人。需要發消息給我的人使用我的公鑰加密后發給我，只有我可以使用私鑰解密，其他人不可能獲知信息的內容。
但這只是單方向的加密，雙向加密怎么辦呢？對方也創建一個公私鑰對就可以了。
A 根據非對稱加密算法生成自己的公私鑰對（PUBLIC_A，PRIVATE_A）；B 也根據非對稱加密算法生成自己的公私鑰對（PUBLIC_B，PRIVATE_B）；A 和 B 可以公開的交換自己的公鑰（私鑰不需要發送，各自保存好即可）；A 使用 B 的公鑰 PUBLIC_B 加密信息，發送給 B；B 接收到消息后，使用自己保存的私鑰 PRIVATE_B 解密就可以看到消息內容（這條消息即使被他人獲得后也是不能解密的）；同樣，B 要發消息給 A 時，使用 A 的公鑰 PUBLIC_A 加密發出；A 收到消息后使用自己的私鑰 PRIVATE_A 解密，這樣就實現了雙方加密的通信。
簽名
上面我們看到，有了公私鑰對，似乎解決了加密通信的難題。但是實際使用中又出問題了，那就是 A 收到消息后如何確認發信人是 B 而不是第三方呢？其實也很簡單，只要發消息前多進行一次使用自己的私鑰加密的過程就可以了，這次「使用自己私鑰加密信息的步驟就叫做簽名」
私鑰只有自己持有，公鑰和私鑰存在一一對應關系，「即使用公鑰只能解密出對應私鑰加密的信息」，因此就可以用私鑰的加密過程當做驗證身份的手段了。其實公鑰、私鑰加密數據的方法與原理都相同，「只是按照用途分別命名了而已」
公鑰一般用來加密，私鑰用來簽名。
還使用上邊的例子來看一下，使用了加密和簽名之后的通信過程：
A 先使用自己的私鑰 PRIVATE_A 對消息進行一遍加密（習慣性稱作簽名），再使用 B 的公鑰 PUBLIC_B 加密信息，然后將加密結果發送給 B。B 接收到消息后，使用自己保存的私鑰 PRIVATE_B 解密，然后使用 A 的公鑰 PUBLIC_A 再解密一遍，如果能解密成功，就可以確保這條消息不是偽造的。同樣，B 要發消息給 A 時先使用自己的私鑰 PRIVATE_B 對消息進行一遍加密（習慣性稱作簽名），再使用 A 的公鑰 PUBLIC_A 加密后發出。A 收到消息后使用自己的私鑰 PRIVATE_A 解密，然后使用 B 的公鑰 PUBLIC_B 再解密一遍，這樣就實現了雙方互相確認身份的加密通信。
由於非對稱加密是復雜且耗時的，而且需要加密的內容越長就越耗時。在實際使用中一般經過摘要算法得到一串哈希值，然后使用私鑰對哈希值進行加密。習慣性將這樣對摘要使用私鑰加密生成的文件叫做簽名文件。
哈希值算法
生成摘要的哈希算法有如下特點：
可以將任意長度的信息與一串固定長度的字符串建立對應關系，即哈希值定長哈希值算法將任意長度映射為有限長度，難免有碰撞（即，兩個不同信息算出的摘要相同）。好的哈希值算法就是能夠盡量減少碰撞的幾率原始信息的任何一點修改都會導致計算出的哈希值的變化，從而可以用哈希值來確保消息體的完整性哈希值算法是單向的，即只能從原信息計算出哈希值，不能由哈希值回算得到原信息
但是有的人可能見過網上有破解哈希加密的，其實它並不是反向推理，而是使用"撞庫"的方式。意思就是事先對大量不同的字符串進行哈希加密，然后再將原來的字符串和生成的哈希值保存起來。然后根據用戶輸入的哈希值來進行檢索，這就是"撞庫"。不過這一般都是比較簡單的哈希加密（md5），而且沒有加鹽。
常見算法有 MD5、SHA1、SHA256、SHA512 等。
大部分網站對用戶密碼保護也是利用哈希值單向性這個特點。數據庫只保存用戶密碼的哈希值，進行登錄操作時，將此次輸入的密碼再次計算哈希值與數據庫保存的哈希值對比，對比通過則認為密碼正確。這樣即使數據庫泄露，黑客也無法獲知用戶的密碼。
這樣就演化出了目前實際使用的簽名、加密過程：
A 先使用哈希算法將要發送的消息計算出摘要，再自己的私鑰 PRIVATE_A 對摘要進行簽名得到簽名文件，然后將原始消息和簽名文件打包到一起，使用 B 的公鑰 PUBLIC_B 加密信息，發送給 B。B 接收到消息后，使用自己保存的私鑰 PRIVATE_B 解密，得到原始消息和一個簽名文件。使用哈希算法對原始消息計算得到一個哈希值，再使用 A 的公鑰 PUBLIC_A 對簽名文件進行解密，得到消息的哈希值，將這兩個哈希值進行對比，如果一致就可以認為這條消息是 A 發送的且未經過篡改。
公鑰與證書
從上邊的流程來看，似乎一切都完美了，但黑客也是絞盡腦汁的，他們還是從中找到了破綻。那就是我們對 A 的身份識別是建立在相信 PUBLIC_A 的公鑰確實是 A 的，然而黑客可以輕易的發布自己的公鑰宣稱這是 A 的公鑰來欺騙我們，那我們又怎么樣區分呢？這就需要一個機構來保證了，這個機構把 A 提供的公鑰和 A 的相關信息放在一起組合成一份證書，這樣你從這個機構獲取證書，就可以得到有權威機構背書的公鑰與 A 的對應關系。
這個機構叫做 CA，發布的證書叫做 CA 證書。
證書授權中心 CA
CA 證書授權（CertificateAuthority）中心是數字證書發行的唯一機構。
CA 中心又稱 CA 機構，即證書授權中心（Certificate Authority），或稱證書授權機構，作為電子商務交易中受信任的第三方，承擔公鑰體系中公鑰的合法性檢驗的責任。CA 中心為每個使用公開密鑰的用戶發放一個數字證書，數字證書的作用是證明證書中列出的用戶合法擁有證書中列出的公開密鑰。CA 機構的數字簽名使得攻擊者不能偽造和篡改證書。在 SET 交易中，CA 不僅對持卡人、商戶發放證書，還要對獲款的銀行、網關發放證書。它負責產生、分配並管理所有參與網上交易的個體所需的數字證書，因此是安全電子交易的核心環節。
CA 證書是逐級保證安全的，最終的根證書內置在操作系統中。由操作系統來保證，這部分下文中會進行介紹。
CA證書鏈如下圖：
HTTPS 的安全傳輸過程
HTTPS 中的 S，就是 Secure（安全）的意思，這就是比 HTTP 多出的一份安全保證，瀏覽器驗證了網站的證書后會在地址欄的左邊顯示綠色的鎖的標志，標志該網站是安全可信任的官網。
由於非對稱加密是耗時的，如果在每一次 HTTPS 的數據傳輸中都使用非對稱加密是不合適的。實際上的做法是在第一次建立 HTTPS 連接時使用一次非對稱加密傳遞對稱加密的密鑰，然后就使用對稱加密來保證接下來的通信過程。
HTTPS 的通信過程如下：
瀏覽器發出 HTTPS 請求。服務器返回本網站的證書。瀏覽器基於內置在操作系統中的CA證書鏈對網站證書的有效性進行校驗。校驗通過后使用證書中的公鑰加密一份對稱加密的密鑰信息，發送給服務端。服務端收到信息后使用自己的私鑰解密信息，得到瀏覽器提供的用於對稱加密的密鑰信息。之后的通信過程就使用這個對稱加密的密鑰來保護。
Android 的安全啟動過程（SecureBoot）
上一小節可以看到 HTTPS 的證書有效性還是要基於內置在操作系統中的「CA 根證書的」
那操作系統又是如何保證系統自身以及系統內包含的 「CA 根證書」不被篡改的呢？我們以 Android 來舉例，因為相較於 PC 而言，手機廠商的安全性目前做的更好。
手機廠商建立了手機內部處理器與手機操作系統的綁定關系（也就是說開啟 SecureBoot 功能的手機是「不能刷非官方系統」的），一旦刷入第三方系統后，手機則會不開機。這也是利用上文提到的公鑰、私鑰實現的，來具體看一下：
手機的處理器內部存在一塊只能寫一次數據的 OTP 區域，出廠時會將廠商的公鑰寫入。物理上就保證了這部分不可更改。手機操作系統固件會使用廠商的私鑰進行加密。手機處理器的第一部分啟動程序（這部分程序也是固化在處理器內部的不可更改）會使用 OTP 中的公鑰對操作系統進行解密，解密成功才可以啟動，否則立馬變"磚"。
這個過程就叫做「安全啟動」，即 SecureBoot 。實際過程中為了加快校驗速度也使用了哈希值算法，但此處僅用於說明加密啟動的過程，忽略了部分細節。
電腦端 Intel 處理器中其實也存在類似的機制，但一般情況下 PC 都希望能夠靈活的安裝系統，因此默認沒有開啟 Intel 芯片中的 SecureBoot 功能。