CN101310472B

CN101310472B - 用以支持获信任环境的计算机可读组件的自动更新

Info

Publication number: CN101310472B
Application number: CN2006800262510A
Authority: CN
Inventors: A·A·舍瓦尼; P·帕尼阿莫希; R·A·德斯帕尼德; A·H·拉姆巴亚; R·J·昆恩; C·P·范德克
Original assignee: Microsoft Corp
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2005-07-19
Filing date: 2006-07-14
Publication date: 2011-12-07
Anticipated expiration: 2026-07-14
Also published as: JP5027807B2; CA2612631A1; BRPI0612865B1; US20070033652A1; CA2612631C; KR20080026132A; EP1905184A4; EP1905184B1; AU2006270273B2; EP1905184A2; KR101238572B1; WO2007011667A2; CN101310472A; WO2007011667A3; JP2009503648A; NO20076576L; US7590841B2; AU2006270273A1; BRPI0612865A2

Abstract

本自动更新机制提供了一种用于周期性地检查更新以支持获信任环境的方法。在周期检查期间，如果存在推荐更新，则从更新服务接收指示。在接收到该指示时，从更新服务下载新的撤销列表并将其保存为挂起撤销列表。然后，当受保护内容请求计算设备上比计算设备上的当前保护级别提供的保护更高级别的保护时，该挂起撤销列表可用于按需更新。

Description

用以支持获信任环境的计算机可读组件的自动更新

背景

在过去，不同类型的内容使用不同类型的介质来分发。例如，音乐被分发在压缩盘(CD)上并使用CD播放器来播放。电影被分发在VHS(家用视频***)带或DVD(数字多功能盘)上，并分别使用VCR(盒式磁带录像机)或DVD播放器来播放。CD播放器、VCR和DVD播放器被归类为针对特定类型的介质设计的消费电子设备。这些消费电子设备是其中无法加载附加软件的封闭***。因此，这些封闭***不允许对其内容未授权的复制。

然而，当前的计算设备通常在其中集成CD/DVD播放器(即，驱动器)以及其它媒体播放器。因而，这些计算设备可播放与消费电子设备可播放的相同的CD或DVD。另外，因为电子设备被设计成开放平台，所以可在这些计算设备上加载附加软件。此附加软件可允许对受版权保护的内容进行复制和/或经由因特网与他人共享该内容。因此，内容的所有者对是否允许计算设备播放他们的内容犹豫不决。

为了照顾内容所有者的顾虑，已设计了许多保护方案来保护在计算设备上处理的内容(在下文中称为数字媒体)以及将计算设备提升为数字媒体的安全播放器。一种保护方案是由美国电影协会(MPAA)授权的。这种保护方案使用称为内容加扰***(CCS)的加密算法来保护DVD的分发。DVD播放器被配备成对电影内容解密，但不复制或存储经解密的内容。然而，计算机黑客开发了一种对CSS解密的计算机程序。然后，该计算机程序被发布在因特网上。通过使用该计算机程序，在其计算设备中具备DVD驱动器的最终用户可对电影内容解密并以标准文件格式存储该内容。然后，可容易地与其它计算设备上的其他用户共享该文件，由此规避版权保护。

因为计算设备是开放***，所以某些个人不断试图“破坏”被设计成保护数字媒体的保护方案。为了继续保护数字媒体，这些保护方案需要不断更新。否则，将存在内容所有者将不允许特定内容在计算设备上处理的风险。持续更新和无法访问特定内容会对最终用户-甚至那些未执行任何非法动作的最终用户-产生影响。因此，需要一种当保护方案以某种方式被侵害时不会对无辜的最终用户产生不必要影响的机制。

概述

本更新机制提供了一种用于周期性地检查更新以支持获信任环境的方法。在周期检查期间，如果存在经推荐的更新，则从更新服务器接收到一指示。在接收该指示时，从更新服务器下载新的撤销列表，并将其保存为挂起(pending)撤销列表。然后，当受保护内容请求高于计算设备上的当前保护级别提供的保护的计算机设备上的保护级别时，挂起撤销列表可用于按需(on-demand)更新。

提供本概述来以简化形式引入在以下详细描述中进一步描述的概念精选。本概述并非旨在标识要求保护的主题的关键特征或本质特征，也非旨在用来帮助确定要求保护主题的范围。

附图的详细描述

参照以下附图描述非限制和非穷尽的实施例，其中同样附图标记在所有各个视图中指同样的部件，除非另外说明。

图1是可用于实现本文所述的自动更新技术和机制的说明性计算设备；

图2示出了本自动更新机制与其交互以保护处理如图1中所示的计算设备内的内容的示例性内容保护方案；

图3是由本自动更新机制使用的全局撤销列表的示例性格式的图形表示；

图4是全局撤销列表的另一实施例的图形表示；

图5是可用在本自动更新机制中以向希望处理受保护内容的媒体应用程序提供统一的应用程序设计接口集合的示例性接口；

图6是示出了用于获得获信任环境的示例性按需自动更新进程的流程图；

图7是示出了适于用在图6中所示的按需进程中的用于更新新的全局撤销列表的示例性进程的流程图；

图8是示出了适于用在图6中所示的按需进程中的用于续展(renew)计算机可读组件的示例性进程的流程图；

图9是示出了用于在图1中所示的计算设备上执行对获信任环境更新的周期进程的示例性进程的流程图；

图10是用于定位全局撤销列表更新和续展组件的示例性机制；

图11是实现周期进程的示例性架构的框图。

详细描述

以下描述涉及一种用于更新计算机可读组件以支持内容保护方案的自动更新机制。自动更新机制平衡了最终用户的易用需要与内容提供商的内容保护需要。自动更新机制基于信任结合内容保护方案来操作。通过使组件遵从内容策略以确保它们不执行任何超出由内容提供商所准许的动作以外的动作、以及创建针对内容所有者的受保护内容的恶意访问进行保护的环境来建立信任。然后，自动更新机制撤销对曾担保的计算机可读组件的信任并尝试自动重建经撤销的计算机可读组件的可信度。其中自动更新机制执行其功能的方式防止最终用户在延长时间段内继续利用保护方案的漏洞，尤其对于发现该利用并修补漏洞之后所发布的内容。这在对以合法方式使用其数字媒体的最终用户造成最小影响的情况下来实现。现在将描述运行在各种计算环境中的自动更新概念的具体实现。

