5G 新通話

5G 新通話作為運營商的一種全新通話概念的探索，雖名為通話，實則遠不止于此，更是一種實時的沉浸式互動體驗。針對 5G 新通話，3GPP 在 R16 階段完成了 5G 網(wǎng)絡 IMS Data Channel 實時交互通道的相關(guān)技術(shù)標準，并于 2020 年 3 月將其寫入并發(fā)布了 TS26.114 V16.5.0 版本，實現(xiàn)了 5G VoNR 業(yè)務能力的增強。IMS Data Channel（簡稱 DC 通道）以 VoLTE/VoNR 高清音視頻通話為基礎(chǔ)，與 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)基礎(chǔ)上進行了擴展，使其能夠支持 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ù)進行加密和認證。

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

DTLS在5G 新通話中的位置

DC通道協(xié)商完成之后（通過SIP交互進行DC通道的協(xié)商），需要先進行DTLS建鏈，之后在此基礎(chǔ)上進行數(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和相關(guān)報文交互結(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é)束再斷開鏈接。