1.1 背景知識(shí)

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

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

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

互聯(lián)網(wǎng)數(shù)據(jù)安全可靠的條件：

1.數(shù)據(jù)來源可信，即數(shù)據(jù)發(fā)送者身份可信。

2.數(shù)據(jù)具備完整性，即數(shù)據(jù)未被修改過。

3.數(shù)據(jù)安全性，即數(shù)據(jù)不會(huì)被泄漏，他人截獲后無法解密。

1.2 互聯(lián)網(wǎng)數(shù)據(jù)加密的細(xì)節(jié)

對(duì)數(shù)據(jù)加密的方法有三種：對(duì)稱加密、私鑰加密和公鑰加密。

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

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

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

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

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

加密的方法很多，但是上述方法是綜合考慮互聯(lián)網(wǎng)安全后較為成熟的一種簡單加密方法。

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

?

?

1.3 互聯(lián)網(wǎng)數(shù)據(jù)簽名的細(xì)節(jié)

互聯(lián)網(wǎng)數(shù)據(jù)的加密：通常使用對(duì)方的公鑰加密數(shù)據(jù)（通常不會(huì)直接使用公鑰加密數(shù)據(jù)，速度太慢，而使用公鑰加密加密數(shù)據(jù)的對(duì)稱密鑰），數(shù)據(jù)發(fā)送給對(duì)方后，對(duì)方使用自己的私鑰解密數(shù)據(jù)（或解密加密數(shù)據(jù)的對(duì)稱密鑰）、

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

互聯(lián)網(wǎng)數(shù)據(jù)簽名：使用自己的私鑰加密數(shù)據(jù)的摘要信息（使用單向加密從數(shù)據(jù)中提取出來能夠代表數(shù)據(jù)的摘要信息），就是數(shù)字簽名

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

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?保證數(shù)據(jù)完整一致性? ? ? ? ? ? ? ? ? ?保證數(shù)據(jù)來源可靠性（即可驗(yàn)證數(shù)據(jù)來源身份）

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

對(duì)于數(shù)據(jù)的完整性和一致性，使用單向加密算法，通過hash函數(shù)計(jì)算出數(shù)據(jù)獨(dú)一無二的校驗(yàn)碼，這個(gè)校驗(yàn)碼稱為“信息摘要(Message Digest)”。

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

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

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

如圖所示分別是數(shù)字簽名和確認(rèn)數(shù)據(jù)的全過程。

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

?

?

要在互聯(lián)網(wǎng)上安全傳輸數(shù)據(jù)，要保證數(shù)據(jù)來源可靠、數(shù)據(jù)原始未被修改過、數(shù)據(jù)丟失不泄密。

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

?

?

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

有兩種方案：

1.先對(duì)數(shù)據(jù)加密，再對(duì)加密后的整體進(jìn)行數(shù)字簽名；

2.先對(duì)數(shù)據(jù)進(jìn)行數(shù)字簽名，再對(duì)簽名后的整體進(jìn)行加密（互聯(lián)網(wǎng)常用）。

在互聯(lián)網(wǎng)上基本使用第二種方法，用戶最終只對(duì)數(shù)據(jù)部分進(jìn)行校驗(yàn)而不對(duì)加密后的數(shù)據(jù)進(jìn)行校驗(yàn)。

具體細(xì)節(jié)如下：

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

數(shù)據(jù)加密過程：A方

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

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

數(shù)據(jù)機(jī)密過程：B方

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

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

?

?

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

?

?

但是這時(shí)還有一個(gè)漏洞，問題出在數(shù)字簽名過程中私鑰加密以及后面公鑰解密的不安全性。圖中李四在拿公鑰A解密的時(shí)候，這個(gè)公鑰A真的是張三的公鑰嗎？也許張三傳輸公鑰給李四的過程中被王五截?cái)?#xff0c;王五聲稱自己是張三，并把自己的公鑰給了李四，然后王五用自己的私鑰對(duì)木馬程序進(jìn)行簽名，進(jìn)行對(duì)稱加密后再使用李四的公鑰加密，最后傳輸給李四，這樣一來李四以為王五就是張三，導(dǎo)致的結(jié)果是李四對(duì)木馬程序完全信任。

如何解決這個(gè)漏洞呢？只要保證李四獲得的公鑰A真的是來源于張三即可，如何保證呢？互聯(lián)網(wǎng)之下，數(shù)據(jù)傳輸?shù)膬啥丝赡苷l都不認(rèn)識(shí)誰，誰也不相信誰，所以最終還是依靠第三方組織——CA。

?

1.5 CA、PKI及信任CA

CA(Certificate Authority)是數(shù)字證書認(rèn)證中心，常稱為證書頒發(fā)機(jī)構(gòu)。

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

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

過程如下圖。

?

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

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

根CA是通過自簽署數(shù)字證書的方式標(biāo)榜自己的可信性和合法性，第一級(jí)子CA由根CA頒發(fā)合法數(shù)字證書，第二級(jí)直至所有的子CA都由上一級(jí)子CA頒發(fā)數(shù)字證書。對(duì)于多級(jí)子CA只需要信任根CA即可，因?yàn)楂@取了根CA的公鑰，可以解密第一級(jí)子CA的證書并獲取驗(yàn)證第一級(jí)子CA的公鑰，層層遞進(jìn)，最終獲取到為申請(qǐng)者頒發(fā)數(shù)字證書的機(jī)構(gòu)并獲取它的公鑰。

