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

返回192.168.1.1

最后更新：2022-04-14 00:23:23 手机定位技术交流文章

社会的数字革命加速了实时通信技术的迅速增长,它侵入了生活的各个方面,已成为人们日常生活中不可或缺和关键的通信方法。

其中，随着WebRTC的采用,实时通信技术的使用更加频繁。它提供一套得到几乎所有受欢迎的浏览器支持的标准。启用在浏览器之间没有插入的音频视频的连接。视听生产的障碍大大降低。提供视频会议、录象招聘、远程医疗和其他类似服务,需要实时参与。我们可以看到 WebRTC 的体形。

在WebRTC中引入了DTLS和SRTP来加密通信程序,以确保媒体传输的安全,DTLS的作用和推理与SSL/TLS相似,其目的都是使通信程序更加安全。

这是《因特网通信安全丛书》中的第二篇文章,侧重于WebRTC传输安全技术,如DTLS和SRTP。

常用加密方法

加密技术

1. 对称加密

对称加密,根据创用CC授权使用又称私钥加密，这是最简单、最直接的加密方法加密和解密使用相同的密钥。

有几种对称加密技术。由于它效率很高，因此,它被广泛用于各种加密方案。对称加密通常使用很小的钥匙。在大多数情况下,不到256比特。密钥越大，加密越强，然而,加密和解密程序越慢钥匙的大小必须从安全角度加以考虑。也要照顾到效率。

2. 非对称加密

非对称加密,又称公用钥匙加密,使用一对钥匙、公用钥匙和私人钥匙,以非常安全的方式加密和解密数据。

只有其中一方可以稳妥地保留私人钥匙。不能外泄，另一方面,公用钥匙可以提供给任何要求公用钥匙的人。用于加密密钥之一的对称加密。解密需要另一个关键。比如，你向银行请求公钥，银行将公钥发给你，你用公用钥匙加密通讯只有拥有私人钥匙的银行才能解码你的数据与对称加密相反,银行不必通过因特网传送私人钥匙。安全性大大提高。

对称加密和对称加密之间的区别可描述如下:

(1) 由于对称加密使用与解密相同的密钥,因此速度很快,但由于需要将密钥传送到网络,因此不安全。

(2) 非对称加密是安全的,因为它使用公用和私用一对钥匙,但加密和解密缓慢。

(3) 答案是在公用钥匙中加密对称加密的钥匙,然后将其发送出去,接收人使用私人钥匙解码对称加密的钥匙,然后当事人可以使用对称加密进行通信。

数字签名

数字签名是一种特定的加密检查代码,或核对和,与使用非对称加密密钥加密方法发出的信息相连。

数字签字的主要目的是防止电文被篡改,一旦攻击者篡改电文,将电文与校验总和相匹配,接收者即可发现电文被篡改。

（数字签名的过程）

