全社会数字化转型加速叠加实时通信技术的蓬勃发展,实时通信已经已经渗透到各行各业,成为了人们现代化生活中不可或缺的重要交流手段。关注【融云全球互联网通信云】了解更多
其中,WebRTC 的出现更是使实时通信技术得以广泛应用,它提供了一套几乎所有主流浏览器都支持的标准 API,让浏览器之间无插件化的音视频互通成为可能,大大降低了音视频开发的门槛。视频会议、视频招聘、远程医疗等等需要实时互动的场景中,都可以看到 WebRTC 的身影。
在 WebRTC 中,为了保证媒体传输的安全性,引入了 DTLS 和 SRTP 来对通信过程进行加密。DTLS 的作用、原理与 SSL/TLS 类似,都是为了使通信过程变得更安全。
本文作为互联网通信安全系列文的第二篇,主要分享 WebRTC 传输安全机制:DTLS 和 SRTP。
常用加密方法
加密技术
1. 对称加密
对称加密(Symmetric Cryptography),又称私钥加密,是最快速、最简单的一种加密方式,加密(encryption)与解密(decryption)用的是同样的密钥(secret key)。
对称加密有很多种算法,由于它效率很高,所以被广泛使用在很多加密协议中。对称加密通常使用的是相对较小的密钥,一般小于 256 bit。密钥越大,加密越强,但加密与解密的过程也就越慢。密钥的大小既要照顾到安全性,也要照顾到效率。
2. 非对称加密
非对称加密(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:04b0ce3c5f2c4a9fbe7c2257c1328438f3378f74e9f528b6e27a00b4
4eee4c19e5e6b2cb6cab09f796bcf8c05102b2a4bcdc753d91cc4f431f558c
845a1ba6f1ce
命名为 Spk;
ECDH Client Paramter
PubKey:0454e8fbef1503109d619c39be0ccaf89efa3c3962300476465cbc6
6b15152cd8a900c45d506420f0123e65d8fbb70cb60b497893f81c5c2a0ef
2f4bc2da996d9e
记为 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_le
n) bytes of data
master_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 密钥。这样安全传输对称密钥,通信双方使用对称密钥对音视频数据进行加解密,这样效率高,同时也确保音视频数据完整安全。