[发明专利]在通信网络中发送受保护数据

说明书

技术领域

本发明涉及在通信网络中发送受保护数据的领域。

背景技术

实时传输协议(RTP)是用于在分组交换网络上传送音频和视频媒体数据的协议。RTP用于传输实时和流媒体数据，如交互式音频和视频。因此，RTP用于诸如IPTV、会议、基于IP的语音(VoIP)等应用中。

在IETF RFC 3711中规定的安全实时传输协议(SRTP)是提供加密RTP形式的传输安全协议。除了加密以外，SRTP还提供消息认证和完整性，以及在单播、多播和广播应用中提供重放保护。SRTP用于保护在RTP会话的对等方之间传送的内容。SRTP是传输安全协议，并且仅意图在运行SRTP的两个对等方之间的传输期间对数据进行保护。具体地，一旦数据已被传送至SRTP会话的端点，SRTP就不对数据进行保护。此外，发送对等方通过对媒体数据进行加密来提供保护，换言之，假设发送对等方知晓所有加密材料并且是对数据施加保护的一方。

RTP与RTCP(RTP控制协议)紧密关联，RTCP能够用于控制RTP会话，并且类似地SRTP具有姊妹协议，称为安全RTCP(或SRTCP)。SRTCP向RTCP提供与SRTP向RTP提供的安全性相关特征相同的安全性相关特征。

使用SRTP或SRTCP对于使用RTP或RTCP来说是可选的；但即使使用了SRTP/SRTCP，所有所提供的特征(如加密和认证)也是可选的，并且能够分别启用或者禁用。唯一的例外是消息认证/完整性特征，当使用SRTCP时消息认证/完整性特征是必不可少的。SRTP和SRTCP中的机密性保护覆盖有效载荷，而完整性保护覆盖有效载荷和整个分组首部。

参见图1，许多内容传送系统和通信服务包括存储转发(SaF)机制，并要求媒体的端到端机密性和完整性保护。在该情形下，发送方单元1在发送方单元1与中间存储实体2之间的第一跳发送媒体，接着(几乎立即或稍后)媒体通过从存储实体2到预期接收方单元3的第二跳。应注意的是，媒体可以通过多于一个的中间单元。然而，应该对中间单元(如SaF服务器)处的每一跳进行完整性保护。(此处使用的术语“跳”指网络中两个逻辑上相邻的节点之间的逻辑链路。)例如，在邮箱或网络应答机存储媒体的情况下，需要进行完整性保护，以允许中间单元2检查到达的媒体数据分组的真实性。为了防范攻击者用垃圾将设备上的存储器填满，这是有必要的。然而，对媒体进行解密或计算/修改端到端(e2e)完整性保护所需的密钥不应对中间单元可用，以防止中间单元操纵或访问明文媒体数据。

SRTP数据可以经由中间单元发送，同时通过向媒体数据提供发送方单元1与接收方单元3之间的端到端保护，确保中间单元无法访问该数据。

从中间单元2向接收方单元3转发媒体数据的可能方式是通过文件传输，例如，以用于存储媒体数据的格式来发送媒体数据。然而，SRTP不支持该类型的转发。

为了防止可能以伪造数据来填充中间单元2的攻击，有利地，确保中间单元2对媒体数据的发送方单元1进行认证，此外核实媒体数据的真实性。这要求在发送方单元1与中间单元2之间建立逐跳(hbh)密钥/安全性上下文。

因此，需要两个独立的安全性上下文；一个端到端(e2e)安全性上下文保护(通过加密或完整性保护)发送方单元1与接收方单元3之间的数据，一个发送方单元1与中间单元2之间的hbh安全性上下文允许中间单元2对发送方单元1进行认证以及对媒体数据进行认证。针对hbh密钥建立，可以使用任意现有密钥管理方案，如多媒体互联网加密(MIKEY)或数据报传输层安全SRTP(DTLS-SRTP)。可能需要较小的扩展以处理SRTP(SaF)操作。在特定情形下，这些密钥管理协议也可用于e2e密钥管理。

虽然建立用于hbh保护的密钥相对简单，当媒体数据通过中间单元2时建立用于发送方单元1与接收方单元3之间的e2e保护的密钥却不简单。如果使用多媒体互联网加密(MIKEY)(关于MIKEY的描述参见RFC3830)来建立用于e2e保护的密钥，针对密钥管理存在以下不同的选项：

1.在预共享密钥模式下使用MIKEY。在该情形下，在进行呼叫时，e2e预共享密钥必须对发送方单元1可用。这意味着：必须在通过安全方法发送数据前分发e2e预共享密钥，从而导致密钥自举问题。发送方单元1必须使用特殊过程来得到针对预期接收方单元3的密钥。该过程可以是允许发送方单元1在需要时获取密钥的在线过程，或者可以是例如下载针对发送方电话薄中所有可能接收方单元的密钥。