本次分享，將針對當(dāng)前各類終端加密場景，分別介紹基于WebRTC的會議、SFU模式的會議以及WebRTC SFU模式的會議數(shù)據(jù)加密的異同。

內(nèi)容源自263音視頻架構(gòu)師?賀曉敏在視頻會議下半場圓桌上的分享。

PPT資料鏈接：https://pan.baidu.com/s/19qf9rzU43gcLyQz0T21VxA

提取碼：t02m

隨著遠程協(xié)作工具在各行業(yè)被廣泛應(yīng)用，并且很多企業(yè)都宣布將遠程辦公作為一種常態(tài)化的協(xié)作模式，這就意味著如視頻會議等遠程協(xié)作辦公產(chǎn)品的普及性已經(jīng)提升到了企業(yè)戰(zhàn)略的高度。也令企業(yè)對視頻會議軟件或平臺的安全性越發(fā)重視。

視頻會議的普及必然意味著需要支持更高的并發(fā)量、更便捷的使用和支持移動化、智能化終端的接入，企業(yè)自建的視頻會議平臺已無法滿足企業(yè)使用需求，企業(yè)對公有云產(chǎn)品的接受度逐漸提高，企業(yè)對視頻會議產(chǎn)品安全性的拷問也隨之而來。

縱觀全球，一方面網(wǎng)絡(luò)攻擊相較從前更具廣泛性、針對性和破壞性，另一方面，由于國際政治環(huán)境的客觀原因，逆全球化發(fā)展帶來信任危機，政企、軍警等各領(lǐng)域都對視頻會議安全性提出更高的信息安全要求。?

非常榮幸能夠代表263參加這次活動。今天我會就視頻會議終端到終端的加密策略，分享目前263正在研發(fā)和實踐中的幾種加密方法。

首先介紹一下263。263在企業(yè)互聯(lián)網(wǎng)通信領(lǐng)域已深耕20余年，為企業(yè)級客戶提供如視頻會議、企業(yè)直播、企業(yè)郵箱、云存儲、電話會議等產(chǎn)品和服務(wù)。2015年，263收購了當(dāng)時國內(nèi)最大的互動直播平臺展視互動，全面布局了企業(yè)互聯(lián)網(wǎng)通信領(lǐng)域產(chǎn)品線。

近年來，263逐漸從傳統(tǒng)的工具型的廠商向一站式數(shù)字化營銷服務(wù)商轉(zhuǎn)變，通過云視頻技術(shù)能力賦能行業(yè)客戶，在云視頻會議、云直播應(yīng)用領(lǐng)域極大地提升了整體視頻服務(wù)的能力，滿足企業(yè)客戶開展遠程視頻會議、直播營銷、遠程培訓(xùn)等各種視頻協(xié)作需求，幫助企業(yè)創(chuàng)造數(shù)字化營銷新價值。

?#視頻會議安全背景介紹.?

提到視頻會議安全，始終繞不開的一個因素就是去年的疫情。自從2020年的疫情之后，快速催化了遠程辦公、遠程協(xié)作市場，尤其在視頻會議、在線教育、線上培訓(xùn)、線上峰會等各行業(yè)的細分場景應(yīng)用越來越廣泛，并且終端不局限于電腦和視頻會議硬件。例如在物聯(lián)網(wǎng)領(lǐng)域，各種傳感器、無人機等終端也需要視頻通信能力；在醫(yī)療領(lǐng)域，核磁共振圖像的傳輸、紅外掃描等，在政府應(yīng)急指揮領(lǐng)域的遠程跟蹤監(jiān)控等，無一不需要在各類終端上實現(xiàn)視頻通信能力。終端種類繁多，對數(shù)據(jù)安全的要求也不盡相同，這對于視頻通信平臺的安全策略是很大的挑戰(zhàn)。

