https 單向雙向認證說明_數位憑證, 數位簽章, SSL(TLS) , SASL

標籤：私密金鑰   版本   sha   組成   加密傳輸   雙向   驗證過   應用程式層   post   

轉自：https 單向雙向認證說明_數位憑證, 數位簽章, SSL(TLS) , SASL

因為項目中要用到TLS +　SASL 來做安全認證層. 所以看了一些網上的資料, 這裡做一個總結.

 1. 首先推薦幾個文章:

 數位憑證: http://www.cnblogs.com/hyddd/archive/2009/01/07/1371292.html 

 數位憑證和SSL: http://www.2cto.com/Article/201203/121534.html 

 數位簽章: http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html 

 

 2. 數位憑證   

 

     2.1 數位憑證和CA的簡介

    數位憑證是一種權威性的電子文檔。它提供了一種在Internet上驗證您身份的方式，其作用類似於司機的駕駛執照或日常生活中的身份證。它是由一個由權 威機構----CA認證授權(Certificate Authority)中心發行的，人們可以在互連網交往中用它來識別對方的身份。當然在數位憑證認證的過程中，認證認證中心（CA）作為權威的、公正的、 可信賴的第三方，其作用是至關重要的。

    CA認證中心是負責簽發，管理，認證數位憑證的機構，是基於國際互連網平台建立的一個公正，權威，可信賴的第三方組織機構。

 

    全球有很多個CA認證中心, 根CA認證中心代表權威, 它可以指派數位憑證(包括下級CA數位憑證 , 使用者數位憑證). 

    CA認證中心的關係圖:

       

    2.2 數位憑證的組成

     數位憑證由CA派發, 包含F認證內容(明文寫明認證的一些資訊,包括派發單位,認證所有人等),  A密碼編譯演算法 , F‘數位簽章(派發該認證的CA的數位簽章) , 所有者的公開金鑰

     這裡要說一下數位簽章的產生過程:

      例如這裡由派發認證的CA產生的數位簽章, 首先, 對認證內容(F)進行hash演算法產生摘要, 使用CA自己的私密金鑰進行RSA加密(或者其他一種非對稱式加密演算法A) , 就產生出了數位簽章(F‘).

    2.3 數位憑證的驗證原理

      數位憑證通過F , A , F‘ 三項來驗證認證的真實性和有效性.

      首先我們要知道下面幾個特點:

      1.數位憑證機制預設, 所有者的私密金鑰是安全的 

      2.根CA的公開金鑰預設認為是合法的, 且是為大多數瀏覽器所知的, 甚至內嵌的. 例如firefox的Cert Manager中就內嵌了已知的根CA的公開金鑰.

      驗證數位憑證(包含驗證‘認證‘和‘持有人‘的真實有效性)的過程: (*******)

       1. 使用派發認證的CA的公開金鑰(可以向CA請求)來對F‘解密得到h1 (hash值)

       2. 對認證內容F進行hash演算法得到h2

       3. 如果h1 == h2 , 那麼認證是真實有效.

       4. 當認證被證明是真實有效, 那麼我們就可以認為數位憑證中包含的公開金鑰, 是認證所有人(申請該認證的使用者或者機構)的真實公開金鑰.

           (從這一點我們可以知道, 其實數位憑證, 就是為了保證公開金鑰的正確性而產生的)

       5. 用此公開金鑰加密一段資訊發送給認證的持有人，如果持有人能發送回（可以是被私密金鑰加密，也可以是明文，沒有關係）被加密的這段資訊的話就證明該持有人擁有該認證對應的私密金鑰，也就是說，該持有人就是該認證的所有者。

 

 

      以上過程(前3步)可以用說明:

        

 

 

      由於一個數位憑證基於上層的數位憑證作驗證，那上層的數位憑證又是否合法呢？？這就會出現一直遞迴上去的現象，事實也是這樣的，驗證一個認證是否合法，需要驗證到他的最頂層的根憑證是否合法！從其他的文章弄來的這幅圖很好地表達了這個思想： 　

 

      

 

 

 

   2.4 數位憑證組成資訊

 

　　1.Certificate(認證)：

　　 (1).Common Name(認證所有人姓名，簡稱CN，其實就是認證的名字，如第一幅圖看到的：ABA.ECOMRoot....)

