共计 7320 个字符，预计需要花费 19 分钟才能阅读完成。
全社会数字化转型减速叠加实时通信技术的蓬勃发展，实时通信曾经曾经渗透到各行各业，成为了人们现代化生存中不可或缺的重要交换伎俩。关注【融云寰球互联网通信云】理解更多
其中，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 密钥。这样平安传输对称密钥，通信单方应用对称密钥对音视频数据进行加解密，这样效率高，同时也确保音视频数据残缺平安。
