[go: up one dir, main page]

CN100592785C - 数字版权管理的系统和网络电视运营系统 - Google Patents

数字版权管理的系统和网络电视运营系统 Download PDF

Info

Publication number
CN100592785C
CN100592785C CN200510074057A CN200510074057A CN100592785C CN 100592785 C CN100592785 C CN 100592785C CN 200510074057 A CN200510074057 A CN 200510074057A CN 200510074057 A CN200510074057 A CN 200510074057A CN 100592785 C CN100592785 C CN 100592785C
Authority
CN
China
Prior art keywords
key
content
user
management subsystem
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
CN200510074057A
Other languages
English (en)
Other versions
CN1874485A (zh
Inventor
陈宇
李强
黎文
范存志
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ud Network Co ltd
Original Assignee
UTStarcom Telecom Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by UTStarcom Telecom Co Ltd filed Critical UTStarcom Telecom Co Ltd
Priority to CN200510074057A priority Critical patent/CN100592785C/zh
Publication of CN1874485A publication Critical patent/CN1874485A/zh
Application granted granted Critical
Publication of CN100592785C publication Critical patent/CN100592785C/zh
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Storage Device Security (AREA)

Abstract

本发明提供了一种数字版权管理系统,包括:内容供应系统,用于存储和加密媒体内容;播放设备,用于播放媒体内容;授权管理子系统,用于为特定用户生成针对特定媒体内容的权利对象,并管理权利对象;以及密钥管理子系统,用于管理内容密钥,并根据授权管理子系统发出的请求生成相应的内容密钥;其中,所述授权管理子系统所产生的权利对象仅存储在授权服务器中;所述密钥管理子系统所生成的内容密钥在所述播放设备把媒体内容播放完毕、中止或者用户关机时被放弃。采用本发明所提供的上述系统,就能够很好地防止攻击者攻击权利对象。本发明还提供了一种包括上述数字权利管理系统的网络互动电视运营系统。

Description

数字版权管理的系统和网络电视运营系统
技术领域
本发明涉及网络互动电视(IP-BASED TV-IPTV)业务平台的数字版权管理系统,具体而言涉及在网络互动电视业务平台上的权利对象(License)管理和内容密钥管理机制。
背景技术
网络互动电视(IPTV),是基于宽带高速IP(Internet Protocol)网的一项以网络视频资源为主体,以电视机、手机等等为显示终端的流媒体服务。网络互动电视业务平台能根据用户的选择配置多种多媒体服务功能,包括数字电视节目、可视IP电话、互联网浏览以及商务功能。目前网络互动电视有如下几种终端:个人电脑;通过IP机顶盒接入的电视;以及可以显示多媒体内容的手机。
网络互动电视IPTV提供了三种视频的发送方式:现场直播、定时广播和点播。在现场直播的同时还可以把直播的内容存储下来,作为定时广播或者点播的节目源。对于现场直播和定时广播,节目网络互动电视使用可节省带宽的IP多点发送方法即组播(Multicast)方式,该方式允许“一发多收”式节目发送。使用这种方式,网络为每个节目只发送一个实时数据流而与收看节目的人数无关。这样您可以将节目发送给几个甚至几千个用户而不会加重带宽的负载。
IPTV与众不同的优势是在提供高质量音视频内容的同时为用户提供足够的交互操作支持,用户能够在节目的播放过程中自由地选择暂停、恢复、多倍速快进、多倍速快退和中止等交互操作。
网络互动电视IP/TV采用了国际标准协议,如实时传输协议RTP(Real time Transport Protocol)、实时控制协议RTCP(Real timeControl Protocol)、实时流协议RTSP(Real time StreamingProtocol)。此外IP/TV还可运行于多种网络之上,包括10/100M BaseT以太网、千兆以太网、ATM网络、ADSL网络及带LAN仿真的其他网络。
网络互动电视业务平台除了为最终用户提供高质量的音视频服务以外,还为内容提供商和运营商赢得足够的利益。网络互动电视业务平台对于安全性的需求与对低成本、高性能、高可靠性、良好的可管理性、网络友好性和用户友好性等需求有着同等重要的地位。网络互动电视业务平台对安全性的要求包括:1)只有注册用户才能请求各种收费音视频服务;2)合法用户只能在规定的权限范围内使用各种音视频服务;3)能够抵御攻击者采用数字或模拟的方法盗版音视频内容。网络互动电视业务平台依靠用户认证系统满足需求1,依靠由MacroVision公司所开发的MacroVision技术或CGMS(Copy GenerationManagement System)/SCMS(Serial Copy Management System)技术保证模拟音视频内容的盗版问题。对于需求2和需求3中的数字音视频内容的防盗版问题,网络互动电视业务平台需要数字版权管理系统(Digital Right Management Sytent-DRMS)的支持。数字版权管理系统由内容制作子系统、密钥管理子系统和授权管理三个子系统构成。
内容制作子系统由内容库存储系统、产品信息库和内容打包器组成。内容存储系统存储媒体内容和相应的元数据,并向最终用户提供服务;产品信息库存储有与媒体内容的销售相关的信息,这些信息包括价格、计费时段、其它促销信息等等。内容打包器按照适合于在宽带网络上传输的格式对媒体内容、元数据和产品信息进行打包。此外,内容打包器还对媒体内容进行加密,以避免在传输过程中明文的媒体内容被盗取和非法使用。
密钥管理子系统为内容存储系统中所存储的媒体内容生成内容密钥,并负责维护媒体内容和内容密钥之间的映射关系。为了避免攻击者以合法用户的身份与密钥管理子系统交互并对其进行攻击,密钥管理子系统在一般情况下并不直接与最终用户的播放设备进行交互。
授权管理子系统是数字版权管理系统的核心,由授权服务器和授权控制器组成。授权服务器根据用户的请求为用户生成权利对象,该用户只能在该授权服务器为该用户所生成的权利对象所许可的范围之内来使用与该权利对象相对应的媒体内容。其中,权利对象定义了使用媒体内容的规则。权利对象由权利对象本身和权利属性组成。权利对象本身定义了用户对内容的处理方式。根据处理方式的不同,权利对象可以划分为使用、交换和派生三种类型。权利对象的属性分别包括:使用权利的代价、使用权利的次数和时间以及使用权利的用户类型。此外,权利对象还包含用户的个人信息,所以权利对象只能由与其中所包含的个人信息相对应的特定用户或用户组来使用。授权控制器对授权服务器所生成的权利对象进行解析,并控制用户按照权利对象定义的规则来使用媒体内容。
内容制作子系统所包含的内容打包器把媒体内容的元数据、内容密钥相关信息和指向授权服务器的定位信息放在媒体内容的文件头中,可以把它们放在独立的元信息文件中。前者适用于文件播放模式,但难以支持普通流媒体业务;后者管理开销略大,但是具有更好的灵活性,适用于多种不同的业务模式。
内容打包器对媒体内容进行加密,以保证攻击者无法直接使用在传输过程中所截取的媒体内容。内容打包器对媒体内容进行加密可以采用多种加密算法。加密算法可以分为对称加密算法和公钥加密算法。对称加密算法实现简单,加密效率高,能够支持对大量数据的实时加密,并且不增加原始数据包的大小。公钥加密算法具有更高的加密强度,但运算开销较大,且加密会改变原始数据包的大小。对于网络互动电视业务而言,鉴于其节目数据量大、实时性强的特点,内容打包器对媒体内容进行加密采用对称加密算法较为适宜。数据加密算法(DES-Data Encryption Standard)、3DES(Triple Data EncryptionStandard,也叫三重数据加密标准)和AES(Advance EncryptionStandard,先进加密标准)是典型的对称加密算法。其中,由于DES的加密强度已远远不能满足对媒体内容的安全性需求,并且3DES和AES在今后的若干年内会得到广泛的使用,因而内容打包器采用3DES或AES来多媒体内容进行加密。
内容打包器在对媒体内容加密之时在选择合适的加密算法之外,还需要确定如何使用所选择的加密算法来加密媒体内容。在实际的加密过程中,内容打包器并不直接使用内容密钥按照加密算法来对加密媒体内容,而是利用从密钥管理子系统所生成的内容密钥而派生出的一系列子密钥,并用子密钥对媒体内容进行加密。派生子密钥的方法有很多种,其中最典型的是利用内容密钥加密每个加密单元的绝对偏移量,然后用加密后的偏移量加密相应的加密单元。
采用3DES或AES加密算法已经能够保证攻击者在没有内容密钥的情况下无法在足够短的时间内解密节目来获得非法的收益。因此,如何安全存放和安全发布内容密钥就变成了数字版权管理系统的核心问题。
内容密钥的发放与对用户的授权相关。最终用户的播放设备根据从媒体内容的元信息文件中所获取的授权服务器的定位信息来向授权服务器发送权利对象的申请。授权服务器首先需要验证用户是否具有足够的使用权限。授权服务器为通过验证的用户生成相应的权利对象。通常,授权服务器与密钥管理子系统进行交互以便获得与媒体内容相对应的内容密钥,并把用请求权利对象的用户的公钥所加密的内容密钥保存在为该用户所生成的权利对象,再将该权利对象传送到该用户的最终用户播放设备中。该权利对象由安装在最终用户播放设备中的数字版权控制器来管理和解析。因此,用户只能在该权利对象规定的权利范围内来使用该权利对象中所包含的内容密钥来访问媒体内容。此外,权利对象还包含状态信息,因而安装在最终用户播放设备中的数字版权控制器要对权利对象进行更新,以便使权利对象中所包含的状态信息能够正确地反映用户对媒体内容的访问情况。
在传统的网络互动电视业务平台中,媒体内容和内容密钥均由网络互动电视业务平台运营商掌握。现如今,随着内容提供商在网络互动电视业务中的积极参与,对数字版权管理系统就提出了新的需求,这种新的需求是:媒体内容由网络互动电视业务平台的运营商掌握,而内容密钥由内容提供商来掌握,这样就能够在根本上控制媒体内容。目前的数字版权管理系统并不能满足上述的新需求。
此外,在目前的数字版权管理系统中,由授权服务器所生成的权利对象由最终用户的播放设备加以控制和更新,因而在安全性上就存在着较大的漏洞,原因在于攻击者可以在最终用户关闭其播放设备之后,能够采用各种方式来攻击在用户的播放设备中所存储的权利对象,例如,攻击者可以修改权利对象的属性,或获取媒体内容的内容密钥。
从上述的现有技术所存在的缺陷来看,需要提供一种能够防止攻击者攻击权利对象的数字权利管理系统。
发明内容
为了克服现有技术所存在的上述缺陷,本发明提供了如下的系统和设备。
在本发明的一个方面,提供了一种数字版权管理系统,包括:
内容供应系统,用于存储和加密媒体内容;
播放设备,用于播放媒体内容;
授权管理子系统,用于为特定用户生成针对特定媒体内容的权利对象,并管理权利对象;
密钥管理子系统,用于管理内容密钥,并所根据授权管理子系统发出的请求生成相应的内容密钥;
所述授权管理子系统所产生的权利对象仅存储在授权服务器中;
所述密钥管理子系统所生成的内容密钥在媒体内容播放完毕、中止或者用户关机时被放弃。
在本发明的另一个方面,还提供了一种网络互动电视运营系统,包括:
上述的数字权利管理系统;
电子节目指南服务器,用于向用户推荐节目;
媒体服务器,响应所述数字权利管理系统而向最终用户播放设备发送所加密的媒体节目;
计费系统,根据所述数字权利管理系统的请求计费。
采用本发明所提供的上述系统,就能够很好地防止攻击者攻击权利对象,并且具有如下的优点:
1.上述数字版权管理系统支持内容提供商对媒体内容的版权控制,即内容提供商通过控制内容密钥的发布实现对租用给网络互动电视运营商的媒体内容的控制;
2.上述数字版权管理系统支持网络互动电视运营商对自有媒体内容的完全控制,即网络互动电视运营商控制自有媒体内容的内容密钥的发布;
3.上述数字版权管理系统将权利对象与内容密钥分离,权利对象仅存在于授权管理子系统中的授权服务器中,内容密钥在被用户公钥加密后交给最终用户的播放设备;
4.在最终用户的播放设备上,解密后的内容密钥仅存在于解密模块的私有存储空间中,并将在媒体内容播放完毕、中止或用户关机时被放弃;
5.本数字版权管理系统中,内容提供商不直接与最终用户交互,内容密钥通过授权管理子系统到达最终用户;
6.内容供应商的内容密钥在交给网络互动电视运营商前将用最终用户的公钥加密以避免网络互动电视运营商窃取内容密钥;
7.本数字版权管理系统同时支持LiveTV和视频点播VoD(Videoon Demand)业务。
附图说明
在以下结合本发明的实施例且参考附图并采用举例的方式对本发明的发明特点和优点进行解释和说明,以便能够使得本领域技术人员对本发明有更好的理解。
图1示出了根据本发明的数字版权管理系统的框图。
图2示出了图1中的媒体生成器加密媒体内容的示意图。
图3示出了图2中的媒体生成器对媒体内容进行加密过程的流程图。
图4示出了图1中的密钥服务器所维护的节目与内容密钥之间的映射关系的示意图。
图5示出了图1中的密钥服务器所维护的频道与内容密钥之间的映射关系的示意图。
图6示出了图1中的最终用户播放设备申请权利对象的示意图。
图7示出了图1中的密钥代理管理模块和密钥代理模块之间的相互关系的示意图。
图8示出了申请内容密钥的示意图。
图9示出了图1中的运行支持系统OSS(Operation SupportingSystem)申请权利对象的示意图。
图10示出了图1中的最终用户播放设备使用权利对象的示意图。
图11示出了最终用户播放设备的数据权利要求管理模块(DigitalRight Management-DRM)的框图。
图12A和12B示出了图1中的EPG(Electronic Program Guide)服务器申请权利对象和密钥对象的过程的流程图。
图13示出了图1中的密钥代理模块管理密钥申请的过程的流程图。
图14A、14B和14C示出了图1中的用户会话控制器USC(UserSession Contoller)申请权利对象和密钥对象的过程的流程图。
图15A和15B示出了图1中的密钥代理管理模块工作的过程的流程图。
图16A和16B分别示出了图1中的用户位置归属器SLR(Subscriber Location Registery)申请和更新权利对象的过程的流程图。
图17示出了图1中的密钥服务器对权利对象和密钥的管理的流程图。
图18示出了在最终用户播放设备中对所接收的媒体内容进行节流的流程图。
具体实施方式
图1示出了根据本发明的数字版权管理系统的框图。其中,数字版权管理系统由内容供应系统11、密钥管理子系统10、授权管理子系统13以及最终用户播放设备14构成。
密钥管理子系统10包括密钥服务器113,用于为媒体内容库117中的媒体内容产生密钥并且维护媒体内容与密钥之间的对应关系。
内容供应系统11包括:媒体内容库117,用于存储媒体内容和相应的元数据;媒体生成器115,用于根据媒体内容中的明文节目根据密钥服务器10为该节目所生成的内容密钥来加密该节目,并且将加密的媒体节目发送到网络互动电视运营系统12中的媒体服务器126。授权管理子系统13由密钥代理管理模块121、用户位置归属器123、用户会话控制器127以及权利对象服务器125(License Server)组成。
网络互动电视运行系统12由所述授权管理子系统13、运营支持系统122、计费系统BS(Billing System)124、媒体服务器126和电子节目指南EPG服务器128组成。其中媒体服务器126响应用户会话控制器127而向最终用户播放设备14发送所加密的媒体节目。优选地,所述密钥管理子系统还包括密钥代理模块111,作为与授权管理子系统13与密钥服务器113之间的中间插件模块。需要说明的是,密钥代理模块111并不是必须的,授权管理子系统13在逻辑上可以直接与密钥服务器113相交互。
其中,用户位置归属器123从权利对象服务器125为用户获取权利对象。用户位置归属器123根据权利对象向计费系统124请求计费。位置归属器123依靠权利对象服务器125所生成的权利对象通过密钥代理管理模块121直接从密钥服务器113获得节目的内容密钥。优选地,所述密钥管理代理模块121通过密钥代理模块111从密钥服务器113获得节目的内容密钥。仅仅把密钥服务器113所生成的内容密钥发送最终用户播放设备14。媒体服务器126发出权利对象更新请求。运营支持系统122或者来自EPG服务器128的用户请求向用户位置归属器123发出权利对象创建和更新请求。用户会话控制器127依靠权利对象通过密钥代理模块121获得节目的内容密钥。
注意,内容供应系统和网络互动电视运营系统可以属于同一实体,也可以属于不同的实体。
密钥服务器113通过授权管理子系统13与最终用户设备14交互,避免最终用户设备14直接访问密钥服务器带来潜在安全漏洞。授权管理子系统13的核心是用户位置归属器123,管理整个授权流程。
图2示出了图1中的媒体生成器115加密媒体内容的示意图。在图2中,媒体生成器115采用AES算法利用内容密钥201对媒体内容进行加密。媒体生成器115也可以采用3DES算法来代替AES算法对媒体内容进行加密。
图3示出了图2中的媒体生成器115对媒体内容进行加密过程的流程图。首先,该过程进入到步骤S301,在该步骤,媒体生成器115输入媒体内容的第一个128位作为Block1。然后,该过程进入到步骤S303,在该步骤输入媒体内容的第二个128位作为Block2。然后,该过程进入到步骤S305,在该步骤进行异或运算,Block2=Block2 XORBlock 1。结合图2可以看出,每个Block2均采用不同的Block1进行异或,因此消除了依靠大量数据进行异或破解的可能。接着,该过程进入到步骤S307,在该步骤计算加密单元即-Block1的偏移量(Offset),Offset1=Block1的相对偏移量。接着,进入到步骤S309,在该步骤产生内容的一个子密钥,其中Offset2=用内容密钥对在步骤S307所产生的偏移量Offset1进行加密之后的结果。然后,该过程进入到步骤S311,在该步骤,输出Block1加密之后的结果,Block1=Block1 XOR Offset2。接着,该过程进入到步骤S313,在该步骤输出Block1和Block2。然后,该过程进入到步骤S315,在该步骤判断是否到达了媒体内容的末尾,如果到达了媒体内容的末尾,则该过程就结束。否则,该过程就返回到步骤S301,在该步骤继续对尚未加密的媒体内容继续加密,步骤S301-S315反复循环进行,直到不再有媒体内容要被加密了为止。
此外,与采用AES的算法相比,异或的运算复杂度要低得多。因此,交替出现的AES计算和异或计算能够显著降低加密媒体内容加密的开销。
分段多密钥加密尽管能够在一定程度上提高媒体内容的安全性,但存在着维护较为复杂的缺点。此外,由于加密算法已经拥有足够的加密强度,内容密钥本身的泄漏才是密钥管理子系统最致命的安全漏洞。因此,本发明不采用分段多密钥加密。对于视频点播VoD节目,每个节目对应一个内容密钥;对于LiveTV,每个频道每天更换一个内容密钥。
图4示出了图1中的密钥服务器所维护的媒体内容与内容密钥之间的映射关系的示意图。密钥服务器113以该图中的存储结构来存储媒体内容与内容密钥之间的映射关系。图中的每一行是32位,每一列是1位,共计32列。在该存储结构中,头32位(也就是第一行)中的第0、1位为存储结构的版本号V,目前为版本号为1,即V=1;第2位标识内容密钥是否被加密,其中E=1表示内容密钥已经被加密,E=0则表示内容密钥未被加密;第3位为标记位,M=0表示为媒体内容的第一个内容密钥,M=1表示媒体内容的第二个内容密钥(因为频道的密钥切换可能在节目播放过程中出现,因此一个媒体内容可能有两个内容密钥);第3位至8位为预留位;第9至15位是加密算法的类型401;第16至31位为密钥长度403。第二个32位(即第二行)为媒体内容的标识ID 405,表示为Content_ID,媒体内容ID包括两部分,即前24位是节目ID,后8位是分段ID,当分段ID是11111111之时,表示媒体内容的所有分段共享同一内容密钥。第三个32位(即第三行)为密钥ID 407,表示为Key_ID,当E为0时,该字段为全0,表示内容密钥未被加密;否则表示用于存储密钥服务器113或密钥代理模块111加密内容密钥时所用的密钥(即用户公钥)的ID。后面的行为内容密钥409,内容密钥总是32位的整数倍。对于实时电视(LiveTV),同一频道的多个节目共享同一内容密钥。
图5示出了图1中的密钥服务器所维护的频道与内容密钥之间的映射关系的示意图。密钥服务器113以该图中这中存储结构来存储频道与内容密钥之间的映射关系。图中的每一行是32位,每一列是1位,共计32列。在该存储结构中,头32位(也就是第一行)中的第0、1位为存储结构的版本号V,目前为版本号为1,即V=1;第2位标识内容密钥是否被加密,其中E=1表示内容密钥已经被加密,E=0则表示内容密钥未被加密;第3位为标记位,M=0表示为媒体内容的第一个内容密钥,M=1表示媒体内容的第二个内容密钥(因为频道的密钥切换可能在节目播放过程中出现,因此一个媒体内容可能有两个内容密钥);第3位至8位为预留位;第9至15位是加密算法的类型501;第16至31位为密钥长度503。第二个32位(即第二行)为频道的标识ID 505,表示为Channel_ID,频道ID包括两部分,即前24位是节目ID,后8位是分段ID,当分段ID是11111111之时,表示媒体内容的所有分段共享同一内容密钥。第三个32位(即第三行)为密钥ID 507,表示为Key_ID,当E为0时,该字段为全0,表示内容密钥未被加密;否则表示用于存储密钥服务器113或密钥代理模块111加密内容密钥时所用的密钥(即用户公钥)的ID。后面的行为频道密钥509,频道密钥509总是32位的整数倍。对于实时电视(LiveTV),同一频道的多个节目共享同一内容密钥。
图6示出了图1中的最终用户播放设备申请权利对象的示意图。在本发明的一个实施例中,最终用户播放设备601基于TCP/IP协议向用户会话控制器605发送加密的、请求权利对象的XML消息,该XML消息中包含如下参数:U_ID(用户ID)、CRID(内容ID)、Num/Time(希望收看的次数和时间)和Pub_Key(用户公钥,由用户设备(例如机顶盒)每次发出请求时随机产生)。最终用户播放设备601使用与用户会话控制器605之间共享的加密密钥对这些参数进行加密,然后进行发送。
在一种优选实施方式中,最终用户播放设备601通过电子节目指南服务器603采用HTTP协议发送请求权利对象的XML消息。该XML请求消息中包含如下参数:U_ID(用户ID)、CRID(内容ID)、Num/Time(希望收看的次数和时间)和Pub_Key(用户公钥,由用户设备(机顶盒)每次发出请求时随机产生)。最终用户播放设备601使用它们之间共享的加密密钥对这些参数进行加密,接着把加密之后的参数添加到HTTP分组的首部中,最后把该HTTP分组发送到电子节目指南服务器603。电子节目指南服务器603根据从最终用户播放设备601所接收的HTTP分组中的那些参数创建一个请求权利的XML消息。电子节目指南服务器603使用与用户会话控制器605之间共享的加密密钥来对所创建的XML消息进行加密,然后,将该XML消息发送到用户会话控制器605。电子节目指南服务器601所创建的请求权利的XML消息(其中,该XML消息中包含了对多个媒体内容或媒体内容包的请求)如下所示:
<?xml vetsion=″1.0″encoding=″utf-8″?>
<Right_Reques t>
<User_ID>user_id</User_ID>
                                 /*用户标识*/
