聊聊webrtc媒体流加密密钥是怎么生出来的

前两天有个朋友问我，说他在做实时音视频开发的时候，经常听到DTLS、SRTP这些词，但具体密钥是怎么生成的根本搞不清楚。我说这事儿吧，确实不是一两句话能说明白的，但核心逻辑其实挺有意思的，今天咱们就掰开揉碎了聊一聊。

在实时通信场景下，音视频数据在网络上裸奔是一件相当危险的事情。你永远不知道中间有没有人在窥探你的视频通话内容。webrtc作为目前最主流的实时通信技术框架，从设计之初就把安全放在相当重要的位置。而密钥生成，就是这个安全体系的第一道门槛。

先搞懂这两个基础概念

在说密钥生成之前，我得先铺垫两个概念，不然后面聊起来会非常费劲。第一个是DTLS，全称是Datagram Transport Layer Security，也就是基于数据报的传输层安全协议。你可能更熟悉它的”兄弟”TLS，就是浏览器上那个HTTPS用的协议。但TLS是面向连接的，而WebRTC传输音视频用的是UDP，它不保证顺序也不保证送达，所以就得用DTLS这个专门为UDP设计的版本。

第二个概念是SRTP，Secure Real-time Transport Protocol，安全实时传输协议。简单说，它就是对 RTP协议（也就是传输音视频数据的那套规则）做了加密封装。所有的媒体流最终都是通过SRTP来传输的，而SRTP使用的加密密钥，正是由DTLS handshake过程产生的。

这两者的关系怎么理解呢？你可以把DTLS想象成”钥匙制造机”，而SRTP则是”保险箱”。DTLS负责在通信双方之间安全地协商出一把钥匙，然后用这把钥匙来打开SRTP这个保险箱，把音视频数据安全地传过去。

DTLS握手：密钥生成的起点

好了，基础概念说完了，正式进入正题。WebRTC的密钥生成过程，核心就是DTLS握手机制。这个过程怎么说呢，看起来步骤挺多，但逻辑其实非常清晰。

证书交换：互相验明正身

DTLS握手第一步，是双方互相交换证书。这里的证书，其实就是一对公私钥中的公钥加上一些身份信息。每一方在建立WebRTC连接之前，都会生成自己的证书，通常是自签名的，也可以在信令服务器那里获取。

举个例子，当你打开一个支持WebRTC的网页时，浏览器会在后台为你生成一对临时密钥。通信双方各自拿着自己的证书，通过信令频道（比如WebSocket）互相交换。这时候双方就都知道对方的公钥是什么了，但私钥都好好地藏在自己手里，谁也不给谁看。

这个交换过程看起来简单，但有个问题需要注意。DTLS是基于UDP的，而UDP可能会丢包、乱序、重复发送早先的握手消息。为了处理这些问题，DTLS在设计上做了很多加固，比如添加记录重传机制、sequence number，还有cookie验证机制来防止DoS攻击。这些设计让DTLS比传统的TLS复杂了不少，但也是必须的代价。

密钥材料生成：从随机数到密钥

证书交换完之后，下一步才是真正生成密钥材料的环节。这一步涉及到几个关键步骤，咱们一个一个说。

首先是随机数生成。在TLS/DTLS协议中，随机数的质量直接决定了最终密钥的安全性。通信双方各自生成一个随机数，这个随机数必须足够随机、不可预测。DTLS协议规定，这个随机数由两部分组成：一部分是当前时间戳（这部分的随机性其实不强，主要用于调试），另一部分是随机生成的字节序列（这个才是关键，得靠密码学安全的随机数生成器）。

然后是预主密钥的协商。这里要涉及到RSA或者Diffie-Hellman这类密钥交换算法。目前WebRTC推荐使用的是ECDHE（Elliptic Curve Diffie-Hellman Ephemeral），也就是基于椭圆曲线的临时DH交换。这个算法的特点是，每一 session 都会生成新的临时密钥对，即使长期密钥泄露了，之前会话的内容也不会被解密——这叫前向安全性。

具体的计算过程大概是这样的：双方各自生成一个临时的EC密钥对，然后用对方的公钥和己方的私钥，计算出一个共享的秘密值。这个共享秘密值就是预主密钥了。整个计算过程的安全性建立在椭圆曲线离散对数问题的困难性上，也就是说，在当前的计算能力下，从公钥反推私钥是不现实的。

密钥派生：从主密钥到会话密钥

有了预主密钥之后，还需要经过一道”加工”才能变成真正用来加密的密钥。这道加工过程叫做密钥派生，用的是PRF（Pseudo-Random Function）函数。

首先，预主密钥会和双方之前交换的随机数一起，通过PRF函数计算出主密钥。然后，主密钥再和两个新的随机数（这时候是真正的随机数了，没有时间戳部分）一起，通过另一个PRF函数，最终派生出所有的密钥材料。

这些密钥材料包括但不限于：

• 客户端写入Mac密钥：客户端用来给数据做消息认证的密钥
• 服务器写入Mac密钥：服务器用来做消息认证的密钥
• 客户端写入加密密钥：客户端用来加密数据的密钥
• 服务器写入加密密钥：服务器用来加密数据的密钥
• 客户端写入IV：客户端加密时用的初始化向量
• 服务器写入IV：服务器加密时用的初始化向量