另外，視頻會議行業(yè)整體的發(fā)展趨勢越來越趨向于協(xié)議的標準化、兼容性和能力的融合。當(dāng)前，視頻會議的應(yīng)用場景越來越復(fù)雜，企業(yè)采用自建方案，使用私有協(xié)議的成本越來越高，因此，采用公有云方案的企業(yè)越來越多，遭到網(wǎng)絡(luò)攻擊的概率也相對增高，并且網(wǎng)絡(luò)攻擊的強度也隨之升級，變得針對性更強、破壞力更大、影響范圍更廣，視頻會議平臺的安全性及加密策略，受到了越來越多企業(yè)的重視。下面我將分享一些傳統(tǒng)視頻通信的加密方法和目前263研發(fā)的幾種視頻會議終端到終端的加密方法。

?#端到端的加密.?

傳統(tǒng)加密技術(shù)共有三種，對稱加密、非對稱加密和TLS加密。

對稱加密，即用同一個方法加密，對方再用同一個方法解密，這種加密技術(shù)要求雙方公用密碼需要通過私有通道提前分配，類似諜戰(zhàn)電影中的密碼本。對稱加密的優(yōu)勢是速度快、效率高，但弊端也很明顯，一旦密鑰暴露，數(shù)據(jù)就會被竊聽。

隨著加密技術(shù)的發(fā)展，由對稱加密技術(shù)引申出了非對稱加密技術(shù)，這種技術(shù)的加密和解密密鑰不同，一般是公鑰加密，私鑰解密。公鑰即使泄露，也不會導(dǎo)致數(shù)據(jù)泄露。通信雙方只需要提前把自己的公鑰發(fā)給對方，就可以實現(xiàn)公鑰加密。而發(fā)送出去后，對方收到再解密，這種技術(shù)比對稱加密的安全性有一定的提高。

第三類是TLS加密。TLS加密的優(yōu)勢是在非對稱加密的基礎(chǔ)上，解決了身份認證問題。加密通信過程是先向認證機構(gòu)申請證書，把證書認證為公鑰發(fā)送給對方，對方收到證書后在第三方驗證其證書是否有效，兩方的驗證通過后開始公鑰加密，私鑰解密通信的過程。

?#基于WebRTC的會議數(shù)據(jù)加密.?

下面，我重點講一下基于WebRTC的數(shù)據(jù)加密。為更好地保障客戶的信息安全，263的云視頻服務(wù)使用的是自研的WebRTC技術(shù)，并且在視頻會議數(shù)據(jù)的安全性上著重做了加固。

由于WebRTC本身的協(xié)議設(shè)置是端到端的通信，所以基于WebRTC的會議大多數(shù)是客戶端到WebRTC服務(wù)器的平臺之間的數(shù)據(jù)。過程是標準的SDP會話協(xié)商——ICE打洞解決數(shù)據(jù)及網(wǎng)絡(luò)問題——基于UDP的DTLS實現(xiàn)雙方密鑰交換——SRTP數(shù)據(jù)傳輸，發(fā)送方使用公鑰加密數(shù)據(jù)，使用SRTP通道發(fā)送，對方收到后解密。

媒體數(shù)據(jù)使用的是SRTP，DataChannel可用例傳輸信令，各大平臺使用比較少，用的是SCTP加密。WebRTC的會話建立過程中，會話信令的交換沒有標準化定義，一般來說基于WebSocket實現(xiàn)以兼容瀏覽器，但也可以自己去實現(xiàn)。如上圖，信令用的就是TCP的TLS加密、數(shù)據(jù)用UDP的SCTP/SRTP的加密過程（新版本W(wǎng)ebRTC已實現(xiàn)基于UDP/HTTP3/Quic的實現(xiàn)）。

密鑰交換的過程是WebRTC的關(guān)鍵，這里舉例說明。例如現(xiàn)在基于WebRTC的會議平臺下有兩個終端，要進行媒體數(shù)據(jù)的轉(zhuǎn)發(fā)，其過程是首先建立會話，建立過程中會生成一對或兩對密鑰，上行的流和下行的流是兩個獨立對等的流，即發(fā)送和接受分別是一對密鑰。假設(shè)終端A生成的是（A，a），服務(wù)器生成的是（S1，s1），終端B也是同樣的過程，完成之后，它們都建立了自己的媒體流。接下來就是數(shù)據(jù)的轉(zhuǎn)發(fā)過程，A終端使用公鑰加密服務(wù)器，發(fā)送給服務(wù)器，服務(wù)器使用它們之間協(xié)商的密鑰解密，然后做處理（包括組包、排序、抗丟包、NACK的過程），在分發(fā)過程中可能還會做SFU的分流，就是Simulcast分流，然后給每一個終端發(fā)的時候再用它們協(xié)商的密鑰加密發(fā)送，終端收到后再解密，反過來同樣。