<Request_ID>request_id</Request_ID>
                                 /*请求标识*/
<LIST>
<Content_ID>content_id_1</Content_ID>
                                 /*内容标识*/
<Operation_Mode>play</Operation_Mode>
                                 /*操作标识*/
<Count>10</Count>
                                 /*播放次数*/
<Start>2005-02-02 T00:00:00Z</Start>/*License
                                 /*生效时间*/
<End>2005-03-02 T23:59:59Z</End>
                                 /*License失效时间*/
<Status>use</Status>
                                 /*请求的状态*/
  </LIST>
<LIST>
<Content_ID>content_id_2</Content_ID>
                                 /*内容标识*/
<Operation_Mode>play</Operation_Mode>
                                 /*操作标识*/
<Count>5</Count>
                                 /*播放次数*/
<Start>2005-02-07 T00:00:00Z</Start>
                                 /*License生效时间*/
<End>2005-03-07 T23:59:59Z</End>
                                 /*License失效时间*/
<Status>buy</Status>
                                 /*请求的状态*/
</LIST>
<LIST>
<Package_ID>content_id_3</Package_ID>
                                 /*内容标识*/
<Operation_Mode>play</Operation_Mode>
                                 /*操作标识*/
<Count>8</Count>
                                 /*播放次数*/
