(1) openssl基礎概念

標籤：_id   數字   visit   成熟   提升   hash   密鑰   傳輸過程   接收   

1.1 背景知識

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

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

單向加密     ：不算是加密，也常稱為散列運算，用於產生獨一無二的校正碼(或稱為指紋、特徵碼)來保證資料的完整性和一致性，如MD5、SHA。具有雪崩效應，任何一點資料的改變，產生的校正碼值變化非常大。

互連網資料安全可靠的條件：

1.資料來源可信，即資料寄件者身份可信。

2.資料具備完整性，即資料未被修改過。

3.資料安全性，即資料不會被泄漏，他人截獲後無法解密。

1.2 互連網資料加密的細節

對資料加密的方法有三種：對稱式加密、私密金鑰加密和公開金鑰加密。

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

考慮這三種密碼編譯演算法的特性，公私密金鑰加密速度慢，對稱式加密快。

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

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

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

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

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

 

 

1.3 互連網資料簽名的細節

互連網資料的加密：通常使用對方的公開金鑰加密資料（或加密加密資料的對稱金鑰），資料發送給對方後，對方使用自己的私密金鑰解密資料（或解密加密資料的對稱金鑰）

互連網資料簽名：使用自己的私密金鑰加密資料的摘要資訊（），得到數位簽章，

在保證了資料的安全性後，還需要保證資料的完整性、一致性以及資料來源的可靠性。

對於資料的完整性和一致性，使用單向密碼編譯演算法，通過hashFunction Compute出資料獨一無二的校正碼，這個校正碼稱為“資訊摘要(Message Digest)”。

對於資料來源可靠性，使用自己的私密金鑰加密即可驗證身份，因為獲得資料後使用公開金鑰不能解密的就證明資料不是配對私密金鑰加密的。但是私密金鑰加密速度慢，所以只用私密金鑰密碼編譯摘要資訊，加密後的摘要資訊稱為“數位簽章(Signature)”。

使用者獲得數位簽章後的資料，首先使用資料來源方的公開金鑰解密，這樣獲得了資料和資訊摘要部分，並確認了資料來源的可靠性。由於這時候資料部分是沒有被加密的，所以使用者也可以使用同種單向密碼編譯演算法計算出摘要資訊，然後對比來源方的摘要資訊和自己計算出的摘要資訊，如果相等則證明資料完全未被修改過，是完整一致的。

因此只要使用數位簽章就能保證資料來源的可靠性、資料的完整性和一致性。

分別是數位簽章和確認資料的全過程。

從可知，資料簽名只保證了資料的可靠性和完整性，並沒有對資料進行加密

 

1.4 互連網資料安全傳輸的細節

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

如果資料轉送雙方張三和李四不在意資料丟失的泄露性，那麼可以不對資料進行加密，只要數位簽章即可。即，可以犧牲資料的安全性，只要保證資料的完整性、一致性和可靠性，即使被中間人王五截獲了甚至截獲後修改一番再發送給李四也無所謂，因為李四可以根據數位簽章驗證資料的來源及資料的完整性，若發現被修改後大不了不用了。現在互連網上很多時候下載軟體時就提供了簽名驗證，使用的就是這種機制，不管軟體是否被截取，只要安裝者能驗證即可，如。

 

 

 但是如果在意資料泄漏呢？就需要將數位簽章和加密結合起來使用

有兩種方案：

1.先對資料加密，再對加密後的整體進行數位簽章；

2.先對資料進行數位簽章，再對簽名後的整體進行加密（互連網常用）。

在互連網上基本使用第二種方法，使用者最終只對資料部分進行校正而不對加密後的資料進行校正。

具體細節如下：

首先進行數位簽章，再使用對稱加密加密簽名後的整體，然後使用對方的公開金鑰只加密對稱金鑰部分。這樣即保證了加密速度，還保證了資料的安全性、可靠性和完整性。解密時反向進行即可。：

 

 

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

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

 

1.5 CA、PKI及信任CA

CA(Certificate Authority)是數位憑證認證中心，常稱為憑證授權單位，申請者提交自己的公開金鑰和一些個人資訊(如申請者國家，姓名，單位等)給CA，CA對申請者的這些資訊單向加密產生摘要資訊，然後使用自己的私密金鑰加密整個摘要資訊，這樣就得到了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握手機制就算結束了。之後所有的資料只需要使用“對話密鑰”加密即可，不再需要多餘的加密機制。

 

需要說明的是，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加密機制的握手通訊過程。

  

(1) openssl基礎概念