8. Security Considerations (安全考虑)
经 SIP 信令的 DTLS 或 TLS 媒体需要某种机制来保证通信对等方证书正确.
TLS/DTLS 认证对等方的常规做法是为服务器 (以及可选的客户端) 分配 PKIX [RFC5280] 证书. 客户端验证证书并检查证书中的名称是否与服务器域名一致. 这在服务器数量相对较少且名称明确的场景可行, 而 VoIP 场景通常并非如此.
本文档描述的设计意在利用信令信道的真实性 (而不要求保密性). 只要连接两侧均能验证自对方收到的 SDP 的完整性, DTLS 握手就无法被中间人攻击劫持. 主叫到被叫 (见第 7 节 Alice 到 Bob) 可轻易通过 SIP Identity [RFC4474] 提供此类完整性保护. RFC 3261 所述 S/MIME 机制或未来定义的其他机制也可承担此角色.
若不使用此类完整性机制, 本机制仍可用, 但所提供安全主要限于防御中间人的被动攻击. 针对信令的主动攻击叠加针对媒体平面的主动攻击可使攻击者破坏连接 ([RFC5479] 记号中的 R-SIG-MEDIA).
8.1. Responder Identity (响应方身份)
SIP Identity 不支持在响应中签名. 理想情况下, Alice 希望确认 Bob 的 SDP 未被篡改且确来自 Bob, 以便 Alice 的 UA 能向 Alice 表明与 Bob 的通话安全. [RFC4916] 定义了一种 UA 向其对等 UA 提供身份并由认证服务签名的方法. 例如, Bob 发送 answer 后立即发送包含指纹并使用 SIP Identity 断言消息来自 [email protected] 的 UPDATE. 缺点是增加 UPDATE 的额外往返. 然而, 即便并非所有代理都可信, 该方法仍简单且安全. 本例中 Bob 只需信任其代理. Offerer 应当 (SHOULD) 支持该机制, answerer 应当 (SHOULD) 使用它.
某些情况下 answerer 不会发送 UPDATE, 且许多呼叫在收到 UPDATE 之前就会发送部分媒体. 此时 Bob 到 Alice 的指纹没有完整性保护. 位于信令路径上的攻击者可篡改指纹并在媒体上充当中间人. Alice 会知道与某人进行了安全通话, 但无法区分对方是 Bob 还是中间人. Bob 则能察觉攻击正在发生. 一侧可检测该攻击意味着在 Alice 与 Bob 都希望加密的多数场景下问题不大. 须记住: 在任何方案下 Bob 都可能将收到的媒体泄露给任何人. 我们假设 Bob 也希望安全通信. 在此“不采取额外措施”的情形下, Bob 知道媒体未被第三方篡改或窃听且来自 [email protected]. Alice 知道自己在与某人通话, 且对方很可能已检查媒体未被窃听或篡改. 该方案虽不理想, 但在许多场景下仍实用.
8.2. SIPS
若未使用 SIP Identity, 但信令由 SIPS 保护, 则安全保证较弱. 只要所有代理均被信任, 仍可提供一定安全性. 这在链式信任模型下为指纹提供完整性. 但若代理不可信, 则所提供安全级别有限.
8.3. S/MIME
RFC 3261 [RFC3261] 定义了可用于对指纹来源 (Bob) 进行签名的 SIP S/MIME 安全机制. 那样做是安全的.
8.4. Continuity of Authentication (认证连续性)
安全媒体系统的一个理想性质是认证连续性: 能以密码学方式确认正在与此前同一人通话. 使用 DTLS 时, 若各方对每次连接 (至少对给定对等实体) 使用相同公钥/自签名证书, 即可实现认证连续性. 从而可缓存凭据 (或其哈希) 并验证其未变. 因此, 一旦建立单次安全连接, 即使未来信令不安全, 实现仍可能建立未来的安全信道.
为实现认证连续性, 实现应当 (SHOULD) 尽量保持长期密钥不变. 负责验证的实现应当 (SHOULD) 为每个对等身份维护所用密钥的缓存, 并在密钥变化时告警用户.
8.5. Short Authentication String (短认证串)
Alice 与 Bob 的另一选择是用语音相互确认身份, 再用语音核对指纹. 若难以模仿他人语音并无缝修改通话音频, 则该方法相对安全. 若使用视频或即时消息等形式则效果不佳. DTLS 支持此种运行方式. 安全指纹最小长度约 64 比特.
ZRTP [AVT-ZRTP] 包含短认证串 (Short Authentication String, SAS) 模式, 在密码握手中生成每条连接唯一的比特串. SAS 可短至 25 比特, 更易口述. DTLS 本身不原生支持该模式. 视部署兴趣, TLS 扩展 [RFC5246] 可提供支持. 注意 SAS 类方案仅在端点能识别对方语音时效果良好, 许多场景 (如呼叫中心) 并不满足.
8.6. Limits of Identity Assertions (身份断言的局限)
使用 RFC 4474 将媒体密钥材料绑定到 SIP 信令时, 关于媒体来源与安全的保证不会超过信令本身. 此处有两个重要情形:
-
RFC 4474 假定持有证书 "example.com" 的代理控制命名空间 "example.com". 因此, 对给定命名空间权威的 RFC 4474 认证服务可控制每个名称分配给哪一用户. 于是认证服务可将原属 Alice 的地址转给 Bob. 这是 RFC 4474 的有意设计特性, 也是 SIP 命名空间架构的直接结果.
-
使用电话号码 URI (例如
sip:[email protected]或sip:[email protected];user=phone) 时, 没有结构上的理由认为域名对给定号码具有权威性, 尽管个别代理与 UA 可有私下安排以信任其他域. 这是结构性问题: 公共交换电话网 (PSTN) 网元被信任能正确断言其号码, 且不存在“某实体对某号段权威”的清晰概念.
上述两种情形下, DTLS-SRTP 在数据源完整性与机密性方面的保证在使用 RFC 4474 时必然不超过 SIP 为信令完整性提供的保证. 实现者因此应注意不要在用户界面展示误导性的对等身份. 即, 若对等身份为 sip:[email protected], 仅显示对等为 +17005551008 并不充分, 除非有策略声明域 "chicago.example.com" 受信任可断言其所声称的 E.164 号码. 若 UA 能确定对等身份明显为 E.164 号码, 将呼叫标明为“已加密但对等未知”可能更少混淆.
此外, 已知部分中间盒 (背靠背用户代理 B2BUA 与 SBC) 会修改参与 RFC 4474 签名计算的 SIP 消息部分, 从而破坏签名. 此类中间人操作正是 RFC 4474 意在检测的篡改. 若中间盒本身被允许生成有效 RFC 4474 签名 (例如与 RFC 4474 认证服务处于同一管理域), 则可对修改后的消息重新签名; 或者中间盒可用其被允许断言的其他身份签名. 否则, 接收方不能依赖 RFC 4474 Identity 断言, UA 禁止 (MUST NOT) 向用户声称已与声称身份建立安全呼叫. 配置为仅建立安全呼叫的实现应当 (SHOULD) 在此情况下终止呼叫.
若未使用 SIP Identity 或等效机制, 则仅提供对无法主动改动信令的攻击者的防护. 这仍优于旧有机制, 但弱于为信令提供完整性的情形.
8.7. Third-Party Certificates (第三方证书)
本规范不依赖端点持有的证书可被独立验证 (例如由可信第三方颁发). 但不妨碍使用此类证书. 除获取难度外, 证书应包含何种身份也不明确: RFC 3261 对 S/MIME 证书约定了可作此处复用的惯例, 但部署很少. 在封闭或半封闭环境若能建立此类惯例, 第三方证书可减少对端点所在域内代理的信任需求.
8.8. Perfect Forward Secrecy (完美前向保密)
长期使用同一密钥的担忧在于, 密钥泄露可能导致过往通信被解密. 为防范此类攻击, DTLS 支持采用 Diffie-Hellman 与椭圆曲线 Diffie-Hellman 密码套件以实现完美前向保密 (Perfect Forward Secrecy, PFS). 使用这些模式时, 系统可抵御此类攻击. 注意长期密钥泄露仍可能导致未来主动攻击. 若担忧此点, 应使用备用认证信道, 如手动建立指纹或短认证串.