互联网通信安全之 WebRTC 传输安全机制

全社会数字化转型加速叠加实时通信技术的蓬勃发展,实时通信已经已经渗透到各行各业,成为了人们现代化生活中不可或缺的重要交流手段。关注【融云全球互联网通信云】了解更多

其中,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)解决方案是将对称加密的密钥使用非对称加密的公钥进行加密,然后发送出去,接收方使用私钥进行解密得到对称加密的密钥,然后双方可以使用对称加密来进行沟通。

数字签名

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

数字签名的主要作用是防止报文被篡改,一旦报文被攻击者篡改,通过将其与校验和进行匹配,可以立刻被接收者发现。数字签名的过程如下图所示:

互联网通信安全之 WebRTC 传输安全机制_第1张图片
 (数字签名的过程)

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

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

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

互联网通信安全之 WebRTC 传输安全机制_第2张图片

 (数字签名的过程)

数字证书

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

  • 证书序列号
  • 证书签名算法
  • 证书颁发者
  • 有效期
  • 公开密钥
  • 证书签发机构的数字签名

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

DTLS协议

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

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

  • 所有信息通过加密传播,第三方无法窃听;
  • 具有数据签名及校验机制,一旦被篡改,通信双方立刻可以发现;
  • 具有身份证书,防止其他人冒充。

协议栈

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

互联网通信安全之 WebRTC 传输安全机制_第3张图片

 (DTLS 协议栈)

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

互联网通信安全之 WebRTC 传输安全机制_第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:F4:70:03:E7:43:91:73:23:5。

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

算法协商-Hello消息

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

互联网通信安全之 WebRTC 传输安全机制_第5张图片

 (ClienHello 消息)

互联网通信安全之 WebRTC 传输安全机制_第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 传输安全机制_第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 传输安全机制_第8张图片

 (WebRTC 用到的扩展)

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

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

身份验证

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

互联网通信安全之 WebRTC 传输安全机制_第9张图片

 (身份验证)

密钥交换

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

  • RSA 算法:如果服务端使用的是 RSA 算法,可以不发送这个消息,因为 RSA 算法使用的公钥已经在 Certificate 中描述。
  • DH 算法,是根据对方的公钥和自己私钥计算共享密钥。因为 Client 和 Server 都只知道自己的私钥,和对方的公钥;而他们的私钥都不同,根据特殊的数学特性,他们能计算出同样的共享密钥。

互联网通信安全之 WebRTC 传输安全机制_第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 传输安全机制_第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 加密参数字节序列,在 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 密钥。这样安全传输对称密钥,通信双方使用对称密钥对音视频数据进行加解密,这样效率高,同时也确保音视频数据完整安全。

你可能感兴趣的:(通信行业,WebRtc,DTLS,SRTP)