本文目錄：
1.2 互聯(lián)網(wǎng)數(shù)據(jù)加密的細節(jié)
1.3 互聯(lián)網(wǎng)數(shù)據(jù)簽名的細節(jié)
1.4 互聯(lián)網(wǎng)數(shù)據(jù)安全傳輸?shù)募毠?jié)
對稱加密 ：加密解密使用同一密鑰，加解密速度快。隨著人數(shù)增多，密鑰數(shù)量急增n(n-1)/2。
非對稱加密 ：使用公私鑰配對加解密，速度慢。公鑰是從私鑰中提取出來的，一般拿對方公鑰加密來保證數(shù)據(jù)安全性，拿自己的私鑰加密來證明數(shù)據(jù)來源的身份。
單向加密 ：不算是加密，也常稱為散列運算，用于生成獨一無二的校驗碼(或稱為指紋、特征碼)來保證數(shù)據(jù)的完整性和一致性，如MD5、SHA。具有雪崩效應(yīng)，任何一點數(shù)據(jù)的改變，生成的校驗碼值變化非常大。
互聯(lián)網(wǎng)數(shù)據(jù)安全可靠的條件：
1.數(shù)據(jù)來源可信，即數(shù)據(jù)發(fā)送者身份可信。
2.數(shù)據(jù)具備完整性，即數(shù)據(jù)未被修改過。
3.數(shù)據(jù)安全性，即數(shù)據(jù)不會被泄漏，他人截獲后無法解密。
對數(shù)據(jù)加密的方法有三種：對稱加密、私鑰加密和公鑰加密。三種方法只靠其中任意一種都有不可容忍的缺點，因此考慮將它們結(jié)合使用。
考慮這三種加密算法的特性，公私鑰加密速度慢，對稱加密快，所以可以首先對數(shù)據(jù)部分使用對稱加密。再進一步考慮，公鑰大家都可以獲取，若使用自己私鑰加密，數(shù)據(jù)被截獲后直接就被破解，因此使用對方的公鑰加密，又由于公鑰加密速度慢，所以可以使用對方公鑰對對稱密鑰部分進行加密。
數(shù)據(jù)的收取者解密時，將使用自己的私鑰解密第一層，得到對稱密鑰后加密的數(shù)據(jù)，再使用對稱密鑰解密，這樣就能獲得最終數(shù)據(jù)。
如下圖所示分別是加密和解密的全過程。
加密的方法很多，但是上述方法是綜合考慮互聯(lián)網(wǎng)安全后較為成熟的一種簡單加密方法。
使用上述方法加密保證了數(shù)據(jù)的安全性，但是還未保證數(shù)據(jù)的完整性、一致性以及數(shù)據(jù)來源的可靠性。
在保證了數(shù)據(jù)的安全性后，還需要保證數(shù)據(jù)的完整性、一致性以及數(shù)據(jù)來源的可靠性。
對于數(shù)據(jù)的完整性和一致性，使用單向加密算法，通過hash函數(shù)計算出數(shù)據(jù)獨一無二的校驗碼，這個校驗碼稱為“信息摘要(Message Digest)”。
對于數(shù)據(jù)來源可靠性，使用自己的私鑰加密即可驗證身份，因為獲得數(shù)據(jù)后使用公鑰不能解密的就證明數(shù)據(jù)不是配對私鑰加密的。但是私鑰加密速度慢，所以只用私鑰加密摘要信息，加密后的摘要信息稱為“數(shù)字簽名(Signature)”。
用戶獲得數(shù)字簽名后的數(shù)據(jù)，首先使用數(shù)據(jù)來源方的公鑰解密，這樣獲得了數(shù)據(jù)和信息摘要部分，并確認了數(shù)據(jù)來源的可靠性。由于這時候數(shù)據(jù)部分是沒有被加密的，所以用戶也可以使用同種單向加密算法計算出摘要信息，然后對比來源方的摘要信息和自己計算出的摘要信息，如果相等則證明數(shù)據(jù)完全未被修改過，是完整一致的。
因此只要使用數(shù)字簽名就能保證數(shù)據(jù)來源的可靠性、數(shù)據(jù)的完整性和一致性。
如圖所示分別是數(shù)字簽名和確認數(shù)據(jù)的全過程。
要在互聯(lián)網(wǎng)上安全傳輸數(shù)據(jù)，要保證數(shù)據(jù)來源可靠、數(shù)據(jù)原始未被修改過、數(shù)據(jù)丟失不泄密。
如果數(shù)據(jù)傳輸雙方張三和李四不在意數(shù)據(jù)丟失的泄露性，那么可以不對數(shù)據(jù)進行加密，只要數(shù)字簽名即可，即使被中間人王五截獲了甚至截獲后修改一番再發(fā)送給李四也無所謂，因為李四可以根據(jù)數(shù)字簽名驗證數(shù)據(jù)的來源及數(shù)據(jù)的完整性，若發(fā)現(xiàn)被修改后大不了不用了?，F(xiàn)在互聯(lián)網(wǎng)上很多時候下載軟件時就提供了簽名驗證，使用的就是這種機制，不管軟件是否被截取，只要安裝者能驗證即可，如下圖。
但是如果在意數(shù)據(jù)泄漏呢？就需要將數(shù)字簽名和加密結(jié)合起來使用。有兩種方案：1.先對數(shù)據(jù)加密，再對加密后的整體進行數(shù)字簽名；2.先對數(shù)據(jù)進行數(shù)字簽名，再對簽名后的整體進行加密。
在互聯(lián)網(wǎng)上基本使用第二種方法，用戶最終只對數(shù)據(jù)部分進行校驗而不對加密后的數(shù)據(jù)進行校驗。具體細節(jié)如下：首先進行數(shù)字簽名，再使用對稱加密加密簽名后的整體，然后使用對方的公鑰只加密對稱密鑰部分。這樣即保證了加密速度，還保證了數(shù)據(jù)的安全性、可靠性和完整性。解密時反向進行即可。如圖所示。
但是這時還有一個漏洞，問題出在數(shù)字簽名過程中私鑰加密以及后面公鑰解密的不安全性。圖中李四在拿公鑰A解密的時候，這個公鑰A真的是張三的公鑰嗎？也許張三傳輸公鑰給李四的過程中被王五截斷，王五聲稱自己是張三，并把自己的公鑰給了李四，然后王五用自己的私鑰對木馬程序進行簽名，進行對稱加密后再使用李四的公鑰加密，最后傳輸給李四，這樣一來李四以為王五就是張三，導(dǎo)致的結(jié)果是李四對木馬程序完全信任。
如何解決這個漏洞呢？只要保證李四獲得的公鑰A真的是來源于張三即可，如何保證呢？互聯(lián)網(wǎng)之下，數(shù)據(jù)傳輸?shù)膬啥丝赡苷l都不認識誰，誰也不相信誰，所以最終還是依靠公益性的第三方組織——CA。
CA(Certificate Authority)是數(shù)字證書認證中心，常稱為證書頒發(fā)機構(gòu)，申請者提交自己的公鑰和一些個人信息(如申請者國家，姓名，單位等)給CA，CA對申請者的這些信息單向加密生成摘要信息，然后使用自己的私鑰加密整個摘要信息，這樣就得到了CA對申請者的數(shù)字簽名，在數(shù)字簽名上再加上CA自己的一些信息(如CA的機構(gòu)名稱，CA層次路徑等)以及該證書的信息(如證書有效期限)，就得到了所謂的數(shù)字證書。
過程如下圖。
如果某用戶信任了該CA，就獲取了該CA的公鑰（實際上信任CA的其中一個作用就是獲取CA公鑰），使用該公鑰解密數(shù)字證書就可以驗證申請者的信息以及申請者公鑰的可靠性（申請者的公鑰只被CA的私鑰加密，解密該私鑰后只是需要驗證可靠性）。
這里的關(guān)鍵是CA使用自己的私鑰給申請者加密，那么如何保證CA是可信并且合法的呢？根CA是通過自簽署數(shù)字證書的方式標(biāo)榜自己的可信性和合法性，第一級子CA由根CA頒發(fā)合法數(shù)字證書，第二級直至所有的子CA都由上一級子CA頒發(fā)數(shù)字證書。對于多級子CA只需要信任根CA即可，因為獲取了根CA的公鑰，可以解密第一級子CA的證書并獲取驗證第一級子CA的公鑰，層層遞進，最終獲取到為申請者頒發(fā)數(shù)字證書的機構(gòu)并獲取它的公鑰。
正是這些根CA和子CA組成了PKI。
信任CA后，每次接收到需要解密的數(shù)字證書時，還要去該頒發(fā)機構(gòu)指定網(wǎng)站的證書吊銷列表（CRL）中查詢該證書是否被吊銷，對于吊銷后的證書應(yīng)該不予以信任，這是信任CA的第二個作用。導(dǎo)致證書被吊銷的可能性不少，例如申請者的私鑰被黑客獲取，申請者申請吊銷等。
也有公司使用自簽的證書，例如某些銀行、12306有時候就要求下載證書并安裝。使用自簽證書的好處當(dāng)然是省錢、方便啦。
PKI的兩種實現(xiàn)方式TLS和SSL使用的證書格式都是x509，TLSv1和SSLv3基本等價，只不過SSL實現(xiàn)在OSI 4層模型中的應(yīng)用層和傳輸層的中間，TLS實現(xiàn)在傳輸層。
還有PKI的另一種實現(xiàn)方式GPG，它的證書使用的不是x509格式。
數(shù)字證書中包含的信息有：申請者的公鑰，證書有效期，證書合法擁有人，證書如何被使用，CA的信息，CA對申請者信息的數(shù)字簽名。
有了CA頒發(fā)的數(shù)字證書后，通信機制就和下圖的機制完全不同了。
上圖中每一段數(shù)據(jù)都簽名加密，有了數(shù)字證書后實際上已經(jīng)驗證了身份，不需要每一段數(shù)據(jù)都簽名，這能提升效率。在上圖中的漏洞是無法確認獲取的公鑰A是否可信，有了數(shù)字證書后已經(jīng)能夠確認公鑰A是可信的。但問題是公鑰A本來目的是用來解密數(shù)字簽名的，有了數(shù)字證書后不需要數(shù)字簽名了，那公鑰A不是多余的嗎，如果多余，那把公鑰A交給CA是不是也是多余的呢？
不多余，因為SSL的握手機制和數(shù)字簽名機制完全不同。以下是單向驗證機制，只驗證服務(wù)端。
第一步：Visitor給出協(xié)議版本號、一個客戶端隨機數(shù)（Client random），以及客戶端支持的加密方法。
第二步：Server確認雙方使用的加密方法，以及一個服務(wù)器生成的隨機數(shù)（Server random）。
第三步：Server發(fā)送數(shù)字證書給Visitor。
第四步：Visitor確認數(shù)字證書有效（查看證書狀態(tài)且查詢證書吊銷列表），并使用信任的CA的公鑰解密數(shù)字證書獲得Server的公鑰，然后生成一個新的46字節(jié)隨機數(shù)（稱為預(yù)備主密鑰Pre-master secret），并使用Server的公鑰加密預(yù)備主密鑰發(fā)給Server。
第五步：Server使用自己的私鑰，解密Visitor發(fā)來的預(yù)備主密鑰。
第六步：Visitor和Server雙方都具有了(客戶端隨機數(shù)+服務(wù)端隨機數(shù)+預(yù)備主密鑰)，它們兩者都根據(jù)約定的加密方法，使用這三個隨機數(shù)生成對稱密鑰——主密鑰（也稱為對話密鑰session key），用來加密接下來的整個對話過程。
第七步：之后所有的數(shù)據(jù)只需要使用“對話密鑰”加密即可，不再需要多余的加密機制。
注意：1.在SSL握手機制中，需要三個隨機數(shù)（客戶端隨機數(shù)+服務(wù)端隨機數(shù)+預(yù)備主密鑰）；2.至始至終客戶端和服務(wù)端只有一次非對稱加密動作——客戶端使用證書中獲得的服務(wù)端公鑰加密預(yù)備主密鑰。3.上述SSL握手機制的前提單向驗證，無需驗證客戶端，如果需要驗證客戶端則可能需要客戶端的證書或客戶端提供簽名等。
Server和Visitor通信，Server把數(shù)字證書發(fā)給Visitor，最關(guān)鍵的一點是Visitor要保證證書的有效性，通過查看證書狀態(tài)并去CA的吊銷列表查看Server的證書是否被吊銷。只有Server的證書可用了，才保證了第一環(huán)節(jié)的安全性。
可以看出，使用SSL比前文介紹的“數(shù)字簽名+加密”簡便多了，將身份驗證和密鑰生成在會話的開始就完成了，而不需要每次的數(shù)據(jù)傳輸過程中都進行，這就是https等使用ssl加密機制的握手通信過程。
回到openssl系列文章大綱：http://www.cnblogs.com/f-ck-need-u/p/7048359.html