　　 (2).Version(版本，現在一般是V3了)

　　 (3).Issuer(發證機關)

　　 (4).Validity(有效日期)

　　 (5).Subject(認證資訊，你會發現它和Issuer裡面的內容是一樣的)

　　 (6).Subject‘s Public Key Info(認證所有人公開金鑰，剛才所說的公開金鑰就是這個!)

　　 (7).Extension(擴充資訊)

　　 (8).Certificate Signature Algorithm(公開金鑰加密演算法)、

 　　 以上這幾項就是上面所說的認證內容(F)。　

　　2.Certificate Signature Algorithm:

　　  這是描述認證的密碼編譯演算法，就是上所說的密碼編譯演算法(A)，看它的Fireld Value，一般會寫：PKCS #1 SHA-1 With RSA Encryption

　　3.Certificate Signature Value:

　　　這記錄的是認證被加密後的結果，相當於上面說講的F‘。

 

 

 

 

 

3. ssl(tls)  - 傳輸層安全性通訊協定

    通過第二節的數位憑證說明, 相信大家都可以大致知道數位憑證的作用(保證公開金鑰確實屬於認證所有人)以及驗證的過程.

那麼下面就可以來看SSL如何結合數位憑證進行工作:

    3.1 為何引入SSL

       我們知道, 傳統的加密技術有2個類型, 一個是對稱式加密(例如DES) , 另一個是非對稱式加密(例如RSA). 

其中非對稱式加密中有私密金鑰和公開金鑰的概念, 十分適合驗證特定對象的真實性和唯一性. 但非對稱式加密演算法比較複雜, 速度緩慢 , 也很消耗資源, 因此就不適合大資料量的加密.

而對稱式加密由於兩端同用一組密碼,加密和解密演算法比較簡單, 適合大資料量加密.

      SSL全稱是 Secure Sockets Layer，它是一種間於傳輸層（比如TCP/IP）和應用程式層（比如HTTP）的協議. 它通過"握手協議"和"傳輸協議"來解決傳輸安全的問題.

握手協議是基於非對稱式加密的，而傳輸協議是基於對稱式加密的。根據不同的應用，SSL對認證的要求也是不一樣的，可以是單方認證（比如HTTP, FTP），也可以是雙方認證（比如網上銀行）。通常情況下，伺服器端的認證是一定要具備的，用戶端的認證不是必須的。

    3.2 SSL的握手和傳輸 

下面兩張圖片顯示了SSL握手的過程。

          

                          圖3.2.1  SSL握手，單方伺服器認證 
                   

 

                             圖3.2.2  SSL握手，雙方認證

 

    

       傳輸過程: 在通訊雙方協商出一個對稱金鑰以後，他們用這個密鑰來加密傳輸的資料。同時為每個訊息產生時間戳記，用此密鑰為訊息和相應的時間戳記產生訊息認證碼（MAC）。也就是說，每次發送的內容包括
             Encrypt(message) + MAC(message + timestamp)

 

    這麼做有幾個好處： 
       1.    防止訊息的篡改 
        所謂訊息篡改就是有第三者插在通訊雙方之間，篡改往來的訊息。由於訊息是加密的，第三者不能獲得訊息的內容，但是他可以閉著眼睛瞎改。如果沒有MAC的話，接受者就無法判斷此  訊息是否被篡改過。 
       2.    防止訊息重放 
       訊息的重放是只第三者記錄下通訊雙方的每一次發送的訊息，雖然他不能獲得訊息的內容。但是它可以通過重新發送用戶端或者服務端的資訊來把自己裝成是用戶端或者服務端。如果在MAC裡面加上了時間戳記，訊息接收方驗證時間戳記就可以阻止訊息的重放攻擊。 
SSL的基本思想是用非對稱式加密來建立連結（握手階段），用對稱式加密來傳輸資料（傳輸階段）。這樣既保證了密鑰分發的安全，也保證了通訊的效率。

 

 

 