正是這些根CA和子CA組成了PKI（公鑰基礎(chǔ)設(shè)施）

信任CA后，每次接收到需要解密的數(shù)字證書時(shí)，還要去該頒發(fā)機(jī)構(gòu)指定網(wǎng)站的證書吊銷列表（CRL）中查詢?cè)撟C書是否被吊銷，對(duì)于吊銷后的證書應(yīng)該不予以信任，這是信任CA的第二個(gè)作用。導(dǎo)致證書被吊銷的可能性不少，例如申請(qǐng)者的私鑰被黑客獲取，申請(qǐng)者申請(qǐng)吊銷等。

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

?

1.6 數(shù)字證書類型和內(nèi)容

PKI的兩種實(shí)現(xiàn)方式TLS和SSL使用的證書格式都是x509，TLSv1和SSLv3基本等價(jià)，只不過SSL實(shí)現(xiàn)在OSI 4層模型中的應(yīng)用層和傳輸層的中間，TLS實(shí)現(xiàn)在傳輸層。

還有PKI的另一種實(shí)現(xiàn)方式GPG，它的證書使用的不是x509格式。

數(shù)字證書中包含的信息有：申請(qǐng)者的公鑰，證書有效期，證書合法擁有人，證書如何被使用，CA的信息，CA對(duì)申請(qǐng)者信息的數(shù)字簽名。

?

1.7 SSL握手機(jī)制

有了CA頒發(fā)的數(shù)字證書后，通信機(jī)制就和下圖的機(jī)制完全不同了

?

上圖中每一段數(shù)據(jù)都簽名加密，有了數(shù)字證書后實(shí)際上已經(jīng)驗(yàn)證了身份，不需要每一段數(shù)據(jù)都簽名，這能提升效率。

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

不多余，因?yàn)?strong>SSL的握手機(jī)制和數(shù)字簽名機(jī)制完全不同。

以下是單向驗(yàn)證機(jī)制，只驗(yàn)證服務(wù)端:

?

第一步：Visitor給出協(xié)議版本號(hào)、一個(gè)客戶端隨機(jī)數(shù)（Client random），以及客戶端支持的加密方法。

第二步：Server確認(rèn)雙方使用的加密方法，以及一個(gè)服務(wù)器生成的隨機(jī)數(shù)（Server random）。

第三步：Server發(fā)送數(shù)字證書給Visitor。

第四步：Visitor確認(rèn)數(shù)字證書有效（查看證書狀態(tài)且查詢證書吊銷列表），并使用信任的CA的公鑰解密數(shù)字證書獲得Server的公鑰，然后生成一個(gè)新的46字節(jié)隨機(jī)數(shù)（稱為預(yù)備主密鑰Pre-master secret），并使用Server的公鑰加密預(yù)備主密鑰發(fā)給Server（這一過程為非對(duì)稱加密）。

第五步：Server使用自己的私鑰，解密Visitor發(fā)來的預(yù)備主密鑰。

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

第七步：在雙方驗(yàn)證完session key的有效性之后，SSL握手機(jī)制就算結(jié)束了。之后所有的數(shù)據(jù)只需要使用“對(duì)話密鑰”加密即可，不再需要多余的加密機(jī)制。

?

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

握手階段分成五步：?

第一步，客戶端client給出協(xié)議版本號(hào)、一個(gè)客戶端生成的隨機(jī)數(shù)（Client random），以及客戶端支持的加密方法。

第二步，服務(wù)端server確認(rèn)雙方使用的加密方法，并給出數(shù)字證書、以及一個(gè)服務(wù)器生成的隨機(jī)數(shù)（Server random）。

第三步，客戶端client確認(rèn)數(shù)字證書有效，然后生成一個(gè)新的隨機(jī)數(shù)（Premaster secret），并使用數(shù)字證書中的公鑰，加密這個(gè)隨機(jī)數(shù)，發(fā)給服務(wù)端server。

第四步，服務(wù)端server使用自己的私鑰，獲取客戶端client發(fā)來的隨機(jī)數(shù)（即Premaster secret）。

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

?注意：

1）生成對(duì)話密鑰一共需要三個(gè)隨機(jī)數(shù)。

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

3）服務(wù)器公鑰放在服務(wù)器的數(shù)字證書之中。

?從上面第二點(diǎn)可知，整個(gè)對(duì)話過程中（握手階段和其后的對(duì)話），服務(wù)器的公鑰和私鑰只需要用到一次

?

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

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

?注意：

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

Server和Visitor通信，Server把數(shù)字證書發(fā)給Visitor，最關(guān)鍵的一點(diǎn)是Visitor要保證證書的有效性，通過查看證書狀態(tài)并去CA的吊銷列表查看Server的證書是否被吊銷。只有Server的證書可用了，才保證了第一環(huán)節(jié)的安全性。

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

??

轉(zhuǎn)載于:https://www.cnblogs.com/wyzhou/p/9738923.html

與50位技術(shù)專家面對(duì)面20年技術(shù)見證，附贈(zèng)技術(shù)全景圖

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。