這就實現(xiàn)了整個會議中每個終端到服務(wù)器之間的信道是加密的，服務(wù)器會把收到的數(shù)據(jù)解密、組包、重新加密、發(fā)送。它存在的問題是服務(wù)器在一系列處理過程中，內(nèi)存CPU消耗比較高。

目前，這一加密技術(shù)已在263平臺加以運用。263基于自研的WebRTC技術(shù)，不僅實現(xiàn)了云視頻會議和云直播產(chǎn)品穩(wěn)定、流暢、超低延遲的視頻通信，也憑這一加密技術(shù)為政府、金融、醫(yī)藥等行業(yè)及對數(shù)據(jù)安全要求較高的企業(yè)客戶的數(shù)據(jù)安全保駕護航。

?#視頻會議中的一對一私密會話.?

對于1對1的視頻會議，263在平臺的開發(fā)上設(shè)計了一種私密對話的加密方式來保障視頻會議安全。假設(shè)這是一個標準的會議服務(wù)器，終端A和B正常進入會議中，它們之間想做一個私密會話，會話使用的是第三方平臺，基于平臺的SDK擴展協(xié)議自己做了加密的信令擴展，它的過程是：A終端欲發(fā)起會話，其先生成密鑰再把公鑰發(fā)給對方，B接受會話，生成應(yīng)答后也把公鑰發(fā)送回來，就可以實現(xiàn)一對一的加密數(shù)據(jù)流轉(zhuǎn)發(fā)。

?#SFU模式下的終端到終端加密.?

在SFU模式，即分發(fā)模式下，會議服務(wù)器需要將每個終端數(shù)據(jù)通過服務(wù)器分發(fā)給多人，因此不能給每個1對1的數(shù)據(jù)流都進行全流程加密，而只能實現(xiàn)上線流或下行流的數(shù)據(jù)傳輸通道加密。我們現(xiàn)在要求整個分發(fā)過程，會議服務(wù)器不能破解每個終端的信令或者數(shù)據(jù)，確保不會被監(jiān)聽。要達成在一個不可信任的平臺上實現(xiàn)可信任的通話，需要以下過程：首先，每個終端先生成一對”信令密鑰”，在入會時會把自己的公鑰廣播到會場里面。后續(xù)發(fā)送需要加密的信令時，只需要使用對方的公鑰進行加密即可。這樣，所有的終端都可以發(fā)送信令給服務(wù)器，但是服務(wù)器不能破解信令。

之后則是數(shù)據(jù)的加密發(fā)送過程。數(shù)據(jù)的加密和信令所有區(qū)別。如果要求每個人的數(shù)據(jù)加密后發(fā)出，服務(wù)器不僅不能解密，還要求所有終端都可以接收，這就需要一個授權(quán)的過程。

例如：A客戶端使用”A1”數(shù)據(jù)密鑰，A客戶端的數(shù)據(jù)在入會后就可以使用自己的A1公鑰進行加密，然后再發(fā)給服務(wù)器；服務(wù)器不知道A客戶端的數(shù)據(jù)私鑰，所以不能解密；其他客戶端在需要接收A的數(shù)據(jù)時，會首先發(fā)送一個請求信令，這個信令使用信令公鑰”A”進行加密，轉(zhuǎn)發(fā)到A終端；A收到后會進行鑒權(quán)認證，確保對方是合法終端（應(yīng)用可以建立自己的鑒權(quán)平臺，并在請求中包含證書）。認證同意后，就可以把相應(yīng)的應(yīng)答發(fā)送出去，這里面的應(yīng)答包括數(shù)據(jù)私鑰”a1”。

注意這里公鑰當(dāng)作私鑰，私鑰當(dāng)作公鑰，是一個反向的過程。這樣，終端B就可以接收服務(wù)器的數(shù)據(jù)流。B已經(jīng)得到授權(quán)可以使用A的私鑰進行解密A的加密數(shù)據(jù)。這樣，通過服務(wù)器轉(zhuǎn)發(fā)加密的數(shù)據(jù)通道就已經(jīng)完成了。

