9.1. SSRC collision and two-time pad (SSRC 冲突和两次一密)

9.1. SSRC collision and two-time pad (SSRC 冲突和两次一密)

从相同密钥和索引生成的任何固定密钥流输出必须 (MUST) 只能用于加密一次。重用这样的密钥流 (被密码学家戏称为 "两次一密" (two-time pad) 系统) 可能会严重损害安全性。NSA 的 VENONA 项目 [C99] 提供了这种妥协的历史例子。要求 (REQUIRED) 必须使用自动密钥管理来建立和维护 SRTP 和 SRTCP 密钥材料; 此要求是为了避免密钥流重用, 这在手动密钥管理中更有可能发生。此外, 在 SRTP 中, 通过要求密钥或其他具有加密意义的参数对于每个 RTP/RTCP 流和数据包都是唯一的来避免 "两次一密"。预定义的 SRTP 转换通过包含数据包索引来实现数据包唯一性, 通过包含 SSRC 来实现流唯一性。

预定义的转换 (AES-CM 和 AES-f8) 通过在 IV 中包含 SSRC, 允许在属于同一 RTP 会话的流之间共享主密钥。主密钥绝对不能 (MUST NOT) 在不同的 RTP 会话之间共享。

因此, 在共享相同主密钥的同一 RTP 会话内的所有 RTP 流之间, SSRC 必须 (MUST) 是唯一的。RTP 本身提供了一种算法来检测同一 RTP 会话内的 SSRC 冲突。因此, 在不幸的情况下, 如果 SSRC 在流也具有相同序列号的时间点发生冲突 (发生概率约为 2^(-48)), 临时冲突可能会导致临时的两次一密。因此, 密钥管理应该 (SHOULD) 通过将会话中要使用的 SSRC 作为协商参数包含进来, 主动确保其唯一性, 从而避免此类 SSRC 冲突。在例如存在多个发送方可以同时开始传输的场景中 (在 RTP 级别检测到 SSRC 冲突之前), 这是一个强要求。

还要注意, 即使使用不同的 SSRC, 同一密钥的广泛使用也可能增加概率性冲突和时间-内存权衡攻击成功的机会。

如前所述, 主密钥可以 (MAY) 在属于同一 RTP 会话的流之间共享, 但建议 (RECOMMENDED) 每个 SSRC 拥有自己的主密钥。当主密钥在 SSRC 参与者之间共享并且 SSRC 由密钥管理模块管理时 (如上所述), 对于 SSRC 冲突错误的建议 (RECOMMENDED) 策略是参与者离开 SRTP 会话, 因为这是故障的迹象。