1.1 背景知識

對稱加密 ? ? ：加密解密使用同一密鑰，加解密速度快。隨著人數增多，密鑰數量急增n(n-1)/2。

非對稱加密 ：使用公私鑰配對加解密，速度慢。公鑰是從私鑰中提取出來的，一般拿對方公鑰加密來保證數據安全性，拿自己的私鑰加密來證明數據來源的身份。

單向加密 ? ? ：不算是加密，也常稱為散列運算，速度快，用于生成獨一無二的校驗碼(或稱為指紋、特征碼)來保證數據的完整性和一致性，如MD5、SHA。具有雪崩效應，任何一點數據的改變，生成的校驗碼值變化非常大。

互聯網數據安全可靠的條件：

1.數據來源可信，即數據發送者身份可信。

2.數據具備完整性，即數據未被修改過。

3.數據安全性，即數據不會被泄漏，他人截獲后無法解密。

1.2 互聯網數據加密的細節

對數據加密的方法有三種：對稱加密、私鑰加密和公鑰加密。

三種方法只靠其中任意一種都有不可容忍的缺點，因此考慮將它們結合使用。

考慮這三種加密算法的特性，公私鑰加密速度慢，對稱加密快。

所以可以首先對數據部分使用對稱加密。再進一步考慮，公鑰大家都可以獲取，若使用自己私鑰加密，數據被截獲后直接就被破解（公鑰任何人都可獲取，而私鑰只有自己才擁有，因此使用私鑰加密數據沒有保障，任何擁有公鑰的人都能將數據解密，因此使用公鑰加密數據，私鑰<只有自己擁有>解密數據），因此使用對方的公鑰加密，又由于公鑰加密速度慢，所以可以使用對方公鑰對對稱密鑰部分進行加密。

數據的接收者解密時，將使用自己的私鑰解密第一層（即使用私鑰解密第一層加密的對稱密鑰），得到對稱密鑰，再使用對稱密鑰解密，這樣就能獲得最終數據。

如下圖所示分別是加密和解密的全過程。

加密的方法很多，但是上述方法是綜合考慮互聯網安全后較為成熟的一種簡單加密方法。

使用上述方法加密保證了數據的安全性，但是還未保證數據的完整性、一致性以及數據來源的可靠性。

?

?

1.3 互聯網數據簽名的細節

互聯網數據的加密：通常使用對方的公鑰加密數據（通常不會直接使用公鑰加密數據，速度太慢，而使用公鑰加密加密數據的對稱密鑰），數據發送給對方后，對方使用自己的私鑰解密數據（或解密加密數據的對稱密鑰）、

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?保證了數據的安全性（數據+對稱加密——>數據? ?+對稱密鑰+公鑰加密——>數據+(公鑰)加密的對稱密鑰）

互聯網數據簽名：使用自己的私鑰加密數據的摘要信息（使用單向加密從數據中提取出來能夠代表數據的摘要信息），就是數字簽名

　　　　　　　　? 保證了數據的來源可靠性、完整一致性（數據+單向加密——>數據+摘要信息——>數據? +摘要信息+自己端的私鑰加密——>數據+數字簽名）

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?保證數據完整一致性? ? ? ? ? ? ? ? ? ?保證數據來源可靠性（即可驗證數據來源身份）

在保證了數據的安全性后，還需要保證數據的完整一致性以及數據來源的可靠性。

對于數據的完整性和一致性，使用單向加密算法，通過hash函數計算出數據獨一無二的校驗碼，這個校驗碼稱為“信息摘要(Message Digest)”。

對于數據來源可靠性，使用自己的私鑰加密即可驗證身份，因為獲得數據后使用公鑰不能解密的就證明數據不是配對私鑰加密的。但是私鑰加密速度慢，所以只用私鑰加密摘要信息，使用私鑰加密的摘要信息稱為“數字簽名(Signature)”。

