全社会数字化转型加速叠加实时通信技术的蓬勃发展，实时通信已经已经渗透到各行各业，成为了人们现代化生活中不可或缺的重要交流手段。关注【融云全球互联网通信云】了解更多
其中，WebRTC 的出现更是使实时通信技术得以广泛应用，它提供了一套几乎所有主流浏览器都支持的标准 API，让浏览器之间无插件化的音视频互通成为可能，大大降低了音视频开发的门槛。视频会议、视频招聘、远程医疗等等需要实时互动的场景中，都可以看到 WebRTC 的身影。
在 WebRTC 中，为了保证媒体传输的安全性，引入了 DTLS 和 SRTP 来对通信过程进行加密。DTLS 的作用、原理与 SSL/TLS 类似，都是为了使通信过程变得更安全。
本文作为互联网通信安全系列文的第二篇，主要分享 WebRTC 传输安全机制：DTLS 和 SRTP。
常用加密方法
加密技术
- 对称加密
对称加密（Symmetric Cryptography），又称私钥加密，是最快速、最简单的一种加密方式，加密（encryption）与解密（decryption）用的是同样的密钥（secret key）。
对称加密有很多种算法，由于它效率很高，所以被广泛使用在很多加密协议中。对称加密通常使用的是相对较小的密钥，一般小于 256 bit。密钥越大，加密越强，但加密与解密的过程也就越慢。密钥的大小既要照顾到安全性，也要照顾到效率。
- 非对称加密
非对称加密（Asymmetric Cryptography），又称公钥加密。它使用了一对密钥，公钥（public key）和私钥（private key），为数据的加密与解密提供了一个非常安全的方法。
私钥只能由一方安全保管，不能外泄，而公钥则可以发给任何请求它的人。非对称加密使用这对密钥中的一个进行加密，而解密则需要另一个密钥。比如，你向银行请求公钥，银行将公钥发给你，你使用公钥对消息加密，那么只有私钥的持有人——银行才能对你的消息解密。与对称加密不同的是，银行不需要通过网络发送私钥，安全性大大提高。
对称加密和非对称加密的区别，总结如下：
（1）对称加密的加密与解密使用的是同样的密钥，所以速度快，但由于需要将密钥在网络传输，所以安全性不高。
（2）非对称加密使用了一对密钥，公钥与私钥，所以安全性高，但加密与解密速度慢。
（3）解决方案是将对称加密的密钥使用非对称加密的公钥进行加密，然后发送出去，接收方使用私钥进行解密得到对称加密的密钥，然后双方可以使用对称加密来进行沟通。
数字签名
数字签名是附加在报文上的特殊加密校验码，即所谓的校验和，利用了非对称加密密钥加密技术。
数字签名的主要作用是防止报文被篡改，一旦报文被攻击者篡改，通过将其与校验和进行匹配，可以立刻被接收者发现。数字签名的过程如下图所示：
（数字签名的过程）
发送者 A 将报文摘要（报文通过 SHA-1 等哈希算法生成摘要）通过私有密钥加密生成签名，与明文报文一起发给接收者 B，接收者 B 通过对收到的信息进行计算后得到两份报文摘要，比较这两份报文摘要是否相等可以验证报文是否被篡改，即：
（1）明文报文通过使用与发送端相同的哈希算法生成摘要 1；
（2）签名通过公开密钥解密后生成摘要 2。
（数字签名的过程）
数字签名
数字证书是由一些公认可信的证书颁发机构签发的，不易伪造。包括如下内容：
- 证书序列号
- 证书签名算法
- 证书颁发者
- 有效期
- 公开密钥
- 证书签发机构的数字签名
数字证书可以用于接收者验证对端的身份。接收者（例如浏览器）收到某个对端（例如 Web 服务器）的证书时，会对签名颁发机构的数字签名进行检查，一般来说，接收者事先就会预先安装很多常用的签名颁发机构的证书（含有公开密钥），利用预先的公开密钥可以对签名进行验证。
DTLS 协议
DTLS（Datagram Transport Level Security，数据报安全协议），基于 UDP 场景下数据包可能丢失或重新排序的现实情况，为 UDP 定制和改进的 TLS 协议。DTLS 提供了 UDP 传输场景下的安全解决方案，能防止消息被窃听、篡改、身份冒充等问题。在 WebRTC 中使用 DTLS 的地方包括两部分：协商和管理 [SRTP]() 密钥和为 [DataChannel]() 提供加密通道。
DTLS 协议能够做到以下几点：
- 所有信息通过加密传播，第三方无法窃听；
- 具有数据签名及校验机制，一旦被篡改，通信双方立刻可以发现；
- 具有身份证书，防止其他人冒充。
协议栈
在 WebRTC 中，通过引入 DTLS 对 RTP 进行加密，使得媒体通信变得安全。通过 DTLS 协商出加密密钥之后，RTP 也需要升级为 SRTP，通过密钥加密后进行通信。协议栈如下图所示：
（DTLS 协议栈）
DTLS 握手协议流程如下，（参考 RFC6347）。
（DTLS 握手协议流程）
TLS 和 DTLS 的握手过程基本上是一致的，差别以及特别说明如下：
- DTLS 中 HelloVerifyRequest 是为防止 DoS 攻击增加的消息。
- TLS 没有发送 CertificateRequest，这个也不是必须的，是反向验证即服务器验证客户端。
- DTLS 的 RecordLayer 新增了 Epoch 和 SequenceNumber；ClientHello 中新增了 Cookie；Handshake 中新增了 Fragment 信息（防止超过 UDP 的 MTU），都是为了适应 UDP 的丢包以及容易被攻击做的改进。（参考 RFC 6347）
- DTLS 最后的 Alert 是将客户端的 Encrypted Alert 消息，解密之后直接响应给客户端的，实际上 Server 应该回应加密的消息，这里我们的服务器回应明文是为了解析客户端加密的那个 Alert 包是什么。
RecordLayer 协议是和 DTLS 传输相关的协议，UDP 上是 RecordLayer，RecordLayer 上是 Handshake 或 ChangeCipherSpec 或 ApplicationData。
RecordLayer 协议定义参考 RFC4347，实际上有三种 RecordLayer 的包:
- DTLSPlaintext，DTLS 明文的 RecordLayer。
- DTLSCompressed，压缩的数据，一般不用。
- DTLSCiphertext，加密数据，在 ChangeCipherSpec 之后就是这种了。
没有明确的字段说明是哪种消息，不过可以根据上下文以及内容判断。比如 ChangeCipherSpec 是可以通过类型，它肯定是一个 Plaintext。除了 Finished 的其他握手，一般都是 Plaintext。
SRTP 密钥协商
角色协商
在 DTLS 协议，通信的双方有 Client 和 Server 之分。在 WebRTC 中 DTLS 协商的身份是在 SDP 中描述的。
描述如下，参考 SDP-Anatomy 中 DTLS 参数
a=setup:active
setup 属性在 RFC4145
setup:active，作为 client，主动发起协商
setup:passive, 作为 sever，等待发起协商
setup:actpass, 作为 client，主动发起协商。作为 server，等待发起协商。
自签证证书
在 WebRTC 中，通信的双方通常将无法获得由知名根证书颁发机构 (CA) 签名的身份验证证书，自签名证书通常是唯一的选择。
在实际的应用场景中，SDP 是在安全的信令通道 (https) 完成交换的，SDP 的安全完整是可以做到的。RFC4572 定义一种机制，通过在 SDP 中增加自签名证书的安全哈希，称为“证书指纹”。
证书指纹在 SDP 中的描述如下，参考 SDP-Anatomy 中 DTLS 参数
a=fingerprint:sha-256 49:66:12:17:0D:1C:91:AE:57:4C:C6:36:DD:D5:97:D2:7D:62:C9:9A:7F:B9:A3:F4:70:03:E7:43:91:73:23:5。使用证书指纹，完成通信双方的身份验证。
算法协商 - Hello 消息
ClienHello 和 ServerHello 协商 DTLS 的 Version、CipherSuites、Random、Extensions。
（ClienHello 消息）
（ServerHello 消息）
- Version：Client 给出自己能支持的或者要使用的最高版本，比如 DTLS1.2。Server 收到这个信息后，根据自己能支持的或者要使用的版本回应，比如 DTLS1.0。最终以协商的版本也就是 DTLS1.0 为准。
- CipherSuites：Client 给出自己能支持的加密套件 CipherSuites，Server 收到后选择自己能支持的回应一个，比如 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc014)，加密套件确定了证书的类型、密钥生成算法、摘要算法等。
- Random：双方的随机数，参与到生成 MasterSecret。MasterSecret 会用来生成主密钥，导出 SRTP 密钥。（详见 【导出 SRTP 密钥】部分）
- Extensions：Client 给出自己要使用的扩展协议，Server 可以回应自己支持的。比如 Client 虽然设置了 SessionTicket TLS 这个扩展，但是 Server 没有回应，所以最终并不会使用这个扩展。
Cipher Suites
（Cipher Suites）
在 Hello 消息中加密套接字使用 IANA 中的注册的名字。
IANA 名字由 Protocol/Key Exchange Algorithm/ Authentication Algorithm/
Encryption Algorithm/Hash Algorithm 的描述组成。
例如：
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 的含义如下：
- Protocol: Transport Layer Security (TLS)
- Key Exchange: Elliptic Curve Diffie-Hellman Ephemeral (ECDHE)
- Authentication: Rivest Shamir Adleman algorithm (RSA)
- Encryption: Advanced Encryption Standard with 128bit key in Galois/Counter mode (AES 128 GCM)
- Hash: Secure Hash Algorithm 256 (SHA256)
Extension
DTLS 的扩展协议，是在 ClientHello 和 ServerHello 的 Extensions 信息中指定的，所有的 TLS 扩展参考 TLS Extensions。
下面列出 WebRTC 用到的扩展：
（WebRTC 用到的扩展）
use_srtp: DTLS 握手完成后 (Finished)，使用 SRTP 传输数据，DTLS 生成 SRTP 的密钥。
ClientHello 中的扩展信息定义了 RFC5764 4.1.2. SRTP Protection Profiles 和 srtp_mki。
身份验证
使用证书指纹，完成通信双方的身份验证。详见【自签证名证书】部分。
（身份验证）
密钥交换
Server Key Exchange 用来将 Server 端使用的公钥，发送给 Client 端。分为两种情况：
- RSA 算法：如果服务端使用的是 RSA 算法，可以不发送这个消息，因为 RSA 算法使用的公钥已经在 Certificate 中描述。
- DH 算法，是根据对方的公钥和自己私钥计算共享密钥。因为 Client 和 Server 都只知道自己的私钥，和对方的公钥；而他们的私钥都不同，根据特殊的数学特性，他们能计算出同样的共享密钥。
（Server Key Exchange）
Client Key Exchange 用来将 Client 使用的公钥，发送给 Server 端。
- RSA 算法：如果密钥协商使用的 RSA 算法，发送使用 server 端 RSA 公钥，对 premaster secret 加密发送给 server 端。
- DH 算法：如果密钥协商使用 DH 算法，并且在证书中没有描述，在将客户端使用的 DH 算法公钥发送给 Server 端，以便计算出共享密钥。KeyExchange 的结果是，Client 和 Server 获取到了 RSA Key，或通过 DH 算法计算出共享密钥。详见 【导出 SRTP 密钥步骤示例】的过程。
（Client Key Exchange）
导出 SRTP 密钥步骤示例
上面介绍了 DTLS 的过程，以下通过结合上面例子给出的实际数据，简单说明 SRTP 密钥的导出步骤。
协商的加密套件：TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
KeyExchange交换的算法公钥：ECDH Server Parameter
Pubkey:04b0ce3c5f2c4a9fbe7c2257c1328438f3378f74e9f528b6e27a00b44eee4c19e5e6b2cb6cab09f796bcf8c05102b2a4bcdc753d91cc4f431f558c845a1ba6f1ce命名为 Spk;
ECDH Client Paramter
PubKey:0454e8fbef1503109d619c39be0ccaf89efa3c3962300476465cbc66b15152cd8a900c45d506420f0123e65d8fbb70cb60b497893f81c5c2a0ef2f4bc2da996d9e记为 Cpk;
根据 ECDHE 算法计算共享密钥 S(pre-master-secret)
假设 Server 的使用的椭圆曲线私钥为 Ds, Client 使用的 Dc，计算共享密钥的如下，参考 ECC 椭圆曲线加密算法 - ECDH,ECDHE,ECDSA
S = Ds Cpk = Dc Spk
这个共享密钥 S 就是我们在 RFC 文档中看到的 pre-master-secret
计算 master secret
计算 master secret 过程如下，可参考 Computing the Master Secret。
master_secret=PRF(pre_master_secret,"master
secret",ClientHello.random+ ServerHello.random)[0..47];计算出来的 master_secret 为 48 Bytes，其中 ClientHello.random 和 ServerHello.random 在 Hello 消息中给出。PRF 是伪随机数函数 (pseudorandom function)，在协商的加密套件中给出。
使用 master_secrete 导出 SRTP 加密参数字节序列，使用 RFC5705 4. Exporter Definition 给出的计算方式，使用参数：
master_secret，client_random，server_random 计算字节序列：
key_block=PRF(master_secret,"EXTRACTOR-dtls_srtp",client_random+server_random)[length]在 DTLS-SRTP 4.2. Key Derivation 中描述了需要的字节序列长度。
2*(SRTPSecurityParams.master_key_len+SRTPSecurityParams.master_salt_len) bytes of datamaster_key_len 和 master_salt_len 的值，在 user_srtp 描述的 profile 中定义。
我们使用的 profile 为 SRTP_AES128_CM_
HMAC_SHA1_80，对应的 profile 配置为：
SRTP_AES128_CM_HMAC_SHA1_80
cipher: AES_128_CM
cipher_key_length: 128
cipher_salt_length: 112
maximum_lifetime: 2^31
auth_function: HMAC-SHA1
auth_key_length: 160
auth_tag_length: 80也就是我们需要 (128/8+112/8)*2 = 60 bytes 字节序列。
导出 SRTP 密钥
计算出 SRTP 加密参数字节序列，在 DTLS-SRTP 4.2.Key Derivation 描述了字节序列含义：
client_write_SRTP_master_key[SRTPSecurityParams.master_key_len]; // 128 bits
server_write_SRTP_master_key[SRTPSecurityParams.master_key_len]; // 128 bits
client_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len]; // 112 bits
server_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len]; // 112 bits至此我们得到了，Client 和 Server 使用的 SRTP 加密参数：master_key 和 master_salt.
Clientkey=client_master_key+client_master_salt;
Serverkey=server_master_key+server_master_salt;密钥导出后，使用 key 初始化 SRTPSession，保证数据安全和完整，Client 使用 Clientkey 对数据进行加密，发送给服务端，使用 Serverkey 对收到的数据进行解密。
在 WebRTC 中，通信的双方分别产生自签名证书(a=fingerprint:)和 DTLS 角色（a=setup）添加到 sdp 中，通过安全的信令通道 (https)，进行 sdp 交换协商。在 DTLS 握手阶段，先进行数据签名和校验，如果数据被攻击者篡改，校验失败，通信双方立刻可以发现。
通信双方协商加密组件，交换双方的公钥，以非对称加密的方法，对 SRTP 密钥进行加密传输。接收方使用私钥进行解密得到对称加密的 SRTP 密钥。这样安全传输对称密钥，通信双方使用对称密钥对音视频数据进行加解密，这样效率高，同时也确保音视频数据完整安全。