图1是可用于实现本文所述的自动更新技术和机制的说明性计算设备。***包括诸如计算机设备100的计算设备。在极为基本的配置中，计算设备100通常包括至少一个处理单元102和***存储器104。取决于计算设备的确切配置和类型，***存储器104可以是易失性(诸如RAM)、非易失性(诸如ROM、闪存等)或两者的某种组合。***存储器104通常保护操作***106、一个或多个程序模块108，并且可包括程序数据110。对于本自动更新机制，操作***106包括用于实现内容保护方案的一个或多个组件140和用于实现自动更新机制的一个或多个组件142。如以下将描述的，自动更新机制在执行其功能时与内容保护方案交互。在图1中通过虚线112内的那些组件示出这种基本配置。

计算设备100可具有附加特征和功能。例如，计算设备100还可包括附加数据存储设备(可移动和/或不可移动)，比如磁盘、光盘或磁带。在图1中通过可移动存储120和不可移动存储122示出这些附加存储。计算机存储介质包括以任何方法或技术实现用于存储诸如计算机可读指令、数据结构、程序模块或其它数据的信息的易失性和非易失性、可移动和不可移动介质。***存储器104、可移动存储120和不可移动存储122均是计算机存储介质的示例。因而，计算机存储介质包括但不限于：RAM、ROM、EEPROM、闪存或其它存储器技术、CD-ROM、数字多功能盘(DVD)或其它光盘存储器、磁带盒、磁带、磁盘存储器或其它磁存储设备、或者可被用来存储所需信息并可由计算机100访问的任何其它介质。任何这种计算机存储介质可以是设备100的一部分。计算设备100还可具有诸如键盘、鼠标、笔、语音输入设备、触摸输入设备等的输入设备124。还可包括诸如显示器、扬声器、打印机等的输出设备126。这些设备在本领域中是众所周知的，并且在此不进一步讨论。

计算设备100还可包含允许设备与其它计算设备130诸如经由网络通信的通信连接128。通信连接128是通信介质的一个示例。通信介质通常可体现为诸如载波或其它传送机制的调制数据信号中的计算机可读指令、数据结构、程序模块或者其它数据，并且包括任何信息传输介质。术语“已调制数据信号”是指以在信号中编码信息的方式设置或改变其特性中的一个或多个的信号。作为示例而非限制，通信介质包括诸如有线网络或直接线连接的有线介质、以及诸如声学、RF、红外线和其它无线介质的无线介质。计算机可读介质可以是任何可由计算机访问的可用介质。作为示例而非限制，计算机可读介质可包括“计算机存储介质”和“通信介质”。

此处可在由一个或多个计算机或其它设备执行的诸如程序模块的计算机可执行指令的通用环境中描述各个模块和技术。一般，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等。这些程序模块等可作为本机代码执行，或可被下载并在诸如虚拟机或其它运行时编译执行环境中执行。通常，在各个实施例中，程序模块的功能可按需组合或分布。这些模块和技术的实现可在多种形式的计算机可读介质上存储或传播。

图2示出了本自动更新机制可与其交互以保护在图1中所示的计算设备内处理的内容的内容保护方案的一个实施例。总言之，本自动更新机制与基于能访问内容的计算机可读组件的可信度对该内容实施其安全的任何内容保护方案交互。内容保护方案的不同实施例可以不同的方式建立对计算机可读组件的信任。在一个实施例中，信任可基于其中“获信任”二进制码由“获信任”授权机构来签署的代码签署技术。一旦建立信任，本自动更新机制操作成撤销对不担保该信任的计算机可读组件的信任。另外，自动更新机制尝试重建经撤销的计算机可读组件的信任。在进行这些时，本自动更新机制与内容保护方案交互。以下讨论描述内容保护方案的一个实施例，然后描述此内容保护方案与该自动更新机制之间的交互。

如上所述，图2示出了内容保护方案的一个实施例。内容保护方案提供其中可按其相关联的许可协定来处理数字媒体的受保护环境。该受保护环境尝试通过限制运行在***上的软件组件对访问正被处理的受保护内容的能力、通过限制对存储器和执行空间访问等来阻挡试图违反许可协定的攻击。因而，可强制实施限制可在其上处理内容的计算设备的数量、限制内容可被播放的次数、限制内容可被复制的次数等的许可协定。因为内容保护方案尝试向数字媒体提供受保护环境，所以术语受保护环境还用来指该保护方案。

总言之，受保护环境对防止试图违反许可协定的外部攻击提供了一堵“墙”。受保护环境包括图1中所示的***存储器104的用户模式存储器空间200和内核模式存储器空间202中的媒体组件。媒体组件被配置成处理需要被保护的内容(例如受保护内容)。因而，媒体应用程序仅需要提供远程控制(例如对CD-ROM的播放、倒带、暂停、写入)功能而非直接处理该受保护内容。受保护环境还提供对可访问该受保护内容的经签署的第三方组件的支持。

为了实现这些，受保护环境提供在用户模式受保护进程220内执行的媒体流水线222。受保护进程220与其中媒体应用程序212执行的***进程210分开。更具体地，在这些进程(例如***进程210和其它进程230)中执行的软件可能不能访问受保护进程220。媒体应用程序212可处理无需受保护的内容。然而，如果媒体应用程序212尝试处理受保护内容，则媒体应用程序与媒体流水线222交互以处理受保护内容。如果受保护环境意识到计算机可读组件需要更新，则使用内容启用器接口228。简言之，在以下结合图5的详细描述中，内容启用器接口封装执行用于处理受保护内容的动作之一(例如更新撤销列表、获得许可等)所需的信息。媒体流水线222执行对受保护内容的处理。

另外，受保护环境包括内核模式组件PEAuth 242。总言之，PEAuth 242负责检查所加载的组件的每一个(例如bad.exe 232、其它plugin.dll 214和badDriver.sys244)是否为获信任组件。如果内核模式中的组件之一未获得信任(例如badDriver.sys 244)，PEAuth 242将不允许受保护内容被处理。

PEAuth 242可基于其相关联的签署二进制码、关于签署二进制码的证书、全局撤销列表(未示出)等来确定计算机可读组件是否获得信任。如果计算机可读组件通过该检查，则PEAuth 242允许计算机可读组件加载。然而，如果计算机可读组件未通过该检查，则PEAuth 242向媒体应用程序提供状态。该状态经由接口228来提供。然后，应用程序被配置成向最终用户提供与该状态有关的用户接口。媒体应用程序还经由接口228请求更新。无论何时受保护进程被创建以及无论何时组件被加载到受保护进程中，都通知PEAuth 242。当PEAuth处于加载计算机可读组件的进程中时，PEAuth检查与该计算机可读组件相关联的文件，以便查看该文件是否在全局撤销列表列为被撤销的。