用戶獲得數字簽名后的數據，首先使用數據來源方的公鑰解密，這樣獲得了數據和信息摘要部分，并確認了數據來源的可靠性。由于這時候數據部分是沒有被加密的，所以用戶也可以使用同種單向加密算法計算出摘要信息，然后對比來源方的摘要信息和自己計算出的摘要信息，如果相等則證明數據完全未被修改過，是完整一致的。

因此只要使用數字簽名就能保證數據來源的可靠性、數據的完整性和一致性

如圖所示分別是數字簽名和確認數據的全過程。

從上圖可知，數據簽名只保證了數據來源的可靠性和完整一致性，并沒有對數據進行加密（所有人可以查看數據的內容，但是能夠通過數字簽名確保數據的來源的可靠性和完整一致性）

?

?

要在互聯網上安全傳輸數據，要保證數據來源可靠、數據原始未被修改過、數據丟失不泄密。

如果數據傳輸雙方張三和李四不在意數據丟失的泄露性，那么可以不對數據進行加密，只要數字簽名即可。即，可以犧牲數據的安全性，只要保證數據的完整性一致性和來源可靠性，即使被中間人王五截獲了甚至截獲后修改一番再發送給李四也無所謂，因為李四可以根據數字簽名（數據源頭方使用私鑰加密數據的信息摘要）驗證數據的來源及數據的完整性，若發現被修改后大不了不用了?，F在互聯網上很多時候下載軟件時就提供了簽名驗證，使用的就是這種機制，不管軟件是否被截取，只要安裝者能驗證即可，如下圖。

?

?

但是如果在意數據泄漏呢？就需要將數字簽名和加密結合起來使用

有兩種方案：

1.先對數據加密，再對加密后的整體進行數字簽名；

2.先對數據進行數字簽名，再對簽名后的整體進行加密（互聯網常用）。

在互聯網上基本使用第二種方法，用戶最終只對數據部分進行校驗而不對加密后的數據進行校驗。

具體細節如下：

首先使用自己的私鑰加密數據摘要信息，即進行數字簽名，
再使用對稱加密加密簽名后的整體，
最后使用對方的公鑰只加密對稱密鑰部分。

數據加密過程：A方

數據+hash算法 ==》數據+摘要信息1? ? ? ? ? ? ? ? ? ? ? 數據+(摘要信息1+ A私鑰去加密摘要信息1) ==》數據+數字簽名? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

?(數據+數字簽名) + 對稱加密算法 ==》? (數據+數字簽名) + 對稱加密秘鑰? ? ? ? ? ? ? ? ? ? ? ??(數據+數字簽名) + 對稱加密秘鑰 + B公鑰? ==》??(數據+數字簽名) + B公鑰加密后的對稱加密秘鑰

數據機密過程：B方

(數據+數字簽名) +?B公鑰加密后的對稱加密秘鑰? +? 自己私鑰B? ? ==>? ? （數據+數字簽名） +? 對稱加密秘鑰? ?==》 得到解密后的（數據+數字簽名） ==》

數據+數字簽名 + A方的公鑰? ==》 數據 + 摘要信息1? ? ? ? ? ?數據 + 摘要信息1? + hash算法 ==》? 數據 + 摘要信息2? ? ? ? ? 若摘要信息2和摘要信息1完全相同，則證明數據來源完整、一致、可靠

?

?

這樣即保證了加密速度，還保證了數據的安全性、可靠性和完整性。解密時反向進行即可。如圖所示：

?

?

但是這時還有一個漏洞，問題出在數字簽名過程中私鑰加密以及后面公鑰解密的不安全性。圖中李四在拿公鑰A解密的時候，這個公鑰A真的是張三的公鑰嗎？也許張三傳輸公鑰給李四的過程中被王五截斷，王五聲稱自己是張三，并把自己的公鑰給了李四，然后王五用自己的私鑰對木馬程序進行簽名，進行對稱加密后再使用李四的公鑰加密，最后傳輸給李四，這樣一來李四以為王五就是張三，導致的結果是李四對木馬程序完全信任。