看到这里你可能会想，搞这么多密钥出来干嘛？直接用一把钥匙不就行了？这其实是密码学设计中的最佳实践——不同用途使用不同的密钥，可以减少密钥泄露带来的风险。而且加密密钥和认证密钥分开，也能避免某些特定的密码学攻击。

SRTP的密钥派生：更精细的加密

等一下，上面说的这些密钥，还不是直接给SRTP用的。WebRTC在DTLS的基础上，又多做了一层SRTP密钥派生。

这是因为DTLS产生的密钥是用来保护DTLS record的，而SRTP有自己的一套加密机制和密钥需求。所以当DTLS握手完成之后，双方还需要再做一次密钥派生，把DTLS产生的密钥材料转换成SRTP可以使用的格式。

这个SRTP密钥派生过程会生成两样东西：SRTP加密密钥和SRTP认证密钥，外加一个salt（盐值）。这个salt很关键，它会让同样的明文在不同时间加密后的结果不一样，大大增强安全性。

这里有个细节值得说一下，WebRTC默认使用的加密算法是AES-CM，也就是AES的Counter Mode。这种模式的特点是加密速度快，适合实时音视频这种对延迟敏感的场景。另外还会配合HMAC-SHA1做消息认证，确保数据没有被篡改。

密钥的生命周期：轮转与更新

密钥生成了不是就完事儿了，还得考虑怎么管理它的生命周期。长期使用同一把密钥，安全性肯定会越来越低。所以WebRTC设计了密钥轮转机制。

在SRTP中，有一个概念叫做key derivation rate，也就是密钥派生速率。简单说，就是每传输一定数量的数据包之后，系统会自动用同样的方法派生出新的密钥来替换旧密钥。这个过程对应用层是透明的，双方会自动同步新的密钥状态。

另外，当DTLS连接因为某种原因断开重连时，整个密钥生成过程会重新走一遍。这又会产生一套全新的密钥材料。由于使用了ECDHE的临时密钥机制，每一次重新握手产生的密钥都是独立的，即使有人能破解某一次的会话密钥，也没法用它来解密其他会话。

实际开发中的一些注意事项

说到这儿，我想起在实际开发中经常遇到的一些坑。第一个就是证书的问题。前面提到WebRTC会使用自签名证书，这在开发测试环境没问题，但正式环境最好还是用受信任CA签发的证书，不然可能会有兼容性问题或者安全警告。

第二个是性能问题。DTLS握手发生在媒体流传输之前，通常需要几百毫秒的时间。对于对延迟要求极高的场景，这部分开销是需要考虑进去的。一些优化策略比如会话恢复（session resumption），可以跳过部分握手步骤来加快连接速度。

第三个是防火墙和网络穿越的影响。DTLS是基于UDP的，而很多企业防火墙会拦截非标准端口的UDP流量。这时候如果ICE打通失败，整个密钥生成过程也没法完成。所以在部署WebRTC服务时，网络配置一定要做好。

声网在密钥生成方面的实践

说到实际应用，我想提一下声网。作为国内做实时音视频云服务的头部厂商，声网在WebRTC的基础上做了很多工程化优化。

声网的全球虚拟网络覆盖了200多个国家和地区，在这种大规模分布式架构下，保证DTLS握手的成功率和低延迟就不是一件容易的事儿。他们在边缘节点部署上做了很多工作，让客户端能就近连接到最优的接入点，这样DTLS握手的过程就能更快完成。

另外，声网还提供了灵活的安全策略配置。开发者可以根据自己的业务需求，选择不同的加密级别和密钥轮转策略。比如金融行业可能需要更频繁的密钥轮转和更严格的证书验证，而一些对延迟敏感的游戏场景则可以适当放宽一些安全参数。

在证书管理方面，声网也提供了完善的解决方案。对于企业级用户，可以支持自定义证书，或者和内部的PKI体系集成，省去了自己管理证书的麻烦。

还有一点值得一提的是，声网的SDK在处理密钥生成过程中的各种异常情况时做了很多容错设计。比如DTLS握手超时重试、网络切换时的密钥重新协商等等，这些细节虽然看起来不起眼，但对用户体验的影响其实挺大的。

写在最后

唠了这么多，你应该对WebRTC媒体流加密密钥的生成流程有个大概的了解了。从证书交换，到随机数生成，再到密钥派生，最后到SRTP密钥的派生，每一步都有它的意义和作用。

安全这个事儿吧，有时候就是很反直觉。你看整个流程走下来，光密钥就生成了一大堆，还要反复轮转，感觉挺麻烦的。但恰恰是这种”麻烦”，才保证了我们的音视频通话不被窃听、不被篡改。技术设计有时候就是这样，看起来笨拙，但每一步都是有道理的。

如果你正在开发实时通信相关的应用，建议还是花时间好好研究一下这些安全机制。了解底层的原理，遇到问题的时候才能快速定位和解决。毕竟，安全无小事嘛。