電子商務時代必知的PKI及HTTPS

PKI

一、通用加密算法以及HASH函數
二、證書頒發機構CA（Certification Authority）
三、數字證書

通用加密算法

1. 對稱加密算法：加密使用的密鑰和解密使用的密鑰是同一把密鑰。3DES、AES、RC5……
   

2. 非對稱加密算法：加密和解密使用兩把不一樣的密鑰，一把稱爲公鑰，可讓全部人知道；另外一把稱爲私鑰，必須嚴格保管不能被擁有者之外的任何人知道。RSA、DSA、ECC
   

傳統加密（對稱加密）

一、加密速度快（winrar AES算法）
二、能夠加密大量數據
三、可是密鑰傳遞困難

加密用的密鑰沒有一種安全的傳遞方式
即便有，在電子商務這種須要密鑰大量快速傳遞的應用場景中，也沒有效率。

非對稱加密（公鑰加密）：

解決了KEY傳遞的問題。
加密速度慢於對稱加密1000倍。

服務器將本身的公鑰經過某種方式紛發出去，如放到網站上。
客戶使用服務器01的公鑰對數據加密，只有服務器01使用本身的私鑰能解開。
服務器01使用本身的私鑰加密，也只有他的公鑰能解開。

惟一性
不可複製性
不能否認性

對源文件運算後產生一串固定長度的消息摘要（特徵碼）
用於惟一的標識源文件。

解決了不須要保密數據的傳遞問題。

混合加密：

混合加密的解密：

服務器將本身的公鑰還有本身的身份信息HASH
用本身的私鑰將特徵碼加密
一塊兒放到網站上，讓客戶下載
下載後拿公鑰解開特徵碼獲得服務器信息
做爲普通用戶爲了證實某網站不是假冒的須要浪費大量精力，這在電子商務時代是不可接受的。

全部須要提供安全服務的服務者須要找CA認證本身。
認證後CA會用本身的私鑰將認證者的公鑰及相關信息HASH後的特徵碼加密（簽名）並還給被認證者。
客戶端瀏覽器會集成CA的公鑰，可以獲得數字證書中的服務器公鑰和相關信息，使用相同方法HASH後和CA簽名的值對比，正確後能夠認定公鑰及相關信息是對的。

HTTPS
各類×××
安全電子郵件
網上銀行

基於PKI的HTTPS工做原理

1. 客戶端的瀏覽器向服務器傳送客戶端 SSL 協議的版本號，加密算法的種類，產生的隨機數，以及其餘必需要的各類信息。
   

2. 服務器向客戶端傳送 SSL 協議的版本號，加密算法的種類，隨機數以及其餘相關信息，同時服務器還將向客戶端傳送本身的證書。

3. 客戶利用服務器傳過來的信息驗證服務器的合法性，服務器的合法性包括：證書是否過時，發行服務器證書的 CA 是否可靠，發行者證書的公鑰可否正確解開服務器證書的「發行者的數字簽名」，服務器證書上的域名是否和服務器的實際域名相匹配。若是合法性驗證沒有經過，通信將斷開；若是合法性驗證經過，將繼續進行第四步。
   

4. 用戶端隨機產生一個用於後面通信的「對稱密碼」，而後用服務器的公鑰（服務器的公鑰從步驟②中的服務器的證書中得到）對其加密，而後將加密後的「預主密碼」傳給服務器。 
   

5. 若是服務器要求客戶的身份認證（在握手過程當中爲可選），用戶能夠創建一個隨機數而後對其進行數字簽名，將這個含有簽名的隨機數和客戶本身的證書以及加密過的「預主密碼」一塊兒傳給服務器。
   

6. 若是服務器要求客戶的身份認證，服務器必須檢驗客戶證書和簽名隨機數的合法性，具體的合法性驗證過程包括：客戶的證書使用日期是否有效，爲客戶提供證書的CA 是否可靠，發行CA 的公鑰可否正確解開客戶證書的發行 CA 的數字簽名，檢查客戶的證書是否在證書廢止列表（CRL）中。檢驗若是沒有經過，通信馬上中斷；若是驗證經過，服務器將用本身的私鑰解開加密的「預主密碼 」，而後執行一系列步驟來產生主通信密碼（客戶端也將經過一樣的方法產生相同的主通信密碼）。

7. 服務器和客戶端用相同的主密碼即「通話密碼」，一個對稱密鑰用於 SSL 協議的安全數據通信的加解密通信。同時在 SSL 通信過程當中還要完成數據通信的完整性，防止數據通信中的任何變化。
   

8. 客戶端向服務器端發出信息，指明後面的數據通信將使用的步驟7中的主密碼爲對稱密鑰，同時通知服務器客戶端的握手過程結束。
   

9. 服務器向客戶端發出信息，指明後面的數據通信將使用的步驟7中的主密碼爲對稱密鑰，同時通知客戶端服務器端的握手過程結束。
   

10. SSL 的握手部分結束，SSL 安全通道的數據通信開始，客戶和服務器開始使用相同的對稱密鑰進行數據通信，同時進行通信完整性的檢驗。
    

    
    

    網絡技術羣：75156605      運營商技術交流羣：80268245   我老師的羣 交流現網技術！