另外，可检查组件自身以查看其是否被列在全局撤销列表中。如果组件在全局撤销列表内被撤销，则执行用于续展该组件的进程，如以下结合图8所述的。简言之，在以下结合图3的详细描述中，全局撤销列表标识未获信任的项目(例如组件、证书)。对哪些项目要被包括在全局撤销列表内的判断可由个体团队来执行。此团队负责分析从受保护内容所有者、因特网和/或其它源接收到的信息。基于这些信息，该团队确定可疑的项目是否侵害了受保护环境以及确定其如何侵害该受保护环境。然后，在将在以下结合图3描述的全局撤销列表中反映此分析的结果。

图3是由本自动更新机制使用的全局撤销列表的示例性格式300的图形表示。通常，该全局撤销列表允许以防止篡改(tamper-proof)、易于更新的方式来存储信任信息。在一个实施例中，格式300包括若干区段：核心区段302、可扩展区段304、续展区段306和签名区段308。可对区段302-308的排列优化以提供高效的查找。例如，可将核心区段302组织成使得信息中不被打断，并且可对核心区段排序。这使得内核组件能够将核心区段302直接加载到存储器中。因而，内核组件无需在能够使用信息之前解析该信息。全局撤销列表可由证书授权机构来数字签署以便确保其真实性。格式300是全局撤销列表的一个示例格式。其它格式可具有较多或较少的区段以及其它相应子区段。另外，其它格式可进行不同的安排。

核心区段302包括若干子区段：头部310、内核组件的撤销列表320、用户模式组件的撤销列表322、证书的撤销列表324、以及获信任根列表326。现在将更详细地描述这些子区段中的每一个。

头部310可包括版本号312、强制重新引导参数314、进程重新启动参数316和时间参数318。该时间参数318存储全局撤销列表被创建的时间。版本号312指定全局撤销列表(GRL)的版本号。每次发布新的全局撤销列表时，该版本号312都被更改。版本号312用于确保处理受保护内容的计算***遵守针对受保护内容而设置的限制。例如，计算***可使用全局撤销列表的版本#5来查看照片。然而，如果同一计算***现在期望播放按次计费(Pay-Per-View)的电影，则该按次计费电影(即，受保护内容)可指定计算设备使用至少全局撤销列表的版本#8。用于更新计算设备以及使该计算设备在版本#8下获得信任的进程将在以下结合图6-10来描述。

强制重新引导参数314由自动更新机制使用以最小化版本更新对计算设备上的最终用户的影响。这通过使用强制重新引导参数314指示对该版本的撤销列表320-324的任何添加是否撤销在被加载之后隐藏其自身的组件来实现。例如，组件可通过将自己从“加载模块”列表移除或通过将代码***另一模块然后卸载自己来隐藏其自身。因而，“隐藏”指扫描技术无法检测所加载的该组件。如果新的全局撤销列表不撤销尝试隐藏自身的任何组件，则自动更新机制可更新该撤销列表而无需重新引导该计算设备。在更新该撤销列表之后，可向自动更新机制保证计算设备信任状态现在处于新版本下。在此情形中，如果未检测到撤销列表320-324之一中所列出的组件之一(即，未被隐藏)，则可向自动更新机制保证该组件未被加载。

然而，如果新的全局撤销列表确实撤销尝试一旦加载就隐藏自身的一组件，则自动更新机制甚至在重新续展之后还可能无法确定该隐藏组件是否仍未被加载。因此，检测隐藏组件需要重新引导。如果隐藏自身的组件是用户模式组件，则在重新引导之后阻止加载该组件。然而，如果该组件是内核模式组件，则该组件将被加载，但是受保护环境将不允许受保护内容被处理。

因为撤销列表320-324中所列出的许多撤销撤销了因未正确实现特征而意外引起侵害的组件，所以强制重新引导参数314最小化计算设备需要被重新引导的次数。这大大地最小化了对计算设备上的最终用户的负面影响。

在一个实施例中，强制重新引导参数314被实现为计数器。每当全局撤销列表撤销试图隐藏自身的组件时，该计数器即被更新。使用计数器作为强制重新引导参数在其中计算设备已跳过全局撤销列表若干版本的情形中是有益的。例如，计算设备当前可能使用全局撤销列表的版本#3。然而，当其尝试处理特定受保护内容时，与该受保护内容相关联的信任协定可指定：只有其使用全局撤销列表的版本#10，该计算设备才可处理该受保护内容。如果强制重新引导参数314使用是/否(yes/no)指示符来实现，则计算设备可能无法在版本#10的级别下建立信任。如果针对强制重新引导参数314，一个或多个版本(版本#4-#9)被指定为“是”，而版本#10被指定为“否”，则会发生这种情况。在不了解其它全局撤销列表中的强制重新引导参数314的情况下，自动更新机制可能不会认识到需要重新引导。在未重新引导的情况下，受保护环境将仍加载经撤销的组件。通过使用计数器，可易于将新的全局撤销列表中的计数器的值与先前的全局撤销列表中的计数器的值作比较。然后，如果计数器不同，则自动更新机制可强制进行重新引导。

重新启动参数316可由自动更新机制使用以进一步最小化版本更新对计算设备上的最终用户的影响。撤销列表320-324中所标识的组件可被分类为三类：1)非恶意组件；2)恶意用户模式组件；以及3)恶意内核模式组件。第一类-非恶意组件-通常由于无法安全地实现组件内的特征而偶然出现。因此，这些类型的组件通常不尝试隐藏它们自己。第二类和第三类专门被编写来违反与某种类型的受保护内容相关联的信任协定。因为这些类型的组件是恶意的，所以它们通常试图在被加载之后隐藏它们自身。

重新启动参数316可结合强制重新引导参数314来使用，以标识是否需要重新引导、是否需要重新启动受保护进程或者是否需要组件的续展，从而在新的全局撤销列表的级别下建立信任。对于第一类中的组件，自动更新机制可通过续展当前被加载的任何经撤销的组件来满足新全局撤销列表的需要。对于第二类中的组件，自动更新机制可通过重新启动每个受保护进程来满足新的全局撤销列表的需要。因为经撤销的恶意用户模式组件处于受保护进程中，所以一旦受保护进程被杀死(kill)，恶意用户模式组件也被有效地杀死。当受保护进程被重新启动时，将防止加载更新后的全局撤销列表中所列出的恶意用户模式组件。对于第三类中的组件，自动更新机制可通过如上针对强制重新引导参数314所述地重新引导计算设备来满足新的全局撤销列表的需要。

