一种广播加密更新***及方法
技术领域
本发明涉及一种广播加密更新***及方法。
背景技术
随着电信运营商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本身受限防火墙,不能完成穿越,则运行于其上的密钥传输将不能完成。
发明内容
本发明的实施例的目的在于提供一种广播加密更新***及方法,该广播加密更新***及方法能解决密钥更新报文周期时间长及穿越防火墙需要建立额外的端口的问题。
本发明的实施例是这样实现的,一种广播加密更新***,包括加密模块、复用模块、解复用模块及密钥生成模块,该加密模块接收多媒体流,将多媒体流通过会话密钥加密形成密文传输到复用模块,该复用模块将广播密钥更新报文和密文复用形成复合数据流,并发送到解复用模块,其中,广播密钥更新报文中包含加密的短效密钥STK和建立安全的实时传输协议SRTP会话所需的参数,该解复用模块分离广播密钥更新报文和密文,解密还原短效密钥STK,STK连同建立SRTP会话的参数通过密钥生成模块生成更新的会话密钥;所述复用模块采用的是实时传输协议RTP复用技术。
本发明所采取的另一技术方案包括一种广播加密更新方法,包括以下步骤:
多媒体流通过会话密钥加密形成密文;
密文与广播密钥更新报文经过复用形成复合数据流发送到会话客户端,所述复用采用实时传输协议RTP复用技术,所述广播密钥更新报文包括加密保护的短效密钥STK和建立安全的实时传输协议SRTP会话所需的参数;
分离广播密钥更新报文和密文,解密还原STK,连同建立SRTP会话的参数生成会话密钥,用于多媒体数据的解密。
本发明实施方式的技术方案具有如下优点或有益效果:上述技术方案的广播加密更新***及方法由于采用RTP信道承载,能够完成大规模用户组的高频率广播密钥更新;另外,,密钥更新报文穿越防火墙不需要建立额外的端口。本发明的实施方式的详细特征及优点将通过实施例结合附图进行详细说明。
附图说明
图1是本发明实施例的广播加密更新***的结构图;
图2是本发明实施例的广播加密更新方法的流程图;
图3是本发明实施例的密钥更新报文格式图。
具体实施方式
为了使本发明实施例的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明实施例进行进一步详细说明。
请参阅图1,为本发明实施例的广播加密更新***的结构图。该广播加密更新***包括加密模块、复用模块、解复用模块、解密模块及会话密钥生成模块。加密模块接收多媒体流,将多媒体流通过会话密钥加密形成密文传输到复用模块。复用模块将广播密钥更新报文和密文复用形成复合数据流,利用组播数据信道将整个复合数据流发送到会话客户端的解复用模块,其中,广播密钥更新报文中包含加密的短效密钥STK(Short Term Key)和建立实时传输协议SRTP会话所需的参数。解复用模块分离广播密钥更新报文和密文,解密还原短效密钥STK,并将密文传送到解密模块。STK信息连同建立SRTP会话的参数通过会话密钥生成模块生成更新的会话密钥,会话密钥生成模块将更新的会话密钥传送至解密模块,用于后续的数据解密。解密模块根据更新的会话密钥解密出多媒体流。该复用模块采用的RTP复用技术包含多种方法,在本实施例中采用基本的版本号字段复用技术。标准的RTP报文的Version字段的数值为RTP版本号2,通过一个新的版本号区分RTP报文和广播加密密钥更新报文。
请参阅图2,为本发明实施例的广播加密更新方法的流程图。该广播加密更新方法包括以下步骤:
多媒体流通过会话密钥加密形成密文;
密文与广播密钥更新报文经过复用形成复合数据流发送到会话客户端,所述广播密钥更新报文包括加密保护的短效密钥STK和建立SRTP会话所需的参数;
由于采用RTP复用技术,通过设置报文缓存解决可能存在加密多媒体数据和密钥报文不同步的问题,发明人通过研究发现,不同步问题主要发生在RTP会话Session建立阶段和密钥更新阶段,对于第一种情况,在RTP会话刚刚开始,RTP的实时多媒体数据可能先于广播加密报文到达,会话接收端需要首先缓存SRTP的数据报文,等接收到广播加密报文后,解密SRTP的密钥生成参数,还原SRTP的会话密钥,解密缓存中的多媒体数据报文,对于第二种情况,即密钥更新阶段,需要缓存密钥更新报文,在密钥更新的过程中,IPTV的客户端需要缓存新旧两套会话密钥信息,客户端可以根据RTP报文的Seq#检验是否采用新的会话密钥解密内容,由于SSC算法的密钥更新周期通常只有秒级,无论缓存多媒体数据报文或是密钥更新报文都不会产生较大的缓存开销,同时也不会因为缓存多媒体数据导致不可接受的接入延时。
在RTP的编码实现中,首先对RTP端口收到的数据进行RTP协议验证,一般包括基于包和基于流的验证。基于包的验证方式首先判断Version字段,只有Version=2的报文交由RTP协议栈处理。在这里增加一个判断分支,例如Version=1的报文,送交广播加密程序处理。
具体的广播加密报文格式采用类似EKT的定义方式,包含SSRC、SEQ#、ROC以及可扩展的密文部分。密文部分包括子集标识符和子集密钥加密后的密文。报文中包含一个验证域,负责广播加密报文的完整性和真实性保护。另外报文中的安全参数索引(Security Parameter Index)用来区分不同周期的密钥更新报文,配合子集标识可以用于密钥更新报文的抗重放保护,具体的报文格式请参阅图3。
分离广播密钥更新报文和密文,解密还原STK,连同建立SRTP会话的参数生成会话密钥,用于多媒体数据流的解密。
在本发明实施例的广播加密更新方法中,用户的状态变化将会触发密钥更新过程。在IPTV***中,用户加入状态可以通过侦听RTSP的Setup报文获得。用户的离开状态主要表现在三个方面:结束RTP会话,切换频道或退出播放。三个方面都可能独立产生用户离开状态。针对第一种情况,可以通过处理RTCPBYE报文获得用户离开的信息。针对后两种情况,通过处理RTSP的Teardown消息或者编号为2103,5502,5401的Announce消息完成。
本发明实施例的广播加密更新方法的不同子集信息相互独立,没有依存关系。图3中的报文格式定义子集ID信息和加密子集密文信息成对出现。密钥更新报文沿着IPTV数据通道下发,实际的数据接收用户将逐渐限定到特定的子集。其它不相关的子集密钥更新信息对于下发路径上的用户没有实际意义,IPTV数据传输通道上的中间监测节点将会过滤这些不相关的子集密钥更新信息,并将鉴裁(Identification and Determination)后的密钥更新报文复用到RTP数据信道下发。具体的鉴裁效率和状态的子集覆(Stateful Subset Cover Algorithm)算法密钥树的构造相关,同一汇聚节点下的用户尽量集中覆盖在一个子集中可以在一定程度上简化鉴裁算法的运算量。本发明实施例结合终端状态子集覆盖SSC算法和SRTP协议的优势,利用SSC算法在广播加密方面的优势,完成SRTP主钥的分发。端状态子集覆盖SSC算法在用户数量为219,并且以正弦规律或单调指数递减变化时,广播报文中的子集数量仅为LKH(Logical KeyHierarchy)算法(由于LKH算法的提出早于完备子集概念,LKH密钥更新报文的子集数通常为LKH密钥树上需加密的路径节点数目)和SSD(Stateless SubsetDifferent)算法的1/4左右,并且密钥更新的子集数量和实际的用户数量无关,只与加入的用户数量和召回的用户数量有关,具体的表达式为:#of TotalSubsets=Δadded users+2×Δrevoked users+1。
本发明实施例中密钥更新的速度可以满足IPTV版权管理的需求。以带宽受限环境下的RTP复用方法为例,在模拟环境不变的情况下,由于采用RTP信道承载,密钥传送带宽由5%增加到95%。同时,RTP复用方法不需要引入RTP报头开销,所以相比一个RTCP EKT报文,实际的有效载荷因报头开销减小而增加64字节。综合以上两点,按照上文例子中的数据计算,总共需要2.4秒完成密钥更新,这个时间间隔可以满足IPTV数字版权的需要。
本发明实施例不需要复杂的防火墙穿越技术,就可以完成密钥更新报文的跨防火墙传输,无论RTP复用技术或者RTSP承载技术,两种技术分别借用IPTV的数据信道和控制信道,防火墙本身不需要建立额外的端口。
本发明实施例减少了对于现有协议的更改,减小具体实施的难度。采用RTP复用技术,密钥更新报文采用RTP数据信道传送,密钥更新报文可以灵活分段,以适应RTP传输的QoS策略。
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等,均应包含在本发明的保护范围之内。