WebRTC 传输安全机制:DTLS 和 SRTP

在 WebRTC 中,为了保证媒体传输的安全性,引入了 DTLS 和 SRTP 来对通信过程进行加密。DTLS 的作用、原理与 SSL/TLS 类似,都是为了使通信过程变得更安全。

常用加密方法

加密技术

1. 对称加密

对称加密(Symmetric Cryptography),又称私钥加密,是最快速、最简单的一种加密方式,加密(encryption)与解密(decryption)用的是同样的密钥(secret key)。

对称加密有很多种算法,由于它效率很高,所以被广泛使用在很多加密协议中。对称加密通常使用的是相对较小的密钥,一般小于 256 bit。密钥越大,加密越强,但加密与解密的过程也就越慢。密钥的大小既要照顾到安全性,也要照顾到效率。

2. 非对称加密

非对称加密(Asymmetric Cryptography),又称公钥加密。它使用了一对密钥,公钥(public key)和私钥(private key),为数据的加密与解密提供了一个非常安全的方法。

私钥只能由一方安全保管,不能外泄,而公钥则可以发给任何请求它的人。非对称加密使用这对密钥中的一个进行加密,而解密则需要另一个密钥。比如,你向银行请求公钥,银行将公钥发给你,你使用公钥对消息加密,那么只有私钥的持有人——银行才能对你的消息解密。与对称加密不同的是,银行不需要通过网络发送私钥,安全性大大提高。

对称加密和非对称加密的区别,总结如下:

  1. 对称加密的加密与解密使用的是同样的密钥,所以速度快,但由于需要将密钥在网络传输,所以安全性不高。

  2. 非对称加密使用了一对密钥,公钥与私钥,所以安全性高,但加密与解密速度慢。

  3. 解决方案是将对称加密的密钥使用非对称加密的公钥进行加密,然后发送出去,接收方使用私钥进行解密得到对称加密的密钥,然后双方可以使用对称加密来进行沟通。

数字签名

数字签名是附加在报文上的特殊加密校验码,即所谓的校验和,利用了非对称加密密钥加密技术。

数字签名的主要作用是防止报文被篡改,一旦报文被攻击者篡改,通过将其与校验和进行匹配,可以立刻被接收者发现。数字签名的过程如下图所示:WebRTC 传输安全机制:DTLS 和 SRTP_第1张图片

数字签名的过程

发送者 A 将报文摘要(报文通过 SHA-1 等哈希算法生成摘要)通过私有密钥加密生成签名,与明文报文一起发给接收者 B,接收者 B 通过对收到的信息进行计算后得到两份报文摘要,比较这两份报文摘要是否相等可以验证报文是否被篡改,即:

  1. 明文报文通过使用与发送端相同的哈希算法生成摘要 1;

  2. 签名通过公开密钥解密后生成摘要 2。

WebRTC 传输安全机制:DTLS 和 SRTP_第2张图片

数字签名的过程

数字证书

数字证书是由一些公认可信的证书颁发机构签发的,不易伪造。包括如下内容:

  • 证书序列号

  • 证书签名算法

  • 证书颁发者

  • 有效期

  • 公开密钥

  • 证书签发机构的数字签名

数字证书可以用于接收者验证对端的身份。接收者(例如浏览器)收到某个对端(例如 Web 服务器)的证书时,会对签名颁发机构的数字签名进行检查,一般来说,接收者事先就会预先安装很多常用的签名颁发机构的证书(含有公开密钥),利用预先的公开密钥可以对签名进行验证。

本文福利, 免费领取C++音视频学习资料包、技术视频,内容包括(音视频开发,面试题,FFmpeg ,webRTC ,rtmp ,hls ,rtsp ,ffplay ,编解码,推拉流,srs)↓↓↓↓↓↓见下面↓↓文章底部点击免费领取↓↓

DTLS 协议

DTLS(Datagram Transport Level Security,数据报安全协议),基于 UDP 场景下数据包可能丢失或重新排序的现实情况,为 UDP 定制和改进的 TLS 协议。DTLS 提供了 UDP 传输场景下的安全解决方案,能防止消息被窃听、篡改、身份冒充等问题。在 WebRTC 中使用 DTLS 的地方包括两部分:协商和管理 [SRTP]() 密钥和为 [DataChannel]() 提供加密通道。

DTLS 协议能够做到以下几点:

  • 所有信息通过加密传播,第三方无法窃听;

  • 具有数据签名及校验机制,一旦被篡改,通信双方立刻可以发现;

  • 具有身份证书,防止其他人冒充。

协议栈

在 WebRTC 中,通过引入 DTLS 对 RTP 进行加密,使得媒体通信变得安全。通过 DTLS 协商出加密密钥之后,RTP 也需要升级为 SRTP,通过密钥加密后进行通信。协议栈如下图所示:

WebRTC 传输安全机制:DTLS 和 SRTP_第3张图片

(DTLS 协议栈)

DTLS 握手协议流程如下,(参考 RFC6347)。

WebRTC 传输安全机制:DTLS 和 SRTP_第4张图片

(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:F
4:70:03:E7:43:91:73:23:5。

使用证书指纹,完成通信双方的身份验证。

算法协商 - Hello 消息 

ClienHello 和 ServerHello 协商 DTLS 的 Version、CipherSuites、Random、Extensions。

WebRTC 传输安全机制:DTLS 和 SRTP_第5张图片

(ClienHello 消息)

WebRTC 传输安全机制:DTLS 和 SRTP_第6张图片

(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

WebRTC 传输安全机制:DTLS 和 SRTP_第7张图片

(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 传输安全机制:DTLS 和 SRTP_第8张图片

(WebRTC 用到的扩展)

use_srtp: DTLS 握手完成后 (Finished),使用 SRTP 传输数据,DTLS 生成 SRTP 的密钥。

ClientHello 中的扩展信息定义了 RFC5764 4.1.2. SRTP Protection Profiles 和 srtp_mki。

身份验证

使用证书指纹,完成通信双方的身份验证。详见【自签证名证书】部分。

WebRTC 传输安全机制:DTLS 和 SRTP_第9张图片

(身份验证)

密钥交换

Server Key Exchange 用来将 Server 端使用的公钥,发送给 Client 端。分为两种情况:

  • RSA 算法:如果服务端使用的是 RSA 算法,可以不发送这个消息,因为 RSA 算法使用的公钥已经在 Certificate 中描述。

  • DH 算法,是根据对方的公钥和自己私钥计算共享密钥。因为 Client 和 Server 都只知道自己的私钥,和对方的公钥;而他们的私钥都不同,根据特殊的数学特性,他们能计算出同样的共享密钥。WebRTC 传输安全机制:DTLS 和 SRTP_第10张图片

    (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 密钥步骤示例】的过程。 

WebRTC 传输安全机制:DTLS 和 SRTP_第11张图片

(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 密钥

计算出 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 密钥。这样安全传输对称密钥,通信双方使用对称密钥对音视频数据进行加解密,这样效率高,同时也确保音视频数据完整安全。

本文福利, 免费领取C++音视频学习资料包、技术视频,内容包括(音视频开发,面试题,FFmpeg ,webRTC ,rtmp ,hls ,rtsp ,ffplay ,编解码,推拉流,srs)↓↓↓↓↓↓见下面↓↓文章底部点击免费领取↓↓

你可能感兴趣的:(音视频开发进阶,音视频,视频编解码,实时音视频,实时互动,webrtc)