专利名称：在数字权利管理(drm)系统中撤销凭证及开除其余主体的制作方法
技术领域：
本发明涉及一个实施对数字内容的权利的系统，例如数字权利管理(DRM)系统。具体而言，本发明涉及这样的实施系统，它只允许数字内容的用户按照所得到的许可证权限规定的参数访问一个计算装置上被加密过的该数字内容。更具体而言，本发明涉及提供一种机制来指示DRM实施系统任何特定数字凭证或该DRM系统中别的主体已不再可靠。
背景技术：
现参照图1，如所周知，数字权利管理(DRM)和实施系统对于数字内容12分销到用户是十分需要的，数字内容12的例子如数字声频、数字视频、数字文本、数字数据、数字多媒体等等。用户得到数字内容后就要借助于适当的播放装置例如个人计算机14上的媒体演播器之类来播放或‘演播’或用别的方式访问该数字内容。
分销这类数字内容12的内容所有者通常希望对用户如何处理这种分销到的数字内容12加以限制。例如，内容所有者可能想限制该用户复制并再度分销此内容12到下一个用户，或者想让分销出去的数字内容12只能被演播有限次数，或限制其总的演播时间，或只限于在某种机器上演播，或只能用某种媒体演播器进行，乃至只能被某类用户来演播，等等。
然而，一旦分销出去后，内容所有者几乎没有多少办法去控制该数字内容12。数字权利管理(DRM)系统10能让任何形式的数字内容12的播放或演播得到控制，这种控制是灵活的、可由该数字内容的所有者定义的。数字内容12通常以打包13形式经合适渠道分销到用户。分销出去的数字内容包13所包含的数字内容12是已经用对称的加密/解密密钥(KD)加密过的，即所称为(KD(CONTENT))，该包内还包含标识该内容的信息、如何得到对该内容的许可证的信息等等。
基于信托的数字权利管理DRM系统10使得数字内容12的所有者规定许可证规则，在用户计算装置14上播放该数字内容12之前以及在使用该内容12期间这些规则必须得到满足。这些许可证规则可包括前述临时性要求，还可被包括在数字许可证16中，用户/用户的计算装置14(本文此后，这两个术语将可互换，除非另有规定的情形)必须从内容所有者或其代理人处得到该许可证。该许可证16是由发证者签署的，它还包含将数字内容(它可能是用用户可解密的密钥加密的)进行解密的解密密钥(KD)。由于内容12必须有许可证16才能够访问，这样一来内容12就可以自由分销了。重要的是，许可证16必须以某种方式直接或间接地捆绑到有待用来播放内容12的计算装置14。否则，就潜在可能将许可证16复制到无限数目的别的装置14上，从而也可在它们上面播放相应内容12了。
一件数字内容12的所有者应该相信用户计算装置14会遵守该内容所有者在其许可证16中规定的规则和要求，即除非许可证16中的规则和要求得到满足，不得播放数字内容12。于是较好的办法为，提供一个置信组元或机制1 8到用户计算装置14中使之不播放该数字内容，除非按照用户得到的伴随数字内容12的许可证16所包括的许可证规则可以播放。
置信组元18通常具有一个许可证评估器20，用以确定许可证16是否有效，如它有效则考察该许可证16的规则和要求，根据这一考察确定该用户是否有权以他请求的方式来播放该数字内容12以及其它事项。应该理解，许可证评估器20在DRM系统中是受信托按许可证16中的规则和要求来执行数字内容12的所有者的意愿，用户应该不能轻易更改这种置信单元的，不管其目的如何，恶意的或非恶意的。必要的是要让置信组元18知道被信托来发出各许可证的各外部实体，并能验证各种实体的身份，例如外部实体、用户、应用程序、和机器。
应该理解，许可证16中的规则和要求可规定用户是否有权播放数字内容12所依据的几个因素，包括用户是谁，用户所在地，用户所用计算装置的类型，用户启动DRM系统的播放程序，日期，时间，等等。此外，许可证16的规则和要求还限制许可证16只能有预定种类的用途，例如预定的演播数，或预定的演播时间。
可按任何合适的语言和句法来规定许可证16中的规则和要求。例如，该语言可简单规定必须满足的属性和值(例如DATE必须晚于X)，或者可要求按规定的语句来执行各种功能(例如IF DATE大于X，THEN DO...)。
一旦许可证评估器20确定了许可证16有效，而且用户满足了其中的规则和要求，则数字内容12就可被播放。特别是，为播放数字内容12，从许可证16得到解密密钥(KD)，将它应用于内容包13的(KD(CONTENT))，以便解密得到实际内容12，于是才真能播放该内容12。置信组元18也可能需要检验并跟踪计算装置14的环境中的动态方面，例如对进行内容播放的应用程序。
为执行与置信组元18相关的密码功能，包括上述应用(KD)到(KD(CONTENT))及所有别的密码功能，通常在置信组元18中设有黑匣22。和许可证评估器20一样，黑匣22在DRM系统中也是受信托按许可证16中的规则和要求来执行数字内容12的所有者的意愿，用户应该不能轻易更改这种置信单元的，不管其目的如何，恶意的或非恶意的。黑匣22也有作为许可证实施者的任务，特别是要保证只在用户计算装置14里内容12被解密并被交付适当的播放程序。
黑匣22通常既可执行对称的(单一密钥)也可执行不对称的(公共-私人密钥对)密码加密和/或解密。特别是，上述解密密钥(KD)通常是对称密钥，并以另一个对称密钥或公共密钥或私人密钥加密后的形式传输。于是，为了解密(KD(CONTENT))，而如果例如(KD)是被公共密钥(PU)加密了的(即为(PU(KD)))，黑匣22必须首先得到相应于(PU)的私人密钥(PR)，不对称地应用私人密钥(PR)到(PU(KD))以便得出(KD)，然后必须对称地应用(KD)到(KD(CONTENT))才能得出内容。
黑匣22带有秘密并被信托不会对任何人或任何物透露该秘密。直接或间接加密内容的密钥(KD)就基于该秘密，于是只有作为该秘密的承担者的黑匣22才能解密该内容密钥(KD)。于是，具有以该秘密关联方式加密了的(KD)的许可证16也就被连接或称束缚到黑匣22。该秘密通常就是密钥对(PU-BB，PR-BB)中的私人密钥(PR-BB)，对黑匣22来说它是独特的或几乎是独特的，而黑匣22相应的公共密钥(PU-BB)被用来直接或间接加密(KD)。顶重要的是，黑匣22必须能隐藏并保护(PR-BB)和相关的密码代码不被察觉和窜改，故而这种代码都是嵌埋或封存在黑匣22里而得以适当地模糊和自保护起来的。
为了防止不受限制地复制，黑匣22是连接到一个特定的硬件机器。这种连接通常是将机器特性用硬代码记入黑匣22并在运行时鉴定这种机器特性的。黑匣22也被信托来密码鉴定别的软件组元，通常是验证其端出的数字签署，从而能保证用户计算装置14上的置信系统18的别的组元和诸如许可证16这样的端出项目未被窜改过。
通常每个黑匣22伴随有一个数字黑匣凭证24(图1A)，它承担着(PU-BB)、独特的ID、版本号、及其它可能的凭证内容。黑匣凭证24是通过(PU-BB)跟(PR-BB)的对应关系连接到黑匣22上。许可证16的发证者可以根据置信组元18的黑匣22的凭证和其中的内容来决定是接受或者驳回来自置信组元18的对许可证16的请求。如果该请求被驳回，通常必须安装一个新的黑匣22后，请求才有可能被接受。当然，还有一些别的理由得安装新的黑匣22，它也许初始就安装了不过是与置信组元18的其余部分分开装的，或许它原来与置信组元的其余部分是一起安装的却一直没有活化，等等缘故。
与别的数字凭证一样，黑匣凭证24是由发证实体用私人密钥(PR-ISSUER)签署的，该密钥是基于一个拼凑的代码其中至少有黑匣凭证24内容的一部分，并且采用相应的公共密钥(PU-ISSUER)来验证。如果内容更改了，该签署不会得到验证。通常，发证者发出的黑匣凭证24包含一个链26的多个凭证24它们导回到置信的根当局发出的根凭证24，在这个链26上的每个凭证24都包含一个公共密钥它可用来验证沿链26的下一个凭证的签署，而其中黑匣22/置信组元18是知道根凭证24的公共密钥的。故而为要验证黑匣凭证24，黑匣22/置信组元18首先验证从根凭证24起以下在链26上的每个凭证24直到黑匣凭证24。此外，如果基于黑匣凭证24发出进一步的凭证24，即用(PR-BB)签署了，对这进一步的凭证24的验证可继续沿上述链的验证过程下来到该进一步凭证24。
更一般地说，应认识到，除了黑匣凭证24外，在DRM系统10的范围内还存在别的凭证24，此处每个凭证24作为一个端出(其对应的单元是真实可靠的)，具有一个密钥，并具有关于其对应单元的信息，及/或类似信息。例如，播放内容12的应用程序可伴随着一个应用程序凭证24及相伴着的一个由多个凭证24形成的链26导回到黑匣22/置信组元18所承认的置信的根当局。类似地，加入DRM系统10的一个用户在此系统中可由用户凭证24来代表而且也有由多个凭证24形成的链26相伴并导回到置信的根当局。注意，许可证16也是凭证24的一种形式。
类似地，计算装置14可有一个计算装置凭证24和其伴随的凭证链26，而且计算装置里的各种硬件单元(硬驱、处理器、显卡等)和软件单元(BIOS、操作系统、图像子系统等)的每个单元都可有其凭证24和与之相伴的链26。此外，因为每个许可证16是由一发证实体签署并发出的，这种许可证16是凭证24的一种形式，为了验证其签署诸目的，它确实也有一个相伴随的链26。
签发特定凭证24的实体通常有权撤销该凭证，例如通过将与该凭证相关的公共密钥列进一个可访问的撤销单中。黑匣22/置信组元18在验证任何特定凭证24以便鉴定其相应的单元时，可从该凭证的发证者得到相应的撤销单加以考察，从而决定是否撤销该凭证24，如果是的话，可拒绝承认凭证24的效用，并且拒绝按此已撤销凭证24来播放权利保护的内容12。然而该认识到，当验证/鉴定来自多个发证者多个凭证24/单元时，正如图1A所示关于由多个凭证24形成的多重链26的情况，要从所有这些发证者得到撤销单并加考察，这种工作很快就变得极其繁琐，即使还不是负担过重。
因此，有需求建立一种系统和方法，让置信组元18、黑匣22、或别的查询实体在鉴定和验证凭证24的过程中得以有效地得到并考察这类撤销单。
发明内容
本发明提供鉴定某相应单元的数字凭证，至少部分满足了上述需求。由计算装置中的置信组元验证了对该单元的鉴定后就由发证者发给数字凭证，此处验证包含了不撤销该凭证的保证。该凭证能认定由发证者委派的某实体的身份，而该实体就是对该凭证有权力撤销它的当局，该委派的撤证当局一旦在撤销单上认出有该凭证就会撤销它。该凭证也至少有一个关于可能撤销它的撤销条件，当用该凭证来鉴定一个单元时，此处每个撤销条件都必须得到满足。
为了鉴定一个凭证，须从该凭证确定认定委派的撤证当局的身份，该从那里得到撤销单的地址，以及有待施加到该撤销单的任何新颖性的要求。从而保证从该地来的撤销单已到，此当前的撤销单符合新颖性的要求，此当前的撤销单是由该凭证认定身份的、被委派的撤证当局所颁发，而且该凭证在此当前撤销单中经认定为不该被撤销。
上述本发明内容的总结，以及后面关于各实施方案的详细描述，结合附图就更易理解。为解说本发明，将最佳实施方案示于图中，但应理解，本发明并不限于图示的具体安排和仪器设置。各图为图1，一个置信系统的例子的实施架构方框图；图1A，可与图1所示架构配合使用的多个链接的数字凭证的示意方框图；图2，一个通用计算机系统，其中可将本发明的几个方面和/或其中的一些部分结合进去的示意方框图；图3，可用于本发明的一个实施方案的数字凭证和撤销单的方框图；图4，按照本发明一个实施方案，采用图2的撤销单，对图3的数字凭证进行验证的各关键步骤的流程图。
具体实施例方式
计算机环境图1和下面的讨论是想要对本发明和/或其各部分可能实施的合适的计算环境提供一个简要的一般性的描述。尽管并非必要，仍从用计算机(例如客户工作站或服务器)执行计算机可执行指令(例如程序模件)这样一般意义上来描述本发明。一般来说，程序模件包括子程序、程序、对象、组件、数据结构之类，它们执行特定任务或实施特定抽象数据类型。此外，也应认识到本发明和/或其各部分还可工作在别的计算机系统结构，包括掌上计算机、多处理器系统、基于微处理器或可编程芯片的家电、网络PC、小型计算机、大中型计算机等类型。本发明还可工作在分布式计算环境，其中由用通信网络连接的远地处理装置来执行任务。在分布式计算环境，程序模件可存在本地和远地的存储器装置里。
图2为通用计算系统一例，包括常规个人计算机120之类，其中包括处理单元121，一个系统存储器122，以及将各个系统组件包括系统存储器连接到处理单元121的系统总线123，它可为几种总线结构之一，包括存储器总线或存储器控制器、外设总线、及采用几种总线架构之一的本机总线。系统存储器包括只读存储器(ROM)124和随机存取存储器(RAM)125。基本输入/输出系统(BIOS)126，它包含帮助个人计算机120里面各单元间传送信息的基本子程序(如在启动时用的)，也存在ROM 124内。
个人计算机120还包括硬盘驱动器127以读出和写进到硬盘(图中未画出)上，磁盘驱动器128以读出和写进到可撤出磁盘129上，光盘驱动器130以读出和写进到可撤出光盘131(例如CD-ROM或别的光媒体)上。硬盘驱动器127、磁盘驱动器128、和光盘驱动器130分别由硬盘驱动器接口132、磁盘驱动器接口133、和光盘驱动器接口134连接到系统总线123。这些驱动器与其相联系的计算机可读媒体为个人计算机20提供的永久性存储的计算机可读指令、数据结构、程序模件和别的数据不是无电源消灭型的。
虽然作为例子在此描述的计算机环境采用了硬盘、可撤出磁盘129、和可撤出光盘131，还应认识到，可以存储数据并可被计算机访问存取的别的类型的计算机可读媒体也可用于本操作环境，例如包括盒式磁带、磁卡、视频数字式磁盘、Bernoulli卡筒、随机存取存储器(RAM)、只读存储器(ROM)等类。
多个程序模件可存储在硬盘、磁盘129、光盘131、ROM124或RAM125上，包括操作系统135、一个或多个应用程序136、别的程序模件137、及程序数据138。用户可通过键盘140和屏幕指点装置142等输入装置来将其命令和信息输入计算机120。图中未画出的别的输入装置可包括拾音器、操纵杆、game pad、satellite disk、扫描仪等类。这些和别的输入装置常通过与系统总线连接的串行端口接口146连到处理单元121，也可通过别的接口来连接，例如并行端口、游戏端口、或通用串行总线(USB)。监视器147或别种显示装置也通过接口(如视频适配器148)连到系统总线123。除了监视器147，个人计算机通常还包括别的外围输出设备，例如扬声器和打印机(未画出)。图2的示例系统也包括主适配器155、小计算机系统接口(SCSI)总线156、及一个连到SCSI总线156的外存储装置162。
个人计算机120可与一个或多个远方计算机逻辑连接从而工作于联网环境，例如图中联网到一个远方计算机149，它可以是另一个人计算机、一个服务器、一个路由器、一个网络PC、一个同等的装置(a peer device)、或别的共用网络节点，它通常包括上面关于个人计算机120所描述到的多个乃至所有这些单元，虽然图2中只画出了其中的存储器装置150。图2所示的逻辑连接有一个局域网(LAN)151和一个广域网(WAN)152。这种联网环境在办公室、企业范围的计算机网络、网际网和因特网的情形都是常见的。个人计算机120也可用作主机来连接一个客户机，例如另一个个人计算机120、或另一个更专门的装置如便携式放映器或便携式数字助理之类，这样主机可下载数据到客户机和/或自客户机上载数据，还可做别的工作。
当用于局域网环境，个人计算机120通过网络接口或适配器153连到LAN151。当用于广域网环境，个人计算机120通常采用调制解调器154或别的手段建立与广域网LAN152，例如因特网，的通信。内置式或外置式的调制解调器154通过串行端口接口146连接到系统总线123。在联网环境中，关于个人计算机120所描述的程序模件或其中各部分可存储在远方存储器装置内。下面将会理解到图2所示的网络连接仅为示例性的，还可用别的手段来建立计算机之间的通信联系。
凭证的撤销如前所述，在数字权利管理DRM系统10中，置信组元18/黑匣22/及别的单元(下文中统称‘置信组元18’)实施对数字内容的密码功能，包括检验凭证24和其与各个实体联系的链接26以便鉴定这些实体，包括保证每个检验过的凭证24不会被撤销，或换个说法，对于权利被保护的内容12的播放不会不可靠。凭证24的撤销须经过相关签署的、且将凭证24列入的撤销单的建立、传布和实施。经签署的这种撤销单被递送到置信组元18，当检验凭证24时就会参照它。经由撤销单确定了凭证24已被撤销，只要该撤销单是由有权撤销此凭证24的实体所发出，置信组元18将不再用此已被撤销的凭证24执行任何操作。
现有技术中，凭证24只能由发出它的实体来撤销。凭证撤销系统的现有技术的一个例子已由美国专利(No.5699431，1997年12月16日发)所陈述，全文引为参考。在本发明的一个实施例，DRM系统10默认此种作法。就是说，只有由凭证24的发证者签署并发出的撤销单才能撤销凭证24。因为该发证者可由其公共密钥(PU-ISSUER)来认定，撤销单和被撤销的凭证24二者都得由密钥(PU-ISSUER)发出，而由相应的私人密钥(PR-ISSUER)签署。
除了这种默认的作法之外，现在转到图3本发明的一个实施例，凭证24可以给一个或几个被允许撤销此凭证的实体明显指定一个公共密钥(图3中的PU-REVOKER1、PU-REVOKER2、PU-ISSUER)。此处有权撤销凭证24的当局是由凭证发证者对各个被指定的撤销实体来委派的。注意对于委派这种当局，发证者可以保留也可不保留它自己作为凭证24的撤证当局。只有在撤销单是由指定的撤销实体所发出(PU-REVOKER1、PU-REVOKER2、或PU-ISSUER)而且是由相应的私人密钥所签署(PR-REVOKER1、PR-REVOKER2、PR-ISSUER)的情况下，该撤销单才能撤销这个凭证24，除非在另一种情况，凭证24不指定撤销实体，于是默认发证者用密钥(PU-ISSUER)发出的撤销单有效。
此外，除规定一个或几个撤销实体外，在本发明的一个实施例中，凭证24还可规定每当凭证24被使用时要撤销它必须满足的撤销条件28。因为撤销条件28构成了凭证24的一部分，条件28已被确立为置信的DRM组元18须实施的政策。可以理解，这种撤销条件28除了别的作用外还规定了从每个撤销实体可以下载撤销单30的地址，及新颖性条件，它指明撤销单30的最大有效期，在该有效期后必须下载其新版本。当用户用规定了撤销条件28的凭证24向其计算装置14上的置信组元18请求播放内容12时，置信组元18必须得到满足撤销条件28的撤销单30。如果撤销单尚未得到，或者这个单子30并不满足条件28的要求，就不能用凭证24来实现播放的请求。
现在就可认识到，因为凭证24可写得对规定的密钥(PU-REVOKER)委派了撤证当局，内容12的发布者同时发出一个相应的许可证16，他可联系于此许可证16用一个撤销单30来决定一些不可靠的凭证24，使之不得用于播放此内容12。于是在本发明的一个实施例中，联系于特定凭证24的撤销单30，至少在该特定凭证24使用范围内，可指定任何别的凭证24为无效(即开除其使用)，而无论该撤销单30是来自该特定凭证24的发证者或者来自一个委派的撤证当局。
综上所述，在本发明中，发证者在发出特定的凭证24时可把该凭证写得只能被发证者自己来撤销，或只能被一个或几个委派的撤证当局来撤销，或能被发证者自己或者一个或几个委派的撤证当局来撤销。从而可想象这类凭证24的撤销可能由于列在了特定凭证24发证者发出的撤销单30上，或者可能由于列在了由特定凭证24所认定的委派的撤证当局发出的撤销单30上。
对应地，如果为特定凭证24的撤销单30，不论它是来自凭证发证者或者来自委派的撤证当局，列举了任何别的凭证24，这类别的凭证24就被从该特定凭证24联系的应用中开除了。然而别的这类被开除的凭证24并未被撤销，因为只有这类被开除的凭证24的发证者或其委派的撤证当局才真正能够撤销这类被开除的凭证24。注意，撤销和开除不仅适用于主要或末端实体凭证24诸如对应于用户、单元、一件内容简介2、一个许可证16的那些凭证，也对应于在伴随前述几个主要凭证24中任何一个的多个凭证24的链26上的任何凭证24。最后要注意，撤销和开除是由用户计算装置14上的置信组元18来实施的，它是由发证者的信托来进行此任务的。
以下陈述只能被委派的撤证当局撤销的凭证24的一部分<BODY>
<ISSUER>
<PUBLICKEY>
<ALGORITHM>RSA</ALGORITHM>
<PARAMETER name＝”public-exponent”>
<VALUE encoding＝”integer32”>65537<NALUE>
</PARAM ETER>
<PARAMETER name＝”modulus”>
<VALUE encoding＝”base64”size＝”1024”>91p...
</VALUE>
</PARAMETER>
</PUBLICKEY>
</ISSUER>
<CONDITIONLIST>
<REFRESH>
<DISTRIBUTIONPOINT>
<OBJECTtype＝”Revocation”>
</OBJECT>
<PUBLICKEY>
<ALGORITHM>RSA</ALGORITHM>
<PARAMETER name＝”public-exponent”>
<VALUE encoding＝”integer32”>65537</VALUE>
</PARAMETER>
<PARAMETER name＝”modulus”>
<VALUE encoding＝”base64”size＝”1024”>25q...
</VALUE>
</PARAMETER>
</PUBLICKEY>
</DISTRIBUTIONPOINT>
<INTERVALTIME/>
</REFRESH>
</CONDITIONLIST>
</BODY>
可以理解，这种凭证24只能被与条件单28里REFRESH条件相联系建立的公共密钥撤销，而那并非ISSUER的公共密钥，因此属于委派的撤证当局。以及此处空的INTERVALTIME条件规定了不需撤销单30。事实上，凭证24并未提供必须从之得到撤销单30的地址。该REFRESH条件仅仅指明什么实体能撤销凭证24，而并未真的要置信组元18从该实体取回撤销单30来考虑凭证24。然而，一些别的凭证24如要求撤销单30，而这撤销单是被REFRESH条件里指定的公共密钥所对应的私人密钥签署的，则该撤销单是能够撤销上述凭证24的。
下面显示一个凭证24也能被多个委派的撤证当局所撤销<BODY>
<ISSUER>
<PUBLICKEY>
<VALUE>
AAA
</VALUE>
</PUBLICKEY>
</ISSUER>
<CONDITIONLIST>
<REFRESH>
<OBJECTtype＝”Revocation”>
</OBJECT>
<DISTRIBUTIONPOINT>
<PUBLICKEY>
<VALUE>
AAA</VALUE>
</PUBLICKEY>
</DISTRIBUTIONPOINT>
<DISTRIBUTIONPOINT>
<PUBLICKEY>
<VALUE>
BBB</VALUE>
</PUBLICKEY>
</DISTRIBUTIONPOINT>
<INTERVALTIME/>
</REFRESH>
</CONDITIONLIST>
</BODY>
可以理解，凭证24的不值得注意的部分已被去掉或压缩。此处，发证者用公共密钥AAA，或委派的撤证当局用公共密钥BBB，二者都可撤销此凭证24。现在该理解到，要使凭证24不能被撤销，只能在REFRESH撤销条件中不列出任何公共密钥。
下列凭证24要求从特定地址(http//server/revocation list.xml)得到撤销单30，该撤销单30是由特定的公共密钥的所有者签署的，此处撤销单的新颖性小于14天<CONDITIONLIST>
<REFRESH>
<DISTRIBUTIONPOINT>
<OBJECT type＝”Revocation”>
<ADDRESS type＝”url”>http//server/revocation_list.xml</ADDRESS>
</OBJECT>
<PUBLICKEY>
<VALUE encoding＝”base64”size＝”1024”>ugi...
</VALUE>
</PUBLICKEY>
</DISTRIBUTIONPOINT>
<INTERVALTIME days＝”14”/>
</REFRESH>
</CONDITIONLIST>
撤销单30的一个例子如下<？xml version＝”1.0”？>
<RevocationList>
<BODY>
<ISSUEDTIME>2001-11-01T0807</ISSUEDTIME>
<DESCRIPTOR>
<OBJECTtype＝”Revocation-List”>
</OBJECT>
</DESCRIPTOR>
<ISSUER>
<OBJECTtype＝”Corporation”>
<NAME>ABC Corporation</NAME>
<ADDRESS type＝”URL”>abct.com</ADDRESS>
</OBJECT>
<PUBLICKEY>
<VALUE>CCC</VALUE>
</PUBLICKEY></ISSUER><REVOCATIONLIST>
<！--revoke a principal by key-->
<REVOKE category＝”principal”type＝”principal-key”>
<PUBLICKEY>
<VALUE>DDD</VALUE>
</PUBLICKEY>
</REVOKE>
<！--revoke a license by id-->
<REVOKE category＝”license”type＝”license-id”>
<OBJ ECT>
<GUID>EEE</GUID>
</OBJECT>
</REVOKE>
<！--revoke a license by hash-->
<REVOKE category＝”license”type＝”license-hash”>
<HASH>FFF</HASH>
</REVOKE>
<！--revoke a license by issuer public key-->
<REVOKE category＝”license”type＝”issuer-key”>
<PUBLICKEY>
<VALUE>GGG</VALUE>
</PUBLICKEY>
</REVOKE>
<！--revoke by issuer id-->
<REVOKE category＝”license”type＝”issuer-id”>
<ID>HHH</ID>
</REVOKE>
<！--revoke content by content-id-->
<REVOKE category＝”content”type＝”content-id”>
<ID>III</ID>
</REVOKE>
<！--revoke a user by email address-->
<REVOKE category＝”user”type＝”email”>
<EMAIL>someuser@hotmail.com</EMAIL>
</OBJECT>
</REVOKE>
</REVOCATIONLIST>
</BODY>
<SIGNATURE>
...
</SIGNATURE>
</RevocationList>
注意撤销单30可能被嵌埋在凭证24例如许可证16中或来自发证者的别的文件中，虽然这种撤销单30也可分别发出。如是这样嵌埋的，那就可能是一种情况，用户请求许可证16，而嵌埋的撤销单30虽未专门请求却被附加到后面。尽管如此，还可专门请求撤销单30，这并不背离本发明的精神和范围。
将撤销单30，或在此情况下的许可证16(撤销单30是在其中找到的)，中的ISSUEDTIME与当前系统时间对比就能确定其新颖性。撤销单30的ISSUER就是执行撤销的实体。撤销单30只能用来撤销凭证24，它是ISSUER被允许撤销的。每个REVOKE结构根据类别、类型、和标识判据指定一个待撤销的凭证24或别的项目。每个REVOKE结构包含有信息可识别规定要撤销的项目，例如公共密钥DDD、带有GUID EEE的许可证16、带有无用数据FFF的许可证16、由具有公共密钥GGG的发证者或发证者ID HHH发出的任何许可证、具有内容ID III的内容、具有特定email地址的用户等等。
现应理解，在撤销单30中规定可能要开除的项目并不仅限于凭证24，也不仅可用公共密钥来识别。一种替代办法是，在撤销单30中的这种项目可包含任何可识别成分或‘主体’，这并未背离本发明的精神和范围。当然，现应理解，只有那些已被构成得能识别撤销单30的当局的主体才真的能被撤销单所撤销。出现在撤销单30上的所有别的主体只能被开除。
给定撤销单30应包含ISSUEDTIME，还应用私人密钥签署。为验证撤销单30上的签署，这种单子30也应伴随着一个凭证链26导回到置信的根当局。现应理解，单子30有权撤销任何被特别指定可用公共密钥撤销的项目，该公共密钥对应于签署凭证24私人签署密钥。
为了用本发明的一个实施例中一个交易的凭证24，该凭证24可能已有与它相联系的撤销单30，现转到图4，要检验凭证24以确定其中是否存在撤销条件28(步骤401)。假定这种条件28事实上确实存在其中，就检验条件28(步骤403)。例如，如果条件28之一规定了一个地址从那里该得到撤销单30，实际就从该地得到撤销单30(步骤405)，或者可保证从该地的来的撤销单30现已到此而且此当前的撤销单30的发出时间满足任何在凭证24所述的撤销条件28中规定了的新颖性条件(步骤407)。
类似地，如果诸条件28之一规定了撤销单30签署者的公共密钥，就要确定相应的撤销单30是否现已到此(步骤409)，如已到就要用该撤销单，假定该撤销单30的发出时间满足凭证24的条件28中规定了的任何新颖性条件(步骤411)。注意可能有这种情形，条件28之一要求得到一个特定的撤销单30，即使相应的条件28并没有规定对应该撤销单30的公共密钥。从而即使得到了撤销单30，却不能和所讨论的凭证24一起使用。相应地也可能有另一种情形，条件28之一规定了对应撤销单30的公共密钥，即使相应的条件28并没有要求得到该特定的撤销单30。如果该撤销单30现已到此，于是就不必去获得它，而可和所讨论的凭证24一起使用它。
注意与所讨论的凭证24使用在一起的交易可为任何不背离本发明的精神和范围的适当的交易。例如，该交易可关于播放内容12的请求，此处所讨论的凭证24为对应内容12的许可证16或者处于伴随该许可证的多个凭证24的链26中的一个。类似地，该交易可牵涉到对许可证16的请求，此处的请求包括从发证者收到所讨论的凭证24，或者作为对发证者的鉴定，或者作为伴随鉴定发证者的凭证24的多个凭证24的链的一部分。
还需注意，和该交易一起，别的一些凭证24也可能起作用，这些凭证可代表用户、计算装置14的操作系统、计算装置14本身等等，它们也形成一个链26。此外，用户采用特定的公共密钥，该机器具有一个ID，由特定公共密钥的所有者签署内容12等等，这些都可作为交易的一部分。应理解，虽然所讨论的凭证24的撤销单30只能撤销所讨论的这个凭证24，该撤销单30也可将单子30上所述的任何别的主体开除出该交易。也应理解，不论对一个交易必须的凭证24是否被撤销，或者不论对一个交易必须的任何主体是否被从交易中开除，该交易都被禁止了。
于是，仍参照图4，需考察凭证24牵涉到的每个撤销单30，以确定它上面是否有任何主体牵涉到该交易(步骤413)。如果有的话，就禁止置信组元18执行该交易(步骤415)。如果没有，允许进行该交易(步骤417)。当然，即使对所讨论的凭证的特定撤销单30允许该交易进行，还很可能遇到这种情形，对所讨论的凭证或者对另一个凭证24的另一个撤销单30阻止该交易的进行。因此，只有考查了对所有的凭证24的撤销单30之后，所有被考查的撤销单30都没禁止该交易，才允许该交易的进行。
结论虽然本发明在个人计算机之类的计算装置14上特别有用，在任何适当的装置上，例如服务器、智能电器、联网的便携式装置等，也可实施本发明，都不会背离本发明的精神和范围。所以，装置14应解释为包括任何具有DRM系统10或者参与DRM架构的适当的装置。
为贯彻本发明相关过程所须的编程是简明的，对相关的编程人员是显而易见的。所以就不在此附带这类程序。可用任何特殊编程来贯彻本发明而不会背离其精神和范围。
由以上描述可见，本发明所包含的新的有用的系统和方法，让置信组元18、黑匣22或任何别的查询实体，在鉴定和验证各凭证24过程中，可有效地获得并考察各撤销单30。应该理解，可对上述实施例作各种变动并不背离其中的发明概念。例如，虽然主要是用播放内容12来描述DRM系统，应该理解DRM系统10也可用于对内容12作任何种类的访问。因此该理解到，本发明并不限于所披露的特定实施例，而是要包括在本发明的精神和范围内的、由权利要求书所定义的各种修改。
权利要求
1.一种用于鉴定相应单元的数字凭证，该凭证由发证者发出并经计算装置的置信组元验证以便鉴定其相应单元，验证包括保证该凭证不被撤销，该凭证包括由该凭证的发证者委派的、对该凭证有权撤销它的一个实体的身份，该委派的撤证当局通过在撤销单中认定该凭证来撤销它；及关于可能撤销该凭证的至少一个撤销条件，在用该凭证来鉴定其相应单元时，必须满足每个撤销条件。
2.如权利要求1所述的凭证，其中委派的撤证当局的身份包括它的一个公共密钥，而其中来自委派的撤证当局的撤销单是由委派的撤证当局用跟它的上述公共密钥对应的私人密钥来数字签署的，且是可用该公共密钥来验证的。
3.如权利要求1所述的凭证，其特征在于，它包括多个委派的撤证当局的身份。
4.如权利要求1所述的凭证，其特征在于，撤销条件规定了须从那里得到撤销单的地址。
5.如权利要求4所述的凭证，其中委派的撤证当局的身份包括它的一个公共密钥，其中从撤销条件中规定的地址来的撤销单是来自委派的撤证当局，是由委派的撤证当局用跟它的上述公共密钥对应的私人密钥来数字签署的，而且是可用该公共密钥来验证的。
6.如权利要求4所述的凭证，其中委派的撤证当局的身份包括它的一个公共密钥，其中从撤销条件中规定的地址来的撤销单不是来自委派的撤证当局，不是由委派的撤证当局用跟它的上述公共密钥对应的私人密钥来数字签署的，而且不可用该公共密钥来验证的。
7.如权利要求1所述的凭证，其中的撤销条件规定了关于撤销单的新颖性的要求，该新颖性要求规定了撤销单可达到的最长使用期限，超过它就必须得到该撤销单的更新颖的一个版本。
8.如权利要求1所述的凭证与从撤销条件中规定的地址来的撤销单的组合，其中委派的撤证当局的身份包括它的一个公共密钥，而其中的撤销单是来自委派的撤证当局，是由委派的撤证当局用与它的上述公共密钥对应的私人密钥来数字签署的，而且是可用该公共密钥来验证的。
9.如权利要求8所述的凭证和撤销单，其中的撤销单规定了一个不可信的主体，在有关该凭证的应用中必须开除这个主体。
10.如权利要求9所述的凭证和撤销单，其中的撤销单规定了多个不可信的主体，在有关该凭证的应用中必须开除这些主体。
11.如权利要求9所述的凭证和撤销单，其中撤销单规定开除的主体为另一个凭证。
12.如权利要求9所述的凭证和撤销单，其中撤销单规定开除的主体选自一个组，包括公共密钥、用户、应用程序、操作系统、硬件、软件、内容、和数字许可证。
13.如权利要求1所述的凭证，其中认定的委派的撤证当局是发证者。
14.一种用于鉴定与计算装置上的单元对应的数字凭证所述的方法，该凭证由发证者发出并经计算装置的置信组元鉴定以便鉴定其相应单元，该方法包括下列步骤从一个凭证来确定由该凭证的发证者委派的、对该凭证有权撤销它的一个实体的身份，该委派的撤证当局通过在撤销单中认定该凭证来撤销它；从一个凭证来确定该从哪里得到撤销单的地址；从一个凭证来确定该施加到撤销单的任何新颖性要求；保证来自该地址的撤销单的存在，而且当前这个撤销单满足新颖性的要求；保证当前这个撤销单是由该凭证认定的委派的撤证当局所颁发；及保证该凭证在当前撤销单中不被认为该撤销。
15.如权利要求14所述的方法，其特征在于，保证撤销单的存在和当前这个撤销单满足新颖性要求的步骤包括从指定地址得到撤销单。
16.如权利要求14所述的方法，其特征在于，保证撤销单的存在和当前这个撤销单满足新颖性要求的步骤包括从指定地址得到的撤销单现已到此而且当前这个撤销单具有的发出时间满足新颖性的要求。
17.如权利要求14所述的方法，其中的撤销单是由委派的撤证当局用其私人密钥来数字签署的，签署所述的方法包括下列步骤从该凭证确定作为委派的撤证当局的身份的它的一个公共密钥，这是与它的私人密钥相对应的；及通过用委派的撤证当局的公共密钥来验证撤销单的签署，保证当前这个撤销单是由该凭证认定的委派的撤证当局所颁发。
18.如权利要求14所述的方法，其中的撤销单规定了一个不可信的主体，该方法进一步包括在有关该凭证的应用中保证开除这个不可信主体。
19.如权利要求18所述的方法，其中的撤销单规定了多个不可信的主体，该方法进一步包括在有关该凭证的应用中保证开除每个不可信主体。
20.如权利要求18所述的方法，其中的撤销单规定的一个不可信的主体为另一个凭证，该方法进一步包括在有关该凭证的应用中保证开除不可信的那另一个凭证。
21.如权利要求18所述的方法，其中的撤销单规定的一个不可信的主体选自一个组，包括公共密钥、用户、应用程序、操作系统、硬件、软件、内容、和另一个凭证的数字许可证，该方法进一步包括在有关该凭证的应用中保证开除这个不可信主体。
22.如权利要求14所述的方法，包括从该凭证确定作为委派的撤证当局的发证者的身份。
全文摘要
一个数字凭证能认定由发证者委派的某实体的身份，该实体为有权力撤销该凭证的当局。该凭证也至少有一个关于可能撤销它的撤销条件。为了鉴定一个凭证，需从该凭证确定认定委派的撤证当局的身份，该从那里得到撤销单的地址，以及有待施加到该撤销单的任何新颖性的要求。从而保证从该地来的撤销单已到，此当前的撤销单符合新颖性的要求，此当前的撤销单是由该凭证认定身份的、被委派的撤证当局所颁发，而且该凭证在此当前撤销单中经认定为不该被撤销。
文档编号G06F21/00GK1540915SQ20041000760
公开日2004年10月27日 申请日期2004年2月26日 优先权日2003年2月26日
发明者B·B·迪拉维, B B 迪拉维, P·J·拉弗那拉, 拉弗那拉, B·A·拉马恰, 拉马恰, R·U·马拉维亚拉齐, 马拉维亚拉齐, J·L·曼弗德利, 曼弗德利, C·F·罗斯三世, 罗斯三世 申请人:微软公司