DTLS協議中client/server的認證過程和密鑰協商過程

1.DTLS介紹

1.1 DTLS的做用

互聯網先驅們最開始在設計互聯網協議時主要考慮的是可用性，安全性是沒有考慮在其中的，因此傳輸層的TCP、UDP協議自己都不具有安全性。SSL/TLS協議是基於TCP socket，利用加密、基於數字證書的身份驗證等機制在傳輸層和應用層之間構建了一個端到端的安全通道，保證了傳輸數據的加密性。
可是SSL/TLS協議並不能用於UDP協議，而UDP也有安全傳輸的需求，因而產生了DTLS協議（Datagram TLS）。
即DTLS的做用爲給UDP提供端到端的安全通道，就像SSL/TLS對TCP的做用同樣。而且DTLS儘量參考了SSL/TLS協議的安全機制，在具體實現上覆用了70%的TLS代碼。

1.2 DTLS的特色

UDP協議是不面向鏈接的不可靠協議，且沒有對傳輸的報文段進行加密，不能保證通訊雙方的身份認證、消息傳輸過程當中的按序接收、不丟失和加密傳送。
而DTLS協議在UDP提供的socket之上實現了客戶機與服務器雙方的握手鍊接，而且在握手過程當中經過使用PSK或ECC實現了加密，而且利用cookie驗證機制和證書實現了通訊雙方的身份認證，而且用在報文段頭部加上序號，緩存亂序到達的報文段和重傳機制實現了可靠傳送。
在握手完成後，通訊雙方就能夠利用握手階段協商好的會話密鑰來對應用數據進行加解密。

1.3 DTLS協議層次

DLTS協議分爲兩層，下層爲記錄層（record層），record包的內容分爲頭部和載荷兩部分。record包的載荷即爲上層的內容。DTLS上層的包的類型分爲三種，分別是握手消息，警告消息，應用數據；如圖一所示。

圖一.DTLS協議的層次

在整個DTLS協議的通訊過程當中，通訊雙方構造報文段的過程都是先產生上層的載荷消息（如握手消息，應用數據，警告消息），而後添加頭部，構成完整的上層消息。接着再以此做爲記錄層的載荷，最後添加記錄層的頭部，構成完整的記錄報文段，最後調用UDP的socket接口，發送給另外一方。
加密過程是隻對記錄層的載荷(即上層消息，此協議中被加密的消息是finished消息和應用數據兩種)進行加密，因此接收方在收到記錄消息後，首先要作的也是判斷記錄消息是否被髮送方加密，如果，則應先解密才能讀取出明文數據以進行後面的處理。

2.client/server創建DTLS鏈接的握手過程

2.1 整個握手階段的交互過程

DTLS的傳輸階段分爲兩個：握手階段和握手創建以後的傳輸應用數據階段。
DTLS的握手階段以下圖二所示：

圖二.DTLS協議客戶機與服務器握手階段的交互過程

客戶機向服務器發起鏈接，服務器能夠根據配置選擇是否驗證客戶機的cookie和證書（便是否向客戶機發送client_hello_verify和certificate_request報文段）。

2.2 DTLS的cookie驗證機制

因爲DTLS是基於UDP的，因此可能會遭受兩種形式的拒絕服務攻擊。一種是相似於對TCP的資源消耗攻擊，另外一種是放大攻擊，即惡意攻擊者仿造被攻擊者的IP地址發通訊初始化報文段給服務器，而服務器會返回一個體積大不少的證書給被攻擊者，超大量證書有可能形成被攻擊者的癱瘓。
cookie機制要求客戶機重複發送服務器以前發送的cookie值來驗證通訊方的源IP地址確實能夠通訊，由此能夠減小拒絕服務攻擊的危害。
cookie驗證身份的具體機制爲：
協議規定客戶機發送的第一個報文段client_hello中含有cookie的值這一項（有可能爲空）。服務器檢驗收到的該報文段中的cookie值，若是cookie爲空，則說明以前沒創建過鏈接，服務器根據客戶機的源IP地址經過哈希方法隨機生成一個cookie，並填入client_hello_verify中發送給客戶機。
客戶機再在第二次發送的client_hello報文段中填入服務器以前發過來的cookie，服務器第二次收到該報文段以後便檢驗報文段裏面的cookie值和服務器以前發給該主機的cookie值是否徹底相同，如果，則經過cookie驗證，繼續進行握手鍊接；若不是，則拒絕創建鏈接。

2.3 client_hello報文段和server_hello報文段的內容

client_hello報文段的內容除cookie外，還有客戶機產生的32字節的隨機數，其中前4字節爲時間戳，後28字節爲系統產生的隨機數。此外，該報文段的內容還有客戶機支持的加密方式（PSK或者ECC）和壓縮方式，供服務器進行選擇。
在經過cookie校驗後，服務器發送server_hello報文段給客戶機。該報文段包含有服務器產生的32字節的隨機數，和服務器選中的用來進行以後的會話的加密方式和壓縮方式。

2.4 certificate報文段的內容

在服務器發給客戶機的證書報文段中，包含有服務器證書的公鑰；客戶機接收到該報文段後，按照協議規定，從報文段的對應位置中讀取出服務器證書的公鑰存入相關變量中。

2.5 基於ECC加密方式的ECDH祕鑰交換協議和ECDSA數字簽名算法

