【上】安全HTTPS-全面詳解對稱加密,非對稱加密,數字簽名,數字證書和HTTPS

一,對稱加密

所謂對稱加密,就是它們在編碼時使用的密鑰e和解碼時一樣d(e=d),我們就將其統稱爲密鑰k。

 

對稱加解密的過程如下:

發送端和接收端首先要共享相同的密鑰k(即通信前雙方都需要知道對應的密鑰)才能進行通信。發送端用共享密鑰k對明文p進行加密,得到密文c,並將得到的密文發送給接收端,接收端收到密文後,並用其相同的共享密鑰k對密文進行解密,得出明文p。

 

一般加密和解密的算法是公開的,需要保持隱祕的是密鑰k,流行的對稱加密算法有:DES,Triple-DES,RC2和RC4

 

對稱加密的不足主要有兩點:

1,  發送方和接收方首先需要共享相同的密鑰,即存在密鑰k的分發問題,如何安全的把共享密鑰在雙方進行分享,這本身也是一個如何安全通信的問題,一種方法是提前雙方約定好,不通過具體的通信進行協商,避免被監聽和截獲。另外一種方式,將是下面我們介紹的通過非對稱加密信道進行對稱密碼的分發和共享,即混合加密系統。

2,  密鑰管理的複雜度問題。由於對稱加密的密鑰是一對一的使用方式,若一方要跟n方通信,則需要維護n對密鑰。

 

對稱加密的好處是:

加密和解密的速度要比非對稱加密快很多,因此常用非對稱加密建立的安全信道進行共享密鑰的分享,完成後,具體的加解密則使用對稱加密。即混合加密系統。

 

另外一個點需要重點說明的是,密鑰k的長度對解密破解的難度有很重大的影響,k的長度越長,對應的密碼空間就越大,遭到暴力破解或者詞典破解的難度就更大,就更加安全。

 

二,非對稱加密

所謂非對稱加密技術是指加密的密鑰e和解密的密鑰d是不同的(e!=d),並且加密的密鑰e是公開的,叫做公鑰,而解密的密鑰d是保密的,叫私鑰。

 

非對稱加解密的過程如下:

加密一方找到接收方的公鑰e (如何找到呢?大部分的公鑰查找工作實際上都是通過數字證書來實現的),然後用公鑰e對明文p進行加密後得到密文c,並將得到的密文發送給接收方,接收方收到密文後,用自己保留的私鑰d進行解密,得到明文p,需要注意的是:用公鑰加密的密文,只有擁有私鑰的一方纔能解密,這樣就可以解決加密的各方可以統一使用一個公鑰即可。

 

常用的非對稱加密算法有:RSA

 

非對稱加密的優點是:

1,  不存在密鑰分發的問題,解碼方可以自己生成密鑰對,一個做私鑰存起來,另外一個作爲公鑰進行發佈。

2,  解決了密鑰管理的複雜度問題,多個加密方都可以使用一個已知的公鑰進行加密,但只有擁有私鑰的一方纔能解密。

  非對稱加密不足的地方是加解密的速度沒有對稱加密快。

 

綜上,分析了對稱加密和非對稱加密各自的優缺點後,有沒有一種辦法是可以利用兩者的優點但避開對應的缺點呢?答應是有的,實際上用得最多的是混合加密系統,比如在兩個節點間通過便捷的公開密碼加密技術建立起安全通信,然後再用安全的通信產生併發送臨時的隨機對稱密鑰,通過更快的對稱加密技術對剩餘的數據進行加密。

 

三,數字簽名

上面討論了非對稱加密技術在編碼中的使用,解決的是傳送數據的私密性,一般是用公鑰作爲加密key,而私鑰作爲解密key,那假如是用私鑰作爲加密key,而公鑰作爲解密key呢?

由於私鑰只有對應一方纔知道,因此若通過對應的公鑰可以驗證對方是用對應的私鑰進行加密的,則可以說明對方的身份,這就是數字簽名。

 

數字簽名需要解決的兩個任務是:

1,  誰編寫的報文;

2,  報文的內容是否被篡改過;

 

數字簽名的過程一般如下:

1,  發送方A首先對變長的報文提取成一個定長的摘要,一般是md5等

2,  A對摘要應用了一個簽名函數,並且用A自己的私鑰作爲參數,因爲只有A才知道私鑰,所以正確的簽名會說明簽名者就是其所有者。

3,  一旦計算出簽名,節點A就將其附加到報文的末尾,並將報文和簽名一起都發送給B

4,  在接收端B,首先會按照同樣的算法計算出報文的摘要,然後對簽名用A的公鑰進行解碼,得出解碼後的摘要,兩個摘要進行比較,則可以判斷是否是A發送的且內容沒被篡改過。

 

四,數字證書

實際上,好多的公鑰都是通過數字證書進行發佈的,數字證書類似一個人的身份證一樣,由對應的官方的頒發結構頒發的,類似一個人的身份證有姓名,身份證ID,有效期,頒發機構-一般是某某派出所等,數字證書也有類似的形式。

 

