5G 新通話

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

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

DTLS簡介

DTLS(Datagram Transport Layer Security)即數(shù)據(jù)包傳輸層安全性協(xié)議。當前眾多數(shù)據(jù)包傳輸?shù)膽贸绦颍ㄈ鐚崟r視頻會議、internet電話和在線游戲等）都是時延敏感的，大都采用了不可靠的UDP數(shù)據(jù)報文傳輸方式。大家都知道，基于 TCP 的應用能夠運用已有的 TLS 協(xié)議來確保安全，然而 TLS 無法保障在 UDP 上傳輸?shù)臄?shù)據(jù)的安全性。正因如此，Datagram TLS 應時而生，它在現(xiàn)存的 TLS 協(xié)議架構(gòu)基礎上進行了擴展，使其能夠支持 UDP 協(xié)議，成為了 TLS 的一個支持 UDP 數(shù)據(jù)包傳輸?shù)陌姹荆渲?DTLS 1.0 是基于 TLS 1.1 版本，DTLS 1.2 則是基于 TLS 1.2 版本。

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

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

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

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

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

DTLS在5G 新通話中的位置

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

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

2.終端-終端之間的application DC建立流程時的DTLS建鏈位置

DTLS交互流程

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

流程描述：

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

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

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

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

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

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

服務端用CertificateRequest報文向客戶端請求客戶端證書。

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

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

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

當服務端發(fā)送的ServerKeyExchang報文驗證無誤時，客戶端向服務端發(fā)送CertificateVerify報文響應。

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

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

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

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

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