如何解決這個漏洞呢？只要保證李四獲得的公鑰A真的是來源于張三即可，如何保證呢？互聯網之下，數據傳輸的兩端可能誰都不認識誰，誰也不相信誰，所以最終還是依靠第三方組織——CA。

?

1.5 CA、PKI及信任CA

CA(Certificate Authority)是數字證書認證中心，常稱為證書頒發機構。

1、申請者提交自己的公鑰（從其私鑰提取）和一些個人信息(如申請者國家，姓名，單位等)給CA，
2、CA對申請者的這些信息單向加密生成摘要信息，
3、然后CA使用自己的私鑰加密整個摘要信息，這樣就得到了CA對申請者的數字簽名，

4、在數字簽名上再加上CA自己的一些信息(如CA的機構名稱，CA層次路徑等)以及該證書的信息(如證書有效期限)，就得到了所謂的數字證書。

過程如下圖。

?

如果某用戶信任了該CA，就獲取了該CA的公鑰（實際上信任CA的其中一個作用就是獲取CA公鑰），使用CA公鑰解密數字證書就可以驗證申請者的信息以及申請者公鑰的可靠性（申請者的公鑰只被CA的私鑰加密，解密該私鑰后只是需要驗證可靠性）。

這里的關鍵是CA使用自己的私鑰給申請者加密，那么如何保證CA是可信并且合法的呢？

根CA是通過自簽署數字證書的方式標榜自己的可信性和合法性，第一級子CA由根CA頒發合法數字證書，第二級直至所有的子CA都由上一級子CA頒發數字證書。對于多級子CA只需要信任根CA即可，因為獲取了根CA的公鑰，可以解密第一級子CA的證書并獲取驗證第一級子CA的公鑰，層層遞進，最終獲取到為申請者頒發數字證書的機構并獲取它的公鑰。

正是這些根CA和子CA組成了PKI（公鑰基礎設施）

信任CA后，每次接收到需要解密的數字證書時，還要去該頒發機構指定網站的證書吊銷列表（CRL）中查詢該證書是否被吊銷，對于吊銷后的證書應該不予以信任，這是信任CA的第二個作用。導致證書被吊銷的可能性不少，例如申請者的私鑰被黑客獲取，申請者申請吊銷等。

也有公司使用自簽的證書，例如某些銀行、12306有時候就要求下載證書并安裝。使用自簽證書的好處當然是省錢、方便

?

1.6 數字證書類型和內容

PKI的兩種實現方式TLS和SSL使用的證書格式都是x509，TLSv1和SSLv3基本等價，只不過SSL實現在OSI 4層模型中的應用層和傳輸層的中間，TLS實現在傳輸層。

還有PKI的另一種實現方式GPG，它的證書使用的不是x509格式。

數字證書中包含的信息有：申請者的公鑰，證書有效期，證書合法擁有人，證書如何被使用，CA的信息，CA對申請者信息的數字簽名。

?

1.7 SSL握手機制

有了CA頒發的數字證書后，通信機制就和下圖的機制完全不同了

?

上圖中每一段數據都簽名加密，有了數字證書后實際上已經驗證了身份，不需要每一段數據都簽名，這能提升效率。

在上圖中的漏洞是無法確認獲取的公鑰A是否可信，有了數字證書后已經能夠確認公鑰A是可信的。但問題是公鑰A本來目的是用來解密數字簽名的，有了數字證書后不需要數字簽名了，那公鑰A不是多余的嗎，如果多余，那把公鑰A交給CA是不是也是多余的呢？

不多余，因為SSL的握手機制和數字簽名機制完全不同。

以下是單向驗證機制，只驗證服務端:

?

第一步：Visitor給出協議版本號、一個客戶端隨機數（Client random），以及客戶端支持的加密方法。

