DTLS協(xié)議詳解

1.DTLS介紹

1.1 DTLS的作用

互聯(lián)網(wǎng)先驅(qū)們最開始在設計互聯(lián)網(wǎng)協(xié)議時主要考慮的是可用性，安全性是沒有考慮在其中的，所以傳輸層的TCP、UDP協(xié)議本身都不具備安全性。SSL/TLS協(xié)議是基于TCP socket，在傳輸層和應用層之間構建了一個端到端的安全通道，保證了傳輸數(shù)據(jù)的加密性。

但是SSL/TLS協(xié)議并不能用于UDP協(xié)議，而UDP也有安全傳輸?shù)男枨螅谑钱a(chǎn)生了DTLS協(xié)議（Datagram TLS）。

即DTLS的作用為給UDP提供端到端的安全通道，就像SSL/TLS對TCP的作用一樣。并且DTLS盡可能參考了SSL/TLS協(xié)議的安全機制，在具體實現(xiàn)上復用了70%的TLS代碼。

1.2 DTLS的特點

UDP協(xié)議是不面向連接的不可靠協(xié)議，且沒有對傳輸?shù)膱笪亩芜M行加密，不能保證通信雙方的身份認證、消息傳輸過程中的按序接收、不丟失和加密傳送。

而DTLS協(xié)議在UDP提供的socket之上實現(xiàn)了客戶機與服務器雙方的握手連接，并且在握手過程中通過使用PSK或ECC實現(xiàn)了加密，并且利用cookie驗證機制和證書實現(xiàn)了通信雙方的身份認證，并且用在報文段頭部加上序號，緩存亂序到達的報文段和重傳機制實現(xiàn)了可靠傳送。

在握手完成后，通信雙方就可以實現(xiàn)應用數(shù)據(jù)的安全加密和可靠傳輸。

1.3 DTLS協(xié)議層次

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

                                                                  圖一.DTLS協(xié)議的層次

在整個DTLS協(xié)議的通信過程中，通信雙方構造報文段的過程都是先產(chǎn)生上層的載荷消息（如握手消息，應用數(shù)據(jù)，警告消息），然后添加頭部，構成完整的上層消息。接著再以此作為記錄層的載荷，最后添加記錄層的頭部，構成完整的記錄報文段，最后調(diào)用UDP的socket接口，發(fā)送給另一方。

加密過程是只對記錄層的載荷(即上層消息，此協(xié)議中被加密的消息是finished消息和應用數(shù)據(jù)兩種)進行加密，所以接收方在收到記錄消息后，首先要做的也是判斷記錄消息是否被發(fā)送方加密，若是，則應先解密才能讀取出明文數(shù)據(jù)以進行后面的處理。

2.DTLS傳輸階段

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

DTLS的傳輸階段分為兩個：握手階段和握手建立之后的傳輸應用數(shù)據(jù)階段。

DTLS的握手階段如下圖二所示：

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

客戶機向服務器發(fā)起連接，服務器可以根據(jù)配置選擇是否驗證客戶機的cookie和證書（即是否向客戶機發(fā)送client_hello_verify和certificate_request報文段）。

2.2 DTLS的cookie驗證機制

由于DTLS是基于UDP的，所以可能會遭受兩種形式的拒絕服務***。一種是類似于對TCP的資源消耗***，另一種是放大***，即惡意***者仿造被***者的IP地址發(fā)通信初始化報文段給服務器，而服務器會返回一個體積大很多的證書給被***者，超大量證書有可能造成被***者的癱瘓。

cookie機制要求客戶機重復發(fā)送服務器之前發(fā)送的cookie值來驗證通信方的源IP地址確實可以通信，由此可以減少拒絕服務***的危害。

cookie驗證身份的具體機制為：

協(xié)議規(guī)定客戶機發(fā)送的第一個報文段client_hello中含有cookie的值這一項（有可能為空）。服務器檢驗收到的該報文段中的cookie值，如果cookie為空，則說明之前沒建立過連接，服務器根據(jù)客戶機的源IP地址通過哈希方法隨機生成一個cookie，并填入client_hello_verify中發(fā)送給客戶機。

