資訊與網路安全技術 第 八章 安全性網頁系統  上一頁      下一頁

 

8-5 SSL 握手協定

內容:

  • 8-5-1 SSL 握手協定運作

  • 8-5-2 第一階段:協商安全套件

  • 8-5-3 第二階段:伺服端確認與鑰匙交換

  • 8-5-4 第三階段:客戶端確認與鑰匙交換

  • 8-5-5 第四階段:完成

  • 8-5-6 簡化的協議方式

8-5-1 SSL 握手協定運作

『握手協定』(Handshake Protocol)是整個 SSL 協定的運作核心,客戶端與伺服器之間利用握手協定確認雙方身份,並協議出雙方可接受的安全機制,下列是握手協定的運作程序中,所必須完成工作的步驟:

  • 雙方交換 Hello 訊息,作為協議演算法、交換亂數數值使用,並檢查是否有 Session 可以重複使用。

  • 雙方交換所需的鑰匙材料,並利用這些鑰匙材料製作出『前置主密鑰』(Pre-master Secret)。

  • 雙方交換身份憑證並利用憑證上鑰匙加密訊息,來完成雙方認證對方身分。

  • 利用『前置主秘鑰』與交換亂數值,產生通訊所需的『主密鑰』(Master Secret),一般系統稱之為『會議鑰匙』(Session Key)。

  • 將所建立的安全參數登錄於『會議連結』上,並提供給 SSL 記錄協定執行壓縮、計算 MAC 值、以及加密處理的相關安全參數。

  • 允許客戶端與伺服端證實所建立安全參數是相同的,並且保證在協議當中未受到駭客偽裝攻擊。

