5G新通話的安全衛(wèi)士——DTLS協(xié)議

5G 新通話

5G 新通話作為運(yùn)營商的一種全新通話概念的探索，雖名為通話，實(shí)則遠(yuǎn)不止于此，更是一種實(shí)時(shí)的沉浸式互動(dòng)體驗(yàn)。針對(duì) 5G 新通話，3GPP 在 R16 階段完成了 5G 網(wǎng)絡(luò) IMS Data Channel 實(shí)時(shí)交互通道的相關(guān)技術(shù)標(biāo)準(zhǔn)，并于 2020 年 3 月將其寫入并發(fā)布了 TS26.114 V16.5.0 版本，實(shí)現(xiàn)了 5G VoNR 業(yè)務(wù)能力的增強(qiáng)。IMS Data Channel（簡稱 DC 通道）以 VoLTE/VoNR 高清音視頻通話為基礎(chǔ)，與 WebRTC 技術(shù)相結(jié)合，進(jìn)一步拓展提供了數(shù)據(jù)通道，使得語音和視頻通話能夠與擴(kuò)展的數(shù)據(jù)通道同步，進(jìn)而在高清視頻通話中達(dá)成屏幕共享、疊加 AR ，甚至是實(shí)現(xiàn)聽覺、視覺、觸覺、動(dòng)覺等同步的全沉浸式體驗(yàn)。IMS Data Channel 基于 UDP 提供具有高實(shí)時(shí)性的單流或多流數(shù)據(jù)交互通道，能夠靈活支持多種數(shù)據(jù)通道，充分兼顧各種應(yīng)用對(duì)于底層通道的多樣化需求。

5G 新通話能夠豐富人們的日常交流方式，讓生活變得更加多姿多彩，然而隨之而來的數(shù)據(jù)安全問題也愈發(fā)重要。目前，5G 新通話中 DC 通道的數(shù)據(jù)是借助 UDP 進(jìn)行封裝和傳輸?shù)模瑸楸Ｕ蠑?shù)據(jù)的安全性，引入了 DTLS 協(xié)議為數(shù)據(jù)傳輸保駕護(hù)航。

DTLS簡介

DTLS(Datagram Transport Layer Security)即數(shù)據(jù)包傳輸層安全性協(xié)議。當(dāng)前眾多數(shù)據(jù)包傳輸?shù)?a class="article-link" target="_blank" href="/tag/%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F/">應(yīng)用程序（如實(shí)時(shí)視頻會(huì)議、internet電話和在線游戲等）都是時(shí)延敏感的，大都采用了不可靠的UDP數(shù)據(jù)報(bào)文傳輸方式。大家都知道，基于 TCP 的應(yīng)用能夠運(yùn)用已有的 TLS 協(xié)議來確保安全，然而 TLS 無法保障在 UDP 上傳輸?shù)臄?shù)據(jù)的安全性。正因如此，Datagram TLS 應(yīng)時(shí)而生，它在現(xiàn)存的 TLS 協(xié)議架構(gòu)基礎(chǔ)上進(jìn)行了擴(kuò)展，使其能夠支持 UDP 協(xié)議，成為了 TLS 的一個(gè)支持 UDP 數(shù)據(jù)包傳輸?shù)陌姹荆渲?DTLS 1.0 是基于 TLS 1.1 版本，DTLS 1.2 則是基于 TLS 1.2 版本。

DTLS 協(xié)議與 TLS 協(xié)議有所不同，DTLS 協(xié)議在傳輸層對(duì)數(shù)據(jù)進(jìn)行加密和認(rèn)證，而 TLS 協(xié)議是在傳輸層之上對(duì)數(shù)據(jù)進(jìn)行加密和認(rèn)證。所以，DTLS 協(xié)議不但能夠提供與 TLS 協(xié)議相同的安全保護(hù)，同時(shí)還能夠保留 UDP 協(xié)議的優(yōu)點(diǎn)，更適合應(yīng)用于對(duì)時(shí)延敏感的程序。

DTLS協(xié)議與TLS協(xié)議類似，通常包含以下三個(gè)階段：

握手階段：客戶端和服務(wù)器之間進(jìn)行握手，協(xié)商加密算法和密鑰等。

數(shù)據(jù)傳輸階段：客戶端和服務(wù)器之間進(jìn)行數(shù)據(jù)傳輸，DTLS協(xié)議對(duì)數(shù)據(jù)進(jìn)行加密和認(rèn)證。