在一个实施例中，重新启动参数316可被实现为计数器并结合强制重新引导参数316来使用。例如，如果强制重新引导参数指示无需重新引导计算设备，则可将重新启动参数316与老的重新启动参数作比较，以确定是否需要重新启动受保护进程。这允许最终用户继续运行无需受保护进程的其它应用程序(例如文字处理程序、游戏等)，而该受保护进程被重新启动。这有效地最小化对最终用户的影响，同时仍维持用于运行于计算设备上的受保护内容的信任级别。

内核组件的撤销列表320、用户模式组件的撤销列表322和证书的撤销列表324是类似的。撤销列表包括标识要撤销的项目的条目。项目可以是文件、各个计算机可读组件或证书。文件可以是其中存储有若干计算机可读组件的动态链接库(DLL)或可执行(.EXE)文件。项目使用诸如要撤销的用户模式或内核模式二进制码的散列、或要撤销的证书的公钥的散列的唯一标识符来标识。有趣的是，全局撤销列表中被指定为撤销的项目可仍在受保护环境外使用。全局撤销列表中对组件的标识仅影响其在受保护环境中作为获信任组件的状态。

如果项目标识证书，则可撤销由该证书授权机构证明的任何计算机可读组件。另外，也可撤销使用直达所标识的证书的信任链中的一证书来证明的任何计算机可读组件。信任链继续直至在根授权机构停止。这防止黑客使用已受损害的证书授权机构来签署恶意计算机可读组件。

获信任根区段326标识可发起信任链的根授权机构。因此，如果计算机可读组件通过未被列为获信任根的根授权机构来鉴别，则PEAuth将不加载该组件。这防止黑客创建签署恶意计算机可读组件的根授权机构。

在区段320-322中已被撤销的项目的条目通常在相应的续展区段330-332中具有续展条目。该续展条目包括续展全局唯一标识符(GUID)。在一个实施例中，续展GUID可指定类别标识符。每个子区段中的续展条目可按散列值来排序。用于续展组件的示例性进程可结合图8在以下进行描述。

可扩展区段304可包含用于与下游组件建立信任的可扩展撤销信息。扩展GUID标识每个可扩展条目。可扩展区段304可按扩展GUID来排序。

签名340存储头部310和核心数据区段320-326的签名。签名342存储头部310和可扩展区段304的签名。签名340和342用于验证全局撤销列表内的相应区段未被篡改。通过获信任实体来签署签名。签署直达预定获信任根的证书根的全局撤销列表在验证期间可用。预定获信任根可在验证逻辑内硬编码。续展条目无需签署。如果某些人对续展区段306进行篡改，则计算设备将无法获得该续展。然而，这种失败将不会对受保护环境或对计算设备引起任何安全问题。如果发生这种情况，则新的全局撤销列表将如以下结合图7所述地来获得。

以下是全局撤销列表(GRL_HEADER)、全局撤销列表中的每个条目(GRL_ENTRY)、可扩展区段中的每个条目(GRL_EXTENSIBLE_ENTRY)、续展区段中的每个条目(GRL_RENEWAL_ENTRY)以及签名(BIN_SIGN)的示例性句法：

typedef struct_GRL_HEADER{

WCHAR wszIdentifier[6]；

WORD wFormatMajor；

WORD wFormatMinor；

FILETIME CreationTime；

DWORD dwSequenceNumber；

DWORD dwForceRebootVersion；

DWORD dwForceProcessRestartVersion；

DWORD cbRevocationsSectionOffset；

DWORD cRevokedKernelBinaries；

DWORD cRevokedUserBinaries；

DWORD cRevokedCertificates；

DWORD cTrustedRoots；

DWORD cbExtensibleSectionOffset；

DWORD cRevokedKernelBinaryRenewals；

DWORD cRevokedUserBinaryRenewals；

DWORD cRevokedCertificateRenewals；

DWORD cbSignatureCoreOffet；

DWORD cbSignatureExtOffset；

}GRL_HEADER；

typedef struct_GRL_ENTRY{

BYTE rgbGRLEntry[GRL_HASH_SIZE]；

}GRL_BNTRY；

typedef struct_GRL_EXTENSIBLE_ENTRY{

GUID guidExtensionID；

BYTE rgbExtensibleEntry[GRL_EXT_ENTRY_SIZE]；

}GRL_EXTENSIBLE_ENTRY；

typedef struct_GRL_RENEWAL_ENTRY{

GRL_ENTRY GRLEntry；

GUID guidRenewalID；

}GRL_RENEWAL_ENTRY；

typedef struct_BIN_SIGN{

DWORD dwSignFormat；

DWORD dwSignSize；

BYTE rgbSignature[1]；

}BIN_SIGN；

应当理解，针对全局撤销列表所述的示例性格式可随时间而变化。当发生这种情况时，现有组件将认识到存在新的格式并适度失败(fail gracefully)。然后，受保护环境可获取被配置成读取新的全局撤销列表格式的更新后的格式读取器。

图4是全局撤销列表的另一实施例的图形表示。如上所述，为了对所有计算设备维护安全级别，一旦计算机可读组件或证书在全局撤销列表中列出，该组件或证书通常保留在全局撤销列表中。因而，单个文件可能变得过大而不易处理。因此，可预想这个文件可被分成多个文件。

图4是多个文件全局撤销列表的一个实施例的图示。每一文件402、404和406维护以上在图3中所述的示例性格式。此外，在链接列表实现中，每个文件402、404和406包含指向下一文件的指针(即，NextGRL)和指向前一文件的指针(即，PrevGRL)。当最后文件406到达特定大小时，可添加其它多部分文件(multi-partfile)。在此实施例中，一旦计算设备已下载了多部分文件402、404和406，则当存在全局撤销列表的新版本时，仅需要下载最后文件(即，多部分文件406)。取决于撤销和续展的数量，这可实质上增加下载全局撤销列表的性能。然而，具有多文件全局撤销列表可使续展进程较低效，尤其是加载全局撤销列表的进程。

本自动更新进程可在两种不同情况中执行。第一情况是在媒体应用程序尝试处理受保护内容时的按需进程。第二情况是以预定间隔调度的周期更新进程。在描述按需和周期自动更新进程之前，描述用在本自动更新机制中的一个示例性接口。图5是可用在本自动更新机制中以向希望处理受保护内容的媒体应用程序提供统一的应用程序编程接口集合的示例性接口500。该统一API集合有助于媒体应用程序的开发。例如，统一API集合使得媒体应用程序的用户接口对各种不同情况-诸如更新全局撤销列表、续展组件、弹出帮助网页等-保持统一。现在将描述API的每一个。