<Start>2005-02-02 T00:00:00Z</Start>
                                 /*License生效时间*/
<End>2005-03-02 T23:59:59Z</End>
                                 /*License失效时间*/
<Status>buy</Status>
                                 /*请求的状态*/
  </LIST>
  <Pub_Key>pub_key</Pub_Key>
                                 /*用户公钥*/
</Right_Request>
该权利请求消息的属性声明见表1:
                  表1
  属性   描述   数据类型
  User_ID   用户标识   Int(80bits)
  Request_ID   请求标识   Int(64bits)
  Content_ID   内容标识(单个节目)   Int(32bits)
  Package_ID   内容标识(一组节目)   Int(32bits)
  Operation_Mode   操作类型   String
  Count   内容播放的次数   Int(32bits)
  Start   License的生效时间   String
  End   License的失效时间   String
  Status   请求的状态   String
  Pub_Key   用户公钥   Int(1024bits)
其中,作为属性的Status(状态)字段用于表示用户希望立刻获得媒体内容的内容密钥以开始节目播放(Status=use(使用)),还是仅仅购买媒体内容的权利对象供今后的播放使用(Status=buy(购买))。在每个请求中,最多只有一个内容的Status字段为“use”。
用户会话控制器605使用与电子节目指南服务器603之间共享的密钥来对所接收的XML格式的消息进行解密,并用用户会话控制器605和用户位置归属器SLR 607之间共享的消息加密密钥再次加密该消息,然后发往用户位置归属器607。用户位置归属器607用与用户会话控制器605之间共享的消息加密密钥解密该XML消息,并根据本地存储的用户信息检验用户发出的请求是否有效。对于有效的用户请求,用户位置归属器607用用户位置归属器607和权利对象服务器609之间共享的消息加密密钥再次加密来自用户会话控制器605的XML信息,并将其发往权利对象服务器609。权利对象服务器609根据收到的消息为每个媒体内容或媒体内容包生成独立的权利对象。与上文所述的用户请求相对应的权利对象如下:
  <?xml version=″1.0″encoding=″utf-8″?>
  <License_Object>
  <Version>1.0</Version>
  <Right_ID>right_id_1</Right_ID>
  <User_ID>user_id</User_ID>
  <Request_ID>request_id</Request_ID>
  <Status>0x01</Status>
  <Agreement>
  <Content_ID>content_id_1</Content_ID>
  <Permission>
  <Operation Mode=″play″>
  <Constraint>
  <Count>10</Count>
  <Start>2005-02-02 T00:00:00Z</Start>
  <End>2005-03-02 T23:59:59Z</End>
  </Constraint>
  </Operation>
  </Permission>
  </Agreement>
  </License_Object>
  <?xml version=″1.0″encoding=″utf-8″?>
  <License_Object>
  <Version>1.0</Version>
  <Right_ID>right_id_2</Right_ID>
  <User_ID>user_id</User_ID>
  <Request_ID>request_id</Request_ID>
  <Status>0x01</Status>
  <Agreement>
  <Content_ID>content_id_2</Content_ID>
  <Permission>
  <Operation Mode=″play″>
  <Constraint>
  <Time>5</Count>
  <Start>2005-02-07 T00:00:00Z</Start>
  <End>2005-03-07 T23:59:59Z</End>
  </Constraint>
  </Operation>
  </Permission>
  </Agreement>
  </License_Object>
  <?xml version=″1.0″encoding=″utf-8″?>
  <License_Object>
  <Version>1.0</Version>
