安全实时传输协议

安全实时传输协议（Secure Real-time Transport Protocol或SRTP）是在实时传输协议（Real-time Transport Protocol或RTP）基础上所定义的一个协议，旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。它是由David Oran（思科）和Rolf Blom（爱立信）开发的，并最早由IETF于2004年3月作为RFC 3711发布。

由于实时传输协议和实时传输控制协议（Real-time Transport Control Protocol或RTCP）有着紧密的联系，安全实时传输协议同样也有一个伴生协议，它被称为安全实时传输控制协议（Secure RTCP或SRTCP）；安全实时传输控制协议为实时传输控制协议提供类似的与安全有关的特性，就像安全实时传输协议为实时传输协议提供的那些一样。

对于 RTP 和 RTCP 应用程序来说, SRTP 和 SRTCP 是可选项, 而且即使使用了 SRTP 和 SRTCP 协议, 它们提供的各种功能(例如加密和认证) 也都是可以独立选择使用或者不使用的. 唯一的例外就是当使用 SRTCP 的时候消息认证(message authentication)是必选的.

数据流加密

为了提供对数据流的保密，需要对数据流进行加密和解密。关于这一点，安全实时传输协议（结合安全实时传输控制协议）只为一种加密算法，即AES制定了使用标准。这种加密算法有两种加密模式，它们能将原始的AES块密文转换成流密文：

• 分段整型计数器模式——一种典型的计数器模式，它允许对任意块的随机访问——这一点对于实时传输协议的数据流在可能丢包的不可靠网络上进行传输是非常必要的。一般情况下，几乎所有的函數都能被作为计数器使用，只要它在一次循环中重复的次数不要太多就可以。但是，用于实时传输协议数据加密的仅仅是一个普通的整型递增计数器。运行在这一模式下的AES是其默认的加密算法，它使用的是默认128位长度的加密密钥和默认112位长度的会话盐密钥。
• f8模式——输出反馈模式的一个变种，它增加了定位功能并改变了初始化功能。其加密密钥和盐密钥的默认值和计数器模式下的AES是一样的。运行在这种模式下的AES被用于UMTS 3G移动网络。

除了AES加密算法，安全实时传输协议还允许彻底禁用加密，此时使用的是所谓的“零加密算法”。它可以被认为是安全实时传输协议支持的第二种加密算法，或者说是它所支持的第三种加密模式。事实上，零加密算法并不进行任何加密，也就是说，加密算法把密钥流想像成只包含“0”的流，并原封不动地将输入流复制到输出流。这种模式是所有与安全实时传输协议兼容的系统都必须实现的，因为它可以被用在不需要安全实时传输协议提供保密性保证而只要求它提供其它特性（如认证和消息完整性）的场合。

尽管从技术上来说安全实时传输协议能轻松地纳入新的加密算法，但安全实时传输协议标准指出除上述加密算法以外的新的加密算法不一定能被简单地添加到一些安全实时传输协议的具体实现中去。添加一种新的加密算法并确保它与安全实时传输协议标准相兼容的唯一有效方式是发布一个明确定义该算法的新的伴生的标准跟踪RFC。

认证、完整性和重放保护

以上列举的加密算法本身并不能保护消息的完整性，攻击者仍然可以伪造数据——至少可以重放过去传输过的数据。因此，安全实时传输协议标准同时还提供了保护数据完整性以及防止重放的方法。

为了进行消息认证并保护消息的完整性，安全实时传输协议使用了HMAC-SHA1算法（在RFC 2104中定义）。这种算法使用的是默认160位长度的HMAC-SHA1认证密钥。但是它不能抵御重放攻击；重放保护方法建议接收方维护好先前接收到的消息的索引，将它们与每个新接收到的消息进行比对，并只接收那些过去没有被播放过的新消息。这种方法十分依赖于完整性保护的使用（以杜绝针对消息索引的欺骗技术）。

参见

• ZRTP

外部链接

• RFC 3711, Proposed Standard, The Secure Real-time Transport Protocol (SRTP)
• RFC 3551, Standard 65, RTP Profile for Audio and Video Conferences with Minimal Control
• RFC 3550, Standard 64, RTP: A Transport Protocol for Real-Time Applications
• RFC 2104, Informational, HMAC: Keyed-Hashing for Message Authentication