GetEnableType(获得启用类型)方法502由媒体应用程序调用并返回为其创建内容启用器500的情形所专用的一类型。在PeAuth 242进行检查以查看受保护环境是否可被信任之后，由图2中所示的媒体流水线222来创建内容启用器。如果环境不可被信任，则内容启用器500被创建并且由媒体流水线222来设置类型，该类型指示允许访问受保护内容需要什么。然后，媒体应用程序可基于返回的类型在用户接口上显示串。

GetEnableURL(获得启用URL)方法504由媒体应用程序来调用，以获得统一资源定位符(URL)。然后，媒体应用程序可启动web浏览器以导航至所指定的统一资源定位符。媒体应用程序可执行对统一资源定位符的HTTP POST请求。GetEnableURL方法504包括三个参数：pwszURL 510、pcchURL 522、pTrustStatus524。参数pwszURL 510是指向由调用程序分配的数组的指针。参数pcchURL 522指定该数组的长度。调用程序将参数pcchURL 522初始化成由参数pwszURL 510所指向的数组的大小。参数pTrustStatus 524向媒体应用程序通知URL是否来自获信任源。媒体应用程序调用GetEnableURL方法504两次。第一次是为获得要分配的数组的长度，而第二次则使用所分配的数组和大小。在内容启用器无法自动执行基于所指定的类型所需的动作时，可使用GetEnableURL方法505。

GetEnableData(获得启用数据)方法506由媒体应用程序来调用以返回伴随在GetEnableURL方法504中执行的HTTP POST请求的数据。GetEnableData方法506包括两个参数：参数pbData 530和参数pcbData 532。参数pbData 530指向由调用程序分配的数组。如果由参数pcbData 532指示的数组的大小是足够的，则内容启用器对象使用POST数据来填充该数组。媒体应用程序调用GetEnableData方法506两次。第一次将参数pbData设置成NULL以便获得要分配的数组的大小。第二次使用所分配的数组及其大小。这使得媒体应用程序能够获得附加数据，诸如撤销组件的发布者、撤销组件的版本等。

IsAutomaticSupported(是否支持自动)方法508由媒体应用程序来调用以确定内容启用器对象是否可自动执行所指定类型所需的动作。如果内容启用器可独自执行所需的操作，则内容启用器将参数pfAutomatic 540设置为真(TRUE)。或者，如果需要媒体应用程序进行所需操作的任何部分，则内容启用器将参数pfAutomatic 540设置成假(FALSE)。例如，如果内容启用器被初始化成通过更新服务获得更新，则将pfAutomatic 540设置成真指示内容启用器应当在内部处理与该更新服务的交互，从而使最终用户在交互期间不会被不必要地打扰。如果内容启用器被初始化成经网页获得更新，则将pfAutomatic 540设置成假指示内容启用器将向应用程序展示网页URL，从而该媒体应用程序可打开浏览器窗口并导航至指定的URL。

Enable(启用)方法510由媒体应用程序调用，以自动地执行专用于内容启用器对象类型的操作。一旦最终用户授权媒体应用程序执行用户接口中呈现的操作，就由媒体应用程序调用Enable方法508。

如果媒体应用程序希望在操作完成时被通知和/或希望接收目前的状态，则由媒体应用程序调用MonitorEnable方法512。内容启用器将MEEnablerCompleted事件在其IMFMediaEventGenerator接口上排队。

Cancel(取消)方法514由媒体应用程序调用以取消挂起操作。

通过经由这些接口抽象化操作，媒体应用程序可编写通用代码来处理用于获得获信任环境的各个步骤。另外，将来内容可自动地***在媒体应用程序下，只要该将来内容的需求可在此接口内抽象化。现在使用来自MICROSOFT(微软)WINDOWS更新软件的API来描述内容启用器的一个示例性调用序列。安装会话通过调用IUpdateSession来创建。更新搜索器对象通过调用IUpdateSession::CreateUpdateSearcher来创建。然后，更新搜索器对象用于通过调用IUpdateSearcher::Search来搜索由GUID标识的更新。下载对象然后通过调用IupdateSession::CreateUpdateDownloder来创建。具体更新可通过将搜索结果传递给IUpdateDownloader来下载。这些更新可通过调用IUpdateDownloader::Download来下载到计算设备。安装对象通过调用IUpdateSession::CreateUpdateInstaller来创建。在调用IUpdateInstaller::Install时，可传递所下载的要安装的更新的集合。然后，安装方法将更新安装在计算设备上。

图6是示出了用于获得获信任环境的示例性按需自动更新进程的流程图。总言之，受保护环境在允许受保护内容被处理之前确保该环境是获信任的。在框602开始按需进程600，其中媒体应用程序正尝试处理受保护内容。在判定框604继续进行处理。

在判定框604，作出是否存在已加载的未获信任的内核组件的判定。这可能在如果未经签署的内核模式组件被安装在计算设备上时发生。因为未获信任的内核组件可能潜在地访问计算设备上的任何内容，包括受保护内容，所以在处理受保护内容之前处理该未获信任的内核组件。如果存在已加载的未获信任的内核组件，则在判定框605继续进行处理。否则，在判定框610继续进行处理。

在判定框605，由媒体应用程序向最终用户呈现用户接口。如果最终用户未授权进程600来处理未获信任组件，则在框624继续进行处理。否则，在框606继续进行处理。

在框606，处理未获信任的内核组件。可卸载该未获信任的内核组件或使用经签署的版本来更新。卸载指令可经由网站上的帮助页面来获得。已更新的经签署版本可使用更新服务、下载中心、属于组件的发布者的第三方站点来获得。如果未获信任的内核组件已被撤销，则撤销该未获信任内核的全局撤销列表条目将标识包标识符。然后，向更新服务请求此包标识符。然而，如果全局撤销列表未标识未获信任内核组件的包标识符或未在全局撤销列表中标识未获信任内核组件，则可使用一链接机制来确定如何处理该未获信任内核组件。以下将结合图10描述链接机制的一个实施例。然后，该链接机制可指定包标识符、其中可下载新版本的网页、描述卸载指令的网页等。用于处理未获信任内核组件的进程使用以上图5中所述的统一API集合。

在进行了这些之后，进程继续到判定框608，其中进行检查以确定未获信任内核组件是否被成功处理。如果未获信任内核组件被成功处理，则在判定框610继续进行处理。否则，在框624继续进行处理。

