DTLS 技術要點解析
DTLS 技術要點解析
</h1>
<div class="clear"></div>
<div class="postBody">
一、DTLS
DTLS 是指 Datagram Transport Level Security，即資料報安全傳輸協議；
其提供了UDP 傳輸場景下的安全解決方案，能防止訊息被竊聽、篡改、身份冒充等問題。
DTLS作為UDP版本的TLS，具備了同樣的安全機制和防護等級，在版本上存在對應關係，如DTLS 1.2版本對應於 TLS1.2。
二、握手流程
前面的文章介紹過TLS的相關演算法流程，對於傳輸層安全來說，金鑰交換機制和資料加密及簽名演算法決定了整個方案的安全等級。
而金鑰協商都必須通過握手流程完成，因而這是理解DTLS的關鍵要點。
根據RFC6347定義，一個DTLS握手流程如下所示：
------ ------
ClientHello --------> Flight 1
<------- HelloVerifyRequest Flight <span style="color: rgba(128, 0, 128, 1)">2</span><span style="color: rgba(0, 0, 0, 1)">
ClientHello --------> Flight 3
ServerHello \ Certificate</span>*<span style="color: rgba(0, 0, 0, 1)"> \ ServerKeyExchange</span>* Flight <span style="color: rgba(128, 0, 128, 1)">4</span><span style="color: rgba(0, 0, 0, 1)"> CertificateRequest</span>* / <-------- ServerHelloDone /<span style="color: rgba(0, 0, 0, 1)">
Certificate
ClientKeyExchange
CertificateVerify Flight 5
[ChangeCipherSpec] /
Finished --------> /
[ChangeCipherSpec] \ Flight </span><span style="color: rgba(128, 0, 128, 1)">6</span>
<-------- Finished /</pre>
三、關鍵演算法
DTLS 由於網路IO機制的限制，其支援的演算法為TLS的子集。
這裡將DTLS演算法描述為一種演算法可能並不恰當，因為一個完整的DTLS過程中，所涉及的演算法是很多的，比如
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256，這其中涉及的演算法包括：
1 金鑰交換演算法 ECDHE_RSA，這是由ECC和DH金鑰交換演算法衍生出來的演算法；
2 動態金鑰演算法 AES_128_GCM，用於實現資料包的加解密；
3 MAC演算法 HMAC_SHA256，用於建立加密資料塊的摘要；
4 偽隨機函式 PRF，TLS1.2 定義其與MAC演算法一致。
因此將一個DTLS過程中協商使用的演算法列表稱謂演算法套件，即CipherSuite，個人認為這個定義還是比較好理解的。
以下是幾個常用的 CipherSuite
TLS_PSK_WITH_AES_128_CBC_SHA256 TLS_PSK_WITH_AES_128_CCM_8 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
演算法的選擇
不同演算法帶來的資料傳輸及計算效能開銷是不同的，尤其在UDP場景下，我們可能更關注的是網路IO的不穩定性，MTU過載導致丟包等等問題。
非對稱金鑰加解密的效能是低下的，尤其在微型裝置上，其計算資源十分有限，因此採用輕量級的金鑰交換演算法可能是最佳方案。
PSK(Pre shared key) 演算法中，服務端為終端預置了金鑰，在交換過程中憑一個identity資訊可快速完成資訊交換，這個極大簡化了金鑰交換的工作。
一個典型的PSK握手流程如下所示：
Client Server
------ ------
ClientHello -------->
<--------<span style="color: rgba(0, 0, 0, 1)"> HelloVerifyRequest
(contains cookie)
ClientHello </span>--------><span style="color: rgba(0, 0, 0, 1)">
(with cookie)
ServerHello
</span>*<span style="color: rgba(0, 0, 0, 1)">ServerKeyExchange
</span><--------<span style="color: rgba(0, 0, 0, 1)"> ServerHelloDone
ClientKeyExchange
ChangeCipherSpec
Finished </span>--------><span style="color: rgba(0, 0, 0, 1)">
ChangeCipherSpec
</span><--------<span style="color: rgba(0, 0, 0, 1)"> Finished
Application Data </span><-------> Application Data</pre>
PSK方案的缺陷在於其無法較好的防止PSF(Perfect Forward Secrecy)攻擊問題，一旦PSK洩露，將丟失安全性。
然而方案的選擇並非力求完美，我們往往要找的是最適合需求的方案。PSK方案輕量級，節省開銷，且具備一定的通用性；
而對於安全級別特別高的場景，你或許可以選擇ECDHE交換演算法，而為了節省證書傳輸的開銷，你可以採取一些擴充套件機制，如Raw Public Key。
這是一種允許直接將公鑰資料替代證書的方案，可一定程度節省CA證書傳輸及信任鏈校驗的開銷。
RFC7925對物聯網場景下的DTLS提供了一些擴充套件定義，可供參考。
四、防護機制
A. 握手流程
握手流程必須嚴格按順序執行，因此有必要保證訊息可靠到達，按序接收。
重傳
DTLS 採用了簡單的重傳機制來確保握手訊息到達，流程如下：
Client Server
------ ------
ClientHello ------>
X</span><--<span style="color: rgba(0, 0, 0, 1)"> HelloVerifyRequest
(lost)
[Timer Expires]
ClientHello </span>------><span style="color: rgba(0, 0, 0, 1)">
(retransmit)</span></pre>
順序
為保證握手訊息按序傳輸，每個handshake訊息包含了一個序列號；
接收方直接處理屬於當前步驟的訊息，對於提前到達的訊息則提供一個佇列進行快取；
分段
理論上一個握手訊息可能接近2^24-1位元組, 而UDP 傳輸中往往限制於MTU 大小，一般為1500位元組；
因此 DTLS 要求針對握手訊息實現分段，每一個握手訊息都可能包含了fragment的offset 和長度，由接收端重新組裝；
重複
DTLS 定義了訊息重放檢測機制，由接收方維護一個bitmap用於記錄一接收的資料包，用於檢測重複資料包；建議解決方案實現對bitmap的自動老化。
該做法借鑑了IPsec AH/ESP機制。
B. 資料包傳輸
加解密演算法很可能依賴於上下文，如CBC組合演算法中，當前資料包的解密依賴於上一個資料包，因此有必要保證資料包傳輸的可靠和有序；
DTLS為每個加密資料包增加了MAC鑑權摘要，用於保證資料包的完整性；此外顯式附帶了一個SN號用於排序。
C. Dos攻擊
攻擊者很可能會利用一些已入侵的主機對伺服器展開攻擊(資料包轉發)，通過瞬時對DTLS伺服器傳送大量的握手訊息導致伺服器資源耗盡；
DTLS定義了基於cookie驗證的機制來預防攻擊，如前面流程中涉及的HelloVerifyRequest便是用於進行cookie驗證
Client Server
------ ------
ClientHello ------>
<-----<span style="color: rgba(0, 0, 0, 1)"> HelloVerifyRequest
(contains cookie)
ClientHello </span>------><span style="color: rgba(0, 0, 0, 1)">
(with cookie)
[Rest of handshake]</span></pre>
Cookie的演算法：HMAC(Secret, Client-IP, Client-Parameters)
其中Secret由server端內建，用於計算cookie值，client端需要在接收到VerifyRequest後提供同樣的cookie值；
server端根據傳送方IP計算cookie值，一旦返現不一致則判定為非法資料。
D. 會話恢復
握手流程所佔的開銷是較大的，與TLS類似，DTLS也定義了會話恢復機制。
Client Server ------ ------
ClientHello --------> Flight 1
ServerHello \
[ChangeCipherSpec] Flight </span><span style="color: rgba(128, 0, 128, 1)">2</span>
<-------- Finished /<span style="color: rgba(0, 0, 0, 1)">
[ChangeCipherSpec] \Flight 3
Finished -------->
簡單原理
握手成功之後，Server端將生成SessionID 返回，客戶端在下次連線時附帶SessionID；
若驗證通過，可直接沿用原有的會話資料，包括協商演算法和金鑰。
五、與TLS的不同
最後，總結下與TLS的差異吧
-
TLS 建立於TCP可靠的傳輸機制之上，而DTLS基於UDP，必須自建保障機制：
DTLS 必須檢測MTU大小，當應用層資料包超過時報錯；
為防止握手的IP資料包超載導致丟失，DTLS 針對握手訊息實現fragment處理。
-
TLS 在傳輸出錯時會中斷連線，而DTLS需相容多種出錯場景，出錯時往往直接丟棄處理；
- DTLS不支援RC4流加密演算法。
六、參考文件
DTLS1.2 定義
https://tools.ietf.org/html/rfc6347
DTLS -IOT extension
https://tools.ietf.org/html/rfc7925#section-4.1
TLS /SSL 原理解析
http://seanlook.com/2015/01/07/tls-ssl/
關於TLS的隱式向量
https://en.wikipedia.org/wiki/Initialization_vector
老外寫的關於PSF的文章
https://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html
分類: 2.安全技術 標籤: TLS&DTLS<div style="float: left; padding-right: 15px"> <img src="https://images.cnblogs.com/cnblogs_com/littleatp/1241412/o_qrcode_for_gh_b2cf486409a0_258.jpg" style="width: 120px; height: 120px"> </div> <div style="padding-top: 15px"> <p> 作者： <a href="http://www.cnblogs.com/littleatp/">美碼師(zale)</a> </p> <p> 出處： <a href="http://www.cnblogs.com/littleatp/">http://www.cnblogs.com/littleatp/</a>, 如果喜歡我的文章，請<b style="font-size: medium">關注我的公眾號</b> </p> <p> 本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出 <a href="#" style="color: #0; font-size: medium">原文連結</a> 如有問題， 可留言諮詢. </p> </div> <div style="clear: both"></div>
好文要頂 關注我 收藏該文<div id="blog_post_info">
美碼師
關注 - 10
粉絲 - 135 +加關注 2 0
posted @ 2017-01-30 18:47 美碼師 閱讀( 15457) 評論( 0) 編輯 收藏<div class="clear"></div> <div id="post_next_prev"> <a href="https://www.cnblogs.com/littleatp/p/6354441.html" class="p_n_p_prefix">« </a> 上一篇： <a href="https://www.cnblogs.com/littleatp/p/6354441.html" title="釋出於 2017-01-28 19:49">實現jul 日誌重定向到 slf4j</a> <br> <a href="https://www.cnblogs.com/littleatp/p/6358593.html" class="p_n_p_prefix">» </a> 下一篇： <a href="https://www.cnblogs.com/littleatp/p/6358593.html" title="釋出於 2017-01-31 01:23">DTLS-PSK演算法抓包解析</a></div>