4. SASL - 簡單認證和安全層 

     SASL是一種用來擴充C/S模式驗證能力的機制認證機制,  全稱Simple Authentication and Security Layer.

     當你設定sasl時，你必須決定兩件事；一是用於交換“標識信 息”（或稱身份認證）的驗證機制；一是決定標識資訊儲存方法的驗證架構。

     sasl驗證機制規範client與server之間的應答過程以及傳輸內容的編碼方法，sasl驗證架構決定伺服器本身如何儲存用戶端的身份認證以及如何核驗用戶端提供的密碼。

     如果用戶端能成功通過驗證，伺服器端就能確定使用者的身份， 並藉此決定使用者具有怎樣的許可權。

 比較常見的機制；

4.1 plain(較常用) 

   plain是最簡單的機制，但同時也是最危險的機制，因為身份認證（登入名稱稱與密碼）是以base64字串格式通過網路，沒有任何加密保護措施。因此，使用plain機制時，你可能會想要結合tls。

4.2 login

   login不是其正式支援的機制，但某些舊版的mua使用這種機制，所以cyrus sasl讓你可選擇其是否支援login機制。如果你的使用者仍在使用這類老掉牙的mua，你必須在編譯sasl函數庫時，指定要包含login的支援。 login的認證交換過程類似plain。

4.3 otp

otp是一種使用“單次密碼”的驗證機制。此機制不提供任何加密保護，因為沒必要－－每個密碼都只能使用一次，每次聯機都要改用新密碼。smto client必須能夠產生otp認證。

4.4 digest-md5(較常用)

   使用這種機制時，client與server共用同一個隱性密碼，而且此密碼不通過網路傳輸。驗證過程是從伺服器先提出challenge（質詢）開始， 用戶端使用此challenge與隱性密碼計算出一個response（應答）。不同的challenge，不可能計算出相同的response；任何擁 有secret password的一方，都可以用相同的challenge算出相同的response。因此，伺服器只要比較用戶端返回的response是否與自己算 出的response相同，就可以知道用戶端所擁有的密碼是否正確。由於真正的密碼並沒有通過網路，所以不怕網路監測。

4.5 kerberos

   kerberos是一種網路型驗證協議。除非你的網路已經使用kerberos，否則你應該用不到kerberos機制；相對的，如果你的網路已經架設了kerberos驗證中心，sasl就能完美的將smtp驗證整合進現有的體系。

4.6 anonymous

   anonymous機制對smtp沒有意義，因為smtp驗證的用意在於限制轉寄服務的使用對象，而不是為了形成open relay，sasl之所以提供這種機制，主要是為了支援其他協議。
當 用戶端連結到一個支援sasl的郵件伺服器時，伺服器會以優先順序列出可用的機制供用戶端選擇。如果用戶端也支援多鐘機制，則當第一種機制驗證失敗時，客戶 端可能會繼續嘗試第二種機制，直到通過驗證或是所有機制都失敗為止。如果雙方在一開始就無法協調出共同的機制，驗證過程就算失敗。
一旦雙方在使用哪種機制上達成共識，就開始進行驗證過程。實際的互動過程隨機制而定，但通常包含一次或多次應答過程。驗證協議本身也規定了應答內容的編碼格式。

 

 

  5. 總結 

       數位憑證, 是級聯認證派發的, 最上層是根CA認證中心. 數位憑證的根本作用, 是為了保證所有人公開金鑰的安全性和真實性. 大致認證過程是: 通過CA的公開金鑰來解出該CA所派發的認證裡面所包含的公開金鑰(使用者或者機構的). 並通過該公開金鑰來驗證認證持有人的真實性. (因為持有人並不一定是認證所有人)

 

       通過上面對SSL的分析，我們可以看到，SSL並不能阻止別人獲得你傳輸的資料，但是由於你傳輸的資料都是加密過的，別人拿到了毫無用處，一樣可以保護信 息的安全。還有一點需要強調一下，SSL並不依賴於TCP，它可以建立在任何可靠的傳輸層協議（比如TCP）之上。也就是說SSL是不能建立在UDP之上 的。這是顯然的，如果傳輸都不可靠，偶爾丟兩個包或者包的順序換一換的話，怎麼保證安全呢？

       SASL是提供一種使用者身份認證機制, 你可以簡單認為是用來認證使用者的帳號/密碼是否運行進入系統或者使用系統的服務. 一般較長使用digest-md5, 該種機制下, 密碼可以不用在網路上傳輸, 也就不用怕密碼被竊聽.

https 單向雙向認證說明_數位憑證, 數位簽章, SSL(TLS) , SASL