下列美国专利申请揭示了关系到当前申请主题材料的一些主题材料,以及其每一项申请都通过引用被结合于此:美国专利申请号为10/185511、2002年6月28日提交的、题为“Systems and Methods For Issuing Usage Licenses For DigitalContent And Services”;美国专利申请号为10/185278、2002年6月28日提交的、题为“Using a Rights Template to Obtain a Signed Rights Label(SRL)forDigital Content in a Digital Rights Management System”;美国专利申请号为10/185527、2002年6月28日提交的、题为“Obtaining a Signed Rights Label(SRL)for Digital Content and Obtaining a Digital License Corresponding to theContent Based on the SRL in a Digital Rights Management System”。
本发明的详细说明
计算设备的案例
图1和下面的讨论,打算提供一个对合适的计算环境简短和基本的描述,在这里本发明可以被实现。然而,将进一步清楚地描述打算用于联结到本发明的各类手持式、便携式以及其它的计算设备的情况。虽然下面对通用计算机描述,但只是作为一个例子,本发明仅需要一台具有网络服务器互操作性和互动的瘦客户机。如此,本发明可以用联网的受控服务环境来实现,在这里一个十分小的客户机资源被涉及,比如,一个网络环境,在这里客户机设备仅用作为浏览器或连接在互联网上的接口。
虽然并不要求,本发明能经过应用程序接口(API)来实现,指令用于开发器,以及/或者包括在网络浏览软件内,它通常将被描述在计算机可执行的上下文中,比如程序模块它可以由一个或者多个计算机来执行,比如客户机工作站、服务器或者其它设备。通常而言,程序模块包括例行程序、程序、对象、组件、数据结构以及执行特定任务的连结或者实现特定抽象数据类型的连结。
典型的程序模块功能可以被联结或者分散,像采用各种具体化方案所期望的那样。而且,在这一领域中的这些技术人员将理解,本发明可能可由其它的计算机系统配置来实现。其它熟知的计算机系统、环境、以及/或者合适的结构可用于本发明中,但这不限于,个人计算机(PC)、自动呼叫机、服务器计算机群、手提式或膝上型电脑、多处理器系统、基于微处理器的系统,可编程电子消费机、网络PC、小型计算机、大型计算机,等等。本发明也可以由分布式计算环境来实现,在这里,任务由遥控处理设备所执行,它经过通信网络或者其它数据传输媒体来连接。在分布式计算环境中,程序模块可以由包括存储器存储设备、本地和遥控计算机存储媒体二者来组成。
图1给示了一个合适的计算系统环境100的实例,在这里,本发明可以被实现。虽然作了清晰的描述,而本计算系统环境100只是合适的计算环境的一个实例,同时,不打算建议作出任何的限制,比如,对使用的范围和本发明的功能这些方面的限制。不能解释为图中所示的任一个与计算机环境100连结组件与作为实例的计算环境100有任何依赖性和要求。
参见图1,作为一个实现本发明的系统实例,它包括一个通用计算设备,比如计算机110这样的形式。计算机110组件可以包括(但不只限于这一些):处理单元120、系统内存130、以及系统总线121,它连结各种系统组件,包括联结到处理单元120的系统内存。系统总线121可以是任何一种类型的总线结构,它包括内存总线或者内存控制器、外部设备总线以及使用任何一种总线结构的本地总线。例如(但不只限定这一些),这些结构可以包括工业标准结构(ISA)总线、微通道结构(MCA)总线、增强型ISA(EISA)总线、视频电子标准协会(VESA)本地总线、以及外部设备组件互连(PCI)总线(也称为Mezzanine总线)。
计算机110典型地包括多种多样的计算机可读媒体。计算机可读媒体可以是任何一种可用的媒体,它可以由计算机110来访问,以及包括易失性和非易失性媒体,可移动和不可移动媒体。作为例子(但不只限于这一些),RAM、ROM、EPROM、闪存或者其他的存储技术CDROM、数字视频光盘(DVD)或者其它光盘存储器、盒式磁带、磁带、磁盘存储器,或者其它存储设备,或者任何其他的媒体,它们可以用来存储期望的信息,并能由计算机110来访问。通信媒体典型地体现为计算机可读的指令、数据结构、程序模块或者其它用模经调制的数据讯号中的数据,比如,载波波形或其它的传送机制以及包括任何信息传递的媒体。术语“调制数据信号”的含意是这样的一种信号,它有一个或多个特性被设定或改变,以此把信息编码到信号中。作为例子,(但不只限于这一些),通信媒体包括有线媒体,比如有线网络或直接连线联接,以及无线媒体,比如,声音、RF、红外线以及其它的无线媒体。上述的任何组合也包括在计算机可读媒体的范围内。
系统存储器130包括易失性和非易失性存储器的计算机存储媒体,比如只读存储器(ROM)131,以及随机存取存储器(RAM)132。基本输入/输出系统133(BIOS),包括基本的例行程序,它帮助在计算机110的单元之间进行信息的传递,比如当启动设备时,有代表性的存储在ROH131中。RAM132有代表性的包括数据和/或程序模块,它立刻由处理单元120处理和/或可存取的当前操作。作为例子,(但不只限于这一些),图1给示了操作系统134、应用程序135、其它程序模块136,以及程序数据137。
计算机110也可以包括其它可移动/不可移动、易失性/非易失性计算机存储媒体。仅仅作为一个例子,图1给示了硬盘驱动区141,它可以从非移动式、非易失性磁媒体上作读或写,磁盘驱动器151,它可以从可移动/不可移动磁盘152上作读或写,以及光盘驱动器155,它可以从可移动非易失性光盘156上进行读或写,光盘156比如是一只CDROM或者其它的光媒体。其它类型的可移动/不可移动、易失性/非易失性计算机存储媒体,它能用在案例的操作环境中,它包括有(但不只限于这一些),盒式磁带、闪存卡、数字视频光盘、数字视频磁带、固态RAM、固态ROM,等等。硬盘141具有代表性的经过不可移动存储器接口(比如接口140),被连结到系统总线121上,以及磁盘驱动器151和光盘驱动器155由可移动存储接口(比如接口150)具有代表性地连结到系统总线121上。
上面讨论的驱动器和它们的相关计算机存储媒体给示在图1中,它们提供计算机可读指令、数据结构、程序模块和从图1中的计算机110用的其它数据,举例来说,图中所示的硬盘驱动器141、存储操作系统144、应用程序145、其它程序模块146以及程序数据147。注意到这些组件可以是和操作系统134、应用程序135、其它程序模块136以及程序数据137相同或者不同的。操作系统144、应用程序145、其它程序模块146以及程序数据147在图中被给定为不同的号数,它们是不同的拷贝。用户可以经过输入设备对计算机110输入命令和信息,这些输入设备比如是键盘162以及指点设备161(通常可以用鼠标、磁道球、或者触感垫板)。其它输入设备(图中没有表示出来)可以包括麦克风话筒、控制杆、游戏板、卫星式转盘、扫描仪等。这些和其它的输入设备通常经过用户输入接口160连接到处理单元120,接口连接到系统总线121上,但是也可以用其它的接口和总线结构,比如,并行接口、游戏端口或者通用串行总线(USB)。
监示器191或者其它类型的显示设备也可以经过一个接口(比如视频接口190),连接到系统总线121上。图形接口182(比如“北桥”Northbridge)也可以连接到系统总线121上。“北桥”是一个芯片它和CPU相通信,或者主处理单元120,以及对加速图形接口(AGP)通信承担响应。一个或者更多个图形处理单元(GPUs)184可以和图形接口182通信。注意到GPUs184通常包括存储在芯片上的存储器中,比如寄存器存储,以及GPUs184与视频存储器186进行通信。然而,GPUs184只是协处理器的一个实例,这样,多样化的协处理器设备可以被包括在计算机110之中。监示器191或者其它类型的显示设备经过接口(比如视频接口190)也连接到系统总线121上,它依次可以与视频存储器186进行通信。除了监示器191之外,计算机也可以包括其它的外部输出设备,比如,扬声器197以及打印机196,它们可以经过输出外部设备接口195进行连接。
计算机110可以在采用逻辑连接一台或多台远程计算机的网络环境下进行操作,比如远程计算机180。远程计算机180可以是个人计算机、服务器、路由器、网络PC机、对等设备或者其它的通信网络节点,以及典型地包括上述与计算机110有关的很多或全部单元,虽然在图1中只给示了一只存储器存储设备181。在图1中所描绘的逻辑连结包括局域网(LAN)171以及广域网(WAN)173,但也可以包括其它的网络。这样的组网环境在办公室内、企业级计算机网络、以及企业内部互联网和国际互联网中是常见的。
当用在LAN组网环境下,计算机110经过网络接口或者适配器170连接到LAN171去。当用在WAN组网环境下,计算机110典型地包括调制器172或者其它通过广域网WAN比如国际互联网173建立通信的其它装置。调制器172可以是内置式的或外置式的,经过用户输入接口160或者其它适宜的设备,可以被联结到系统总线121上。在网络工作环境下,描绘与计算机110或它的一部分的相互关系的程序模块可存储在远程存储器存储设备上。作为实例,(但不只限于这一些),图1所给示的远程应用程序185驻留在存储器设备181上。应理解所示的网络连结是一种示例,以及在计算机之间建立通信链路的其它装置也可能被采用。
在这一领域中的一个普通的技术人员能理解,计算机110或者其它客户机设备能被部署为计算机网络的一个部分。注意到,本发明适合于有任何数量存储器或者存储单元的任何计算机系统,以及任何数量的应用和过程发生跨越任何数量的存储单元或存储体上。本发明可以应用于部署在网络环境下带有服务器计算机和客户机计算机的环境下,它具有远程和本地的存储器。本发明还可以应用于独立的计算设备,它具有程序语言功能、解释和执行能力。
分布计算装置通过计算设备和系统之间直接交换来共享计算机资源和服务。这些资源和服务包括信息的交换、高速缓存存储,以及对文件的盘存储。分布式计算利用了网络连通性的优势,允许客户发挥它们集体的功效,以达到使整个企业受益的目的。注意到多样化的设备可以有应用、对象或者资源,它可以交互地实行本发明的鉴别技术,用于受托的图形管道。
图2提供了一张网络工作或者分布式计算机环境实例的逻辑框图。分布式计算环境由计算对象10a,10b等,以及计算对象或设备110a,110b,110c等组成。这些对象可以包括程序、方法、数据存储、可编程序的逻辑等等。对象可以由一部分相同或不同的设备所构成,比如PDAs、电视机、MP3放送机、个人计算机等等。每个对象能由通信网络14与其它对象进行通信。这一网络可以自己包括其它对象以及计算设备,它们对图2系统提供服务。按照本发明的一个方面,每个对象10或者对象110可以包括一个应用程序,它可以请求本发明的鉴别技术用于受托图形管道。
它也应理解一个对象,比如象110c,它可以驻宿于计算设备10或110中。这样,虽然被描绘的物理环境可以给示像计算机那样的被连结设备,这种描述仅仅是一个实例,并且物理环境可以被另外描绘或说明为包括不同的数字设备,比如PDA、电视机、MP3放送器等等,软件对象比如接口、COM对象等。
有多种多样的系统、组件以及网络结构,它支持分布式计算机环境。举例来说,计算系统可以由有线或无线系统和本地网络或广域分布式网络来联结在一起。当今流行的,很多网络耦合到Internet国际互联网上,它提供用于广域布式计算和包容很多不同的网络的基础结构。
在家庭网络环境下,至少有四种不同的网络传播媒体,它们可以支持单一的协议,媒体比如:电源线、数据(无线和有线二者)、声音(例如,电话),以及娱乐媒体。很多家庭控制设备,比如照明和电器可以用电源线用来连接。数据服务可以用宽带方式进入家庭(比如,DSL或者有线电缆调制解调器),同时它也可以用无线通信(比如家庭HomeRF或者802.11b)或者用有线通信(比如,Home PNA,Cat5,甚至电源线)连结进行访问。声音话务可以采用有线(比如,Cat3)或者无线(比如蜂窝电话网)进入家庭,同时可以用Cat3连线在家庭内分布。娱乐媒体可以通过卫星或者有线电缆进入家庭,同时具有代表性的可采用同轴电缆在家庭内分布。IEEE1394和DVI也显露出了是用一种于群集媒体设备的数字内部连接方案。所有这些网络环境和其它的网络环境可以显露出协议标准可以被内部连结为一个内部互联网(intranet)的式样,它可以由Internet国际互联网连结到外部世界。在很短时间内,有很多种不同的源存在,它用于存储传送数据,从而向前移动,在数据处理管道的所有部分中,计算设备将要求一种保护内容的方法。
国际互联网通常指的是网络和网关的聚集,它应用TCP/IP协议,这是计算机网络领域中一个著名的协议。TCP/IP是“传输控制协议/接口程序”的缩写词。国际互联网能被描述为是一个地理上分布的远程计算机网络系统,它由执行网络协议的计算机群互联,它允许用户在网络上交互动作和共享信息。因为这样广阔一分布信息的共享,像国际互联网这样的远程网络通常如此快的进化为一个开放系统,为此开发者可以设计软件应程序用于执行专门的通常不受限制的操作或服务。
这样,网络的基本结构使得能实现网络主机拓扑,比如客户/服务器、对等结构、或者混合结构。“客户”是很多的类或者组群,它用其它的类或组群服务,这些组群是互不相关的。这样,在计算中,客户是一个进程,也就是说,粗糙的说是一组指令或者任务,它由其它程序请求提供服务。客户进程应利用请求服务不用“知道”任何其它程序或者服务本身工作的详细情况。在客户/服务器结构中,特别在网络系统中,客户通常是这样的计算机,它访问由其它的计算机(比如服务器)提供的共享网络资源。图2作为例子,计算机110a,110b等等能想像为客户,而计算机10a、10b等等能想像为服务器,在这里服务器10a,10b等等能维护数据,并复制在客户计算机110a,110b等等上。
服务器具有典型的远程计算机系统,它可以在网络(比如国际互联网)上存取数据。客户进程可以在第一计算机系统中活动,而服务器进程可以在第二计算机系统中活动,二者在通信媒体上相互通信,这样提供了分布式功能,同时允许许多客户利用服务器的信息一集合能力。
客户和服务器之间的相互通信由网络协议层来提供功能。举例来说,传输协议(HTTP)是一个通信协议,它用来联接互联网(WWW)。典型地,计算机网络地址,比如通用资源定位器(URL)或者国际互联网协议(IP)地址是用来相互之间识别服务器或者客户计算机的。网络地址能被认为是通用资源定位器地址。举例来说,通信能够在通信媒体上被提供。特别是客户和服务器能够通过TCP/IP连接被互相静合用于高容量通信。
这样,图2给示了网络环境或者分布式环境的一个实例,它经过网络/总线在服务器和客户之间进行通信,在这里本发明可以被使用。更详细的,几台服务器10a、10b等等经过通信网络/总线14被互相连结起来,连结它们的可能是LAN、WAN、企业内部网、国际互联网等等,带有几台客户机或者远程计算设备110a、110b、110c、110d、110e等等,比如它们是可携式计算机、手提式计算机、瘦客户机、网络装置、或者其它设备,比如它们是VCR、TV、烘箱、电灯、取暖器以及按照本发明的类似设备。本发明如予期的可以应用于任何连接的计算设备,可期望用它从受托源处理、存储或者重现安全的内容。
在网络环境下,通信网络/总线14是国际互联网,举例来说,服务器10可以是Web服务器,它带有客户机110a、110b、110c、110d、110e等等,经过任何的已知协议,比如http进行通信。服务器10也可以象客户机110那样服务,象可能具有分布式计算环境下的特性。通信可以采用适宜的有线制或无线制。客户设备110可以或者可以不经过通信网络/总线14进行通信,同时可以有与之关联的独立通信。举例来说,在TV或者VCR的情况下,对于它们的控制它们可以不具有联网络的特性。每个客户计算机110以及服务器计算机10可以被装备有各种应用程序模块或者对象135,同时具有连接或者接入各种类型的存储单元或者对象,文件可以交叉存储或者部分文件可以被下载或者迁移。如此,本发明能够被用在计算机网络环境下,它有客户计算机110a,110b等等,它们可以接入和与计算机网络/总线14相互作用。以及服务器10a、10b等等,它们可以与客户计算机110a、110b等及其它设备111和数据库20进行相互作用。
数字内容的发布
图3是按照本发明用于发布数字内容更合适的具体系统和方法的功能逻辑框图。
“发布”用在这里的这一术语是指应用或服务跟随的一个过程,用受托实体建立一组权利和条件,此权利和条件是该实体能对这一内容发布的,以及对这些权利和条件能被发布的人。按照本发明,发布过程包括加密数字内容和一系列持续强迫执行的权利相关联,此权利要使内容的创始人对内容的所有可能的用户适用。这一过程可以由内容的创始人以安全的方式来完成,禁止访问任何的权利或内容,除非内容的作者试图访问。
本发明的较佳实施例中提出三种特别能用来发布安全数字内容的实体:内容准备应用程序302,它在客户300上执行,同时对内容准备作发布,数字权利管理(DRM);应用程序接口(API)306,它也驻留在客户机300上,同时DRM服务器320经过通信网络330以通信方式耦合到客户机300。本发明的较佳实施例提出的通信网络330包括国际互联网,虽然应理解,为通信网络330可以是任何的局域网或广域网,比如作为例子,专有的企业内部网。
内容准备应用程序302能产生数字内容的任何应用程序。举例来说,此应用程序302可以是字处理器或者它产生数字文档文件、数字音乐、视频或者其它内容的发布者。内容也可以包括流内容,比如,流音频/视频实况或者录制的事件,或者例子。按照本发明,内容准备应用程序访问用户,由用户提供的密钥将它加密。数字准备应用程序302用密钥加密数字内容,这样形成一个已被加密的数字内容文件304。客户申请也访问用户,提供对数字内容文件304的权利数据。权利数据包括对每个实体的标识,它对数字内容具有权利。这样的实体,举例来说,可以是个人、一类个人或者一个设备。对每个这样的实体,权利数据也包括该实体在内容中具有的一个权利列表,以及任何条件,这些条件可以被施加在任何或者全部的这些权利上。这些权利数据内容包括进行读、编辑、拷贝、打印该内容的权利等。另外,权利可以是包容性的或者排斥性的。包容性权利指示一个专门的用户,在内容上有一个指定的权利(也就是说,用户可以编辑此数字内容)。排斥性权利指示一个专门的用户,在内容上有除了这些指定的权利以外的所有的权利(也就是说,用户可以对数字内容做任何事情,除了拷贝它以外)。
按照本发明的一个实施例,客户API306能把加密数字内容以及权利数据传送到DRM服务器320上。用一个过程,它被在下面作详细的描述,DRM服务器320确定它是否能强制执行已指派的权利,假如是这样,DRM服务器320签名权利数据以形成已签名的权利标识(SRL)308。然而,一般来讲,任何受托机构能签名权利数据,更可取的是,使用由DRM服务器320信托的密钥。举例来说,客户能使用由DRM服务器320提供的密钥来对权利数据签名。
权利标签308能包括表示权利说明的数据、加密内容密钥和在权利说明上的数字签名以及加密内容密钥。假如DRM服务器正在签名权利标签,则它把已签名的权利标签308经过客户API306返回到客户端,它将已签名的权利标签308存储在客户设备300上。内容准备应用程序302之后把已签名的权利标签308与加密数字内容文件304相关联。例如,SRL 308可以与加密的数字内容文件相连以形成权利管理的内容文件310。然而,一般而言,权利数据不需要与数字内容联合。举例来说,权利数据能被存储在已知位置上,并且对存储的权利数据的引用可与加密数字内容相结合。此引用可包括标识符,它指示权利数据在哪里被存储(也就是说,包括权利数据的数据存储),对应于在指定的存储位置处的此特定权利数据的标识符(例如,包含感兴趣的特定权利数据的文件的标识符)。权利管理内容310之后能被传递到任何一个地方,并且只有具有权利消费该内容的实体能消费其内容,而且只有按照对它们赋予的权利。
图4是实例方法400的流程图,它按照本发明用于发布权利管理数据内容,在这里权利标签由DRM服务器来签名。然而应该明白,这个具体环境只是一个实例,权利标签通常只能被任何受托的实体签名。通常的,按照本发明用于发布数字内容的方法可以包括:用一只内容密钥(CK)加密此数字内容,产生与数字内容关联的权利描述,按照用于DRM服务器(PU-DRM)的公钥加密内容密钥(CK),得到(PU-DRM(CK)),以及基于与(PU-DRM)对应的私钥(PR-DRM)在验证说明和(PU-DRM(CK))的组合上创建数字签名。
在步骤402中,应用程序302产生一个内容密钥(CK),它用来加密数字内容。较佳地,内容密钥(CK)是一个对称的密钥,虽然通常来说,任何密钥都能被用于加密数字内容。对称密钥算法有时称作为“保密密钥”算法,使用相同密钥加密一个信息就像它们加密这个信息那样。由于这一原因,(CK)最好被保密。在发送器和接收器之间共享的(CK)将十分小心地工作,以避免这一(CK)被非授权截取。因为(CK)是被加密器和解密器二者所共享的,因此(CK)最好在任何加密消息被传送之前被传送。
几个对称密钥产生算法在本领域中是知名的,在一个较佳实施例中是采用数据加密标准(DES)。然而应该明白,任何对称密钥算法都可以被使用。这种对称密钥算法的实例包括(但不只限于这一些),Triple-DES(三重数字加密标准),国际数据加密算法(IDEA),Cast,Cast-128,RC4,RC5,以及SkipJack。
在步骤404中,应用程序302用对称内容密钥(CK)来加密数字内容以形成加密的数字内容304,这里可以写作记号CK(Content)。作者用应用程序302也能产生与数字内容关联的权利数据。权利数据可以包括一系列的实体,这些实体有权消费此内容,同时附带了施加在这些特定权利上的任何条件。举例来说,这一权利可以包括浏览、打印内容等。应用程序302把权利数据提供给API306。用XML/X1-ML格式的权利数据实例请见附录1。
在步骤406中,API306产生第二加密钥(DESI),它被用来加密内容密钥(CK)。更可取地,(DESI)也是一个对称密钥。在步骤408中,API306用(DES1)加密(CK),得到(DESI(CK))。在步骤410中,API306抛弃(CK),相随的结果是(CK)现在只能由解密(DES1(CK)来获得。为保证(CK)(Content)内容)被保护到中央DRM320中,同时用于内容的全部“许可请求”可按照权利数据集中地完成API306,在步骤412中,与所提供的DRM服务器320联系并检索其公钥(PU-DRM)。在步骤414中,API306用(PU-DRM)加密(DES1),得到(PU-DRM(DESI))。如此,(CK)能被保护到(PU-DRM)中,保证DRM服务器320是唯一能取得对(CK)的访问的实体,正如要求解密(CK(Content))那样。在步骤416中,API306用(DES1)加密权利数据(也就是说,一系列列表授权实体的列表以及与列表中的每个授权的实体相关的相应权利和条件),得到(DES1(rightsdata))。
在一替换的实施例,(CK)能被用来直接加密权利数据,得到(CK(rightsdata)),并因此,完全放弃使用上述的(DES1)。然而,使用(DES1)加密权利数据允许此(DES1)符合任何特定的适合于DRM服务器的算法,然而(CK)可以由独立于DRM服务器的实体所指定,且可能对DRM服务器不适合。
在步骤418中,内容保护应用程序302能把(PU-DRM(DES1))以及(DES1(rightsdata))提交给DRM服务器320,作为用于签名的权利标签。另一方面,客户它自己可以签名数据。假如权利数据将要被提交给服务器用于签名,之后,在步骤420中,DRM服务器320访问权利数据并验证它能否履行提交的权利标签中的权利和条件。为了验证它可以履行权利数据,DRM服务器320把(PR-DRM)应用到(PU-DRM(DES1))中,得到(DES1),随后将把(DES1)用到(DES1)(rightsdata))中,得到明文权利数据。服务器320之后能作出任何政策性检查来验证用户、权利证以及权利数据中指定的条件处在由服务器320履行的任何政策之内。服务器320签名原始提交的包括(PU-DRM(DES1))以及(DES1(rightsdata))的权利标签以得到已签名的权利标签(SRL)308,这里签名是基于DRM服务器320的私钥(PR-DRM),并将SRL 308返回给API306,它随后把返回的SRL308呈交给客户应用程序302。
SRL308是数字化签名的文档,它做到防窜改。另外,SRL308独立于用于加密内容的实际密钥类型和算法,并对它保护的内容维持强的1-1对应关系。现在参见图4A,在本发明的一个具体实施例中,SRL308可以包括关于内容的信息,它是SRL308的基础,也许还包括内容的ID;DRM服务器上签名SRL308的信息包括(PU-DRM(DES1))以及参考信息,比如用于在网络中对DRM服务器定位的URL以及假如URL失效而退回的信息;信息描述了SRL308它自己;尤其是(DES1(rightsdata));(DES1(CK));以及S(PR-DRM)。用XML/XrML格式的SRL样本见附录2。
通过确保受托实体签名权利数据来创建一个已签名权利标记308,DRM服务器认定它将按照权利标签308中的权利数据所描述的那样由发布者设置的项来发布对内容的许可。正如应被理解的那样,用户需要获得许可证来重现内容,特别是由于许可证包含内容密钥(CK)。当用户需要获得许可来对内容加密时,用户可向DRM服务器320或其它许可证签发实体呈交一个许可请求,它包括用于内容的SRL308,以及验证用户信任状的证书。这许可证发放实体之后能解密(PU-DRM(DES1))以及(DES1(rightsdata))产生权利数据,列出由作者(如有的话)授予给许可证请求实体的全部权利,同时构成只带有这些特定权利的许可证。
较佳地,一当应用程序302接受SRL308,此应用程序302把签名权利标签308与相应的(CK(content))304串接去形成有权利管理的数字内容。另一种方式下,权利数据能被存储在一个已知位置上,带有一个由加密数字内容所产生的位置的基地址。如此,DRM使能的重现应用程序能通过重现应用程序试图重现的一件内容来发现签名权利标签308。这一发现触发了重现应用程序向DRM许可证服务器320始发一许可证请求。例如,发布申请302能存储到DRM许可服务器320的URL中,或者DRM许可证服务器320可以将自已的URL作为一段元数据在数字化签名之前嵌入到权利标签中,这样由重现应用程序所调用的DRM客户机API306就能识别正确的DRM许可证服务器320。更合适的是,一种唯一的标识符,比如全球唯一的标识符(GUID),举例来说,在它被签名之前加到权利标签之中。
在本发明的较佳实施例中,简单对象访问协议(SOAP)能被用于在内容保护应用程序302或者重现应用程序和DRM服务器320之间进行通信。另外,可提供APR库,比如API306,使得诸如应用程序302的应用程序,不需要执行DRM客户端的协议,而只要能作出本地API调用。更可取地,采用XrML,这是一种XML语言,用来描述权利说明、许可证和用于数字内容的权利标签,然而应该明白,对于权利说明和其它数据任何合适的格式都可以被采用。
获取对发布内容的许可证
图5是按照本发明的系统和方法的一种较佳实施例的功能框图,它用于许可权利管理的数字内容。用在这里的术语“许可”指的是一个过程,应用程序或者服务遵照该过程来请求和接受一个许可证,该许可证将使许可证中提名的实体能按许可证中指定的条款消费内容。对许可过程的输入可以包括与正在请求许可证的内容有关的签名权利标签(SRL)308,以及正在要为它请求许可证的实体的公钥证书。注意请求许可证的实体不一定必需是要为之请求许可证的实体。一般而言,许可证包括来自SRL308的权利说明,能解密加密的内容加密密钥,以及在权利说明和加密密钥上的数字签名。数字签名断言提到的这些实体和权利是合法的。
对应用程序302消费权利管理的内容310的一种方法,是让此客户机API306通过通信网络330向DRM服务器320呈交权利管理的内容310的已签名权利标签308。DRM服务器320的位置,例如,可在SRL308中的推荐信息中找到。在这样的一个实施例中,DRM许可证服务器320通过下述过程,可以使用权利标签中的此权利说明来确定它是否能发布一个许可证,并且如果是这样,则得到包括了该许可证的权利说明。如上所述,权利标签308包括按照DRM服务器320的公钥(PU-DRM)加密的内容密钥(CK)(也就是说(PU-DRM(CK)))。在发布许可的过程中,DRM服务器320安全地解密这个值以获得(CK)。之后,它用许可请求中传送过去的公钥证书中的该公钥(PU-ENTITY)再去加密(CK)(也就是说,(PU-ENTITY(CK)))。此新的加密(PU-ENTITY(CK))是被服务器320置入许可证之中的东西。如此,此许可证可以被返回到调用者,而不会有暴露(CK)的风险,因为只有相关私钥(PR-ENTITY)的持有者才能从(PU-ENTITY(CK)))恢复(CK)。客户机API306然后用(CK)去解密加密的内容,形成解密的数字内容312。客户应用程序302随后能按照许可中提供的权利来使用解密的数字内容312。
另一方面,例如发布客户之类的客户,能发布它自己的许可证去消费其内容。在这样的实施例中,安全过程能被运行在客户计算机上,它为客户提供适宜环境下解密数字内容所必须的密钥。
图6A和6B提供了一种更合适的,按照本发明用于许可权利管理的数字内容的方法600的流程图。按照本发明,请求实体能代表一个或多个潜在的受证人提交的许可证请求。此请求实体可以是或者可以不是一个潜在的许可证接收者。一个潜在的受证人可以是个人、一个群组、一个设备、或者能以任何形式消费内容的任何其它实体。现在将参照一个实施例描述方法600,其中DRM服务器处理许可证请求,然而应该明白,许可证请求处理也可以被执行在客户端上,同时许可发布直接由客户端执行。
在步骤602中,举例来说,一个许可证发布实体,比如DRM服务器接受一个许可证请求。更合适的,许可证请求包括或者是一个公钥证书,或者是对一个或者请求发证人的身份。用于许可请求的较佳实施例的SOAP协议是:
<soap:Envelope xmlns:xsi=“http:∥www.w3.org/2001/XMLSchema-instance”
xmlns:xsd=“http:∥www.w3.org/2001/XMLSchema”
xmlns:soap=“http:∥schemas.xmlsoap.org/soap/envelope/”>
<soap:Body>
<AcquireLicense xmlns=“http:∥xxxx.com/PublishingService”>
<RequestParams>
<AcquireLicenseParams>
<LicenseeCerts>
<String>string</String>
<String>string</String>
</LicenseeCerts>
<RightsSpecification>string</RightsSpecification>
<RightsOfferID>string</RightsOfferID>
<ApplicationData>string</ApplicationData>
</AcquireLicenseParams>
<AcquireLicenseParams>
...
</AcquireLicenseParams>
</RequestParams>
</AcquireLicense>
</soap:Body>
</soap:Envelope>
在步骤604中,请求实体(也就是作出许可证请求的实体)被认证。按照本发明的一个实施例,许可证发布实体能被配置成使用协议(例如,盘问—应答)认证来确定请求实体的身份,或者它被配置为不需要对请求实体认证(也称为“允许匿名认证”)。在需要认证之处,任何类型的认证方案可被采用(例如,上述盘问—应答方式,用户身份证—与—口令方式,比如MICROSOFT.NET,PASSPORT,WINDOWS认证,X509,等等)。更合适的是,允许匿名认证,以及支持由集成信息系统支持的任何协议认证方案。认证步骤的结果将是一个身份,比如“匿名”身份(对于匿名认证),或例如,一个个人账户身份。假如对于任何理由许可证请求不能被认证,则将返回一个出错,同时没有许可证被授予。
在步骤606中,经认证的实体是被授权的,也就是说,它确定是否步骤608中被认证的实体被允许请求一个许可证(或者是为它自己,或者是代表其它实体)。较佳地,许可证发布实体存储允许(或者不允许)请求许可证的实体的一个列表。在一个较佳实施例中,在这一身份列表中的一个身份是作出请求的实体的身份,而不是为之请求许可证的实体的身份,虽然两者都可以。举例来说,个人账户身份可能不允许直接作出一个许可证请求,但是一个受托服务器过程可能代表一个实体作出一个许可证请求。
按照本发明,许可请求可以是包括一个公钥的证书,或者是每一个潜在受证人的身份。假如只有一个许可证被许可被证接受者请求,则只有一个证书或者身份被命名。假如多个许可证接受者请求一个许可证,则一个证书或者身份可以对每个潜在的许可证接受者命名。
更合适的,许可证发布实体对每个有效的受证人有一个公钥证书。然而,应用程序302可能需要对一个给定的用户产生一个许可证,但是此应用程序302可能对这一用户的公钥证书没有访问权。在这样一种情况下,该应用程序302可以在许可证请求中指定用户的身份,且作为一个结果,许可证发布实体可以启用一个已被注册的证书插入模块,它执行目录中查找的服务,同时将公钥证书返回给合适的用户。
假如在步骤608中,发布实体确定公钥不包括在许可证请求中,则发布实体使用特定的身份在一个目录服务或数据库中执行查找合适的公钥证书。假如在步骤610中,发布实体确定该证书在目录中,则在步骤612中,检索该证书。在一个较佳实施例中,证书插入模块被用于通过用目录访问协议的方法从目录服务中检索公钥证书。假如请求中的或者目录中的给定潜在受证人证书不能被找到,则许可证服务器不能为那个受证人产生一个许可证,并且在步骤614中,一个出错将返回到请求实体。假定许可证发布实体具有至少一个潜在受证人的公钥证书,则在步骤616处,发布实体确认受证人证书的真实性。发布实体最好用一组可信任的证书发布方证书来配置,并且它确定受证人证书的发布方是否在受托发布方列表中。如果在步骤616处,发布实体确定受证人认证的发布方不在受托发布方的列表中,则对于该受证人请求失败,并且在步骤614处产生错误。这样,证书并非由受托发布方发布的任何潜在受证人都不会接收到许可证。
此外,发布实体最好对从受托发布方证书到个人受证人公钥证书的证书链中的所有实体执行数字签名生效。确认链中的数字签名的过程是众所周知的算法。如果给定潜在受证人的公钥证书并未生效,或者链中的证书并未生效,则潜在受证人并不可信,因此,不给该潜在受证人发布许可证。否则,在步骤618处可以发布许可证。过程在步骤620处重复,直到已被请求了许可证的所有实体都被处理为止。
如图6B所示,许可证发布实体继续确认许可证请求中接收到的签名后的权利标签308。在优选实施例中,发布实体可以使用权利标签插件、以及利用一个后台数据库来在服务器上存储每个由发布实体签名的权利标签的主拷贝。权利标签由发布时放入其中的GUID来标识。在许可证时间处(步骤622处),发布实体分析许可证请求中输入的权利标签并且检索其GUID。然后,它将该GUID传送到权利标签插件,该插件发布对数据库的查询来检索主权利标签的拷贝。主权利标签会比许可证请求中发送的权利标签的拷贝更新,它也将是下列步骤的请求中使用的权利标签。如果根据GUID未在数据库中找到权利标签,则发布实体在步骤624处检查其政策,以确定它是否仍被允许根据请求中的权利标签来发布许可证。如果政策不允许这样,则许可证请求在步骤626处失败,并且在步骤628处将错误返回到API 306。
在步骤630处,许可证发布实体使权利标签308生效。权利标签上的数字签名生效,而且,如果发布实体并非权利标签的发布方(对其签名的实体),则许可证发布实体确定权利标签的发布方是否是另一个受托实体(例如,使许可证发布实体能共享密钥资料的实体)。如果权利标签未生效,或者它并非由受托实体发布,则许可证请求在步骤626处失败,在步骤628处将错误返回给API306。
在所有生效都发生之后,许可证发布实体为各个经认可的受证人将权利标签308转化为许可证。在步骤632处,许可证发布实体为要被发布给每个受证人的许可证产生相应的权利说明。对于每个受证人而言,发布实体评价以该受证人的公钥证书中命名的身份相对于以权利标签中权利说明中命名的身份。权利说明将能实行许可证中的权利或一组权利的一组身份分配给每个或每组权利。对于与该受证人的身份相关的每个权利或每组权利而言,该权利或该组权利被拷贝到许可证的新数据结构中。所产生的数据结构是对于特定受证人的许可证中的权利说明。作为该过程的一部分,许可证发布实体评价可能与权利标签的权利说明中的任一权利或一组权利相关的任何前提。例如,一项权利可能具有与其相关的时间前提,它限制许可证发布实体在指定时间后发布许可证。在这种情况下,发布实体需要检查当前时间,并且如果已经过了前提中指定的时间,则即使该受证人的身份与该权利相关,发布实体也不能将该权利发布给受证人。
在步骤636处,发布实体从权利标签308中取得(PU-DRM(DES1))和(DES1(CK))并且应用(PR-DRM)来获得(CK)。发布实体然后用(PU-ENTITY)受证人的公钥证书来重新加密(CK),从而得到(PU-ENTITY(CK))。在步骤638处,发布实体将所产生的权利说明与(PU-ENTITY(CK))串接,并且用(PR-DRM)对产生的数据结构数字签名。该经签名的数据结构是该特定受证人的许可证。
在步骤640处,当发布实体确定不再有为特定请求产生的许可证时,它将产生零个或多个许可证。在步骤642处,所产生的许可证被返回请求实体,以及与那些许可证相关的证书链(例如,服务器自身的公钥证书以及发布其证书的证书,等等)。
许可应答的优选实施例的SOAP协议如下:
<soap:Envelope xmlns:xsi=“http:∥www.w3.org/2001/XMLSchema-instance”
xmlns:xsd=“http:∥www.w3.org/2001/XMLSchema”
xmlns:soap=“http:∥schemas.xmlsoap.org/soap/envelope/”>
<soap:Body>
<AcquireLicenseResponse xmlns=“http:∥xxxx.com/LicensingService”>
<AcquireLicenseResult>
<AcquireLicenseResponse>
<CertificateChain>
<String>string</String>
<String>string</String>
</CertificateChain>
</AcquireLicenseResponse>
<AcquireLicenseResponse>
...
</AcquireLicenseResponse>
...
</AcquireLicenseResult>
</AcquireLicenseResponse>
</soap:Body>
</soap:Envelope>
在按照本发明的系统的优选实施例中,可以使用多个发证人密钥。在这种实施例中,经过权利标签308加密并进入许可证的内容密钥(CK)实际上可以是任意数据。一种特别有效的变动是在权利说明分别使用多个独立的、加密的、不同权利或不同委托人与相关的内容密钥(CK)。例如,专辑上歌曲的数字版本可以都用不同密钥(CK)来加密。这些密钥(CK)会被包括在同一权利标签中,但是一个委托人可以具有播放一首歌曲的权利(例如,他仅有取得其许可证中一个密钥的权利),然而第二委托人可能有播放所有歌曲的权利(她可能有取得其许可证中所有密钥的权利)。
按照本发明的系统最好使发布应用程序/用户能在权利标签308中命名受证人的群组或类别。在这种实施例中,许可证发布实体将评价权利标签中命名的任何群组/类别,以确定当前许可证受让人身份是否是那些群组类别的一员。如果找到命名的群组/类别中的一员,则发布实体会将与该群组/类别相关的权利或一组权利加入该许可证所用的权利说明数据结构。
在本发明的优选实施例中,DRM服务器中的公开和许可证协议接口支持对调用应用程序或用户的认证和授权,DRM服务器的管理控制台允许管理员为用于许可和发布的两个界面产生访问控制列表。这使服务器的用户能把政策应用在哪个用户/应用程序许可、或两者均可之上。
修改或重新发布签名后的权利标签308
在本发明的一个实施例中,如果内容的用户已经被授权足够的许可,则SRL308可以被“重新发布”。也就是说,如果用户被允许,则它能改变SRL308内的权利数据。值得注意的是,这种改变权利数据的许可应被保守地、根据判断而授权,尤其因为具有改变权利数据的许可的用户基本上可以给自己授权关于相关内容的广泛权利。可以想像,这样的用户甚至能给自己授权发布该内容并将其公之于众。
这里,改变的许可通过将指示包括在SRL308中的权利数据内来表示,该指示表示特定用户或用户类别实际上能改变或“重新发布”权利数据和权利标签308。当DRM服务器接收带有与许可证请求有关的这类许可的SRL308时,DRM服务器320将对称密钥(DES1)包括在为用户请求的许可证内,该对称密钥按照用户的公钥(即,PU-ENTITY)来加密而得到(PU-ENTITY(DES1))。
于是,为了编辑SRL308内的权利数据,现在参考图7,用户从许可证中检索(PU-ENTITY(DES1))(步骤701),对它应用(PU-ENTITY)来产生(DES1)(步骤703),从SRL308中检索(DES1(rightsdata))(步骤705),并对它应用(DES1)来产生权利数据(步骤707)。然后,用户根据需要改变权利数据(步骤709),并以上述结合图4提出的方式将经改变的权利数据呈交到DRM服务器320以获得签名后的权利标签308(步骤711)。当然,这里签名后的权利标签308实际上是重新发布的SRL308,因此,一旦接收到SRL308(步骤713),则用户剥离与相关内容串接的原始SRL308(步骤715),并且将重新发布的SRL308与该内容串接(步骤717)。
这样,可以理解,重新发布SRL308使用户能更新SRL308中的权利数据,包括权利、条件和用户,而无须改变相关内容。特别是,重新发布不需要用新的(CK)加密相关内容。同样,重新发布不需要从头开始产生新的SRL,尤其因为原始SRL308中具有许多能被用在新的SRL308上的项目。
自发布签名后的权利标签308
在本发明的一个实施例中,SRL308可以由请求用户自身来被签名。因此,用户不需要联系DRM服务器320来为一件相关内容获得SRL308。因此,自发布也可被称为脱机发布。在这种实施例中,用户可能需要联系DRM服务器320来根据这种自发布的SRL308请求许可证。也可以理解,发布实体能够发布其自身的许可证。
现在参考图8,特别在实施例中,首先通过从DRM服务器320接收DRM证书810来预备用户自发布,DRM证书810包括公钥(PU-CERT)和相应按照用户的公钥(PU-ENTITY)加密的私钥(PR-CERT)以产生(PU-ENTITY(PR-CERT))。证书应该用DRM服务器320(PR-DRM)的私钥签名,以便这种DRM服务器可以与下列详述的那样验证该证书。可以理解,DRM证书810授权用户自发布。也可以理解,密钥对(PU-CERT,PR-CERT)与(PU-ENTITY,PR-ENTITY)分开,并且尤其为了自发布而被使用。注意到密钥对(PU-CERT,PR-CERT)可以被省却,这种情况中DRM证书810仅包括用户的公钥(PU-ENTITY)并且由DRM服务器320的私钥(PR-DRM)签名,以便这种DRM服务器能验证该证书。
自发布与图4所示的发布不同,因为关于那里执行的步骤,用户基本上取代了DRM服务器320。重要的是,用户用从DRM证书810获得的(PR-CERT)(即,S(PR-CERT))对包括(PU-DRM()DES1)和(DES1(rightsdata))在内的已呈送的权利标签签名,从而产生经签名的权利标签(SRL)308。应该理解,用户通过从这类DRM证书810获得(PU-ENTITY()PR-CERT)并在那里应用(PR-ENTITY)而从DRM证书810获得(PR-CERT)。然而,注意到用户不能验证DRM服务器320可以实施已呈送权利标签中的权利,尤其因为用户不具有应用在(PU-DRM(DES1))的(PR-DRM)。因此,DRM服务器320自身应该在根据自发布的SRL308请求许可证时执行验证。
一旦用户自发布SRL308,则用户将这种自发布的SRL308与用于产生相同内容的DRM证书810串接,且带有SRL308和DRM证书810的这种内容被分发到另一个用户。此后,另一用户从DRM服务器320请求并获得该内容的许可证,其方式大致与图6A和6B所示的方式相同。然而,这里许可证请求用户将与内容串接的自发布SRL308和DRM证书810呈送到DRM服务器320。然后,DRM服务器根据相应的(PU-DRM)验证DRM证书810中的S(PU-DRM),并从DRM证书810获得(PU-CERT)。DRM服务器接着根据获得的(PU-CERT)来验证SRL308中的S(PR-CERT),并且如前一样继续。然而,注意到由于用户不验证DRM服务器320能否实施SRL308中的权利,因此如前所述,DRM服务器320自身应该在此时执行验证。
权利模板
如上所述,用户具有创建权利标签中的大多数各类或各种权利数据的自由,这是通过定义用户或用户类别、为每个所定义的用户或用户类别定义权利、以及定义任何使用条件而完成的。然而,重要的是,为多个权利标签重复定义权利数据可能是麻烦并重复的,尤其当为不同的内容块重复定义相同的用户或用户类别、权利、以及条件时。例如,这种情况会发生在团体或办公室环境中,其中用户重复发布要与特别定义的一队用户共享的不同内容块。然后,在这种情况下,并且在本发明的一个实施例中,创建一个权利模板,使用户能在关于创建权利标签时重复使用,其中权利模板已经包括一组预定的用户或用户类别,每个所定义的用户或用户类别的预定权利、以及预定的使用条件。
在本发明的一个实施例中,现在参考图9,权利模板900具有与权利标签中相同的权利数据。然而,由于(DES1)在内容被发布之前未知,因此权利数据不能像权利标签中的情况那样。按照这样的(DES1)被加密。然后,在本发明的一个实施例中,在图4的步骤416中,带有未加密权利数据的权利模板900在用(DES1)加密权利数据的过程中被呈送以产生(DES1(rightsdata))。当然,权利数据在这样被加密之前从已呈送的权利模板900中被检索出来。
在构造权利模板时,DRM服务器320以及其中的公钥(PU-DRM)可能或可能不是已知的。而且,即使已知,也可能有或可能没有多于一个DRM服务器320,各具有其自身的(PU-DRM)。然而,在DRM服务器320及其公钥(PU-DRM)在构造权利模板时已知的情况下,并且在仅使用一个DRM服务器320的情况下,或仅有一个DRM服务器320要与权利模板900一起使用的情况下,这样的模板也可以在其中包括DRM服务器上的信息,它对从权利模板900产生的权利标签签名,该信息包括公钥(PU-DRM)。尽管这种(PU-DRM)出现在SRL308中来加密(DES1)而产生(PU-DRM(DES1)),然而又可以理解,在内容被发布之前(DES1)未知,在权利模板900中的并且因而(PU-DRM)不能对这种(DES1)加密,这与权利标签中的情况相同。然后,在本发明的一个实施例中,在图4的步骤414中,带有未加密(PD-DRM)的权利模板900在用(PU-DRM)加密(DES1)的过程中被呈送以产生(PU-DRM(DES1))。当然,(PU-DRM)在被使用之前从已呈送权利模板900中被检索出来。
同样在上述情况中,可能包括在权利模板中的DRM服务器上的其它信息也可能包括证人信息,如用于将DRM服务器定位在网络上的URL,以及当URL失败时的退回(fall-back)信息。在任何情况下,权利模板还可以包括描述权利模板900自身的信息,连同其它信息。注意到权利模板900也可以为与要被发布的内容相关的信息提供空间,譬如出现在与内容有关的权利标签中的信息和/或加密密钥(CK)和(DES1),然而如果权利模板的示例并未实际上转换为权利标签时,这种空间是不必要的。
尽管如此揭示的权利模板900主要为了方便用户,然而也可以理解,在某些情况下,用户不应在权利标签中定义权利数据时有无限止的自由,且权利模板900可以用来限制可被创建的权利标签的范围或类型。例如,并且尤其在团体或办公室环境的情况下,可被预定义为政策的是:特定用户应总是仅将内容发布给特定用户类别,或者用户应该永不将内容发布给特定用户类别。在任何情况下,并且在本发明的一个实施例中,这样的政策作为预定义的权利数据被包含在一个或多个权利模板900中,用户可被限止使用这种权利模板而在发布内容时创建权利标签。注意到,使用户指定为用户发布政策可用的权利模板或一组权利模板可以指定任何特定类型的发布政策,而无须背离本发明的精神和范围。
为了为受限止用户等人指定权利模板900,现在参考图10,管理员等人实际上通过定义预定义的权利数据(步骤1001)、以及定义诸如有关特定DRM服务器320的信息这样的任何必要并适当的其它数据(步骤1003)来构造权利模板900。重要的是,为了实现受限止用户等人所使用的权利模板,必须使权利模板900成为法定的。也就是说,权利模板900必须被视作受限止用户或其它人会使用的权利模板。因此,在本发明的一个实施例中,由管理员等人构造的权利模板被呈送到DRM服务器320来签名,其中这种签名使权利模板成为法定的(步骤1005)。
注意到签名DRM服务器320是其信息在权利模板900中的DRM服务器320,如果实际上这种信息存在于权利模板900中的话。同样注意到,DRM服务器可以仅在作出任何必要的检查后在权利模板900上签名,或者根本不检查而签名。最后注意到,来自DRM服务器的权利模板签名S(PR-DRM-T)(其中-T表示该签名用于ORT 900)应该至少基于权利模板900中的预定权利数据,但也可以基于其它信息而不背离本发明的精神和范围。如下所述,签名S(PR-DRM-T)应被结合在权利标签中,并在那里被验证,因此无论签名基于什么,它都应以未改变的形式被结合在权利标签中。
在DRM服务器320签名权利模板900并将同一模板返回管理员等人时,管理员接收带有S(PR-DRM-T)的经签名并且现在是法定的权利模板900(步骤1007),并将法定权利模板(ORT)900转送给那里所用的一个或多个用户(步骤1009)。由此,对于基于ORT900发布内容的用户而言,用户检索ORT900(步骤1011),并通过提供任何必要信息而根据ORT900构造权利标签(步骤1013),必要信息诸如内容信息、适当的密钥信息、由(DES1)加密的来自ORT900以产生(DES1(rightsdata))的权利数据,以及任何来自ORT900的其它信息。重要的是,用户还在权利标签内包括来自ORT900的签名S(PR-DRM-T)。
此后,如前所述,用户将权利标签发送到DRM服务器320来签名(步骤1015)。然而,这里DRM服务器320不会对已呈送权利标签签名,除非验证了其中的S(PR-DRM-T)。也就是说,DRM服务器320强迫用户必须使已呈送的权利标签是基于ORT900的,这通过除非这种已呈送权利标签包括来自ORT900的签名S(PR-DRM-T)时、才对已发送权利标签签名而实现。特别是,DRM服务器320从已发呈的送权利标签中检索这种S(PR-DRM-T)以及这种签名所基于的任何信息,然后根据(PU-DRM)验证这种签名。注意到已呈送的权利标签内的权利数据按照(DES1)被加密(即,(DES1(rightsdata)))。由此,DRM服务器320必须首先获得(DES1)并且在那里解密(DES1(rightsdata)),如上结合图7所述,要能根据已呈送的权利标签中的权利数据来验证签名。
一旦被验证,DRM服务器320用S(PR-DRM-L)对已呈送权利标签签名以产生SRL308,跟以前一样(其中-L表示该签名用于SRL308)。这里,S(PR-DRM-L)可以代替S(PR-DRM-T),或者可以附加于这种S(PR-DRM-T)之上。如果是附加的,则S(PR-DRM-L)部分基于S(PR-DRM-T)。注意到可以使用(PR-DRM)来产生S(PR-DRM-T)和S(PR-DRM-L),或者可以为各个S(PR-DRM-T)和S(PR-DRM-L)使用不同的(PR-DRM)。在DRM服务器320对权利标签签名并将SRL308返回给用户后,用户接收带有S(PR-DRM-L)的SRL308(步骤1017)并继续将其与被发布的内容串接,跟以前一样。
如果ORT900的签名S(PR-DRM-T)至少部分基于ORT900内的预定义权利数据,则如出现在SRL308中(DES1(rightsdata)中的这种权利数据不能被修改或改变。否则,S(PR-DRM-T)不会验证。然而,在本发明的一个实施例中,OPT900内的权利数据可以在ORT900中也包括的规定规则内改变。例如,规则可以指定一组或两组权利数据要被包括在SRL308内,或者可以允许从一组替换物中作出选择。可以理解,这些规则可以是以任何适当语法提出的任何特定规则,而不背离本发明的精神和范围。这里,当创建权利标签时,由适当的规则解释程序来为用户解释这些规则。尽管权利数据可以变化,然而规则不会相应变化,因此ORT900的模板签名S(PR-DRM-T)至少部分基于规则而非基于权利数据本身。因此,包括在ORT900内的规则也可以包括在SRL308内。
在本发明的一个实施例中,如上所述,ORT900内的预定义权利数据是部分固定并不变的,并且是部分可变并且是规则驱动的。这里,ORT900的模板签名S(PR-DRM-T)至少部分基于规则的固定部分以及基于权利数据可变部分的规则。
可以理解,由用户拥有的ORT900可以成为过时并陈旧的。也就是说,通过那里的权利数据的ORT900可以反映已经过时、无关、或简单地不再能应用的政策。例如,ORT900的权利数据中指定的一个或多个用户或用户类别可能不再存在于政策环境中,即ORT900的权利数据中指定的一个特定用户或用户类别可能不再具有与政策环境中相同的权利。在这种情况下,管理员可能已发布了修订版的ORT900,然而用户仍然使用ORT900的先前、陈旧的版本。
然后,在这样的情况下以及在本发明的一个实施例中,在对已发送的权利模板900签名以创建ORT900之后,DRM服务器320保持ORT900的拷贝,各ORT900具有唯一的标识标记,各个根据ORT900构造的权利标签包括这种ORT900的标记。因此,在如结合图10接收到已呈送的权利标签之后,DRM服务器320在权利标签中找到ORT900的标识标记,根据已找到的标识标记检索这种ORT900的最新拷贝,从已发送权利标签中移去权利数据,插入来自已检索的ORT900的权利数据,然后至少部分根据所插入的权利数据对权利标签进行签名。当然,DRM服务器也执行任何必要的加密和解密步骤,它们在上述过程中是必要且负有责任的,包括解密和重新加密(DES1(rightsdata))。注意到如果DRM服务器适用于替代已呈送的权利标签内的权利数据,则这种权利标签以及来自构造这种权利标签的ORT900不必要在其中包括权利数据。取而代之,权利数据仅需驻留在DRM服务器320中。然而,使权利数据包括在权利标签中以及从中构造这种权利标签的ORT900中对用户是有用的,因此在某些情况下也是有用的。
密钥操作的抽象
按照本发明的数字权利管理系统可以包括密钥管理接口,它允许不同的密钥保护方案被插入数字权利管理系统中。这种结构可以暴露签名数据的功能,用公钥解密经加密的数据,并且使用通过接口输出到不同经认证的委托人的公钥重新解密已加密的数据(即,不同的公钥)。这样,可以提供安全接口以便数据以明文进入或离开接口。这种接口可以输出签名和解密的私钥操作,并且在许可和发布时为DRM系统提供安全性和认证。在发布期间,客户可以加密资源密钥以便只有指定的实体才能对其解密,例如,用实现上述接口的插件。在许可期间,许可证发布实体可以用接口来解密资源密钥并且对许可证和权利标签签名,以便资源被保护并且可由主管数字权利管理平台消费。该接口从而提供了密钥操作的抽象。
图14提供了按照本发明的方法的优选实施例流程图,用于提供数字权利管理系统内安全密钥操作的抽象。在步骤1402处,提供了密钥管理接口与数字权利管理系统一起使用。如上所述,密钥管理接口把诸如密码操作这样的操作抽象化,它包括密钥资料的使用,例如来自公/私密钥对的私钥。这种抽象最好在检索密钥资料或其它资料期间允许密钥资料的外部识别,这取决于密钥的使用(例如,证书)。也就是说,密钥管理接口提供了一种机制,外部呼叫方可以通过该机制来标识要被用来执行操作的密钥材料。
在步骤1404处,提供了数字权利管理系统中所使用的多个密钥管理组件。各密钥管理组件使数字权利管理系统能执行相应的方法来管理密钥资料。例如,下述结合图11A-D、12和13描述的方法可以用相应的密钥管理组件来实现。密钥管理组件最好用插件组件来实现。
然后,DRM系统的用户可以从可用的任选项中作出选择,从而按照用户的需求来定制用户系统。这种系统使用户能根据成本、安全性、以及保护密钥资料时的性能而从多个密钥管理组件中选择被选密钥管理组件。
在步骤1406处,所选密钥管理组件通过密钥管理接口被集成在数字权利管理系统中。这样,可以向用户提供一种DRM系统,该系统包括用户已选择最适合用户安装的密钥管理能力。此外,插件设计允许所选的密钥管理方法被快速、容易、并且廉价地被换入或换出。
下面是几个优选密钥保护方案的每一个的详细说明,它们能与按照本发明的密钥操作的抽象一起使用。
通过将其移出前端服务器来保护私钥
一般来说,如图11A所述,可包括诸如签名和解密数据等功能的密码操作1114发生在服务器池1110中,服务器池包括一个或多个前端服务器1110a-c。密码操作1114涉及私钥1116的使用,私钥一般被存储在数据库服务器1113上的数据库1112中。私钥1116作为执行密码操作1114所用的公/私密钥对的一部分而产生。为了执行密码操作1114,前端服务器1110从数据库1112中检索私钥1116。
尽管可能试图保护前端服务器池1110上的私钥1116,然而最好将私钥从前端服务器池1110中移去,因为这种解决方式使可能的攻击者更难闯入前端服务器1110来偷取或损害私钥。
一般而言,本发明的一方面提供了密钥的存储并且在前端服务器外部的后端服务器池上执行相关密码操作。后端服务器池最好包括一个或多个后端服务器,它们通过局域网耦合到前端服务器池(并且互相耦合)。因此,前端服务器池可以通过诸如因特网这样的全球通信网来访问,后端服务器池不能直接从因特网访问。这种配置使黑客更难偷取或损害私钥以及相关的密码功能,从而相对于在前端服务器上执行密码操作的系统改进了系统的总体安全性。
图11B说明了一个优选实施例,其中后端服务器1121包括数据库服务器1122。密码操作1124作为数据库服务器1122上扩展存储的过程的一部分而被执行,该服务器在前端服务器池1120外部。为了执行调用私钥的密码操作1124,前端服务器1120通过LAN1126对数据库服务器1122启动被存储的过程调用1127。该存储的过程使密码操作在数据库服务器722上被执行。结果,私钥1126不需要离开数据库1128,密钥1126和被存储的过程可以与数据库本身一样安全。由于数据库1128一般不在前端服务器1120上,因此有一种成本合算的方式来将私钥从前端1120中移去。
使用了与图11C和11D中相同的方法后,中间服务或服务器被引入来执行使用私钥的密码操作。这种服务或服务器最好在前端服务器池外部,并且位于不能通过因特网访问的私有后端LAN上。
图11C说明了一种优选实施例,其中后端服务器1131包括外部密码服务器/服务1136,它被耦合在服务器存储池1130和数据库服务器1132之间。为了执行任一密码操作1134,前端服务器1130启动对外部密码服务器1139的调用。外部密码服务器1139可以通过诸如LAN这样的本地通信网1137通信上耦合到各前端服务器1130和数据库服务器1132。外部密码服务器1139调出驻留在数据库服务器1132上的被存储的过程。被存储的过程引起密码操作1134在数据库服务器1132上被执行。这样,如上结合图7B所述的实施例,所有涉及私钥1136的密码操作都可以在数据库服务器1132上执行。因此,私钥1136不需要离开数据库1138。
图11D说明了另一种优选实施例,其中后端服务器1141包括了耦合在服务器池1140和数据库服务器1142之间的外部密码服务器/服务1149。如图11D所示,密码操作1144可以由外部密码服务器/服务1149执行。为了执行任一密码操作1144,前端服务器1140启动对外部密码服务器1149的调用。外部密码服务器1149从数据库1148中检索私钥1146,并且用该私钥1146来执行外部密码服务器1149内的密码操作1144。因此,私钥1146可被存储在密码服务器1149上,并作为其上提供的一部分密码服务而被保存。应该理解,这种方法由于其规模可变性而特别有效。在某些点处,随着更多前端服务器被加入服务器池1140来处理更多的负载,密码操作1144会成为一个瓶颈。由于数据库服务器的部署和维护一般是更为昂贵的,因此宁愿部署更多的外部密码服务/服务器,而非数据库服务器。
应该理解,外部密码服务/服务器的其它实施例(即,其中密码操作发生在后端LAN上的外部服务器/服务上)也是可行的,并且较佳地使用数据库,但并不必要。
通过从内容保护私钥中分开证书签名私钥来保护私钥
如上具体所述,按照本发明的DRM服务器为至少两个不同操作使用公/私密钥对的私钥部分:对许可证签名以便主机DRM平台能认证的内容和认证防窜改用途的其它证书,并且解密用于保护数字内容的内容对称密钥。可以为两种操作使用同一公/私密钥对。
然而,按照本发明的一个方面,可以使用两个独立的私钥一证书签名私钥和内容保护私钥。应该理解,尽管目让证书签名私钥驻留在前端服务器上这样的风险认为是可以接受的,然而使内容保护私钥驻留在前端服务器上的风险是远不能接受的。这是因为许可证发布中可以加入其它防护装置来防止第三方产生其自身的许可证。这种技术的一个实例是可以将已加密的数据插入许可证,该已加密的数据与某些由DRM系统验证的未加密的数据相匹配。通过分开两个私钥,更多功能可以保持驻留在前端服务器上,而且系统的规模可以更有效。
如图12所示,DRM系统1230可以具有根或“内容保护”公/私密钥对,它们能用来解密用于保护数字内容的内容对称密钥。内容保护公钥可以通过由最终“可信根”1235(例如,微软拱顶(vault)密钥)签名的公开证书1236来发布。内容保护私钥可以被保持在高安全性区域1234中,例如,该区域可以是扩展的安全性后端服务器。
按照本发明的这个方面,DRM系统1230中的前端服务器1232可以在运行时产生用于证书签名的独立的公/私密钥对。扩展的安全性后端服务器1234可以使用它对根私钥的知识来对证书1237签名,表示该新的公钥是可信的。
前端服务器1232可以使用分开产生的证书签名密钥来执行所有的签名签名。当返回文档1238时,可以将包括证书签名公钥和根公钥的证书链返回给用户1210。客户1210可以沿证书链“向上走”来在返回的文档中建立其可信度。无论它是否期望,DRM系统1230可以重新产生签名公/私密钥对,而无须与客户1210协调。
通过使用无状态的滚动私钥来保护私钥
图13是说明本发明一个实施例的功能流程图,其中通过使用无状态的滚动私钥来保护私钥。DRM服务器使用根(即,主)私钥(Sroot)以及包含由主机发布的根公钥(Proot)的根发证人证书(Lroot)1310。新“滚动”密钥对(Si,Pi)1320由安全后端服务器1308周期性地产生(例如,一天一次,每100次交易一次,等等),并与发证人证书(Li)1312一起被提供给前端服务器1304。当前滚动私钥可被存储在前端服务器中的高速缓存1316内。可以根据需要来定义滚动密钥的窗口的度量。密钥产生得越频繁,则可以获得更多的安全性。为了建立无状态的解决方式,Li1312包含用Proot加密的Si。如上结合图12所述,独立密钥的概念也可以用来提供更稳定和安全的解决方式。
按照本发明的这个方面,当向DRM服务器发布请求来获得发证人证书时,当前发证人证书Li1312被返回。客户机1302上执行的DRM启用的客户应用程序1314在将权利标签上载到服务器来发布之前,对从Li获得的Pi将内容密钥加密。当在服务器上建立权利标签时,内容密钥用Si解密并且在用当前滚动密钥Pj加密之后被重新插入权利标签。当为发布而签名权利标签时,当前滚动私钥(Sj)用于对权利标签签名。经签名的权利标签1322、Lroot1310和Lj1312被返回调用者。在被调用以产生内容的许可证1318后,内容密钥被重新加密为所提供的用户角色密钥,从而将内容与请求用户结合。
注意到所有关键操作都使用上述私钥操作的接口来确保操作和密钥的安全。进行私钥操作的服务器保持滚动私钥的小LRU高速缓存来方便更快的查找。这使因为,否则各密钥服务器将必须要求安全后端来为每个请求解密Si,并且如果安全后端是远程数据库,则性能降级。如果这个服务器受到损害,则仅仅缓存内容被暴露给黑客。最终,为了使损害最小,高速缓存的尺寸可以相对很小。这是安全性和性能之间折衷的经典实例。
如果黑客攻击的概率为γ,则在不存在滚动密钥并且根密钥用于所有操作的情况下,损害所有内容的机会为γ,这使因为黑客取得所有内容的私钥。假如使用滚动密钥,则损害所有内容的机会为γ·((p+t)/N),其中p是高速缓存大小,t是私钥框上的工作线程数,N是表中私钥的数目。为了使高速缓存相干性本地化并且防止高速缓存上的系统颠簸,也可以使作为密钥操作寄主的服务器负载平衡来处理特定密钥的子集。
结论
由此,已经描述了用于提供特别适用于数字权利管理系统中使用的安全服务器密钥操作的系统和方法。本领域的技术人员可以理解,可以对本发明的优选实施例作出许多变化和修改,且这些变化和修改可以无须背离本发明的精神而作出。因此,所附权利要求覆盖这样落在本发明的真实精神和范围内的所有这种等价变化。
附录1
示例权利数据<?xml version=“1.0”?><XrML version=“1.2”><BODY type=“Rights Template”>
<DESCRIPTOR>
<OBJECT>
<ID type=“GUID”>c43...</ID>
<NAME>$$411$411name$411desc</NAME>
</OBJECT>
</DESCRIPTOR>
<WORK>
<OBJECT>
<ID/>
</OBJECT>
<RIGHTSGROUP name=“MAIN RIGHTS”>
<RIGHTSLIST>
<VIEW>
<CONDITIONLIST>
<ACCESS>
<PRINCIPAL>
<OBJECT>
<ID/>
<NAME>test@company.com</NAME>
</OBJECT>
</PRINCIPAL>
</ACCESS>
</CONDITIONLIST>
</VIEW>
<RIGHT name=“generic”>
<CONDITIONLIST>
<ACCESS>
<PRINCIPAL>
<OBJECT>
<ID/>
<NAME>test@company.com</NAME>
</OBJECT>
</PRINCIPAL>
</ACCESS>
</CONDITIONLIST>
</RIGHT>
</RIGHTSLIST>
</RIGHTSGROUP>
</WORK>
</BODY>
<SIGNATURE>
<ALGORITHM>RSA PKCS#1-V1.5</ALGORITHM>
<DIGEST>
<ALGORITHM>SHA1</ALGORITHM>
<PARAMETER name=“codingtype”>
<VALUE encoding=“string”>surface-coding</VALUE>
</PARAMETER>
<VALUE encoding=“base64”size=“160”>MwI...=</VALUE>
</DIGEST>
<VALUE encoding=“base64”size=“1024”>Msi...=</VALUE>
</SIGNATURE></XrML>
附录2
示例已签名权利标签(SRL)308<?xml version=“1.0”?><XrML version=“1.2”><BODY type=“Rights Label”version=“3.0”>
<ISSUEDTIME>2002-01-01_12:00:00</ISSUEDTIME>
<DESCRIPTOR>
<OBJECT>
<ID/>
<NAME>$$409$...</NAME>
</OBJECT>
</DESCRIPTOR>
<ISSUER>
<OBJECT type=“DRM-Server”>
<ID type=“GUID”>{d81... }</ID>
<NAME>Test DRM Server</NAME>
<ADDRESS type=“URL”>http:∥licensing.dev.com</ADDRESS>
</OBJECT>
<PUBLICKEY>
<ALGORITHM>RSA</ALGORITHM>
<PARAMETER name=“public-exponent”>
<VALUE encoding=“integer32”>65537</VALUE>
</PARAMETER>
<PARAMETER name=“modulus”>
<VALUE encoding=“base64”size=“1024”>NcO...=</VALUE>
</PARAMETER>
</PUBLICKEY>
<ENABLINGBITS type=“sealed-key”>
<VALUE encoding=“base64”size=“1024”>tFg...=</VALUE>
</ENABLINGBITS>
<SECURITYLEVEL name=“Server-Version”value=“2.0”/>
<SECURITYLEVEL name=“=Server-SKU”value=“22222-3333”/>
</ISSUER>
<DISTRIBUTIONPOINT>
<OBJECT type=“LICENSE ACQUISITION URL”>
<ID type=“GUID”>{0F4...}</ID>
<NAME>DRM Server Cluster</NAME>
<ADDRESS type=“URL”>http:∥localhost/Licensing</ADDRESS>
</OBJECT>
</DISTRIBUTIONPOINT>
<WORK>
<OBJECT type=“TEST-FORMAT”>
<ID type=“MYID”>FDB-1</ID>
</OBJECT>
<METADATA>
<SKU type=“PIDTYPE”>PID</SKU>
</METADATA>
<PRECONDITIONLIST>
<TIME/>
</PRECONDITIONLIST>
</WORK>
<AUTHDATA name=“Encrypted Rights data”>PAB...</AUTHDATA></BODY><SIGNATURE>
<ALGORITHM>RSA PKCS#1-V1.5</ALGORITHM>
<DIGEST>
<ALGORITHM>SHA1</ALGORITHM>
<PARAMETER name=“codingtype”>
<VALUE encoding=“string”>surface-coding</VALUE>
</PARAMETER>
<VALUE encoding=“base64” size=“160”>Prc...=</VALUF>
</DIGEST>
<VALUE encoding=“base64”size=“1024”>EHd...=</VALUE></SIGNATURE></XrML>