SRTP加密保障媒体流传输过程安全

你有没有想过，当你在视频会议里和同事讨论薪资调整时，那些对话是不是真的“私密”？或者孩子上网课时的摄像头画面，会不会被某个不怀好意的人截获？🤔

这可不是危言耸听。我们每天使用的音视频通话、直播互动、远程医疗……背后跑的都是 RTP（Real-time Transport Protocol） ——一个高效但“裸奔”的协议。它能把音频视频快速送达对方，可问题是： 全程明文传输，谁都能看！

于是， SRTP（Secure Real-time Transport Protocol） 登场了。它是 RTP 的“防弹衣”，在不拖慢实时性的前提下，给每一帧画面、每一段声音都套上加密锁。🔐

那它是怎么做到的？别急，咱们一步步拆开来看。

---

想象一下你要寄一封机密信件。光写内容不行，你还得做三件事：

1. 把内容加密，防止路人偷看；
2. 加个防伪印章，确保信没被中途篡改；
3. 标个唯一编号，防止有人复制粘贴反复寄给你搞骚扰。

SRTP 干的就是这个活儿，只不过对象是 RTP 包。

它不是取代 RTP，而是在 RTP 外面加了一层“安全壳”。原始的时间戳、序列号、SSRC 这些控制字段依然可见，方便网络设备做 QoS 调度；但真正的音视频数据——也就是 payload——已经被 AES 加密得严严实实。

🤔 为什么头部不加密？
因为 NAT、防火墙、媒体网关这些中间设备需要读取 SSRC 和序列号来做路由、抖动缓冲或带宽自适应。如果全加密了，整个链路就“瞎了”。

---

那么，这层“安全壳”是怎么生成的？

首先得有钥匙🔑——但 SRTP 不会直接用一把主钥匙去加密所有包，那样太危险。它的做法更聪明： 从一个主密钥 + 主盐值出发，通过 KDF（Key Derivation Function）动态派生出多个子密钥 。

比如：
- 每个 SSRC 流有自己的加密密钥；
- 认证用的 HMAC 密钥独立存在；
- 初始化向量（IV）由 SSRC、PT 类型、序列号等拼接而成，确保每包唯一。

这样一来，即使某个流的密钥泄露，也不会波及其他流。而且密钥材料通常来自 DTLS-SRTP 握手后的导出结果，完全避免了信令中传密钥的风险。

说到 DTLS-SRTP，这是现代 WebRTC 系统里的标配。浏览器之间先来一次基于 UDP 的 DTLS 握手，交换证书、完成身份认证，然后调用 exporter() 函数生成所谓的“keying material”——一块包含客户端/服务器各自读写密钥的数据块。

这块数据喂给 libsrtp 库，立马就能创建出收发两个方向的 SRTP 会话。整个过程自动化，用户无感知，安全性却拉满。✅

---

加密用什么算法？主流是 AES-128-CTR（Counter Mode） 或 f8 模式，属于流加密，适合实时场景。解密时哪怕丢了一两个包，也不影响后续恢复。

完整性保护呢？靠的是 HMAC-SHA1 。每个 SRTP 包末尾都会附带一个 MAC 值（常见 80bit 或截断为 32bit），接收方重新计算一遍，对不上就直接扔掉——这意味着任何中间篡改都会被立刻发现。

至于重放攻击？SRTP 有个“滑动窗口”机制，默认大小 64。它会记住最近收到的最大序列号，并维护一个位图标记哪些包已经收过：

• 新包序列号比最大值大 → 正常接收，窗口前移；
• 在窗口范围内且未接收 → 收下；
• 已经收过 or 太老了 → 判定为重放，丢弃！

这就堵住了“录下来再重播”的漏洞。🎯

---

来看一组 RFC 3711 定义的典型参数：

参数	默认值	说明
加密算法	AES-128-CM	计数器模式，性能好
认证算法	HMAC-SHA1	输出可选 80bit 或 32bit
主密钥长度	128位	外加 112位 salt 提供熵
IV 构造方式	SSRC + seq + rollover count	保证全局唯一
滑动窗口大小	64	防御最近 64 个包内的重放

这些参数看似固定，其实高度可配。你可以根据业务需求灵活调整：高安全场景上 80bit MAC；IoT 设备省带宽用 32bit；甚至未来还能换上抗量子的算法模块。

---

实际开发中，大多数人会选择开源库 libsrtp 。下面是个极简示例：

#include <srtp/srtp.h>