在判定框610，作出当前全局撤销列表是否是未获信任的判定。这可在如果该全局撤销列表比所保护内容所指定的版本旧、如果发生对全局撤销列表的篡改等情况时发生。如果全局撤销列表未获信任，则在框611继续进行处理。否则，在判定框616继续进行处理。

在判定框611，由媒体应用程序向最终用户呈现用户接口。如果最终用户未授权进程600更新全局撤销列表，则在框624继续进行处理。否则，在框612继续进行处理。

在框612，全局撤销列表被更新。简言之，在结合图5和7的详细描述中，当前全局撤销列表使用可用的所指定的版本或高于所指定的版本的版本来替代。在尝试更新全局撤销列表之后，作出检查(判定框614)以确定该全局撤销列表的更新是否成功。如果成功，则在判定框616继续进行处理。否则，在框624继续进行处理。

在判定框616，作出是否撤销组件的判定。简言之，在结合图5和8的详细描述中，一旦最终用户授权媒体应用程序来获得新(即，更新后)组件，则媒体应用程序经由统一API可自动续展组件而无需最终用户的进一步干涉。在下文中，更新后组件还被称为续展组件。在过去，向最终用户发送组件需要更新并随后重试的通知。这对于需要更新的每个组件都将如此进行。相反，根据本自动更新机制，一旦最终用户授权媒体应用程序处理内容，则所需组件的每一个被自动更新而无需任何进一步的用户干涉。如果存在被撤销的组件，则在框618继续进行处理。否则，在框622继续进行处理。虽然未示出，但是进程600可具有用以更新在全局撤销列表中被标识经撤销的每个所需的组件的循环或者其它逻辑。

在框618，续展被标识为经撤销的一个或多个组件。简言之，在以下结合图5和8的详细描述，组件的续展在与最终用户的最小交互的情况下进行。在续展成功时，最终用户将在受保护内容开始无缝处理之前经历短暂延迟。在尝试续展组件之后，作出检查(判定框620)以确定经撤销组件是否被成功续展。如果它们被成功续展，则在框622继续进行处理以允许媒体应用程序处理受保护内容。否则，在框624继续进行处理。

在框624，向媒体应用程序发送警报以使媒体应用程序了解为何不能处理受保护内容。然后，处理进行到结束。

图7是用于更新图1中所示的计算设备上的新的全局撤销列表的示例性进程700的流程图。进程700从框702开始，其中受保护环境检查全局撤销列表所请求的版本或更高版本是否已在之前下载。如以下结合图9所述的，周期自动更新进程可被配置成周期性地下载新的全局撤销列表。新近下载的全局撤销列表可被保存在计算设备上作为挂起全局撤销列表之一。检查这些挂起全局撤销列表以查看全局撤销列表的新版本是否已被下载。然后，处理前进到判定框704。

在判定框704，作出所请求的全局撤销列表或全局撤销列表的更高版本是否在计算设备上已经可用的判定。另外，对挂起全局撤销列表，作出全局撤销列表是否与受保护内容一起打包的检查。如果所需的全局撤销列表不可用，则在框706继续进行处理。否则，在判定框708继续进行处理。

在框706，获得所请求的全局撤销列表或更高(版本)的全局请求列表。内容启用器对象被创建并使用全局撤销列表的标识符来初始化。受保护环境内的选项指定全局撤销列表是被更新至所请求版本还是被更新到全局撤销列表的最高版本。使用所请求版本进行更新是有益的，因为在进行升级之后，几乎肯定允许处理受保护内容。使用全局撤销列表的较高版本可能会导致受保护内容无法工作，但向内容所有者提供最大的安全性。它还最小化全局撤销列表需要更新的次数。媒体应用程序可调用以上结合图5所述的一个或多个统一API。例如，如果“AUTOMATIC(自动)”被启用，则调用启用方法510将自动安装由全局撤销列表内的标识符标识的全局撤销列表。如果标识符指定包标识符，则该标识符被发送到更新服务以获得全局撤销列表。如果标识符指定唯一URL，则该URL可导航至下载中心、帮助网页等。在一个实施例中，自动安装可经由MICROSOFT(微软)

WINDOWS

更新软件来实现。对于此实施例，当发布新的全局撤销列表时，全局撤销列表被上传到诸如媒体续展的指定类别内的更新服务。指定类别可基于标识符对全局撤销列表的不同版本排序。因而，当选择获得全局撤销列表的最高版本的选项时，更新服务下载所上传的最新的全局撤销列表。在一个实施例中，上传到更新服务的全局撤销列表将包含最新的全局撤销列表。在另一实施例中，全局撤销列表设置包可主宿在下载中心。下载中心接受命令行参数，并使用命令行参数来安装全局撤销列表的相应版本。即使全局撤销列表设置包可包含多个全局撤销列表，但可基于命令行选项来选择一个全局撤销列表进行安装。在判定框708继续进行处理。

在判定框708，审阅强制重新引导参数以确定是否需要重新引导。在一个实施例中，参照当前全局撤销列表中的强制重新引导参数来审阅新的全局撤销列表的强制重新引导。如果比较不同，则在框710继续进行处理。否则，在判定框714继续进行处理。

在框710，续展媒体应用程序所需的、并已被撤销的组件。以下结合图8描述续展进程。在续展了组件之后，在框712继续进行处理。

在框712，新的全局撤销列表被保存为当前全局撤销列表，并且计算设备进行重新引导。在重新引导之后，在加载组件时，PEAuth使用新的全局撤销列表。处理完成。

在判定框714，作出新的全局撤销列表是否指定重新启动受保护进程的判定。此判定可基于新的全局撤销列表和当前全局撤销列表中的进程重新启动参数。如果进程重新启动参数不同，则在框716继续进行处理。否则，处理完成。

在框716，续展媒体应用程序所需的、并已被撤销的组件。以下结合图8描述续展进程。在续展了组件之后，在框718继续进行处理。

在框718，重新启动受保护进程。如上所说明的，重新启动受保护进程杀死了受保护进程内的恶意用户模式组件。然后，当重新启动受保护进程时，防止加载新的全局撤销列表中所列出的用户模式组件。然后，用于更新全局撤销列表的进程700完成。

图8是示出了用于续展适用于图6中所示的按需自动更新进程的计算机可读组件的示例性进程800的流程图。对媒体应用程序所需的、在全局撤销列表中标识为已撤销的组件中的每一个执行进程800。然而，可仅向最终用户呈现询问用户是否希望执行自动更新的用户接口一次。进程800从框802开始，其中检查挂起续展组件以确定所需续展组件是否已被下载和安装。简言之，在以下结合图9所示的描述中，挂起续展组件可能之前已由周期自动更新进程下载。在判定框804继续进行处理。