客戶機再在第二次發(fā)送的client_hello報文段中填入服務器之前發(fā)過來的cookie，服務器第二次收到該報文段之后便檢驗報文段里面的cookie值和服務器之前發(fā)給該主機的cookie值是否完全相同，若是，則通過cookie驗證，繼續(xù)進行握手連接；若不是，則拒絕建立連接。

2.3 client_hello報文段和server_hello報文段的內(nèi)容

client_hello報文段的內(nèi)容除cookie外，還有客戶機產(chǎn)生的32字節(jié)的隨機數(shù)，其中前4字節(jié)為時間戳，后28字節(jié)為系統(tǒng)產(chǎn)生的隨機數(shù)。此外，該報文段的內(nèi)容還有客戶機支持的加密方式（PSK或者ECC）和壓縮方式，供服務器進行選擇。

在通過cookie校驗后，服務器發(fā)送server_hello報文段給客戶機。該報文段包含有服務器產(chǎn)生的32字節(jié)的隨機數(shù)，和服務器選中的用來進行之后的會話的加密方式和壓縮方式。

2.4 certificate報文段的內(nèi)容

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

2.5 基于ECC加密方式的ECDH秘鑰交換協(xié)議和ECDSA數(shù)字簽名算法

若協(xié)議所選加密方式為ECC（橢圓曲線加密），則在server_key_exchange報文段的構造過程中會使用ECDH（橢圓曲線秘鑰交換協(xié)議）和ECDSA（橢圓曲線數(shù)字簽名算法）。ECDH和ECDSA分別是ECC和DH（diffie-hellman）秘鑰交換協(xié)議、DSA（數(shù)字簽名算法）的結合。

在server_key_exchange報文段中，包含有所選用的橢圓曲線E，階N和基點G的x,y坐標，客戶機在收到這個報文段后，進行對應的格式檢驗，并讀取數(shù)據(jù)，因此服務器和客戶機共同獲得約定好的用來進行ECDH秘鑰協(xié)商交換協(xié)議的參數(shù)，從而可以共同協(xié)商出相同的對話秘鑰用于加密之后的會話內(nèi)容。

同時，為了防范中間人***，服務器還在server_key_exchange報文段的末尾對整個報文段進行了ECDSA數(shù)字簽名。具體簽名過程為先用client_hello報文段和server_hello報文段中的2個32字節(jié)的隨機數(shù)作為函數(shù)參數(shù)，利用sha256哈希算法對server_key_exchange報文段本身的載荷產(chǎn)生摘要，然后再用服務器的私鑰和sha256哈希算法進行ECDSA數(shù)字簽名，得到簽名結果r和s,并寫入server_key_exchange報文段的末尾。

客戶機在收到server_key_exchange報文段后，先進行各數(shù)值項格式的校驗，然后提取出報文段末尾的簽名值r和s。之后，用已經(jīng)讀取出的服務器的公鑰的x,y坐標值來對server_key_exchange報文段進行ECDSA簽名驗證，若結果和報文段中的r和s值一致，則報文段通過驗證。

2.6 基于PSK加密方式的身份認證過程和會話秘鑰產(chǎn)生過程

整個DTLS協(xié)議的加密方式可選用ECC或PSK（預共享秘鑰，PreSharedKey）兩種。若為ECC，則通過ECDH協(xié)議來進行通信雙方的秘鑰協(xié)商；若為PSK，則直接以通信雙方事先就已經(jīng)約定好了的秘鑰為基礎來進行加密通信。

對于PSK加密通信來說，驗證對方的通信身份非常關鍵。所以通信雙方會在本地存取對方的psk_id（即身份標志）和psk_id_length（身份標志長度），通過比較收到的報文段中的psk_id,psk_id_length和本地存儲的是否完全一致來進行對方身份的驗證。

