RTC音视频通讯加密

在实时音视频互动过程中，由于很多信息是非常重要的，用户需要对通讯过程以及媒体流加密，从而保障用户的数据安全。同时加密是全方位的，从信令，到流媒体等所有的网络传输媒介，都是需要进行加密保护的。

加密的方式

信令加密

信令通道中传输的信息对用户的数据及隐私安全极为重视，传输层 TLS 加密和客户端 256 位 AES 加密可以为用户数据提供有效保护。

a.传输层加密：用户客户端和服务器端与 RTM 服务器之间数据传输采用 TLS 加密。

b.消息加密：用户每一条消息都提供了端到端的 AES_256_GCM 加密保护。

c.Token 权限控制：提供基于时间限制的访问权限控制策略，确保客户端在可控状态下进行通讯。

媒体流加密

指通过由App开发者控制的唯一的密钥和盐为 App 中的音视频流加密。RTC的SDK 提供媒体流加密功能以确保传输过程中数据的保密性，可以根据实际的业务场景合理应用。加密的类型包含：

AES_128_XTS
AES_128_ECB
AES_256_XTS
SM4_128_ECB
AES_128_GCM
AES_256_GCM
AES_128_GCM2（推荐）
AES_256_GCM2（推荐）

端到端加密

在数据安全要求较高的场景下，除了使用媒体流加密功能，你还可以使用端到端加密功能，实现在发送端设备上对媒体流进行加密、在接收端设备上对媒体流进行解密，确保数据不会在传输过程中被第三方获取。基于端到端加密的方式，用户可以实现自定义加密算法进行音视频通讯。

加密方式对比

方式	兼容性	安全性	复杂度	设备适配度
媒体流加密	高	中	中	中
端到端加密	中	高	高	低

加密模式介绍

1，盐(Salt)：是由伪随机数生成器生成的随机数，在生成密钥（KEY）时会和口令一起输入单向散列函数。

2，密钥(KEY)：是根据秘密的口令生成的。

3，ECB(Electronic Codebook Mode)电码本模式。

如下图所示，将信息分组，然后对每组信息使用key加密，其实就是无模式加密，图中P为明文，E为加密算法，C为密文。

4，XTS(XEX tweak ciphertext stealing) 带密文挪用模式

初始值TW也叫teeak值，先经过加密后得到T1，然后每乘一次阿尔法a得到一个Ti；分组明文先与Ti异或，然后再经过加密，加密后结果与当前的Ti异或，结果为本组的密文。

如果最后一组明文为d bit数长度小于分组长度n，我们需要对最后一组和倒数第二组特殊处理，如下图，把倒数第二组得到的明文的最后前d bit 最后最后一组的密文输出，n-d bit 拼接到最后一组明文的后面组成n bit，进过加密后，输出密文作为倒数第二组的最终密文输出。

从算法结构上来看，初始值TW不仅经过加密模块，同时又称上阿尔法a，明文也经过加密模块，这里的乘法是基于伽罗化域的。相比于CTR来说，这里的安全性更高，因为CTR值是每次简单递增，而XTS是经过了有限域乘法计算的。

5，GCM(Galios Count Mode)伽罗华域计数模式:

从下图来看，GCM加密模式是在计数器模式上多增加了一个GHASH的功能，这样，通过对比TAG值来确定数据源是否被篡改；图上H值是用密钥对128bit 0加密所得；MultH为GF(2,128)的乘法，密文的获取和计数器模式一样，，每一级的tag值为上一级tag * H 再异或上输出密文；最后一个级tag值为迭代最后一级乘H，然后与A|C长度异或，再乘H，再与counter0加密值异或；GCM最大的功能就是增加了Hash功能，防止信息被篡改。我们将加密后的消息，与Auth tag一起发送出去，接受者将数据解密后，同时计算Auth tag值，如果计算的值与消息中附加的值一致，我们可以认为消息是没被篡改的。

流程介绍

一个典型的RTC流加/解密流程，如下：

加密端支持情况

端	开发语言	AEC加密	国密	自定义加密
Android	C++/Java	支持	支持	支持
iOS	C++/Swift	支持	支持	支持
Windows	C++	支持	支持	支持
Mac	C++	支持	支持	支持
Web	JS/Wasm	部分支持	部分支持	不支持
小程序	JS	不支持	不支持	不支持
嵌入式	C++	支持	支持	支持
国产化桌面应用	C++	支持	支持	支持
可穿戴iot	C++	不支持	不支持	不支持
服务端	C++/Go	支持	支持	不支持