第二步：Server確認雙方使用的加密方法，以及一個服務器生成的隨機數（Server random）。

第三步：Server發送數字證書給Visitor。

第四步：Visitor確認數字證書有效（查看證書狀態且查詢證書吊銷列表），并使用信任的CA的公鑰解密數字證書獲得Server的公鑰，然后生成一個新的46字節隨機數（稱為預備主密鑰Pre-master secret），并使用Server的公鑰加密預備主密鑰發給Server（這一過程為非對稱加密）。

第五步：Server使用自己的私鑰，解密Visitor發來的預備主密鑰。

第六步：Visitor和Server雙方都具有了(客戶端隨機數+服務端隨機數+預備主密鑰)，它們兩者都根據約定的加密方法，使用這三個隨機數生成對稱密鑰——主密鑰（也稱為對話密鑰session key），用來加密接下來的整個對話過程。

第七步：在雙方驗證完session key的有效性之后，SSL握手機制就算結束了。之后所有的數據只需要使用“對話密鑰”加密即可，不再需要多余的加密機制。

?

也可使用如下更加形象的方式理解整個握手過程：

握手階段分成五步：?

第一步，客戶端client給出協議版本號、一個客戶端生成的隨機數（Client random），以及客戶端支持的加密方法。

第二步，服務端server確認雙方使用的加密方法，并給出數字證書、以及一個服務器生成的隨機數（Server random）。

第三步，客戶端client確認數字證書有效，然后生成一個新的隨機數（Premaster secret），并使用數字證書中的公鑰，加密這個隨機數，發給服務端server。

第四步，服務端server使用自己的私鑰，獲取客戶端client發來的隨機數（即Premaster secret）。

第五步，客戶端client和服務端server根據約定的加密方法，使用前面的三個隨機數，生成"對話密鑰"（session key），用來加密接下來的整個對話過程。

?注意：

1）生成對話密鑰一共需要三個隨機數。

2）握手之后的對話使用"對話密鑰"加密（對稱加密），服務器的公鑰和私鑰只用于加密和解密"對話密鑰"（非對稱加密），無其他作用。

3）服務器公鑰放在服務器的數字證書之中。

?從上面第二點可知，整個對話過程中（握手階段和其后的對話），服務器的公鑰和私鑰只需要用到一次

?

需要說明的是，session key不是真正的對稱加密密鑰，而是由session key進行hash算法得到一段hash值，從這個hash值中推斷出對稱加密過程中所需的key(即對稱加密所需的明文密碼部分)、salt(在RFC文檔中稱為MAC secret)和IV向量。

以后客戶端每次傳輸數據，都需要用key + salt +IV向量來完成對稱加密，而服務端只需一個key和協商好的加密算法即可解密。同理服務端向客戶端傳輸數據時也是一樣的。

?注意：

1.在SSL握手機制中，需要三個隨機數（客戶端隨機數+服務端隨機數+預備主密鑰）； 2.至始至終客戶端和服務端只有一次非對稱加密動作————即客戶端使用證書中獲得的服務端公鑰加密預備主密鑰。
3.上述SSL握手機制的前提單向驗證，無需驗證客戶端，如果需要驗證客戶端則可能需要客戶端的證書或客戶端提供簽名等

Server和Visitor通信，Server把數字證書發給Visitor，最關鍵的一點是Visitor要保證證書的有效性，通過查看證書狀態并去CA的吊銷列表查看Server的證書是否被吊銷。只有Server的證書可用了，才保證了第一環節的安全性。

可以看出，使用SSL比前文介紹的“數字簽名+加密”簡便多了，將身份驗證和密鑰生成在會話的開始就完成了，而不需要每次的數據傳輸過程中都進行，這就是https等使用ssl加密機制的握手通信過程。

??

轉載于:https://www.cnblogs.com/wyzhou/p/9738923.html

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的(1) openssl基础概念的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。