斷開連接階段：客戶端和服務(wù)器之間斷開連接，并清除相關(guān)的狀態(tài)信息。

DTLS在5G新通話中的位置

DC通道協(xié)商完成之后（通過SIP交互進(jìn)行DC通道的協(xié)商），需要先進(jìn)行DTLS建鏈，之后在此基礎(chǔ)上進(jìn)行數(shù)據(jù)傳輸，DTLS建鏈位置參見下面示例：

1.?終端發(fā)起協(xié)商bootsrap DC流程時(shí)的DTLS建鏈位置

2.?終端-終端之間的application DC建立流程時(shí)的DTLS建鏈位置

DTLS交互流程

與TCP三次握手類似，DTLS也是通過握手的方式建立鏈接，握手交互流程示例見下（遵循RFC 6347定義的DTLS 1.2協(xié)議）：

流程描述：

客戶端發(fā)送ClientHello報(bào)文，發(fā)起握手和密鑰協(xié)商，報(bào)文主要包含：隨機(jī)數(shù)（后續(xù)用于生成共享密鑰）、密碼算法族、壓縮算法族。

按照RFC 6347交換Cookie：服務(wù)端生成Cookie，打包在HelloVerifyRequest報(bào)文中發(fā)送給客戶端。

客戶端收到Cookie后，將Cookie打包在ClientHello報(bào)文中并再次發(fā)送給服務(wù)端。

服務(wù)端校驗(yàn)Cookie，確認(rèn)有效后向客戶端發(fā)送ServerHello報(bào)文，報(bào)文主要包含：隨機(jī)數(shù)、選擇的加密方式、選擇的壓縮方式。

服務(wù)端用Certificate報(bào)文向客戶端發(fā)送服務(wù)端證書（證書可以采用自簽名證書，證書格式基于X.509標(biāo)準(zhǔn)，需要遵循RFC 5280，客戶端根據(jù)SDP中的fingerprint信息來校驗(yàn)服務(wù)器證書）。

服務(wù)端用ServerKeyExchange報(bào)文向客戶端發(fā)送服務(wù)端的密鑰協(xié)商信息。

服務(wù)端用CertificateRequest報(bào)文向客戶端請求客戶端證書。

服務(wù)端向客戶端發(fā)送ServerHelloDone報(bào)文，指示服務(wù)端的Hello和相關(guān)報(bào)文交互結(jié)束。

客戶端用Certificate報(bào)文向服務(wù)端發(fā)送客戶端證書（證書可以采用自簽名證書，證書格式基于X.509標(biāo)準(zhǔn)，需要遵循RFC 5280，服務(wù)端采用SDP中fingerprint信息來校驗(yàn)客戶端證書）。

客戶端采用信令消息SDP中的fingerprint信息來校驗(yàn)服務(wù)端證書，校驗(yàn)通過后用ServerKeyExchange報(bào)文向服務(wù)端發(fā)送主密鑰。

當(dāng)服務(wù)端發(fā)送的ServerKeyExchang報(bào)文驗(yàn)證無誤時(shí)，客戶端向服務(wù)端發(fā)送CertificateVerify報(bào)文響應(yīng)。

客戶端向服務(wù)端發(fā)送ChangeCipherSpec報(bào)文，表明后續(xù)將要使用當(dāng)前加密參數(shù)。

客戶端向服務(wù)端發(fā)送加密的Finished報(bào)文，用于驗(yàn)證雙方協(xié)商的對(duì)稱加密算法、客戶端密鑰。

服務(wù)端向客戶端發(fā)送ChangeCipherSpec報(bào)文，表明將要使用當(dāng)前加密參數(shù)。

服務(wù)端向客戶端發(fā)送加密的Finished報(bào)文，用于驗(yàn)證雙方協(xié)商的對(duì)稱加密算法、客戶端密鑰，至此握手完成。

以上便是DTLS協(xié)議及主要流程介紹，其中握手流程中同一方向的數(shù)據(jù)可以放在一起發(fā)送，如步驟4~8中的握手?jǐn)?shù)據(jù)可以一起發(fā)送給客戶端，握手完成之后就進(jìn)入應(yīng)用數(shù)據(jù)傳輸階段，在客戶端和服務(wù)器之間進(jìn)行數(shù)據(jù)傳輸時(shí)，DTLS協(xié)議一致維護(hù)鏈接并會(huì)對(duì)數(shù)據(jù)進(jìn)行加密和認(rèn)證，直至?xí)捊Y(jié)束再斷開鏈接。