9.5. Integrity of the RTP payload and header (RTP 负载和头部的完整性)

9.5. Integrity of the RTP payload and header (RTP 负载和头部的完整性)

SRTP 消息容易受到对其完整性和源识别的攻击, Section 9.5.1 讨论了这些风险。为了防止这些攻击, 每个 SRTP 流应该 (SHOULD) 通过具有 80 位输出标签和 160 位密钥的 HMAC-SHA1 [RFC2104] 或具有同等强度的消息认证码来保护。安全 RTP 不应该 (SHOULD NOT) 在没有消息认证的情况下使用, 除非在本节描述的情况下。重要的是要注意, 加密算法 (包括 AES 计数器模式和 f8) 不提供消息认证。SRTCP 绝对不能 (MUST NOT) 与弱 (或 NULL) 认证一起使用。

SRTP 可以 (MAY) 与弱认证 (例如 32 位认证标签) 或无认证 (NULL 认证算法) 一起使用。这些选项允许在以下情况下使用 SRTP 提供机密性:

• 弱或空认证是可接受的安全风险, 并且
• 提供强消息认证是不切实际的。

这些条件在下面和 Section 7.5 中描述。请注意, 为了使用弱或空认证, 必须 (MUST) 同时满足这两个条件。鉴于 Section 9.5.1 中讨论的风险, 在将弱或空认证选项用于特定应用或环境之前, 需要通过安全审计考虑与行使这些选项相关的风险。

当 RTP 应用使得小部分成功伪造的影响可以忽略不计时, 弱认证是可接受的。如果应用是无状态的, 那么单个伪造的 RTP 数据包的影响仅限于该特定数据包的解码。在这种情况下, 认证标签的大小必须 (MUST) 确保 SRTP 接收方传递给 RTP 应用的数据包中只有可忽略不计的一部分可能是伪造的。当攻击者即使控制了伪造的数据包也无法对 RTP 应用的输出产生重大影响时, 这个比例是可以忽略不计的 (参见 Section 7.5 的示例)。

当攻击者不太可能修改密文使其解密为可理解的值时, 弱或空认证可以 (MAY) 是可接受的。一个重要的情况是攻击者很难获取 RTP 明文数据, 因为对于许多编解码器, 不知道输入信号的攻击者无法以受控方式操纵输出信号。在许多情况下, 攻击者可能很难确定明文的实际值。例如, 为了了解实时音频或视频信号, 可能需要隐藏的窃听设备。攻击者的信号必须具有与被攻击信号相当或更高的质量, 否则攻击者将没有足够的信息使用受害者使用的编解码器对该信号进行编码。对于诸如电话呼叫之类的交互式应用, 明文预测也可能特别困难。

当 RTP 应用基于 RTP 数据做出数据转发或访问控制决策时, 绝对不能 (MUST NOT) 使用弱或空认证。在这种情况下, 攻击者可能能够通过使接收方将数据转发给攻击者来破坏机密性。有关此类攻击的真实示例, 请参见 [B96] 的 Section 3。

当重放攻击 (攻击者存储数据包然后稍后在会话中重放它们) 可能对接收方产生不可忽略的影响时, 绝对不能 (MUST NOT) 使用空认证。成功的重放攻击的一个例子是存储监控摄像机的输出一段时间, 然后将该输出注入监控站以避免监控。加密不能防止这种攻击, 为了击败它, 需要 (REQUIRED) 非空认证。

如果存在性消息伪造是一个问题, 即当接收数据的准确性具有不可忽略的重要性时, 绝对不能 (MUST NOT) 使用空认证。