在判定框804，作出经撤销组件是否已可用的判决。如果经撤销组件之前已下载，则在框814继续进行处理。否则，在框806继续进行处理。

在框806，针对经撤销组件创建内容启用器对象。内容启用器对象由媒体流水线组件222来创建。内容启用器对象使用经撤销组件的标识符来初始化。该标识符可以是与经撤销组件相关联的散列或该经撤销组件的证书。对于经撤销证书，内容启用器使用该证书的公钥的散列以及正被撤销的组件的文件名来初始化。然后，链接机制可基于散列和/或证书来重定向。链接机制可具有针对由经撤销证书签署的每个组件的单独条目。在框808继续进行处理。

在框808，调用内容启用器对象的启用方法。在媒体流水线组件222将内容启用器对象传递给媒体应用程序之后，由媒体应用程序212来执行该调用。如上结合图5所述，媒体应用程序还可使用其它统一API以按需获得附加信息。内容启用器对象中的标识符标识更新服务上可用的续展包。在框810继续进行处理。

在框810，更新对象被创建并发送到更新服务。内容启用器对象的启用方法负责创建更新对象。更新对象包括经撤销组件的标识符。当更新服务接收到更新对象时，它在其包中搜索具有指定标识符的包。以上结合图5描述了一个示例性调用序列。在框812继续进行处理。

在框812，媒体应用程序经由启用方法接收续展组件。在框814继续进行处理。

在框814，存储在计算设备上的经撤销组件使用续展组件来替代。这可能需要使用续展组件来重写经撤销组件。在框816继续进行处理。

在框816，加载续展组件，使得媒体应用程序可使用该组件来进行其处理。然后，用于续展组件的进程800完成。如上所述，针对媒体应用程序所需的、并已被撤销的每个组件执行进程800。

图9是示出了用于更新获信任环境的示例性周期进程900的流程图。在一个实施例中，周期进程900可使用诸如由华盛顿州雷德蒙市的微软公司制造的MICROSOFT(微软)

WINDOWS

更新软件的现有软件更新机制。进程900于框902开始，其中接收预定事件以发信号通知应当针对对获信任环境的更新执行检查。预定事件可被指定为特定时间、特定动作(例如，启动)等。在预定事件之前，客户端服务中与软件更新机制相关联的选项被配置成对周期进程的自动更新行为进行控制。例如，选项可指定成：1)自动下载和安装最新的全局撤销列表以及列表内所标识的所有续展组件；2)下载最新的全局撤销列表和所标识的续展组件，但等待安装；3)发送新的全局撤销列表和/或续展组件可用于下载的通知但不下载或安装它们；或4)关闭周期续展。可向以上所标识的选项添加其它选项。如上所说明的，续展组件的续展包被上传到配置成提供软件更新机制的服务器。一般，周期更新的续展包与按需更新的续展包是一样的。然而，在全局撤销列表的情况中，两个包可不同。周期更新包将新的全局撤销列表安装到临时位置，而按需更新包使用更新后的撤销列表替代当前全局撤销列表。在框904继续进行处理。

在框904，计算设备上的客户端服务连接到被配置成实现软件更新服务的更新服务器。通常，此连接经由因特网进行。客户端服务和更新服务根据所指定的选项来彼此通信。在判定框906继续进行处理。

在判定框906，客户端服务向服务器发送查看该服务器是否具有可用的新的全局撤销列表的请求。在使用MICROSOFT(微软)

WINDOWS更新软件的实施例中，最新的全局撤销列表可作为推荐更新来发布。如果最新的全局撤销列表之前已被下载，则在判定框912继续进行处理。否则，在框908继续进行处理。

在框908，基于所指定的选项，客户端服务执行所需动作。如果选择选项4(发送通知)，则客户端服务发送显示在计算设备上的通知。该通知使得最终用户能够指定是忽略更新、下载和安装还是仅下载。下载选项需要将续展包作为文件复制到存储设备上。安装选项需要将续展包解包成各个项目(即，指定GRL、指定组件)。通常，客户端服务使用默认选项1来安装，该选项对最终用户造成较少的干扰。假设选择选项1，则最新的全局撤销列表被推行到计算设备上。然后，客户端服务调用计算设备上的获信任安装程序来安装最新的全局撤销列表。在框910继续进行处理。

在框910，最新的全局撤销列表被保存为挂起全局撤销列表。因为在更新新全局撤销列表时可能需要重新引导计算设备，所以新的全局撤销列表被保存而不使用该新的全局撤销列表来更新该计算设备。新的全局撤销列表不被激活，直至最终用户尝试处理请求较新的全局撤销列表而非当前活动的全局撤销列表的某些受保护内容。计算设备可设置成具有一个挂起全局撤销列表和一个活动全局撤销列表。使用此设置，当前挂起全局撤销列表使用推行到计算设备的最新全局撤销列表来替代。在另一实施例中，计算设备可设置成维护预定数量的挂起全局撤销列表。使用此设置，推行到计算设备的最新全局撤销列表被添加作为另一挂起全局撤销列表。期望将挂起全局撤销列表存储到计算设备上计算设备的所有用户能够读写访问的位置中。这使得非管理员具有按需更新全局撤销列表的能力。通过将新近下载的全局撤销列表保存为挂起撤销列表来替代自动更新全局撤销列表的版本，用户将不具有无法处理先前可处理的受保护内容的令人遗憾的体验。因此，最终用户不必被麻烦。在框912继续进行处理。

在判定框912，作出是否应当下载续展组件的判决。如果选择不下载续展组件的选项，则处理完成。否则，在框914继续进行处理。

在框914，客户端服务发送对具有与最新全局撤销列表相关联的续展组件的最近包的请求。在框916继续进行处理。

在框916，计算设备接收所标识的包。在框918继续进行处理。

在框918，已下载的续展组件在存储中被保存为可由计算设备访问的挂起组件。然后，PEAuth可在执行图7中所示的按需进程时加载这些续展的计算机可读组件而无需下载计算机可读组件。然后，处理完成。

图11是实现周期进程的示例性架构的框图。该示例性架构包括经由因特网1104连接的服务器1102和计算设备100。服务器1102包括用于更新后的经撤销组件的版本和新近发布的全局撤销列表的服务器更新服务1110和存储1112。计算设备100包括自动更新服务1120和安装程序1122。自动更新服务与服务器更新服务通信以获得所标识的组件。然后，使用安装程序1122将所标识的组件安装在计算设备上作为挂起组件1124。

