內容源自263音視頻架構師 賀曉敏在視頻會議下半場圓桌上的分享。

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

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

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

 #視頻會議安全背景介紹

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

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

 #端到端的加密

傳統加密技術共有三種，對稱加密、非對稱加密和TLS加密。

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

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

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

 #基于WebRTC的會議數據加密

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

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

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

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

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

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

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

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

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

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

之后則是數據的加密發送過程。數據的加密和信令所有區別。如果要求每個人的數據加密后發出，服務器不僅不能解密，還要求所有終端都可以接收，這就需要一個授權的過程。
 

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

注意這里公鑰當作私鑰，私鑰當作公鑰，是一個反向的過程。這樣，終端B就可以接收服務器的數據流。B已經得到授權可以使用A的私鑰進行解密A的加密數據。這樣，通過服務器轉發加密的數據通道就已經完成了。

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

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

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

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

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

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

 #問題

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

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

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

以上就是我今天分享的全部內容，謝謝大家。