int main() {
    srtp_err_status_t err;

    // 初始化库
    err = srtp_init();
    if (err != srtp_err_status_ok) {
        fprintf(stderr, "SRTP init failed\n");
        return -1;
    }

    // 示例密钥（生产环境应由 DTLS 动态生成）
    uint8_t key[30];  // 128位主密钥 + 112位盐
    memset(key, 0x00, 30);

    // 设置策略
    srtp_policy_t policy;
    memset(&policy, 0, sizeof(policy));
    policy.rtp_cipher = &srtp_aes_cm_128_cipher;
    policy.rtp_auth = &srtp_hmac_sha1_auth;
    policy.rtp_auth_len = 10;          // 80-bit MAC
    policy.ssrc.type = ssrc_specific;
    policy.ssrc.value = 0x12345678;
    policy.key = key;
    policy.next = nullptr;

    srtp_t send_session;
    err = srtp_create(&send_session, &policy);
    if (err != srtp_err_status_ok) {
        fprintf(stderr, "Failed to create SRTP session\n");
        return -1;
    }

    // 加密 RTP 包
    uint8_t rtp_packet[] = { /* header + payload */ };
    int pkt_len = sizeof(rtp_packet);

    err = srtp_protect(send_session, rtp_packet, &pkt_len);
    if (err == srtp_err_status_ok) {
        printf("Encrypted! New length: %d\n", pkt_len);
    }

    // 解密（接收端）
    err = srtp_unprotect(recv_session, rtp_packet, &pkt_len);
    if (err == srtp_err_status_ok) {
        printf("Decryption & verification passed.\n");
    }

    srtp_dealloc(send_session);
    return 0;
}

几个关键点提醒你注意 ⚠️：

• srtp_protect() 是一站式操作：加密 + 计算 MAC；
• srtp_unprotect() 先验 MAC 再解密，顺序不能反；
• 密钥绝不能硬编码！务必通过 DTLS-SRTP 或 ZRTP 协商获得；
• 多路流记得配置多个 policy 或使用 wildcard SSRC。

---

在典型的 WebRTC 架构中，SRTP 的位置非常清晰：

[浏览器A] ↔ [STUN/TURN] ↔ [浏览器B]
     ↑             ↑             ↑
 DTLS Handshake   Relay      DTLS Handshake
     ↓             ↓             ↓
 SRTP Encrypt ← Media Path → SRTP Decrypt

信令阶段交换 SDP，里面带着 a=fingerprint 字段声明证书指纹， a=setup 定义 DTLS 角色（client/server）。一旦 DTLS 握手成功，立即导出密钥启动 SRTP。

最关键的是： TURN 中继服务器只能看到加密后的 SRTP 包 ，根本看不到里面的内容。也就是说，哪怕运营商想监听，也拿你没办法。👀

---

面对各种攻击，SRTP 的应对策略也很扎实：

攻击类型	SRTP 如何防御
窃听	AES 加密 payload，内容不可读
篡改	HMAC-SHA1 校验失败，包被丢弃
重放	滑动窗口检测重复包
中间人	DTLS 证书指纹匹配，身份可验证
密钥泄露	前向安全（PFS）设计，历史会话仍安全

特别是 PFS（Perfect Forward Secrecy），配合 ECDHE 密钥交换，确保每次会话的密钥都是临时的。就算你的长期私钥哪天被盗了，之前的通话记录也不会被破解。

---

部署 SRTP，有些经验值得分享 💡：

1. MAC 长度权衡 ：
   80bit 更安全，32bit 节省带宽。但在高并发场景下要评估碰撞概率，别为了省几字节丢了安全性。

2. 定期重协商 ：
   长时间通话建议每 30 分钟重新走一次 DTLS 握手，刷新密钥，防密钥老化。

3. 禁用 SDES ：
   有些人图省事用 SDES 在 SDP 里明文传密钥，简直是把钥匙挂在门把手上。🚫 必须禁用！

4. 启用硬件加速 ：
   在网关或 MCU 上开启 AES-NI 指令集，CPU 占用能降一半以上，吞吐量翻倍不是梦。

5. 日志脱敏 ：
   故障排查可以记 SSRC、序列号、丢包率，但绝对不能记录密钥或加密包内容。否则审计一查一个准 😬。

---

回过头看，SRTP 之所以能成为实时通信领域的“安全基石”，就在于它做到了一件事： 在极致低延迟的前提下，把安全闭环打得死死的 。

它不像 TLS 那样层层封装，而是精准打击——只加密该加密的部分，只认证该认证的地方，不多不少，刚刚好。

未来呢？随着量子计算逼近，SRTP 也在演进。IETF 已开始研究抗量子版本，比如结合基于格的密钥封装机制（KEM），让这套体系继续守护下一代通信安全。

所以啊，下次你打开摄像头开会的时候，不妨想想：那一道看不见的加密屏障，正默默为你守住隐私底线。🛡️

这才是真正的“看得见、听得到、信得过”。