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包的內容分爲頭部和載荷兩部分。記錄包的載荷即爲上層的內容。DTLS上層的包的類型分爲三種，分別是握手消息，警告消息，應用數據；如圖一所示。
圖一.DTLS協議的層次
在整個DTLS協議的通信過程中，通信雙方構造報文段的過程都是先產生上層的載荷消息（如握手消息，應用數據，警告消息），然後添加頭部，構成完整的上層消息。接着再以此作爲記錄層的載荷，最後添加記錄層的頭部，構成完整的記錄報文段，最後調用UDP的socket接口，發送給另一方。
加密過程是隻對記錄層的載荷(即上層消息，此協議中被加密的消息是finished消息和應用數據兩種)進行加密，所以接收方在收到記錄消息後，首先要做的也是判斷記錄消息是否被髮送方加密，若是，則應先解密才能讀取出明文數據以進行後面的處理。
2.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所不具備的安全性。