具体实施方式
图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反复循环进行,直到不再有媒体内容要被解密了为止。
虽然已经在以上结合所述典型实施例描述了本发明,但很清楚,许多替换、修改、和变化对于本领域的普通技术人员来说都是显而易见的。因此,以上提出的本发明的典型实施例旨在进行说明,而不是为了限制。在不偏离由下面的权利要求书限定的本发明的构思和范围的条件下,可以进行各种变化。