1 非對稱加密
非對稱加密，是指不能從加密密鑰推算出解密密鑰。加密密鑰不需要保密，可以公開，稱之為公鑰，只需要保守解密秘鑰稱之為私鑰。公鑰和私鑰是成對的。常見的非對稱加密算法有：RSA、Elgamal、背包算法、Rabin、D-H、ECC。
所謂“成對”的含義：如果用公開密鑰對數(shù)據(jù)進行加密，只有用對應(yīng)的私有密鑰才能解密；如果用私有密鑰對數(shù)據(jù)進行加密，那么只有用對應(yīng)的公開密鑰才能解密。因為加密和解密使用的是兩個不同的密鑰，所以這種算法叫作非對稱加密算法。
舉例：甲乙兩人通信，甲將他的加密密鑰（公鑰）公布，任何想與甲通信的人都可以使用這個加密密鑰將要傳送的信息（明文）加密成密文發(fā)送給甲，只有甲自己知道解密密鑰（私鑰），能夠把密文還原為明文。任何第三方即使截獲到密文也不可能知道密文所傳遞的信息。即用公鑰加密，私鑰解密。
非對稱加密保證了乙向甲傳遞的數(shù)據(jù)的保密性。第三方由于沒有私鑰不能解密。但是第三方也能用公鑰加密數(shù)據(jù)，如何保證甲得到的數(shù)據(jù)是乙發(fā)出的呢？這需要配合數(shù)字簽名技術(shù)。數(shù)字簽名主要是利用哈希函數(shù)對要傳遞的數(shù)據(jù)進行運算后得到一個運算結(jié)果，將該結(jié)果也加密發(fā)送給甲，甲獲取后進行解密，得到運算結(jié)果，然后將收到的數(shù)據(jù)進行相同的哈希運算后的結(jié)果進行比較。這個加密解密過程與數(shù)據(jù)加密解密過程是相反的，乙用私鑰加密數(shù)據(jù)，因此只有乙能加密，所有人都可以用乙的公鑰解密，因此第三方無法對偽造的數(shù)據(jù)進行加密傳輸。由于哈希函數(shù)的單向性（不可逆），第三方無法根據(jù)公鑰解密后的數(shù)據(jù)（明文的哈希運算結(jié)果）反推哈希運算之前的原數(shù)據(jù)。
總之，非對稱加密保證數(shù)據(jù)安全，數(shù)字簽名驗證身份。
2 數(shù)字簽名
假設(shè)有一天，Alice 收到了一份署名為 Bob 的文件。Alice 希望能夠確認這份文件一定是來自 Bob；另外 Alice 希望能夠確信，這份文件在傳輸過程中并沒有被它人篡改。那么基于非對稱密鑰算法我們應(yīng)該怎么做？
在信息安全中，文件的安全性有兩方面的含義：一是不可抵賴性，即文件一定來自于發(fā)送者，也就是身份正確；二是不可篡改性，即確信文件并沒有中途被篡改，也就是數(shù)據(jù)完好。
在非對稱密鑰算法中提到，公鑰加密的內(nèi)容使用私鑰可以解密。同樣的，私鑰加密的內(nèi)容使用公鑰也可以解密。因此我們可以很容易想到。如果 Bob 利用自己手里的私鑰對文件進行加密后，傳輸給 Alice。Alice 再通過公鑰庫中 Bob 的公鑰進行解密，則可以證明文件一定是由 Bob 發(fā)出（由于只有Bob持有私鑰）。另外，因為傳輸?shù)氖敲芪模绻軌蚴褂霉€解密，同時也證明了文件并沒有中途被篡改。這樣的做法其實已經(jīng)同時滿足了不可抵賴性和不可篡改性。
然而，由于傳輸?shù)奈募赡芎艽螅?/strong> 為了證明文件的不可抵賴性和不可篡改性，需要對整個文件進行加密，由于非對稱算法效率較低，這樣做的代價太大。因此常規(guī)的做法是用到信息摘要和數(shù)字簽名的方式。
所謂信息摘要，其實就是某種 Hash 算法，將信息明文轉(zhuǎn)化為固定長
度的字符，它具有如下特點：
- 無論輸入的消息有多長，計算出來的消息摘要的長度總是固定的；
- 用相同的摘要算法對相同的消息求兩次摘要，其結(jié)果必然相同；
- 一般地，只要輸入的消息不同，對其進行摘要以后產(chǎn)生的摘要消息也幾乎不可能相同；
- 消息摘要函數(shù)是單向函數(shù)，即不可逆的，而無法從摘要中恢復(fù)出任何的消息；（當原文用公鑰加密后，這一條能保證摘要的泄露（摘要可用公鑰解密）不影響原文的安全性）
- 好的摘要算法，沒有人能從中找到“碰撞”，雖然“碰撞”是肯定存在的。即對于給定的一個摘要，不可能找到一條信息使其摘要正好是給定的?；蛘哒f，無法找到兩條消息，是它們的摘要相同。
一般的，我們將信息的摘要也稱作信息的指紋。如同指紋的含義，相同的信息一定會得相同的指紋，而僅通過指紋又無法還原出原始信息。目前主要的摘要算法有 MD5（Message Digest-5）和 SHA1（Secure Hash Algorithm）。
當有了信息摘要技術(shù)以后，基于 Bob 向 Alice 發(fā)送文件的場景，我們可以進行如下的操作：
第一步：
① 用 Hash 計算摘要：Bob 將原始的信息進行一次信息摘要算法，得到原始信息的摘要值；
② 用密鑰加密摘要：Bob 使用自己的私鑰，對該摘要值進行加密。得到信息摘要的密文；
③ 打包發(fā)送：Bob 將原始文件和摘要值的密文一起發(fā)送給 Alice。
一般的，我們將原始文件和摘要密文放一起稱作 Bob 對原始文件的簽名結(jié)果。
第二步：
① 用公鑰解密摘要：當 Alice 接收到 Bob 傳輸?shù)男畔ⅲㄔ嘉募?信息摘要密文）后，使用 Bob 的公鑰將摘要密文解密，得到信息摘要明文；
② 獨立計算摘要：使用相同的信息摘要算法，對收到的原文進行計算，獲取原始文件摘要信息；
③ 對比摘要：Alice 比較解密后的摘要信息和取得的摘要信息。如果相同，則可以證明文件一定由 Bob 發(fā)送，并且中途并沒有經(jīng)過任何篡改。一般將這個過程稱作驗簽。
總之，所謂指紋、摘要，就是原始數(shù)據(jù)的Hash值；所謂數(shù)字簽名，就是摘要的私鑰加密。這樣，即可保證文件的特征（摘要值）一定經(jīng)過了私鑰的加密；同時由于信息摘要的長度普遍不長（MD5為128位，SHA1主要為256位），也并沒有帶來太大的開銷。
3 數(shù)字證書
基于非對稱密鑰算法，Bob 生成了一對公私鑰。Bob 將公鑰發(fā)布在公開的密鑰庫中。而 Alice 在向 Bob 發(fā)送加密文件或者驗證 Bob 簽名的文件時，均要從公鑰庫取到 Bob 的公鑰。我們已經(jīng)知道，一般來說公鑰就是一段固定長度的字符串，并沒有特定的含義。
為了讓 Alice 能夠方便的辨別公鑰，我們可以考慮對給公鑰附加一些信息，例如該公鑰使用的算法，該公鑰的所有者（主題），該公鑰的有效期等一系列屬性。這樣的數(shù)據(jù)結(jié)構(gòu)我們稱作 PKCS#10 數(shù)據(jù)包（參考https://blog.csdn.net/shenyongjun1209/article/details/52781461 ）。即：
PKCS#10 數(shù)據(jù)包 = 公鑰 + 算法(RSA) + 有效期 + 主題(持有者信息、公司、版本號等)
例如有一天一個叫做 Richard 的人想冒充 Bob，也生成一對公私鑰，并且使用了相同的公鑰主題封裝為 PKCS#10 數(shù)據(jù)結(jié)構(gòu)。Alice 其實并沒有辦法分辨哪個是真實 Bob 的公鑰。
為了解決這個問題，就需要一個權(quán)威的第三方機構(gòu)，對公鑰信息進行認證。就如同對公鑰信息文件蓋上一個權(quán)威的章，防止仿照。這樣的權(quán)威機構(gòu)，我們稱作 CA (Certificate Authority)，數(shù)字證書認證中心。CA 會通過一些手段對公鑰持有者以及公鑰附加信息進行驗證，確保身份無誤。
而 CA 如何為公鑰信息蓋章呢？非常簡單，就是前文已經(jīng)提到的數(shù)字簽名技術(shù)。公鑰及其附加信息作為證書的內(nèi)容，CA 為此內(nèi)容添加一個數(shù)字簽名，就構(gòu)成了一個數(shù)字證書。步驟如下：
① CA 機構(gòu)也持有公鑰私鑰對（由根 CA 頒發(fā)）。CA 會對這份私鑰進行特別的保護，嚴禁泄漏和盜用。
② Bob 將自己的公鑰附加上一系列信息后，形成了 P10 數(shù)據(jù)包（請求包），并發(fā)送給 CA。
③ CA 機構(gòu)通過其他一些手段認證 Bob 的身份，然后使用自己的私鑰對P10 請求進行簽名。（也可能會先對數(shù)據(jù)進行一些簡單修改，如修改有效期或主題等），簽名結(jié)果，就稱作數(shù)字證書。
數(shù)字證書同樣遵循一個格式標準，我們稱作 X509 標準（參考上個超連接）。正如內(nèi)容示例：
其中寫明了 Hash 算法（SHA-1）和非對稱加密算法（RSA），包含了持有人的身份信息及其公鑰。最下面是 CA 的簽名。
如何通過數(shù)字證書驗證身份和文件信息呢？
第一步： Bob 除了對文件進行簽名操作外，同時附加自己的數(shù)字證書。一同發(fā)給 Alice。
第二步： Alice 進行驗簽：首先使用 CA 的公鑰，對證書進行驗證。如果驗證成功，提取證書中的公鑰，對 Bob 發(fā)來的文件進行驗簽。如果驗證成功，則證明文件的不可否認和不可篡改。
可以看到，基于數(shù)字證書后，Alice 不在需要一個公鑰庫維護 Bob（或其他人）的公鑰證書，只要持有 CA 的公鑰即可。
4 數(shù)字簽名和數(shù)字證書的區(qū)別
有了數(shù)字簽名，為什么還需要數(shù)字證書呢？數(shù)字簽名的驗證是在收到的文件中進行的，可以用來驗證收到的文件是來源于密鑰對（公鑰+私鑰）的持有者。但是，如何確保此密鑰對的持有者就是真實的持有者呢？收到的文件可能來源于第三者。也就是說，如果密鑰對被頂替，信息接收方獲取的是被掉包的公鑰，第三者使用此公鑰對應(yīng)的私鑰對文件進行簽名，加入冒充的信息發(fā)給接收者，那么接收者也能正常解密和驗證簽名，這就是一個漏洞。即，如何保證公鑰是真正的公鑰？這就需要數(shù)字證書了。
獲取數(shù)字證書，就是把真正的公鑰放到 CA 中，CA 會對公鑰持有者進行驗證。這樣，只要 CA 的權(quán)威性得到保障，公鑰的真實性也就得到了保障。
相當于把公鑰的驗證轉(zhuǎn)移到了對 CA 的簽名的檢驗上去了。CA 的簽名得到驗證后，發(fā)送者才能放心的用對方的公鑰加密和解密信息。
5 CA 認證中心如何保證權(quán)威性
CA 作為電子商務(wù)交易中受信任的第三方，承擔公鑰體系中公鑰的合法性檢驗的責任。CA 中心為每個使用公開密鑰的用戶發(fā)放一個數(shù)字證書，數(shù)字證書的作用是證明證書中列出的用戶合法擁有證書中列出的公開密鑰。CA 機構(gòu)的數(shù)字簽名使得攻擊者不能偽造和篡改證書。
CA 認證中心自己也有一個數(shù)字證書，和屬于自己的公鑰和私鑰，這是他們的父 CA 認證中心頒發(fā)給他們的。根 CA 認證中心的證書稱為根證書，根證書自己認證自己的有效性，根證書是整個證書體系安全的根本，如果根證書出了問題，他下面所有子證書都不可被信任，因為子證書都是依賴根證書證明自己的有效性的，從而形成證書信任鏈。
- CA 私鑰：CA 認證中心/數(shù)字證書所有人自己保存，不公開。
- CA 公鑰：CA 認證中心/數(shù)字證書所有人會把公鑰存在父 CA 認證中心為他頒發(fā)的數(shù)字證書內(nèi)。
當你要驗證一個數(shù)字證書可信/合法性時，你需要找到上一層CA認證中心為它頒發(fā)的數(shù)字證書，并且從中獲取公鑰，由于一個數(shù)字證書是基于上層的數(shù)字證書作驗證的，那么又怎么驗證上層的數(shù)字證書是否合法呢？這就會出現(xiàn)一直遞歸上去的現(xiàn)象，也就是上面說的形成證書信任鏈。事實也是這樣的，驗證一個證書是否合法，需要驗證到他的最頂層的根證書是否合法！所以上面說到根證書是整個證書體系安全的根本。
6 HTTPS 協(xié)議
下面，我們看一個應(yīng)用 數(shù)字證書 的實例：HTTPS 協(xié)議。這個協(xié)議主要用于 HTTP 通信的加密。
HTTP 協(xié)議中沒有加密機制，但可以通過和 SSL（Secure Socket Layer，安全套接層）或 TLS（Transport LayerSecurity，安全層傳輸協(xié)議）的組合使用，加密 HTTP 的通信內(nèi)容。用 SSL 建立安全通信線路之后，就可以在這條線路上進行 HTTP 通信了。與 SSL 組合使用的 HTTP 被稱為 HTTPS（HTTP Secure，超文本傳輸安全協(xié)議）或 HTTP over SSL。
（1）首先，客戶端（瀏覽器）發(fā)起 https 請求；
（2）服務(wù)器返回它的數(shù)字證書；
（3）客戶端驗證服務(wù)器的證書，以便確認是正確的服務(wù)器：瀏覽器通過 CA 的公鑰對證書簽名進行校驗，檢查證書是否有效。另外，客戶端持有證書即可完成個人身份的確認。
客戶端（瀏覽器）的"證書管理器"，有"受信任的根證書頒發(fā)機構(gòu)"列表。客戶端會根據(jù)這張列表，查看解開數(shù)字證書的公鑰是否在列表之內(nèi)。如果這張數(shù)字證書不是由受信任的機構(gòu)頒發(fā)的，瀏覽器會發(fā)出警告：
如果數(shù)字證書內(nèi)容中記載的網(wǎng)址，與你正在瀏覽的網(wǎng)址不一致，就說明這張證書可能被冒用，瀏覽器會發(fā)出警告：
（4）驗證通過后，瀏覽器生成一個臨時密鑰（對稱加密的密鑰）并用服務(wù)器的公鑰對它加密，然后將其發(fā)送給服務(wù)器；
（5）服務(wù)器用私鑰解密，得到瀏覽器發(fā)送給它的密鑰， 然后用該密鑰對數(shù)據(jù)進行（對稱）加密；
（6）瀏覽器得到加密數(shù)據(jù)，并用發(fā)給服務(wù)端的密鑰進行解密。
7 HTTPS 與 SSL
HTTPS 是身披 SSL 外殼的 HTTP。HTTPS 并非是應(yīng)用層的一種新協(xié)議。只是 HTTP 通信接口部分用 SSL（SecureSocket Layer）和 TLS（Transport Layer Security）協(xié)議代替而已。通常，HTTP 直接和 TCP 通信。當使用 SSL 時，則演變成先和 SSL 通信，再由 SSL和 TCP 通信了。簡言之，所謂 HTTPS，其實就是身披 SSL 協(xié)議這層外殼的HTTP。
在采用 SSL 后，HTTP 就擁有了 HTTPS 的加密、證書和完整性保護這些功能。SSL 是獨立于 HTTP 的協(xié)議，所以不光是 HTTP 協(xié)議，其他運行在應(yīng)用層的 SMTP和 Telnet 等協(xié)議均可配合 SSL 協(xié)議使用?？梢哉f SSL 是當今世界上應(yīng)用最為廣泛的網(wǎng)絡(luò)安全術(shù)。
HTTPS 采用混合加密機制。HTTPS 采用對稱加密和非對稱加密兩者并用的混合加密機制。
由于非對稱加密與對稱加密相比，其處理速度要慢，所以實際應(yīng)用中將多種方法組合起來用于通信。在交換對稱密鑰環(huán)節(jié)使用非對稱加密方式，之后的建立通信交換報文階段則使用對稱密鑰加密方式。
為了更好地理解 HTTPS，我們來觀察一下 HTTPS 的通信步驟。
- 步驟 1： 客戶端通過發(fā)送 Client Hello 報文開始 SSL 通信。報文中包含客戶端支持的 SSL 的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長度等）。
- 步驟 2： 服務(wù)器可進行 SSL 通信時，會以 Server Hello 報文作為應(yīng)答。和客戶端一樣，在報文中包含 SSL 版本以及加密組件。服務(wù)器的加密組件內(nèi)容是從接收到的客戶端加密組件內(nèi)篩選出來的。
- 步驟 3： 之后服務(wù)器發(fā)送 Certificate 報文。報文中包含公開密鑰證書。
- 步驟 4： 最后服務(wù)器發(fā)送 Server Hello Done 報文通知客戶端，最初階段的SSL握手協(xié)商部分結(jié)束。
- 步驟 5： SSL 第一次握手結(jié)束之后，客戶端以 Client Key Exchange 報文作為回應(yīng)。報文中包含通信加密中使用的一種被稱為 Pre-master secret 的隨機密碼串（即對稱密鑰）。該報文已用步驟 3 中的公開密鑰進行加密。
- 步驟 6： 接著客戶端繼續(xù)發(fā)送 Change Cipher Spec 報文。該報文會提示服務(wù)器，在此報文之后的通信會采用 Pre-master secret 密鑰加密。
- 步驟 7： 客戶端發(fā)送 Finished 報文。該報文包含連接至今全部報文的整體校驗值。這次握手協(xié)商是否能夠成功，要以服務(wù)器是否能夠正確解密該報文作為判定標準。
- 步驟 8： 服務(wù)器同樣發(fā)送 Change Cipher Spec 報文。
- 步驟 9： 服務(wù)器同樣發(fā)送 Finished 報文。
- 步驟 10： 服務(wù)器和客戶端的 Finished 報文交換完畢之后，SSL 連接就算建立完成。當然，通信會受到 SSL 的保護。從此處開始進行應(yīng)用層協(xié)議的通信，即發(fā)送 HTTP請求。
- 步驟 11： 應(yīng)用層協(xié)議通信，即發(fā)送 HTTP 響應(yīng)。
- 步驟 12： 最后由客戶端斷開連接。斷開連接時，發(fā)送 close_notify 報文。下圖做了一些省略，這步之后再發(fā)送 TCP FIN 報文來關(guān)閉與 TCP 的通信。在以上流程中，應(yīng)用層發(fā)送數(shù)據(jù)時會附加一種叫做 MAC（Message Authentication Code）的報文摘要。MAC 能夠查知報文是否遭到篡改，從而保護報文的完整性。
8 為什么不一直使用HTTPS
既然 HTTPS 那么安全可靠，那為何所有的 Web 網(wǎng)站不一直使用 HTTPS？
其中一個原因是，因為與純文本通信相比，加密通信會消耗更多的 CPU 及內(nèi)存資源。如果每次通信都加密，會消耗相當多的資源，平攤到一臺計算機上時，能夠處理的請求數(shù)量必定也會隨之減少。因此，如果是非敏感信息則使用 HTTP 通信，只有在包含個人信息等敏感數(shù)據(jù)時，才利用 HTTPS 加密通信。特別是每當那些訪問量較多的 Web 網(wǎng)站在進行加密處理時，它們所承擔著的負載不容小覷。在進行加密處理時，并非對所有內(nèi)容都進行加密處理，而是僅在那些需要信息隱藏時才會加密，以節(jié)約資源。文章來源：http://www.zghlxwxcb.cn/news/detail-491666.html
除此之外，想要節(jié)約購買證書的開銷也是原因之一。要進行 HTTPS 通信，證書是必不可少的。而使用的證書必須向認證機構(gòu)（CA）購買。證書價格可能會根據(jù)不同的認證機構(gòu)略有不同。那些購買證書并不合算的服務(wù)以及一些個人網(wǎng)站，可能只會選擇采用 HTTP 的通信方式。文章來源地址http://www.zghlxwxcb.cn/news/detail-491666.html
到了這里，關(guān)于非對稱加密與數(shù)字證書的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