基本的數字證書包括了一些常見的信息:

1, 對象的名稱(人,服務器,組織等)

2, 過期時間

3, 對象的公鑰

4, 證書發佈者(由誰爲證書擔保)

5, 來自證書發佈者的數字簽名。

需要注意的是,任何人都可以創建一個證書,但不是所有人都能夠獲得受人尊敬的簽發權從而爲證書信息提供擔保,並用其私人密鑰簽發證書。

不幸的是,數字證書沒有單一的全球標準,但現在使用的大多數證書是以一種標準格式– X.509 v3,來存儲它們的信息。

 

x.509證書格式:

字段

描述

版本號

這個證書的X.509證書版本號,現在通常是版本3

序列號

證書頒發機構CA生成的唯一整數,CA生成的每個證書都要有一個唯一的系列號,類似身份證號碼

簽名算法ID

簽名使用是算法,如用RSA加密的MD2摘要

證書頒發者

以X.500格式說明的CA的組織名稱

有效期

證書的有效期,由一個起始日期和一個結束日期來表示

對象名稱

證書中描述的實體,比如一個人或者一個組織,對象名稱以x.500格式表示

對象的公開密鑰信息

證書對象的公鑰,公鑰使用的算法,以及所有附加的參數

發佈者唯一的ID(可選)

可選的證書發佈者唯一ID,這樣可以重用相同的發佈者名稱了

對象唯一的ID(可選)

可選的證書對象唯一ID,這樣就可以重用相同的對象名稱了

擴展

一些擴展信息

證書的頒發機構簽名

CA用指定的簽名算法對上述所有字段的數字簽名

 

x.509證書有很多種,如服務器端證書,個人證書等。

瀏覽器中的證書:

 

 



 

注意:每個證書均有對應於證書公鑰的私鑰,私鑰不能被導出,訪問一般需要密碼等。

 

瀏覽器會默認存儲一些受信任的根證書頒發機構的證書,從圖中可以看,這些證書都是頒發者頒發給自己的。

 

 

五,用服務器證書對服務進行認證

在支付網站中,用戶需要確認他們輸入支付密碼的站點是真正的經過認證的站點,而不是被釣魚的網站,因此用戶有必要認證對應的服務器,而這種方式是通過服務器證書來進行的。過程大概如下:

1, 通過https建立一個安全web事務之後,瀏覽器會自動獲取所連服務器的數字證書;

其中服務器證書包括了:

        Web站點名稱和主機名

        Web站點的公鑰;

        頒發機構的名稱;

        頒發機構給證書的簽名;

2,  若服務器沒有證書,則安全連接失敗。

3,  瀏覽器首先檢查服務器證書是否還在有效期內,若過期,則提示失效;

4,  瀏覽器查看服務器證書對應的CA,若該CA是很權威的機構,則瀏覽器可能已經知道了對應的公鑰了(瀏覽器會預先安裝很多簽名頒發機構的證書並認爲是受信任的),這時,瀏覽器用CA的數字證書裏面的公鑰來驗證該CA頒發的服務器證書的有效性。類似去公安局驗證某人的身份證是否是真的。

5,則瀏覽器對簽名頒發機構CA一無所知,瀏覽器無法確定是否該信任這個簽名頒發機構,它通常會向用戶提示一個對話框,看看他是否相信這個簽名發佈者。

5,  一旦完成了對服務器證書的驗證,接下來就可以使用服務器證書裏面的公鑰進行服務器身份的驗證;

6,  客戶端生成一個隨機數給到服務器,要求對應的服務用對應服務器證書是私鑰進行簽名。

7,  服務器對隨機數進行簽名,並回傳給到客戶端。

8,  客戶端用服務器證書的公鑰對隨機數的簽名進行驗證,若驗證通過,則說明對應的服務器確實擁有對應服務器證書的私鑰,因此判斷服務器的身份正常。否則,則任務服務器身份被僞造。

 

六,用客戶端證書對客戶端進行認證

客戶端證書和服務器證書類似,只是服務器證書增加一些對服務器站點名稱和主機名等內容的簽註,客戶端證書一般是某個機構針對個人頒發的,用於標識個人的身份。如財付通提示用戶安裝對應的數字證書,就是一個客戶端證書,在安裝客戶端證書的時候,實際上會把用戶對應該證書的私鑰要保存起來。客戶端用私鑰進行簽名,然後第三方用客戶端證書的公鑰進行驗籤實現對客戶端身份的認證。

 

七,HTTPS的雙向認證,則需要客戶端和服務器交換證書。

在發送已加密的HTTP報文前,客戶端和服務器要進行一次SSL握手,在這個握手的過程中,它們要完成以下工作:

1,  交換協議版本號;

2,  選擇一個兩端都瞭解的密碼;

3,  對兩端的身份進行驗證;

4,  生成臨時的會話密鑰,後續便用該密鑰進行加密信道。

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章