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