這SFU模式下的終端到終端加密，其證書的過程。首先存在兩個客戶終端A和B。下面是基于會議平臺SDK做的第三方的應(yīng)用。A客戶端首先向會議管理服務(wù)器發(fā)布一個加密的視頻流，服務(wù)器會廣播給所用終端；然后B終端在觀看前需要向客戶自己搭建的證書平臺獲取證書，完成之后再向會議管理服務(wù)器訂閱視頻流并提供證書；服務(wù)器收到請求后將包含證書B的請求轉(zhuǎn)發(fā)給終端A后，終端A在證書服務(wù)器上進行證書認證，通過后再把自己的公鑰通過會議管理服務(wù)器轉(zhuǎn)發(fā)給B，B接收收，A和B之間就可以進行數(shù)據(jù)流的交流。

?#WebRTC SFU模式的終端到終端加密.?

在WebRTC SFU模式下，若既想用到WebRTC的標準協(xié)議，又想在其之上進行終端間加密則需要以下的過程。

前面的的過程和剛剛一樣，使用加密的信令通道。標準的WebRTC會話建立完成之后，例如一個B請求A的數(shù)據(jù)，B請求數(shù)據(jù)的私鑰。之后在數(shù)據(jù)流的分發(fā)過程中，在WebRTC的SRTP的加密之前，做一個API層的回調(diào)交給應(yīng)用端，讓其自己再做一層加密之后，再用SRTP的加密。

另外，在WebRTC的服務(wù)器上只需要做通道的解密，不需要完整的視頻幀數(shù)據(jù)解密，不要組幀等過程，只需要做一個排序，之后給每個人分發(fā)還是使用WebRTC的連接。這樣B在收到數(shù)據(jù)后，不僅需要進行SRTP的解密，還需要解密一層客戶自己做的API層的加密處理。這樣就將終端到終端的加密過程嵌入到WebRTC里。

WebRTC SFU加密信令通道和標準會議相同。私鑰請求需要在WebRTC之外獨立建立這樣的過程。數(shù)據(jù)流的分發(fā)就進行剛剛介紹的三個變化：多一層加密、少一層組幀、多一層解密。基于上述的方法，通過協(xié)議的設(shè)計即可實現(xiàn)一種可信任加密數(shù)據(jù)的通信過程。

?#問題.?

這里存在兩個問題。一個是身份認證，一個是協(xié)議兼容問題。

身份認證方面。我們已經(jīng)實現(xiàn)服務(wù)器是安全的、傳輸通道是安全的，但是終端是不是安全的并沒有明確的定義。剛剛提到的證書過程，沒有標準化。我們只提供開放的API或者類似的方式，用戶可以很靈活的自己去實現(xiàn)。一般來說一對多的證書認證很難實現(xiàn)一個標準化的過程。除了使用證書平臺之外，也可以使用硬件層面實現(xiàn)，例如加密狗的方式。

協(xié)議兼容方面。在一套加密的WebRTC的系統(tǒng)上，如果想兼容標準WebRTC瀏覽器客戶端就需要其他的解決方案。瀏覽器拿到數(shù)據(jù)后不會進行API的解密，發(fā)送的數(shù)據(jù)也沒有公鑰”A1”的加密過程。我們有兩個解決思路：一、系統(tǒng)同時支持兩種加密和不加密的會議，加密的會議暫不支持瀏覽器。二、提供服務(wù)器層的SDK，讓用戶可以基于SDK建立一個管理平臺專門用于授權(quán)。這樣在瀏覽器端的接入時，在服務(wù)器分發(fā)之前可以進行完全解密再加密。這樣的分發(fā)建議第三方在自己可信任的機房搭建服務(wù)器來實現(xiàn)轉(zhuǎn)接。

以上就是我今天分享的全部內(nèi)容，謝謝大家。

詳情請掃描圖中二維碼或點擊閱讀原文了解大會更多信息。

總結(jié)

以上是生活随笔為你收集整理的【线上圆桌 - 263】视频会议终端到终端的加密的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。