内容源自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建立一个管理平台专门用于授权。这样在浏览器端的接入时，在服务器分发之前可以进行完全解密再加密。这样的分发建议第三方在自己可信任的机房搭建服务器来实现转接。

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