加密、簽名和SSL握手機制細節

openssl系列文章：http://www.cnblogs.com/f-ck-need-u/p/7048359.html

---

1.1 背景知識

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

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

單向加密     ：不算是加密，也常稱爲散列運算，用於生成獨一無二的校驗碼(或稱爲指紋、特徵碼)來保證數據的完整性和一致性，如MD五、SHA。具備雪崩效應，任何一點數據的改變，生成的校驗碼值變化很是大。

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

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

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

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

1.2 互聯網數據加密的細節

對數據加密的方法有三種：對稱加密、私鑰加密和公鑰加密。三種方法只靠其中任意一種都有不可容忍的缺點，所以考慮將它們結合使用。

考慮這三種加密算法的特性，公私鑰加密速度慢，對稱加密快，因此能夠首先對數據部分使用對稱加密。再進一步考慮，公鑰你們均可以獲取，若使用本身私鑰加密，數據被截獲後直接就被破解，所以使用對方的公鑰加密，又因爲公鑰加密速度慢，因此可使用對方公鑰對對稱密鑰部分進行加密。

數據的收取者解密時，將使用本身的私鑰解密第一層，獲得對稱密鑰後加密的數據，再使用對稱密鑰解密，這樣就能得到最終數據。

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

加密的方法不少，可是上述方法是綜合考慮互聯網安全後較爲成熟的一種簡單加密方法。

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

1.3 互聯網數據簽名的細節

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

對於數據的完整性和一致性，使用單向加密算法，經過hash函數計算出數據獨一無二的校驗碼，這個校驗碼稱爲「信息摘要(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受權的某個二級或者某個二級受權的三級CA不在信任列表中，就須要將這個中間的CA補齊，不然中間出現斷層，沒法成功解密該中間CA頒發的證書。一般這種中間CA的證書稱爲chain證書，例如"xxx.com.chain.crt"。若是購買的證書發給你的文件中包含了chain.crt文件，則說明他是中間CA，且有些瀏覽器或操做系統中沒有內置它的CA，這時應該將chain證書也配置到web server上。

正是這些根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加密機制的握手通訊過程。

 

關於https的握手協議過程RFC文檔：https://tools.ietf.org/html/rfc6101#appendix-F.1