在整個通信過程中，采用PSK與ECC的區(qū)別主要體現(xiàn)在server_key_exchange報文段、client_key_exchange報文段的內(nèi)容不同和雙方計算得到預主秘鑰方式的不同。

當采用PSK加密時，server_key_exchange報文段和client_key_exchange報文段的內(nèi)容分別是服務器與客戶機各自的psk_id和psk_id_length，由此雙方可以互相知道對方的psk_id和psk_id_length。

之后，雙方都會對收到的報文段進行檢驗，只有psk_id和psk_id_length與本地存儲的完全一致才會進行后面的通信。

當雙方都通過身份驗證后，雙方再各自用相同的函數(shù)產(chǎn)生預主秘鑰，而函數(shù)的參數(shù)包括之前通信階段中雙方各自產(chǎn)生的32字節(jié)的隨機數(shù)，由此可以保證雖然本地存儲的psk秘鑰不變，但每次臨時通信時的會話秘鑰還是會一直變化的，從而增強了抗***性。

雙方產(chǎn)生預主秘鑰后，再調(diào)用和使用ECC加密的相同方式來產(chǎn)生主秘鑰，即用于之后會話通信的對稱秘鑰，該過程中依然會用到雙方產(chǎn)生的32字節(jié)的隨機數(shù)。

由此，通信雙方使用PSK加密方式來實現(xiàn)了身份認證和會話秘鑰的產(chǎn)生。

2.7 server_hello_done報文段和client_key_exchange報文段的內(nèi)容

服務器發(fā)送的server_hello_done報文段的載荷部分為空，只是發(fā)給客戶機來作為標志，表示服務器當前階段的報文段已經(jīng)發(fā)送完畢。

客戶機在收到server_hello_done報文段后，發(fā)送client_key_exchange報文段給服務器，里面包含了用于秘鑰協(xié)商的基點的x,y坐標,并且不同于server_key_exchange報文段，客戶機并沒有在報文段的末尾進行ECDSA數(shù)字簽名。

2.8 客戶機產(chǎn)生會話秘鑰

之后，客戶機再通過ecdh_pre_master_secret函數(shù)來產(chǎn)生用于之后會話的預主秘鑰。其中函數(shù)的參數(shù)包括客戶機自己的私鑰，和服務器共享的用于ECDH秘鑰協(xié)商算法的基點的x,y坐標。

產(chǎn)生預主秘鑰后，再根據(jù)之前階段客戶機和服務器分別產(chǎn)生的32字節(jié)的隨機數(shù)產(chǎn)生主秘鑰master_secret，此時主秘鑰為對稱秘鑰，用于之后會話的加解密。

2.9 change_cipher_spec報文段和finished報文段的內(nèi)容

客戶機計算出會話秘鑰后，發(fā)送change_cipher_spec報文段給服務器，這個報文段的有效載荷為空，用來作為標志通知服務器，表示客戶機已經(jīng)算出主秘鑰，之后發(fā)送的報文段會采用主秘鑰加密。

握手階段中客戶機發(fā)送的最后一個報文段為finished報文段，載荷內(nèi)容為MAC值（消息驗證碼），用于給服務器做認證。并且值得注意的是，finished報文段作為記錄層的載荷部分在發(fā)送時已經(jīng)用上一步產(chǎn)生的會話秘鑰進行加密編碼。

2.10 服務器產(chǎn)生會話秘鑰

服務器在收到客戶機發(fā)送過來的finished報文段后，也會和客戶機用ECDH秘鑰協(xié)商算法經(jīng)過相同的流程，調(diào)用相同的函數(shù)先產(chǎn)生預主秘鑰，再產(chǎn)生主秘鑰。

2.11 握手階段的結束

最后，服務器產(chǎn)生經(jīng)會話秘鑰加密后的finished報文段給客戶機，標志整個握手階段的結束。

客戶機收到服務器發(fā)過來的finished報文段后，便可發(fā)送應用數(shù)據(jù)。并且應用數(shù)據(jù)會一直用會話秘鑰加密，從而實現(xiàn)了UDP所不具備的安全性。