8-6 SSL 握手協定的運作程序,利用四個協商階段完成上述的工作,概略說明如下:由客戶端啟動第一階段協商,採用 Hello 訊息來協商所能接受的安全套件,並建立『前置主密鑰』(Pre-master Secret作為保護爾後交換鑰匙的訊息;第二階段與第三階段的功能是,雙方互相認證對方憑證與交換鑰匙材料,並建立『主密鑰』以作為傳輸資料所用;第四階段的功能是,雙方確認所建立的安全套件(主密鑰與 MAC 演算法)無誤之後,依照安全套件與主密鑰計算出相關安全參數,然後啟動變更密文規格協定,並通知對方以完成協議。

8-6 SSL/TLS 握手協定的運作程序

值得注意的是,並非每一個 Session 的安全機制都如同圖 11-6 般的完善,也許會有不同的選擇。譬如,若伺服端不需要認證客戶端的憑證,便不用送出 certificate_request 訊號,客戶端也不會傳送憑證給伺服端。因此,在圖 11-6 中的訊號如果有加上星號(*)記號,表示該訊息是選項項目,需依照安全機制的強度選擇使用,以下分別敘述各階段的運作程序與命令格式。

8-5-2 第一階段:協商安全套件

第一階段裡包含兩個 Hello 訊息(圖 8-3 訊號 (1) 與訊號 (2)),主要用來交換亂數與協議雙方可以接受的安全套件,每一訊息(client_hello server_hello)包含下列參數:

  • 版本(Version): SSL 協定版本,目前為 3

  • 亂數(Random):資料結構為一個 32 位元的時戳與 28 位元的亂數,如 client_hello 訊息內的亂數(28 位元)稱之為 ClientHello.random,然而 server_hello 訊息則稱為 ServerHello.random。此亂數協議『前置主密鑰』使用,或作為交換鑰匙當中預防重送攻擊時使用。

  • 會議識別碼(Session ID):欲建立安全機制的會議識別碼。如果 client_hello 中此參數為零的話,則表示欲建立新的 Session;否則表示欲引用已建立完成 Session 的識別碼。伺服端收到 Client_hello 後,如果此參數為零,便指定一個號碼回應給客戶端(server_hello),表示欲建立新的 Session;如果不是零的話,依照該 Session ID 數值搜尋是否有此 Session 的安全機制,如有便回應同樣的 ID 給客戶端;則回應錯誤訊息。

  • 加密套件(Cipher Suite):客戶端(client_hello)以此參數作為建議所欲採用的交換鑰匙演算法與加密規格,伺服端(server_hello)也用此參數回應可以接受的安全機制。在 SSL/TLS 規格書內已將各種安全套件編號,協商時祇要指定套件號碼即可。但除了協商安全套件之外,還是需要協商該套件之下的加密規格,協商內容接下來就會介紹到。

  • 壓縮方法(Compression Method):列出可以使用的壓縮演算法。但 TLS 規格內並沒有指定壓縮方法(SSL 協定有列出一些方法可供選擇)。

經過第一階段協商之後,必須能協商出雙方可以接受的安全套件與壓縮方法。如果伺服端無法接受客戶端所建議的安全套件時,伺服端會發送 hello_request 訊息,要求客戶端重新建議新的方案。

SSL 規範裡,安全套件可以區分為:『鑰匙交換』(Key Exchange)與『加密規格』(Cipher Specification)兩部份,前者的功能是雙方以交換鑰匙材料方式製作共享的『前置主密鑰』(之後再計算成主密鑰);後者是協商加密系統的相關參數。SSL 鑰匙交換協定是以 RSADiffie-Hellman Fortezza 等三種密碼系統為基礎,其中 Diffie-Hellman 密碼系統又可區分為三種模式;共計有五種協定可供協商,分別敘述如下:

  • RSA利用接收端的 RSA 公開鑰匙來對秘密鑰匙加密。首先客戶端產生一個『前置主密鑰』,並利用伺服端的公開鑰匙加密,然後再傳送給伺服端。

  • 匿名的 Diffie-Hellman利用 Diffie-Hellman 演算法進行交換鑰匙材料,唯計算前置主密鑰的參數是取自雙方自行產生的亂數(鑰匙材料),但容易受到中間人攻擊。

  • 固定的 Diffie-Hellman利用 Diffie-Hellman 演算法進行鑰匙交換,但計算前置主密鑰的參數是取自雙方公開鑰匙憑證(X.509v3)上所簽署的亂數來產生。

  • 暫時的 Diffie-Hellman建立只使用一次的秘密鑰匙,其建立方法是,首先傳送端利用私有 RSA 鑰匙或 DSS 鑰匙來交換與簽署 Diffie-Hellman 公開鑰匙;接收端則利用對應的公開鑰匙確認這個簽署,並且雙方可藉由憑證彼此確認公開鑰匙。雙方安全的交換參數後,再依照 Diffie_Hellman 驗算法計算出前置主密鑰,此方法也是三種方法中最安全的。

  • FortezzaFortezza 密碼系統。本書未介紹,有興趣讀者請參考 SSL v3 協定規格。

除了協議鑰匙交換協定之外,在 Hello 訊息內也包含加密規格可供雙方協議使用,加密規格有下列協商項目:

  • 加密演算法(Cipher Algorithm):可選用 RC4RC2DES3DESDES40IDEA Fortezza 等加密系統。

  • MAC 演算法(MAC Algorithm):MD5 SHA-1 演算法。

  • 密文型態(Cipher Type):串流加密(Stream Cipher)或區塊加密(Block Cipher)。

  • 可否出口(Is Exportable):表示該套件是否允許出口;True False

  • 雜湊碼大小(Hash Size):016MD5)或 20SHA-1)個位元組。

  • 鑰匙材料(Key Material):一連串的二進位數值(亂數),用來產生鑰匙。

  • 起始值大小(IV Size:密文區段串接(CBC)加密演算法的起始值大小。

8-5-3 第二階段:伺服器確認與鑰匙交換

經過第一階段協商後,雙方已協議出鑰匙交換協定與加密套件,第二階段利用協議出的鑰匙交換協定,互相交換雙方的鑰匙材料,並從事伺服端身份的確認,運作程序如圖 8-3 中訊號 (3) ~ (6)。如果第一階段協議當中需要伺服端憑證時,伺服端會傳送自己的憑證資料(X.509v3)給客戶端。譬如,採用固定的 Diffie-Hellman 演算法時,便需要伺服端的憑證,這是因為憑證中有簽署過的鑰匙材料(亂數)。接著,是否需要傳送 server_key_exchange 訊息的條件,完全決定於第一階段所協議的安全套件,一般若無需交換訊息建立秘密鑰匙,就不需要此訊息,如匿名的 Diffie-Hellman 演算法,因為用來計算秘密鑰匙的亂數是固定數值,所以不需要雙方交換亂數;或者是採用 RSA 鑰匙交換。

接下來,certificate_request 訊息也是選項項目,如果雙方協議的安全套件需要認證客戶端,或者需要客戶憑證上所簽署的亂數時,可發送此訊息要求客戶端傳送憑證資料。最後伺服端以 server_done 表示已完成相關訊息的傳送,之後伺服端就進入等待狀態,預備接收客戶端的安全訊息。

8-5-4 第三階段:客戶端確認與鑰匙交換

當客戶端受到 sever_done 訊息後便進入第三階段的協商(圖 11-6 (7) ~ (9))。如果安全套件裡需要客戶端的憑證時,則客戶端會傳送憑證相關訊息給伺服端(certificate),接下來的『客戶鑰匙交換』(client_key_exchange)訊息是不可以或缺的,但內容是隨鑰匙交換協定而異:

  • RSA客戶端產生一個 48 位元組的『前置主秘鑰』(Pre-master Secret),並以伺服端的公開鑰匙加密,或是用 server_key_exchange 中的臨時 RSA 鑰匙來加密,再將加密後的前置主秘鑰包裝於 client_key_exchange 訊息內。

  • 暫時或匿名的 Diffie_Hellman將客戶端公開的 Diffie-Hellman 參數包裝於此訊息內。

  • 固定的 Diffie-Hellman客戶端公開的 Diffie-Hellman 參數被包裝於憑證之中,因此,此訊息並未承載任何資訊。

  • Fortezza此訊息攜帶客戶端的 Fortezza 參數。

最後,如果客戶端有傳送憑證給伺服端,則必須送出『憑證驗證』(certificate_verify訊息,來驗證客戶端憑證。此訊息內攜帶著客戶端憑證內資料的雜湊值,並經過客戶端私有鑰匙簽署過。伺服端利用相對應的公開鑰匙將此簽章解密,並驗證所接收憑證資料的雜湊值是否與 certificate_verify 內的雜湊值相同。

8-5-5 第四階段:完成

雙方協商完成之後,亦即已完成建立一個會議(Session連結。如圖 11-6 (10) ~(13) 所示,客戶端送出『變更密文規格』訊息來要求伺服端正式改變安全協定,此訊息並非握手協定所有,而是利用密文變更規格協定來完成;相同的,伺服端也會發送此訊息給客戶端。收到變更密文規格訊號之後,雙方會將新的安全機制複製到現有的加密規格內。另外,『完成』(finished訊息就較為複雜,除了驗證雙方協議是否成功之外,還必須完成下列安全參數設定:(產生方式容後介紹)

  • Client write MAC secret客戶端產生 MAC 碼的密鑰。

  • Server write MAC secret伺服端產生 MAC 碼的密鑰。

  • Client write key客戶端加密傳輸訊息的鑰匙。

  • Server write key伺服端加密傳輸訊息的鑰匙。

  • Client write IV客戶端起始向量,僅使用於區塊加密法。

  • Server write IV伺服端起始向量,僅使用於區塊加密法。

值得注意的是,雖然客戶端與伺服端所使用的加密鑰匙、MAC 鑰匙與起始向量並不相同,但雙方都擁有這些安全參數,祇不過各自採用不同的安全參數來增加破解的困難度。例如,當伺服端收到客戶端所傳送的加密訊息,則利用客戶端的加密鑰匙來解密,反之亦然;如果攻擊者破解出客戶端的加密鑰匙,無法知曉伺服端的加密鑰匙。

8-5-6 簡化的協議方式

並非每一次 SSL 連線都需要經由上述四個階段的協商過程,始能建立雙方的安全機制。記得前面說過,一個已協商成功的安全機制稱之為『會議』(Session)連結,並且給予一個唯一的識別碼,稱為 Session ID,此外,當新的連線啟動時,也可以引用已協商完成的 Session。如圖 8-7 所示,客戶端啟動握手協定時,在 client_hello 訊息內指定使用哪一個 Session ID 的安全機制,只要伺服端同意,並將該 Session ID 置於 server_hello 訊息內,雙方便成功協議使用該 Session ID。接下來,便可直接用 change_cipher_spec 來啟動新的安全機制。

8-7 簡化的握手協定

主講人:粘添壽博士

 

資訊與網路安全技術