5G 新通話

5G 新通話作為運(yùn)營商的一種全新通話概念的探索，雖名為通話，實(shí)則遠(yuǎn)不止于此，更是一種實(shí)時(shí)的沉浸式互動體驗(yàn)。針對 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)聽覺、視覺、觸覺、動覺等同步的全沉浸式體驗(yàn)。IMS Data Channel 基于 UDP 提供具有高實(shí)時(shí)性的單流或多流數(shù)據(jù)交互通道，能夠靈活支持多種數(shù)據(jù)通道，充分兼顧各種應(yīng)用對于底層通道的多樣化需求。

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

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

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

數(shù)據(jù)傳輸階段：客戶端和服務(wù)器之間進(jìn)行數(shù)據(jù)傳輸，DTLS協(xié)議對數(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é)商的對稱加密算法、客戶端密鑰。

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

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

以上便是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ù)鏈接并會對數(shù)據(jù)進(jìn)行加密和認(rèn)證，直至?xí)捊Y(jié)束再斷開鏈接。