图6-9中所执行的处理使用图3中所述的全局撤销列表。然而，处理还可使用其它撤销列表格式来执行。例如，数字权限媒体(DRM)应用程序使用卡蒂亚(Cardea)样式组件撤销列表和App(应用程序)组件撤销列表。对于这些其它格式，本自动更新机制可结合链接机制。链接机制被配置成使标识符与其中更新后组件可被下载或新的撤销列表可被下载的统一资源定位符(URL)相关联。图10示出了用于关联标识符与URL的一个示例性链接机制。在这些其它媒体应用程序中，它们的查找***不支持本自动更新机制所需的信息类型。因此，内容启用器API被配置成接收任何类型的标识符，并区分它是与更新服务、第三方网站还是与帮助页面相关联。使用这些其它撤销列表的媒体应用程序包括调用本自动更新机制的代码。然后，代替传递GUID，媒体应用程序传递其自身类型的标识符，诸如散列或公钥。媒体流水线使用标识符构建FWLINK。然后，该进程经由链接机制查找唯一标识符以获得相关联URL。表1000示出了链接机制的一个实施例。表1000包括两列：标识符列1002和URL列1004。一般，标识符唯一地标识组件或撤销列表。标识符包括支持FWLINK机制1008的网站URL部分1006。标识符还包括链接id 1012或散列1010以便与唯一组件或撤销列表相关联。URL列1004存储其中可安装所标识组件、可获得帮助指令等的网站的URL。如果URL包括GUID＝{someguid(一些guid)}作为查询串参数，则自动更新机制尝试使用指定GUID经由更新服务来定位。如果组件不位于更新服务上，则自动更新机制向最终用户显示URL。然后，FWLINK数据库确保经由更新服务可用的组件的URL配有作为任选参数的GUID。在一个实施例中，特定全局撤销列表可使用查询串参数来指定。然后，填充链接机制，使得FWLINK指向一GUID，该GUID表示使用第二查询串参数指定的全局撤销列表版本的设置包。在操作中，当内容启用器对象使用全局撤销列表散列(即，固定串)来初始化时，使用查询串参数来指定全局撤销列表的版本。当内容启用器执行FWLINK操作时，其检测指定了一GUID的链接。然后，内容启用器使用更新服务来下载并安装具有该GUID的组件。

虽然已示出并描述了示例实施例和应用，但是应当理解，本发明并不限于上述精确配置和资源。对于本领域技术人员而言，可在本文所公开的实施例的配置、操作和细节作出各种更改、改变和变化而不背离所要求保护的本发明的范围。

Claims

1.一种计算机实现方法，包括：

周期性检查新的撤销列表是否已在更新服务上发布；

在周期检查期间，当从所述更新服务接收对存在用于所述新的撤销列表的推荐更新的指示时，下载所述新的撤销列表并将所述新的撤销列表保存为挂起撤销列表来替代自动更新撤销列表的版本，当受保护内容请求计算设备上比所述计算设备上的当前保护级别提供的保护更高级别的保护时，所述挂起撤销列表用于按需更新。

2.如权利要求1所述的计算机实现方法，其特征在于，当所述计算设备被重新引导时，进行周期性的检查。

3.如权利要求1所述的计算机实现方法，其特征在于，所述新的撤销列表替代当前挂起撤销列表。

4.如权利要求1所述的计算机实现方法，其特征在于，所述挂起撤销列表被保存为之前已下载的多个挂起撤销列表之一。

5.如权利要求1所述的计算机实现方法，其特征在于，所述更新服务包括

更新服务。

6.如权利要求1所述的计算机实现方法，其特征在于，还包括在接收到所述指示时，下载在所述新的撤销列表内列为经撤销组件的每个组件的更新后版本。

7.如权利要求6所述的计算机实现方法，其特征在于，所述撤销列表包括卡蒂亚样式的证明撤销列表CRL，并且每个经撤销组件使用证书散列来标识，所述证书散列用于标识所述更新服务上用以下载所述更新后版本的位置。

8.如权利要求6所述的计算机实现方法，其特征在于，所述撤销列表包括应用程序App证明撤销列表CRL，并且每个经撤销组件使用公钥来标识，所述公钥用于标识所述更新服务上用以下载所述更新后版本的位置。

9.如权利要求6所述的计算机实现方法，其特征在于，所述经撤销组件由GUID来标识，所述GUID用于标识所述更新服务上用以安装所述更新后版本的位置。

10.如权利要求6所述的计算机实现方法，其特征在于，所述经撤销组件由所述经撤销组件的散列来标识。

11.如权利要求6所述的计算机实现方法，其特征在于，所述经撤销组件由所述经撤销组件的证书来标识。

12.如权利要求1所述的计算机实现方法，其特征在于，所述更新服务提供与媒体应用程序相关联的类别，并且在所述类别内发布新的撤销列表。

13.如权利要求12所述的计算机实现方法，其特征在于，在所述类别内发布多个包，每个包与所述新的撤销列表之一相关联，并且包括所述相关联撤销列表中列为经撤销的组件的更新后版本。

14.一种计算机实现方法，包括：

经由网络周期性地检查新的撤销列表是否已在更新服务上发布；

在从所述更新服务下载所述新的撤销列表之后将所述新的撤销列表安装在计算设备上；以及

将所安装的新的撤销列表存储为挂起撤销列表来替代自动更新撤销列表的版本，如果受保护内容的处理要求一保护级别，则所述挂起撤销列表用于将计算设备更新至由所述新的撤销列表指定的所述保护级别。

15.如权利要求14所述的计算机实现方法，其特征在于，所述更新服务包括

更新服务。

16.如权利要求14所述的计算机实现方法，其特征在于，还包括将所安装的新的撤销列表存储为多个挂起撤销列表之一，所述挂起撤销列表用于将计算设备更新至相应的保护级别。

17.一种计算机实现***，包括：

用于经由网络周期性地检查新的撤销列表是否已在更新服务上发布的装置；

用于在从所述更新服务下载所述新的撤销列表之后将所述新的撤销列表安装在计算设备上的装置；以及

用于将所安装的新的撤销列表存储为挂起撤销列表来替代自动更新撤销列表的版本的装置，如果受保护内容的处理要求一保护级别，则所述挂起撤销列表用于将计算设备更新至由所述新的撤销列表指定的所述保护级别。