文章分享

1.DTLS介紹

1.1 DTLS的作用

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

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

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

1.2 DTLS的特點(diǎn)

UDP協(xié)議是不面向連接的不可靠協(xié)議，且沒(méi)有對(duì)傳輸?shù)膱?bào)文段進(jìn)行加密，不能保證通信雙方的身份認(rèn)證、消息傳輸過(guò)程中的按序接收、不丟失和加密傳送。

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

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

1.3 DTLS協(xié)議層次

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

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

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

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

2.DTLS傳輸階段

2.1 整個(gè)握手階段的交互過(guò)程

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

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

                                                 圖二.DTLS協(xié)議客戶(hù)機(jī)與服務(wù)器握手階段的交互過(guò)程

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

2.2 DTLS的cookie驗(yàn)證機(jī)制

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

cookie機(jī)制要求客戶(hù)機(jī)重復(fù)發(fā)送服務(wù)器之前發(fā)送的cookie值來(lái)驗(yàn)證通信方的源IP地址確實(shí)可以通信，由此可以減少拒絕服務(wù)攻擊的危害。

cookie驗(yàn)證身份的具體機(jī)制為：

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

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

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

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

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

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

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

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

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

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

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

客戶(hù)機(jī)在收到server_key_exchange報(bào)文段后，先進(jìn)行各數(shù)值項(xiàng)格式的校驗(yàn)，然后提取出報(bào)文段末尾的簽名值r和s。之后，用已經(jīng)讀取出的服務(wù)器的公鑰的x,y坐標(biāo)值來(lái)對(duì)server_key_exchange報(bào)文段進(jìn)行ECDSA簽名驗(yàn)證，若結(jié)果和報(bào)文段中的r和s值一致，則報(bào)文段通過(guò)驗(yàn)證。

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

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

對(duì)于PSK加密通信來(lái)說(shuō)，驗(yàn)證對(duì)方的通信身份非常關(guān)鍵。所以通信雙方會(huì)在本地存取對(duì)方的psk_id（即身份標(biāo)志）和psk_id_length（身份標(biāo)志長(zhǎng)度），通過(guò)比較收到的報(bào)文段中的psk_id,psk_id_length和本地存儲(chǔ)的是否完全一致來(lái)進(jìn)行對(duì)方身份的驗(yàn)證。

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

當(dāng)采用PSK加密時(shí)，server_key_exchange報(bào)文段和client_key_exchange報(bào)文段的內(nèi)容分別是服務(wù)器與客戶(hù)機(jī)各自的psk_id和psk_id_length，由此雙方可以互相知道對(duì)方的psk_id和psk_id_length。

之后，雙方都會(huì)對(duì)收到的報(bào)文段進(jìn)行檢驗(yàn)，只有psk_id和psk_id_length與本地存儲(chǔ)的完全一致才會(huì)進(jìn)行后面的通信。

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

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

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

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

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

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

2.8 客戶(hù)機(jī)產(chǎn)生會(huì)話秘鑰

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

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

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

客戶(hù)機(jī)計(jì)算出會(huì)話秘鑰后，發(fā)送change_cipher_spec報(bào)文段給服務(wù)器，這個(gè)報(bào)文段的有效載荷為空，用來(lái)作為標(biāo)志通知服務(wù)器，表示客戶(hù)機(jī)已經(jīng)算出主秘鑰，之后發(fā)送的報(bào)文段會(huì)采用主秘鑰加密。

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

2.10 服務(wù)器產(chǎn)生會(huì)話秘鑰

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

2.11 握手階段的結(jié)束

最后，服務(wù)器產(chǎn)生經(jīng)會(huì)話秘鑰加密后的finished報(bào)文段給客戶(hù)機(jī)，標(biāo)志整個(gè)握手階段的結(jié)束。

客戶(hù)機(jī)收到服務(wù)器發(fā)過(guò)來(lái)的finished報(bào)文段后，便可發(fā)送應(yīng)用數(shù)據(jù)。并且應(yīng)用數(shù)據(jù)會(huì)一直用會(huì)話秘鑰加密，從而實(shí)現(xiàn)了UDP所不具備的安全性。