<Right_ID>right_id_2</Right_ID>
  <User_ID>user_id</User_ID>
  <Request_ID>request_id</Request_ID>
  <Status>0x01</Status>
  <Agreement>
  <Package_ID>content_id_3</Package_ID>
  <Permission>
  <Operation Mode=″play″>
  <Constraint>
  <Time>5</Count>
  <Start>2005-02-02 T00:00:00Z</Start>
  <End>2005-03-02 T23:59:59Z</End>
  </Constraint>
  </Operation>
  </Permission>
  </Agreement>
  </License_Object>
该权利申请消息的属性声明见表2:
                  表2
  属性  描述   数据类型
  Version  License的版本号   Int(32bits)
  Right_ID  权利对象标识   Int(80bits)
  User_ID  用户标识   Int(80bits)
  Request_ID  请求标识   Int(64bits)
  Status  是否为新生成的License   Int(8bits)
  Content_ID   内容标识(单个节目)   Int(32bits)
  Package_ID   内容标识(一组节目)   Int(32bits)
  Operation   操作类型,模式为play   String
  Count   内容播放的次数   Int(32bits)
  Start   License的生效时间   String
  End   License的生效时间   String
权利对象服务器609首先对所生成的权利对象进行签名,并采用RSA(Rivest-Shamir-Adleman)算法来对所述签名进行加密以保证权利对象的完整性和一致性。该权利对象的签名和加密格式如下:
License+RSA(MD5(License))LS_Private_Key
上述消息由权利对象服务器609和用户位置归属器607共享的密钥加密后发往用户位置归属器607。用户位置归属器607将验证该权利对象的有效性,并根据有效权利对象的权限(Permission)和约束(Constraint)向计费系统BS 611发送计费请求。需要说明的是,从图1可以看出,计费系统并不属于授权管理子系统13,属于网络互动电视运营系统12对用户进行计费的模块。计费系统611完成扣费操作后向用户位置归属器607返回计费响应。计费请求和计费响应消息采用计费系统611和用户位置归属器607之间共享的密钥加密来确保通信安全性。为保证所有网元相互之间的交互消息,所有的交互消息均在加密后传输,优选地,采用Kerberos架构(该Kerberos架构是从MIT(麻省理工)的一项研究计划中衍生出来的,也已经成为标准草案(RFC1510)来实现网元间的认证和密钥交换。用户位置归属器607需要权利对象服务器609的公钥,公钥的交换在权利对象服务器609向用户位置归属器607认证时进行,此后每隔一定时间,权利对象服务器609将向用户位置归属器607发送公钥更新消息,消息均以加密格式传递。
图7示出了密钥代理管理模块和密钥代理模块之间的相互关系的示意图。上述结合图6的描述,用户位置归属器607获得权利对象后,立刻向密钥代理管理模块(Key Agent Mgnt)709申请该权利对象中的媒体内容的内容密钥。需要说明的是,密钥管理子系统10与授权管理子系统13可以同属一个实体,也可以分属不同的实体。但是,无论这两个系统间的归属关系如何变化,密钥管理子系统10和授权管理子系统13间采用流程方式交互。
在一种优选实时方式下,所述密钥管理子系统10包括密钥代理模块,是授权管理子系统13与密钥管理子系统10之间交互的桥梁。由于网络互动电视运营系统12可能与多个内容提供系统11交互,因此授权管理子系统13可能与多个密钥管理子系统10互联,其中包括网络互动电视运营系统12自己控制的密钥管理子系统10。授权管理子系统10的密钥代理管理模块709与多个密钥管理子系统10交互。在上述的优选实施方式下,与多个密钥代理模块703、705、707交互。
密钥代理模块703、705、707分别向密钥服务器701和密钥代理管理模块709注册。需要说明的是,图7只给出了三个密钥代理模块703、705、707。实际上密钥代理模块的数目取决于和上述的网络互动电视运营系统12所连接的内容供应系统11的数目。密钥代理模块703、705、707拥有密钥服务器701发布的证书,并将利用该证书实现与密钥服务器701之间的安全通信。密钥服务器701定期更新发给密钥代理模块703、705、707的证书。密钥代理管理模块709将来自用户位置归属器123的权利对象和用户公钥转发至对应的密钥代理模块703、705、707,以申请与权利对象中的媒体内容相对应的密钥对象。密钥代理模块703、705、707将消息转发至密钥服务器701。密钥服务器701验证收到的消息中的权利对象的有效性,并为有效的权利对象生成相应的密钥对象。密钥服务器701将记录所有标记(Markup)字段为0x01的权利对象,做为内容供应系统11与网络互动电视运营系统12之间对帐和分成之用,不过这一操作不属于授权管理子系统的能力范畴。所生成的密钥对象包含用户请求的媒体内容的内容密钥,该内容密钥将用密钥代理模块703、705、707的公钥加密,而整个消息将由密钥服务器701进行摘要和数字签名。密钥对象的具体格式如下:
<?xml version=″1.0″encoding=″utf-8″?>
<Key_Object>
<Version>1.0</Version>
<Right_ID>right_id_1</Right_ID>
<User_ID>user_id</User_ID>
<Content_ID>content_id_1</Content_ID>
<Status>0x01</Status>
<Markup>0x01</Markup>
<Key_Num>0x02</Key_Num>
<Key_Info>
<List>
<Encrypt_Algorithm>AES</Encrypt_Algorithm>
<Key_Length>0x80</Encrypt_Algorithm>
<Key>XXXX</Key>
</List>
<List>
<Encrypt_Algorithm>AES</Encrypt_Algorithm>
<Key_Length>0x80</Encrypt_Algorithm>
<Key_Value>XXXX</Key_Value>
</List>
</Key_Info>
</Key_object>
密钥对象的属性声明见表3:
                            表3
  属性   描述   数据类型
  Version   密钥对象的版本号   Int(32bits)
  Right_ID   权利对象标识   Int(80bits)
  User_ID   用户标识   Int(80bits)
  Content_ID   内容标识(单个节目)   Int(32bits)
  Package_ID   内容标识(一组节目)   Int(32bits)
  Status   是否为新生成的权利对象   Int(8bits)
  Key_Num   密钥数量   Int(8bits)
  Encrypt_Algorithm   加密算法   String
  Key_Length   内容密钥的长度   Int(8bits)
  Key_Value   内容密钥的值   Int(128bits)
密钥服务器701将对密钥对象签名,并采用RSA算法加密签名以保证密钥对象的完整性和一致性。为保证密钥传输的安全性,密钥服务器701用密钥服务器和密钥代理模块共享的对称密钥来加密该密钥对象。完整的签名和加密格式如下:
AES(Key_Object+RSA(MD5(Key_Object))Key_Server_Private_Key)Server_Agent_Key
密钥代理模块703、705、707收到来自密钥服务器701的密钥对象后,解密密钥对象并验证内容密钥的完整性和一致性。密钥代理模块703、705、707按照图4和图5的格式缓存内容密钥,且内容密钥将以加密形式存储。密钥代理模块703、705、707向密钥代理管理模块709返回密钥对象消息,其中密钥代理模块703、705、707将采用RSA算法并使用用户公钥对内容密钥加密。密钥代理模块703、705、707将对密钥对象签名,并采用RSA算法加密签名以保证权利对象的完整性和一致性。
设Encrypted_Object=RSA(Key_Object)STB_Public_Key,则完整的签名和加密格式如下:
Encrypted_Object+RSA(MD5(Encrypted_Object))Key_Agent_Private_Key
密钥代理模块703、705、707处理后的密钥对象的具体格式如下:
<?xml version=″1.0″encoding=″utf-8″?>
<Key_Object>
<Version>1.0</Version>
<Right_ID>right_id_1</Right_ID>
<User_ID>user_id</User_ID>
<Content_ID>content_id</Content_ID>
<Status>0x01</Status>
<Markup>0x01</Markup>
<Key_Num>0x02</Key_Num>
<Key_Info>
<List>
<Encrypt_Algorithm>AES</Encrypt_Algorithm>
<Key_Length>0x80</Encrypt_Algorithm>
<Pub_Key_Algorithm>RSA</Pub_Key_Algorithm>
<Key>XXXX</Key>
</List>
<List>
<Encrypt_Algorithm>AES</Encrypt_Algorithm>
<Key_Length>0x80</Encrypt_Algorithm>
<Key_Value>XXXX</Key_Value>
</List>
</Key_Info>
</Key_object>
密钥对象的属性声明如下:
  属性  描述   数据类型
  Version  密钥对象的版本号   Int(32bits)
  Right_ID  权利对象标识   Int(80bits)
  User_ID  用户标识   Int(80bits)
  Content_ID  内容标识(单个节目)   Int(32bits)
  Package_ID  内容标识(一组节目)   Int(32bits)
  Status  是否为新生成的License   Int(8bits)
  Key_Num  密钥数量   Int(8bits)
  Encrypt_Algorithm  加密算法   String
  Key_Length  内容密钥的长度   Int(8bits)
  Key_Value  内容密钥的值   Int(128bits)
密钥代理管理模块709不对收到的消息做任何附加操作,而是直接转发给用户位置归属器。用户位置归属器将验证密钥对象的完整性和一致性。
图8给出了密钥申请的流程。首先,用户位置归属器801采用TCP/IP协议把经过签名的权利对象消息和用户公钥即Pub_Key发送到密钥代理管理模块803。密钥代理管理模块803采用TCP/IP协议把收到的、经过用户位置归属器801签名的权利对象消息和用户公钥转发到密钥代理模块805。在一种优选方式下,则直接转发到密钥服务器807。密钥代理模块805采用TCP/IP协议把收到的、经过用户位置归属器801签名的权利对象消息转发到密钥服务器807。密钥服务器807在收到密钥代理模块805所发送的经过用户位置归属器801签名的权利对象消息之后,生成密钥对象消息,并对该密钥对象消息加密,然后采用TCP/IP协议把加密的密钥对象消息发送到密钥代理模块805。密钥代理模块805在收到由密钥服务器807所加密的密钥对象消息之后,使用它们之间共享的密钥来解密该密钥对象消息,然后对该密钥对象消息签名(使用密钥代理模块805和密钥代理管理模块803之间共享的密钥加密该密钥对象消息)。然后,密钥代理管理模块803采用TCP/IP协议把所签名且加密的密钥对象消息发送给用户位置归属器801。用户位置归属器801在获得了上述的密钥对象消息之后,对其进行解密,从而获得密钥。
用户位置归属器801将权利对象的Status置位为0x0,并将更新后的权利对象发往用户会话控制器。此外,对于Status字段为“use”的权利请求消息,用户位置归属器801将该消息对应的密钥对象返回用户会话控制器。对于Status字段为“buy”的权利请求消息,用户位置归属器801将抛弃该消息对应的密钥对象。权利对象由用户位置归属器801签名,但不对密钥对象签名。上述权利对象在用户位置归属器801和用户会话控制器间传输时采用用户位置归属器801和用户会话控制器共享的对称密钥加密。用户会话控制器将缓存权利对象,并将密钥对象通过电子节目指南服务器发往最终用户播放设备。在用户会话控制器到电子节目指南服务器和电子节目指南服务器到播放设备的通道中,密钥对象将用通信双方共享的对称密钥加密传输。
图9示出了图1中的运行支持系统OSS申请权利对象的示意图。
除上述流程外,网络互动电视运营系统12的运行支持系统901也能发起权利对象申请流程。在图9中,运行支持系统901首先对带有U_ID、CRID、Num/Time和Pub_Key的XML消息加密,然后采用TCP/IP协议将该加密的消息发送到用户位置归属器903。用户位置归属器903采用TCP/IP协议把接收到的加密的XML消息转发到权利对象服务器905。然后,权利对象服务器905根据所接收到的消息中的请求生成权利对象消息。接着,权利对象服务器905采用TCP/IP协议把加密的权利对象消息发送到用户位置归属器903。用户位置归属器903在接收到该权利对象之后,采用TCP/IP协议向计费系统907发送加密的计费消息。计费系统907采用TCP/IP协议向用户位置归属器903发送加密的、计费成功的应答消息。然后,用户位置归属器903对权利对象进行加密和签名,并采用TCP/IP协议把上述加密且签名的权利对象消息发送到密钥代理管理模块911。密钥代理管理模块911把所接收的权利对象消息发送到密钥代理模块,在从密钥代理模块返回密钥对象消息之后,对该密钥对象消息进行签名和加密,然后采用TCP/IP协议把所签名和加密的密钥对象消息发送到用户位置归属器903。用户位置归属器903采用与密钥代理管理模块911之间共享的密钥来解密所接收的密钥对象消息,然后,对该密钥对象消息签名,并采用与用户会话控制器909之间共享的密钥对该签名的密钥对象消息进行加密。接着,用户位置归属器903采用TCP/IP协议把签名且加密的密钥对象消息发送到用户会话控制器909。然后,向运行支持系统901发送一个成功应答消息。
用户位置归属器903在获得权利对象后,向密钥代理管理模块发送内容密钥申请以便从密钥服务器获得新的权利对象做为内容提供系统对帐和分成凭据。用户位置归属器903在获得返回的密钥对象后更新权利对象的状态信息,并抛弃密钥对象。用户位置归属器903将更新后的权利对象同步至用户会话控制器909,并向OSS 901的用户管理模块发送购买成功信息。
用户在电子节目指南服务器上浏览购买的VoD节目的权利对象,并通过点击权利对象连接申请来播放权利对象对应的媒体内容的内容密钥。
图10示出了图1中的最终用户播放设备使用权利对象的示意图。电子节目指南服务器1003将用户请求转换为密钥请求,并将该请求发往用户会话控制器1005。用户会话控制器1005根据请求中的Right_ID搜索对应的权利对象,并将权利对象和用户公钥发往密钥代理管理模块1007以获得内容密钥。密钥代理管理模块1007将上述消息转发至合适的密钥代理模块1009。密钥代理模块1009将验证权利对象的有效性,并为有效权利对象生成密钥对象。如果密钥代理模块1009缓存有所需的内容密钥,则用用户公钥加密内容密钥,并返回密钥对象消息。如果密钥代理模块1009没有缓存所需的内容密钥,密钥代理模块1009将密钥请求信息发往密钥服务器1011,并从密钥服务器1011获得相应的密钥对象消息。密钥对象沿着密钥代理管理模块1007、用户会话控制器1005和电子节目指南服务器1003的通道返回最终用户的播放设备1001,在上述传输通道中,消息均以加密形式传递。
密钥代理模块1009记录所有收到的Status为0x00的权利对象,并定期将记录的结果发往密钥服务器1011。
对于LiveTV,最终用户的播放设备1001在接到用户的切换频道请求后,同样将发出内容密钥请求。与VoD节目的不同在于,LiveTV的密钥请求用Channel_ID代替VoD节目请求中的CRID。其余流程与VoD节目一致。
当最终用户的播放设备1001完成一次播放时,媒体服务器(MediaServer)将向用户会话控制器发出权利对象更新请求,请求中包含User_ID和Content_ID。用户会话控制器向用户位置归属器转发权利对象更新请求和用户位置归属器签名的权利对象。用户位置归属器将在更新权利对象后将其同步至用户会话控制器。
最终用户设备1001直接向用户会话控制器1005发送权利对象请求消息,该请求消息中包含加密的U_id、CRID、Right_ID以及Pub_Key。在一种优选方式下,最终用户设备1001以HTTP协议向电子节目指南服务器1003发送权利对象请求,该请求中包含加密的U_id、CRID、Right_ID以及Pub_Key。电子节目指南服务器1003根据该请求中的这些参数创建一个XML格式的消息,然后,对该XML格式的消息进行加密。接着,采用TCP/IP协议把经过加密的XML格式的消息发送到用户会话控制器1005。用户会话控制器1005将所接收的XML格式的消息转发到用户代理管理模块1007。密钥代理管理模块1007采用TCP/IP协议把用户会话控制器1005由权利对象服务器签名的权利对象消息和用户公钥发送到密钥代理模块1009。密钥代理模块1009把所接收的、由权利对象服务器所签名的权利对象消息发送到密钥服务器1011。密钥服务器1011在接收到权利对象消息之后,生成密钥对象,然后对该密钥对象消息加密,接着采用TCP/IP协议把加密的密钥对象消息发送到密钥代理模块1009。密钥代理模块1009使用与密钥服务器1011之间共享的密钥解密所接收的密钥对象消息,然后对加密的密钥对象消息签名。接着,密钥代理模块1009把签名的密钥对象消息发送到密钥代理管理模块1007。密钥代理管理模块1007采用TCP/IP协议把密钥代理模块签名的密钥对象消息转发到用户会话控制器1005。用户会话控制1005接着采用TCP/IP协议把加密的密钥对象消息转发到电子节目指南服务器1003。接着,电子节目指南服务器1003用与用户会话控制器1005之间共享的密钥解密所接收的密钥对象消息,然后用与最终用户设备1001之间共享的密钥对该密钥对象消息加密,接着采用HTTP协议把加密的密钥对象消息发送到最终用户播放设备1001。
图11示出了最终用户播放设备的数据权利要求管理模块的框图。其中,认证模块(Authentication Module)1011用于播放设备的认证,浏览器(Browser)1105实现播放设备与电子节目指南服务器之间的交互,会话控制器(Session Controller)1103用于为播放设备与电子节目指南服务器之间的信息交互提供加密支持。浏览器1105接收用户的请求,并依靠控制器1107调用数字版权管理模块的核心模块-密钥管理模块1113。密钥管理模块1113调用RSA模块1111随机生成一对公钥和私钥,并将用户公钥交给控制器1107。除了控制公钥/私钥的生成外,密钥管理模块1113还负责内容密钥在本地的存储和管理。当浏览器1105返回来自用户会话控制器1103的内容密钥后,密钥管理模块1113将用户公钥和加密的内容密钥一同交给RSA模块1111,由RSA模块1111完成解密,并将解密后的内容密钥返回密钥管理模块1113。RSA模块1111需要维护最近产生的公钥和私钥对,并根据密钥管理模块的输入决定采用哪个私钥进行解密操作。密钥管理模块1113以图4或图5的格式维护内容密钥的列表。媒体流接收器1117,用于接收加密的媒体流,并将收到的数据送往解密器1115。解密器1115使用密钥管理模块1113送来的密钥解密节目流,并将解密后的数据送往播放器1109。密钥对象和解密后的密钥仅存在于最终用户播放设备的内存中,因此当用户关机时,密钥对象和解密后的密钥将在最终用户播放设备上消失。当节目播放完毕或用户中止节目播放,密钥管理模块1113将放弃密钥对象和解密后的密钥。会话控制器1103管理最终用户播放设备和服务器之间的通信,而控制器1107管理密钥申请、使用和放弃的整个流程。
图12A和12B示出了图1中的电子节目指南服务器申请权利对象和密钥对象的过程的流程图。
在图12A中,电子节目指南服务器128以步骤S1201开始,在步骤S 1201中,该服务器128从最终用户播放设备14接收HTTP GET消息。然后,该过程进入到步骤S1203,在步骤S1203中,该电子节目指南服务器128HTTP分组的首部中提取用户请求,并用与最终用户播放设备14之间共享的密钥来对该用户请求解密。接着,进入到步骤S1205,在该步骤中,电子节目指南服务器128根据用户的请求生成权利对象请求消息,并用于与用户会话控制器127之间共享的密钥加密该消息。然后,进入到步骤S1207,在步骤S1207中,电子节目指南服务器128把加密的请求消息发送到用户会话控制器127。然后,进入到步骤S1209,在该步骤,电子节目指南服务器128从用户会话控制器127中接收应答消息和密钥对象。接着,进入到步骤S 1211,在该步骤中,电子节目指南服务器128使用HTTP POST消息把用与最终用户设备14之间共享的加密密钥所加密的消息发送到最终用户播放设备14。然后,该过程结束。
在图12B中,电子节目指南服务器128以步骤S1231开始,在步骤S1231中,该服务器128从最终用户播放设备14接收HTTP GET消息。然后,该过程进入到步骤S1233,在步骤S1233中,该电子节目指南服务器128从HTTP分组的首部中提取用户请求,并用与最终用户播放设备14之间共享的密钥来对该用户请求解密。接着,进入到步骤S1235,在该步骤中,电子节目指南服务器128根据用户的请求生成密钥对象请求消息,并用于与用户会话控制器127之间共享的密钥加密该消息。然后,进入到步骤S1237,在步骤S1237中,电子节目指南128把加密的密钥对象请求消息发送到用户会话控制器127。然后,进入到步骤S1239,在该步骤,电子节目指南服务器128从用户会话控制器127中接收加密的密钥对象消息。接着,进入到步骤S1241,在该步骤中,电子节目指南服务器128使用HTTP POST消息把用与最终用户设备之间共享的加密密钥所加密的消息发送到最终用户播放设备14。然后,该过程结束。
图13示出了图1中的密钥代理模块管理密钥申请的流程图。
在图13中,密钥代理模块121以步骤S1301开始,在该步骤中,密钥代理模块121从密钥代理管理模块121接收加密且签名的用户公钥和权利对象。然后,进入到步骤S1303,在该步骤中,密钥代理模块111判断所接收的权利对象是一个新的权利对象吗?如果是,则进入到步骤S1309;否则就进入到步骤S1305中。在步骤S1309中,密钥代理模块111把加密的权利对象发送到密钥服务器113。接着,进入到步骤S1313,在该步骤中,密钥代理模块111判断从密钥服务器113所返回的密钥是一个新的密钥吗?如果是新的密钥,则进入到步骤S1315,否则就进入到步骤S1307。在步骤S1315中,密钥代理模块111对该密钥进行加密并缓存该密钥。在步骤S1305,密钥代理模块111判断是否已经缓存了所请求的密钥,如果是则进入到步骤S1307,否则就进入到步骤S1317。在步骤S1317中,密钥代理模块111向密钥服务器113发送密钥请求。接着,进入到步骤S1319,在该步骤,密钥代理模块111从密钥服务器113接收加密的密钥对象并缓存该密钥,然后进入到步骤S1307。在步骤S1307中,把加密的密钥对象发送到密钥代理管理模块121。然后,该过程结束。
图14A和14B示出了图1中的用户会话控制器申请权利对象和密钥对象的的过程的流程图。
在图14A中,首先以步骤S14001开始,在该步骤,用户会话控制器127从电子节目指南服务器128接收加密的权利对象请求消息,并对其解密。然后,该过程进入到步骤S14003,在该步骤中,用户会话控制器127判断经过解密的权利对象请求有效吗?如果该权利对象请求有效,则该步骤进入到步骤S14007,否则进入到步骤S14005。在步骤S14005,用户会话控制器127把加密后的请求无效消息发送到EPG。在步骤S14007,用户会话控制器127把该加密且有效的消息转发到权利对象服务器125。然后,该过程进入到步骤S14009,在该步骤中,权利对象服务器125从用户会话控制127接收签名的权利对象(密钥对象)。然后,该过程进入到步骤S14011,用户会话控制器127把加密的成功消息(和密钥对象)发送到电子节目指南服务器128,然后该过程就结束。
在如14B中,以首先以步骤S14031开始,在该步骤,用户会话控制器127从电子节目指南服务器128接收加密的密钥对象消息请求。然后,该过程进入到步骤S14033,在该步骤中,用户会话控制器127判断经过解密的密钥请求有效吗?如果该密钥请求有效,则该步骤进入到步骤S14037,否则进入到步骤S14035。然后,该过程就结束。在步骤S14035,用户会话控制器127把加密且无效的消息发送到电子节目指南服务器128。在步骤S14037,用户会话控制器127把权利对象和用户公钥发送到密钥代理管理模块121。然后,该过程进入到步骤S14039,在该步骤中,用户会话控制器127从密钥代理管理模块接收加密的密钥对象。接着,进入到步骤S14041,在该步骤,用户会话控制器127把加密的密钥对象发送到电子节目指南服务器128。然后,该过程就结束。
在图14C中,首先以步骤S14051开始,在该步骤中,用户会话控制器127从媒体服务器126中接收加密的权利更新消息并对其进行解密。接着,该过程进入到步骤S14053,在该步骤,用户会话控制器127把签名的权利对象和更新请求发送到权利对象服务器125。然后,该过程进入道步骤S14055,在该步骤中,用户会话控制器127从权利对象服务器125中接收加密且签名的权利对象。然后,该过程进入到步骤S14057,在过程中,用户会话控制器127把更新成功消息发送到媒体服务器126。然后,该过程就结束。
图15A和15B示出了图1中的密钥代理管理模块工作的过程的流程图。
在图15A中,该过程以步骤S15001开始,在该步骤,密钥代理管理模块121从权利对象服务器125接收用户公钥和加密且签名的权利对象。然后,进入到步骤S15003,在该步骤中,密钥代理管理模块121选择一个密钥代理模块并把用户公钥传送给所选定的密钥代理模块。接着,该过程进入到步骤S15005,在该步骤中,密钥代理管理模块121从密钥代理模块111接收加密的密钥对象。接着,该过程进入到步骤S15007,在该步骤中,密钥管理代理模块121把加密的密钥对象发送到用户位置归属器123。然后,该过程结束。
在图15B中,该过程以步骤S15031开始。在该步骤,密钥代理管理模块121从用户会话控制器127接收用户公钥和加密且签名的权利对象。然后,进入到步骤S15033,在该步骤中,密钥代理管理模块121选择一个密钥代理模块并把该权利对象和用户公钥发送到选定的密钥代理模块。接着,该过程进入到步骤S15035,在该步骤中,密钥代理管理模块121从密钥代理模块111接收加密的密钥对象。接着,该过程进入到步骤S15037,在该步骤中,密钥管理代理模块121把加密的密钥对象发送到用户会话控制器127。然后,该过程结束。
图16A和16B分别示出了图1中的用户位置归属器申请和更新权利对象的过程的流程图。
在图16A中,用户位置归属器123以步骤S1601开始,在该步骤中,用户位置归属器123从用户会话控制器127或者从运行执行系统122中接收加密的权利请求消息。然后,该过程进入到步骤S1603,在步骤S1603中,用户位置归属器123把加密的消息转发到权利对象服务器125中。然后,该过程进入到步骤S1605,在步骤S1605中,用户位置归属器123把从权利对象服务器125接收加密的权利对象,然后,进入到步骤S1607,在步骤S1607中,用户位置归属器123把加密的计费消息发送到计费系统124中,然后进入到步骤S1609中,在步骤S1609中,用户位置归属器123从计费系统124接收加密的计费成功消息。然后,进入到步骤S1611,在步骤S1611中,位置归属器123把加密并签名的权利对象和用户公钥发送到密钥管理代理模块121。然后,进入到步骤S1613中,用户位置归属器123在该步骤中从密钥代理管理模块121中接收加密的密钥对象,接着,进入到步骤S1615。用户位置归属器123在步骤S1615中更新权利对象。然后,进入到步骤S1617中,用户位置归属器123把加密和签名的权利对象(以及密钥对象)发送到用户会话控制器127中。接着,进入到步骤S1619中,用户位置归属器123判断有来自用户会话控制器127的权利请求吗?如果有,则把加密的成功消息发送到运行支持系统122,然后结束该过程,否则就结束该过程。
在图16B中,用户位置归属器123以步骤S1631开始,在步骤S1631中,用户位置归属器123从用户会话控制器127中接收加密的权利更新消息和签名的权利对象。接着,进入到步骤S1633,在步骤S1633,用户位置归属器123更新该权利对象。然后,进入到步骤S1635中,用户位置归属器123把加密且签名的权利对象发送到用户会话控制器127中。
图17示出了图1中的密钥服务器对权利对象和密钥的管理的过程的流程图。
该过程在步骤S1701开始,在该步骤中,密钥服务器113首先从密钥代理模块111接收内容密钥请求。然后,该过程进入到步骤S1703,在该步骤,密钥服务器113判断所接收的权利对象有效吗?如果该权利对象有效,则该过程进入到步骤S1709,在该步骤,密钥服务器113存储该权利对象;否则进入到步骤S1705,在步骤S1705中,密钥服务器113判断密钥是否被请求了,如果密钥被请求了,则进入到步骤S1711,在步骤S1711中,密钥服务器113则把加密的密钥对象发送到密钥代理模块111,然后进入到步骤S1707;否则进入到步骤S1707。在步骤S1707中,密钥服务器113把请求失败消息发送到密钥代理模块111。然后该过程结束。
图18示出了在在图1中的最终用户播放设备解密内容密钥的流程图。
首先,该过程进入到步骤S1801,在该步骤,由图11所示的最终用户播放设备14的解密器1115输入媒体内容的第一个128位作为Block1。然后,该过程进入到步骤S1803,在该步骤,解密器1115输入媒体内容的第二个128位作为Block2。然后,该过程进入到步骤S1805,在该步骤,求取Block1的偏移量(Offset),Offset1=Block1的相对偏移量。然后,该过程进入到步骤S1807,在该步骤中,Offset2=用解密密钥对在步骤S1807所求出的偏移量Offset1进行解密之后的结果。接着,该过程进入到步骤S1809,输出Block1解密之后的结果,Block1=Block1 XOR Offset2。接着,该过程进入到步骤S1811,在该步骤输出计算Block2,Block2=Block2 XOR Block1。然后,该过程进入到步骤S1815,在该步骤判断是否到达了媒体内容的末尾,如果到达了媒体内容的末尾,则该过程就结束。否则,该过程就返回到步骤S1801,在该步骤继续对尚未解密的媒体内容继续解密,步骤S1801-S1815反复循环进行,直到不再有媒体内容要被解密了为止。
虽然已经在以上结合所述典型实施例描述了本发明,但很清楚,许多替换、修改、和变化对于本领域的普通技术人员来说都是显而易见的。因此,以上提出的本发明的典型实施例旨在进行说明,而不是为了限制。在不偏离由下面的权利要求书限定的本发明的构思和范围的条件下,可以进行各种变化。

Claims (13)

1.一种数字版权管理系统,包括:
内容供应系统,用于存储和加密媒体内容;
播放设备,用于播放媒体内容;
授权管理子系统,用于为特定用户生成针对特定媒体内容的权利对象,并管理权利对象;以及
密钥管理子系统,用于管理内容密钥,并根据授权管理子系统发出的请求生成相应的内容密钥;
其中,所述授权管理子系统所产生的权利对象连同用户公钥被转发给所述密钥管理子系统中的密钥代理模块,所述内容密钥被提供给所述播放设备而所述权利对象不被提供给所述播放设备;用户通过选择所述权利对象的连接申请来播放该权利对象对应的媒体内容;所述密钥管理子系统所生成的内容密钥在所述播放设备把媒体内容播放完毕、中止或者用户关机时被放弃。
2.如权利要求1所述的数字版权管理系统,其中,所述密钥管理子系统还包括:密钥代理模块,所述授权管理子系统通过所述密钥代理模块与所述密钥管理子系统交互。
3.如权利要求1或2所述的数字版权管理系统,所述授权管理子系统通过密钥代理管理模块向所述密钥管理子系统请求内容密钥。
4.如权利要求3所述的数字版权管理系统,所述授权管理子系统响应所述播放设备的用户请求而为所述用户生成权利对象。
5.如权利要求1所述的数字版权管理系统,其中所述播放设备的用户通过电子节目服务器与所述授权管理子系统交互。
6.如权利要求1所述的数字版权管理系统,所述内容密钥仅存在于播放设备的私有存储空间中。
7.如权利要求1所述的数字版权管理系统,所述内容密钥通过用户公钥加密之后发送到所述授权管理子系统。
8.如权利要求1所述的数字版权管理系统,包括多个所述内容供应系统,每一个所述内容供应系统由不同的内容供应商提供。
9.如权利要求1所述的数字版权管理系统,所述密钥管理子系统由内容供应商所控制。
10.如权利要求1所述的数字版权管理系统,所述密钥管理子系统由网络互动电视运行商所控制。
11.如权利要求1或2所述的数字版权管理系统,所述授权管理子系统还包括用户会话控制器,用于与播放设备交互。
12.如权利要求11所述的数字版权管理系统,播放设备通过电子节目指南服务器与用户会话控制器交互。
13.如权利要求1或2所述的数字版权管理系统,所述授权管理子系统还包括用户位置归属器,根据所述权利对象服务器所生成的权利对象从所述密钥管理子系统获得节目的内容密钥。
CN200510074057A 2005-05-30 2005-05-30 数字版权管理的系统和网络电视运营系统 Expired - Fee Related CN100592785C (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN200510074057A CN100592785C (zh) 2005-05-30 2005-05-30 数字版权管理的系统和网络电视运营系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN200510074057A CN100592785C (zh) 2005-05-30 2005-05-30 数字版权管理的系统和网络电视运营系统

Publications (2)

Publication Number Publication Date
CN1874485A CN1874485A (zh) 2006-12-06
CN100592785C true CN100592785C (zh) 2010-02-24

Family

ID=37484707

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200510074057A Expired - Fee Related CN100592785C (zh) 2005-05-30 2005-05-30 数字版权管理的系统和网络电视运营系统

Country Status (1)

Country Link
CN (1) CN100592785C (zh)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101202883B (zh) * 2006-12-15 2010-09-29 中兴通讯股份有限公司 一种iptv系统的数字版权管理系统
CN101207794B (zh) * 2006-12-19 2010-06-16 中兴通讯股份有限公司 Iptv系统的数字版权管理加密和解密方法
CN101291420A (zh) * 2007-04-20 2008-10-22 华为技术有限公司 基于ims的iptv系统及内容保护服务功能实体和方法
CN101102476B (zh) * 2007-08-08 2010-12-08 Ut斯达康通讯有限公司 一种标识媒体资产对象的方法
CN101365098B (zh) * 2007-08-08 2010-11-17 北京视博数字电视科技有限公司 数字节目权利管理方法及其数字权利管理系统
CN101442669B (zh) * 2007-11-22 2010-07-14 上海文广互动电视有限公司 数字版权管理系统中的后台系统
CN101442655B (zh) * 2007-11-22 2010-08-11 上海文广互动电视有限公司 数字节目广播系统中的数字版权管理系统
CN101350917B (zh) * 2007-12-14 2010-09-15 北京中企开源信息技术有限公司 数字视频版权管理方法及系统
US9009854B2 (en) * 2012-12-19 2015-04-14 Intel Corporation Platform-hardened digital rights management key provisioning
CN103530532A (zh) * 2013-09-17 2014-01-22 亚欧宝龙信息安全技术(湖南)有限公司 一种文件加密方法和系统
CN104751067B (zh) * 2013-12-27 2019-03-12 北京慧眼智行科技有限公司 一种图片文件安全存储的方法和装置
CN104410828B (zh) * 2014-11-26 2019-04-12 北京视博数字电视科技有限公司 家庭监控方法和设备
CN107426589B (zh) * 2017-03-31 2018-08-10 武汉斗鱼网络科技有限公司 一种视频请求、视频播放方法及装置
CN109981271B (zh) * 2019-04-11 2022-03-11 乾讯信息技术(无锡)有限公司 一种网络多媒体安全防护加密方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
无线流媒体DRM解决方案. 叶云,孙瑞囡,隆岗.现代电信科技,第2005年1月第1期. 2005 *
网络版权管理战略:版权与技术的结合--网络环境下数字版权管理(DRM)的应用. 刘可静,杨小溪.中国知识产权发展战略论坛论文集. 2005 *

Also Published As

Publication number Publication date
CN1874485A (zh) 2006-12-06

Similar Documents

Publication Publication Date Title
US10848806B2 (en) Technique for securely communicating programming content
US8413256B2 (en) Content protection and digital rights management (DRM)
CN100459697C (zh) 一种iptv系统、加密数字节目的发布、收看方法
US7801819B2 (en) Rendering rights delegation system and method
KR101354768B1 (ko) 소셜 tv 서비스를 이용하여 식별되는 컨텐트에 대한 디지털 권리 관리 보호
CN109711117B (zh) 用于分发数字内容的装置和方法
CN101453624B (zh) 一种视频点播系统
CN100592785C (zh) 数字版权管理的系统和网络电视运营系统
CN103873895B (zh) 一种dvb/iptv双模互动业务保护系统
CN101442655B (zh) 数字节目广播系统中的数字版权管理系统
EP2232748A1 (en) Content protection of internet protocol (ip)-based television and video content delivered over an ip multimedia subsystem (ims)-based network
US12095910B2 (en) System for thin client devices in hybrid edge cloud systems
CN108476337B (zh) 从数字内容识别外围设备的方法和设备
CN101207794B (zh) Iptv系统的数字版权管理加密和解密方法
CN101202883B (zh) 一种iptv系统的数字版权管理系统
US12010394B2 (en) Secure content distribution and trusted recording of content consumption
US20250190606A1 (en) Method and system for managing content data access
WO2023039694A1 (zh) 定制信息安全等级之流媒体服务方法及系统
TW202312741A (zh) 客製化資安等級之串流服務方法及系統
CN115811625A (zh) 定制信息安全等级之流媒体服务方法及系统
Pei et al. An intelligent digital content protection framework between home network receiver Devices
HK40006493B (zh) 用於分发数字内容的装置和方法
HK40006493A (zh) 用於分发数字内容的装置和方法

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
ASS Succession or assignment of patent right

Owner name: UT SIDAKANG (CHINA) CO. LTD.

Free format text: FORMER OWNER: UT STARCOM COMMUNICATION CO., LTD.

Effective date: 20130320

C41 Transfer of patent application or patent right or utility model
COR Change of bibliographic data

Free format text: CORRECT: ADDRESS; FROM: 310053 HANGZHOU, ZHEJIANG PROVINCE TO: 100027 DONGCHENG, BEIJING

TR01 Transfer of patent right

Effective date of registration: 20130320

Address after: Beihai Manhattan building 6 No. 100027 Beijing Dongcheng District, Chaoyangmen North Street 11

Patentee after: UTSTARCOM (CHINA) CO.,LTD.

Address before: 310053 No. six, No. 368, Binjiang District Road, Zhejiang, Hangzhou

Patentee before: UTSTARCOM TELECOM Co.,Ltd.

TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20190102

Address after: 518000 Lenovo Building, No. 016, Gaoxin Nantong, Yuehai Street, Nanshan District, Shenzhen City, Guangdong Province, on the east side of the third floor

Patentee after: UD NETWORK CO.,LTD.

Address before: 100027 11 Floor of Beihai Wantai Building, 6 Chaoyangmen North Street, Dongcheng District, Beijing

Patentee before: UTSTARCOM (CHINA) CO.,LTD.

CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20100224

CF01 Termination of patent right due to non-payment of annual fee