若協議所選加密方式爲ECC（橢圓曲線加密），則在server_key_exchange報文段的構造過程當中會使用ECDH（橢圓曲線祕鑰交換協議）和ECDSA（橢圓曲線數字簽名算法）。ECDH和ECDSA分別是ECC和DH（diffie-hellman）祕鑰交換協議、DSA（數字簽名算法）的結合。
在server_key_exchange報文段中，包含有所選用的橢圓曲線E，階N和基點G的x,y座標，客戶機在收到這個報文段後，進行對應的格式檢驗，並讀取數據，所以服務器和客戶機共同得到約定好的用來進行ECDH祕鑰協商交換協議的參數，從而能夠共同協商出相同的對話祕鑰用於加密以後的會話內容。
同時，爲了防範中間人攻擊，服務器還在server_key_exchange報文段的末尾對整個報文段進行了ECDSA數字簽名。具體簽名過程爲先用client_hello報文段和server_hello報文段中的2個32字節的隨機數做爲函數參數，利用sha256哈希算法對server_key_exchange報文段自己的載荷產生摘要，而後再用服務器的私鑰和sha256哈希算法進行ECDSA數字簽名，獲得簽名結果r和s,並寫入server_key_exchange報文段的末尾。
客戶機在收到server_key_exchange報文段後，先進行各數值項格式的校驗，而後提取出報文段末尾的簽名值r和s。以後，用已經讀取出的服務器的公鑰的x,y座標值來對server_key_exchange報文段進行ECDSA簽名驗證，若結果和報文段中的r和s值一致，則報文段經過驗證。

2.6 基於PSK加密方式的身份認證過程和會話祕鑰產生過程

整個DTLS協議的加密方式可選用ECC或PSK（預共享祕鑰，PreSharedKey）兩種。若爲ECC，則經過ECDH協議來進行通訊雙方的祕鑰協商；若爲PSK，則直接以通訊雙方事先就已經約定好了的祕鑰爲基礎來進行加密通訊。
對於PSK加密通訊來講，驗證對方的通訊身份很是關鍵。因此通訊雙方會在本地存取對方的psk_id（即身份標誌）和psk_id_length（身份標誌長度），經過比較收到的報文段中的psk_id,psk_id_length和本地存儲的是否徹底一致來進行對方身份的驗證。
在整個通訊過程當中，採用PSK與ECC的區別主要體如今server_key_exchange報文段、client_key_exchange報文段的內容不一樣和雙方計算獲得預主祕鑰方式的不一樣。
當採用PSK加密時，server_key_exchange報文段和client_key_exchange報文段的內容分別是服務器與客戶機各自的psk_id和psk_id_length，由此雙方能夠互相知道對方的psk_id和psk_id_length。
以後，雙方都會對收到的報文段進行檢驗，只有psk_id和psk_id_length與本地存儲的徹底一致纔會進行後面的通訊。
當雙方都經過身份驗證後，雙方再各自用相同的函數產生預主祕鑰，而函數的參數包括以前通訊階段中雙方各自產生的32字節的隨機數，由此能夠保證雖然本地存儲的psk祕鑰不變，但每次臨時通訊時的會話祕鑰仍是會一直變化的，從而加強了抗攻擊性。
雙方產生預主祕鑰後，再調用和使用ECC加密的相同方式來產生主祕鑰，即用於以後會話通訊的對稱祕鑰，該過程當中依然會用到雙方產生的32字節的隨機數。
由此，通訊雙方使用PSK加密方式來實現了身份認證和會話祕鑰的產生。

2.7 server_hello_done報文段和client_key_exchange報文段的內容

服務器發送的server_hello_done報文段的載荷部分爲空，只是發給客戶機來做爲標誌，表示服務器當前階段的報文段已經發送完畢。
客戶機在收到server_hello_done報文段後，發送client_key_exchange報文段給服務器，裏面包含了用於祕鑰協商的基點的x,y座標,而且不一樣於server_key_exchange報文段，客戶機並無在報文段的末尾進行ECDSA數字簽名。

2.8 客戶機產生會話祕鑰

以後，客戶機再經過ecdh_pre_master_secret函數來產生用於以後會話的預主祕鑰。其中函數的參數包括客戶機本身的私鑰，和服務器共享的用於ECDH祕鑰協商算法的基點的x,y座標。
產生預主祕鑰後，再根據以前階段客戶機和服務器分別產生的32字節的隨機數產生主祕鑰master_secret，此時主祕鑰爲對稱祕鑰，用於以後會話的加解密。

2.9 change_cipher_spec報文段和finished報文段的內容

客戶機計算出會話祕鑰後，發送change_cipher_spec報文段給服務器，這個報文段的有效載荷爲空，用來做爲標誌通知服務器，表示客戶機已經算出主祕鑰，以後發送的報文段會採用主祕鑰加密。
握手階段中客戶機發送的最後一個報文段爲finished報文段，載荷內容爲MAC值（消息驗證碼），用於給服務器作認證。而且值得注意的是，finished報文段做爲記錄層的載荷部分在發送時已經用上一步產生的會話祕鑰進行加密編碼。

2.10 服務器產生會話祕鑰

服務器在收到客戶機發送過來的finished報文段後，也會和客戶機用ECDH祕鑰協商算法通過相同的流程，調用相同的函數先產生預主祕鑰，再產生主祕鑰。

2.11 握手階段的結束

最後，服務器產生經會話祕鑰加密後的finished報文段給客戶機，標誌整個握手階段的結束。客戶機收到服務器發過來的finished報文段後，即可發送應用數據。而且應用數據會一直用會話祕鑰加密，從而實現了UDP所不具有的安全性。