发件人A使用私人密钥加密生成签名(通过提供报告摘要(报告文本使用HAshi方法如SHA-1形成)。在提交正式报告的同时,还将其送交了接受方B。通过计算所获得的信息,收受人B收到两份报告摘要。对两份报纸摘要的比较表明,该报是否被篡改。即：

(1) 使用与发件人相同的 " 桥 " 技术,明确声明产生摘要;1

(2) 为创建摘要2,签字使用公用钥匙解码。

（数字签名的过程）

数字证书

数字证书由若干公认和可靠的签发证书组织颁发,不易伪造。

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

接受者可以利用数字证书认证对方的身份。当收件人(例如,当浏览器(例如)从另一端(例如,网络服务器)获得证书时),签发当局的数字签字将生效。一般来说，接收人预先安装了几个经常使用的(有公用钥匙的)签字签发机构的证书。可用于验证签字的公用前钥匙。

DTLS协议

DTLS（Datagram Transport Level Security，数据报安全协议），由于可能发生数据包丢失或在联合民主党背景下重新确定优先次序,联合民主党的成套数据目前无法获取。可定制和改进 UDP 的 TLS 协议。就联合民主党的通信而言,DTLS提供了一个安全的选择。除其他外,它可以防止信息被窃听、篡改或身份被冒充。WebRTC中DTLS的应用分为两部分:[SRTP](钥匙)的协商和管理以及提供[数据通道]的加密渠道()。

DTLS协议可以采取以下行动:

(b) 所有信息均经过加密,第三方不得窃听;
(b) 存在数据签字和核查机制,如果被篡改,可以由通信双方确定;
拥有身份证件,以防止冒名顶替者假冒身份。

协议栈

在WebRTC中引入DTLS加密 RTP可保证媒体通信。在使用DTLS谈判加密密钥后,RTP还需要更新到SRTP,以便通过密钥加密进行通信。

(《DTLS议定书》)

以下是DTLS握手协议程序(根据RFC 6347)。

(《DTLS握手议定书》的处理)

TLS 和 DTLS 之间的握手方法通常不变,有以下修改和具体描述:

为防止多斯攻击,在HelloVerify Request中使用DTLS的做法越来越普遍。
TLS 没有提交证书请求, 证书请求也是不必要的; 这是反向认证, 即服务器验证客户的身份。
DTLS的记录室现在包括Epoch和序列号;客户你好现在包括Cookie;手握现在包括零散信息(以防止MTUs超过UDP)。为了适应民进联的空投袋和脆弱的强化措施,所有事情都要适应。(参考RFC 6347)
DTLS发送的最后一条警报信息是客户端加密的警报信息如果您需要解密, 您可以直接对客户端作出反应。事实上,服务器应该对加密通信作出反应。我们的服务器反应明确设计解密什么客户加密在警报包。

DTLS通信与记录室协议有关。联合民主党被称为 " 录音馆 " 。握手、更改密码或应用程序数据都是录音室的例子。

RFC 4347在记录室协议描述中提及,有三个录音室软件包:

DTLS 明确录音室,DTLSPlainext。
DTLS 压缩压缩数据,很少使用。
在 ChangeCipherSpec、 DTLSCphertext、加密数据之后

没有明确的实地说明是何种类型的信息。然而,它可以依据背景和实质加以确定。例如, ChangeCifferSpeec 可用于类型。这显然是一纸空文。除了完结的握手之外最经常使用的是普通文字。

SRTP密钥协商

角色协商

在DTLS协议中,通信双方分为客户和服务器,WebRTC中的DTLS咨询身份在SDP中界定。

参照SDP-解剖DTLS参数,观察以下说明

a=setup:active

RFFC4145 属性配置

配置: 活动, 以客户端开始协商

设置:与往常一样,被动,在谈判开始之前。

设置: actpass 作为客户端开始协商。作为服务器, 您必须等待协商开始。

自签证证书

使用WebRTC, 对话的参与者通常无法获得由众所周知的根证书签发人签发的身份证明书,而后者通常是唯一的选择。

在实际应用情况下,通过安全信使频道(https)交换SDP,并可能实现SDP的安全完整。

证书指纹在 SDP 中的参照SDP-解剖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。

需要证明指纹才能完成双方通信方的身份。

欢迎欢迎信件分析咨询

Clieen Hello和Server Hello 查查版本、 CipherSits、 Random 和 DTLS 扩展。

(欢迎来电克莱尔)

(ServerHello发来的信件)

版本:客户指定了他可以支持或希望使用的最新版本。和DTLS1.2一样当服务器得到这个信息时,回答,基于您可以支持或希望使用的版本。类似DTLS1. 照片来自Flickr用户pic.最后,商定的版本为DTLS1.0,但须遵守。
CephellSits:客户提供了他能够支持的加密软件包。

加密软件包,如ECDSA_WITH_AES_256_CBC_SHA (0xc014),指定证书类型、关键生成算法、简易算法等等。
随机 : 包含在 Master Secret 的生成中, 是来自双方的随机数字。 Master Secret 将被用于生成主密钥并SRTP 键导出。 (详情请参见 [Export SRTP 密钥] 。)
扩展名:客户指定要使用的扩展程序。服务器可以响应自己的帮助。例如,Clit在配置会话 Ticket TLS 扩展时,但服务器没有回复。因此,这一延长将不再使用。

Cipher Suites

（Cipher Suites）

在欢迎信中,使用加密软件包的 IANA 注册名称。

IANNA 根据协议/关键交换算法/机构算法指定名称

加密/ Hash 算法的算法

例如：

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扩展协议在客户 Hello 和 Server Hello 扩展文件中提供,所有TLS扩展都与TLS扩展有关。

以下是WebRTC使用的扩展名:

(WebRTC附加)

使用_strtp: DTLS 握手完成( 完成) 后, 使用 SRTP 传输数据; DTLS 生成 SRTP 键。

一、二. SRTP保护项目和Srtp_mki项目

身份验证

需要证明指纹才能完成双方通信方的身份。详见【自签证名证书】部分。

（身份验证）

密钥交换

服务器密钥交换用于将服务器端的公用密钥传送到客户端。有两种设想:

如果服务端使用RSA技术,则无法发送此电文,因为证书方法官使用RSA技术时说明了RSA算法中使用的公用钥匙,因此无法发送该电文,因为证书中说明了RSA算法中使用的公用钥匙。
因为客户和服务器只知道自己的私人密钥, 他们的私人密钥是不同的, 他们可以根据各自的数学属性计算相同的共享密钥, DH 算法根据对方的公用密钥和自己的私人密钥生成共享密钥。

（Server Key Exchange）

Cliet Key Exchange 用于向服务器端交付 Cliet 的公用密钥。

如果使用RSA算法进行关键咨询,则使用服务器端端的RSA将加密的公用密钥传送到服务器端,并加密服务器端的高级密钥。
如果钥匙是使用DH算法谈判的证书上也没有提到过将 DH 密钥传递到客户端 DH 算法服务器端,计算共享密钥由于关键交换,需要做大量工作。客户端和服务器都获得了RSA 键。或使用 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(预设总机)计算共享密钥。

鉴于服务器的椭圆私人密钥是Ds,客户的Dc计算共享密钥的计算方法如下:使用ECC电子加密技术(ECDH、ECDHE、ECDHE、ECDSA)计算共享密钥。

S = Ds * Cpk = Dc * Spk

这个共享的钥匙S 就是我们在预订的 RFC 制版论文上看到的

一套总制计算法计算法

一套总制计算法计算法过程如下，可参考 Computing the Master Secret。

master_secret=PRF(pre_master_secret,"master

secret",ClientHello.random+ ServerHello.random)[0..47];

估计主控集长度为48字节。这是在客户欢迎函中由Hello. Random和服务器Hello. Random所发的。PRF代表假冒功能。包含在咨询的加密包中。

RFC57054用于利用总务秘书输出SRTP加密数字部门序列。

cliet_random、服务器_random、硕士_secret:

key_block=PRF(master_secret,"EXTRACTOR-

dtls_srtp",client_random+server_random)[length]

在DTLS-SRTP版本4. 2 中,关键出处说明预期字节序列长度。

2*

(SRTPSecurityParams.master_key_len+SRTPSecurityParams.master_salt_le

n) bytes of data

用户_rtp 配置文件中定义了 master_key_len 和 master_salt_len 的值。

SRTP_AES128_CM_是我们使用的配置文件。

HMAC_SHA1_80,使用以下配置配置配置:

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字节。

SRTP 键导出

SRTP加密数字段序列在 DTLS- SRTP 4. 2. 2. Key 出处指定字节序列 :

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

因此,我们获得了客户和服务器使用的SRTP加密参数:主控和主标。

Clientkey=client_master_key+client_master_salt;

Serverkey=server_master_key+server_master_salt;

在导出密钥后, 使用关键初始化 SRTPSsession 键以确保数据安全和完整性。 Cliet 用Clitkey 加密数据, 将其传送到服务器, 并解密使用 Serverkeys 接收的数据。

WebRTC 包含通信所涉双方分别是签字证书(指印:a=指印)和DTLS(设置)的作用(a=设置),它们已分别添加到Sdp中。使用安全信使渠道(https)。与 sdp 交流参与者协商。在DTLS握手期间,这是首次签署和核实数据。如果攻击者篡改了数据校验失败，双方可立即进入该交换所。

加密部件由传输双方商定。交换双方的公钥，这是一种不对称加密。SRTP 密钥已加密。用对称加密, 收件人使用私人密钥解密 SRTP 密钥。因此,对称钥匙以这种方式安全转移。为了解密音频和视频数据,双方使用了对称键。这样效率高，它还保护音频和视频数据的完整性和安全性。

本文由在线网速测试整理编辑，转载请注明出处。