[发明专利]一种广播加密更新系统及方法

说明书

技术领域

本发明涉及一种广播加密更新系统及方法。

背景技术

随着电信运营商IPTV业务的兴起，针对IPTV内容保护方案变得日益重要。多个IPTV版权管理的标准化组织已经先后推出针对IPTV业务的版权管理方案。实时传输协议RTP(Real-time Transport Protocol)作为成熟的实时传输协议，广泛应用到IPTV多媒体业务的数据承载。RTP是用于Intemet上针对多媒体数据流的一种传输协议，RTP提供端对端网络传输功能，适合通过组播和点播传送实时数据，如视频、音频和仿真数据，但RTP没有涉及资源预订和质量保证等实时服务。安全的实时传输协议SRTP(Secure Real-time TransportProtocol)是实时传输协议RTP的一个子集，该协议在RTP基础上加强了保密性，并定义了消息认证和完整性保护。一个SRTP会话的建立需要首先生成会话密钥Session Key，会话密钥包括加密密钥encr_key、认证密钥auth_key及盐密钥salt_key，会话密钥由伪随机函数(Pseudorandom Function)负责生成。伪随机函数的输入参数包括一个主钥(Master Key)和RTP会话的报文索引。RTP会话的报文索引采用＜ROC，Seq#＞二元组隐性通告机制，其中ROC(Roll OverCounter)用来标记Seq#的循环次数。

目前IPTV版权管理中，比较流行的方案是扩展有线电视方案中的扰码机制，采用划分等级的长短效密钥更新机制。多媒体数据通过SRTP协议加密承载，由组播发送给SRTP会话接收端，接收端用事先共享的共享会话密钥解密多媒体数据，完成多媒体内容的消耗。该方案的关键问题是向SRTP协议高效输送密钥生成参数。根据对SRTP密钥生成算法的分析，SRTP协议生成会话密钥，需要三个参数：＜Master Key，ROC，Seq#＞三元组，另外用于区分不同的RTP会话发起者的SSRC(Synchronization Source Indentifier)参数，也必须传送给SRTP协议。综上所述，版权管理系统需向SRTP协议传递＜SSRC，MasterKey，ROC，Seq#＞四个参数，其中Master Key就是版权管理系统的短效密钥。

SRTP协议设计之初，缺乏一个集中式的控制方式，当时的设计主要考虑节约网络带宽。为了解决SRTP控制和密钥管理问题，SRTP协议常和一个信令系统同时使用，通过信令系统完成SRTP的集中控制功能。但是，这种方式容易出现信令和SRTP内容不同步的问题，例如Early Media，Forking等问题。另外，SRTP协议生成会话密钥，需要ROC，SSRC等参数，这些参数本身属于RTP会话的一部分，应该由RTP传输层来完成。而传统的实现中，这些参数需要由信令控制层传送，于是产生信令控制层和RTP传输层的复杂交互。这种复杂性产生的根源是RTP传输层和信令控制层的功能混杂，信令控制层需要完成部分RTP传输层的功能。

因此产生了EKT(Encrypted Key Transport)方案，由RTCP协议承载部分RTP协议的控制功能。EKT方案在SRTP协议框架的基础上进行扩展，减少SRTP协议对于信令协议的依赖程度。方案中定义了SRTCP载荷扩展用来承载SRTP的主钥(Master Key)，ROC参数和SEQ#的初始值，通过验证域完成扩展报文的完整性保护。其中，SRTP的主钥在报文中是通过密钥加密密钥(KEK：Key Encryption Key)加密后承载。扩展后的SRTCP报文，携带SRTP的密钥参数，利用RTP会话的控制信道下发给全部的会话接收端，接收端利用KEK还原SRTP主钥，连同其他密钥参数一起生成会话密钥，完成RTP数据的解密。

EKT方案的缺点是：为了保障RTP会话的QoS，通常需要为RTP会话预留带宽。RTCP报文带宽通常为有效RTP会话带宽的5％，留给会话发送端的RTCP带宽只是RTCP总带宽的75％。加之RTCP报文头的开销(约64字节)，实际的有效的密钥下载带宽非常有限。如果采用EKT方案传送广播加密密钥，必然导致密钥更新报文周期超长；EKT方案继承了RTCP方案的缺点，在存在防火墙的应用中，需要在防火墙本身开辟RTCP端口，如果RTCP本身受限防火墙，不能完成穿越，则运行于其上的密钥传输将不能完成。

发明内容

本发明的实施例的目的在于提供一种广播加密更新系统及方法，该广播加密更新系统及方法能解决密钥更新报文周期时间长及穿越防火墙需要建立额外的端口的问题。