确保软件更新仅在特定设备或设备类上安装或运行

摘要

所描述的是一种系统和方法，其中，设备制造商或软件映象提供商控制哪些设备被允许安装或运行软件映象。一种映象加密钥机制使用包数据和与该设备或设备类相关联的UUID来对映象加密钥。由于UUID在密钥中使用，安装程序核实器和/或引导时核实器可确保该设备被授权来安装和/或运行该映象。任一包，包括现有设备包和向其要求安装的包，可要求实施加密钥。安装程序机制检查该设备是否被允许安装该映象。引导时实施机制通过在要求的密钥无效或丢失时暂停引导过程来防止操作不正确地安装的映象。

说明书

相关申请的参照

本发明要求2003年12月16日提交的美国临时专利申请序列号60/530,126的优先权，该申请整体结合于此。

本发明涉及以下与本发明一起提交的美国专利申请，这些申请整体结合于此：

摘要号4271/307,649，“以故障保险方式向非易失存储应用自定义软件映象更新(Applying Custom Software Image Updates To Non-Volatile Storage in a FailsafeManner)”；

摘要号4281/307,650，“确定对安装有效的最大依赖软件更新组(Determing theMaximal Set of Dependent Software Updates Valid for Installation)”：

摘要号4301/307,652，“自描述软件映象更新组件(Self-Describing SoftwareImage Update Components)”；

摘要号4311/307,663，“以存储技术抽象方式在文件内创建文件系统(CreatingFile Systems Within a File In a Storage Technology-Abstracted Manner)”。

技术领域

本发明一般涉及计算设备，尤其涉及更新计算设备的非易失存储。

背景技术

诸如个人数字助理、当代移动电话和手持式及袖珍计算机等移动计算设备正在变为重要且流行的用户工具。一般而言，它们变得足够小，使得它们极度方便，而消耗较少的电池功率，且在一时变得能够运行更强大的应用程序。

在制造这类设备的过程中，嵌入式操作系统映象通常被内建到每一设备的单块映象文件中，并储存在非易失存储中(如，NAND或NOR闪存、硬盘等等)。作为结果，更新这一设备有时是必需或期望的。注意，更新设备的持久应用程序映象不同于通常在计算设备上安装应用程序的方式，应用程序储存在用户可访问文件系统中，并与用户数据混合。

然而，某些制造商希望能够控制对其设备软件更新的访问(以及对连同设备一起出厂的初始映象的访问)。其原因是一个制造商可能不希望在其设备上安装另一制造商的更新映象。有些制造商希望能够向愿意为映象的某些更新或新映象付费的顾客收费，而其它制造商不希望。有些制造商希望能够向愿意为映象的某些更新或新映象付费的顾客收费，因为这些新映象可包含新应用程序或特征(注意，“更新”可以是完整的应用程序或新特征)。

需要一种控制对初始映象和/或更新映象的访问的机制，但是以可以实现或不依赖于关于初始映象或更新的制造商的特定情况组的灵活方式。

发明内容

简言之，本发明针对一种制造商(或其它初始映象或更新映象提供商)控制允许哪些设备安装或运行映象的系统和方法。为此，本发明提供了一种映象加密钥机制，通过该机制，如果试图在不同于制造商(或其它更新提供商)指定的设备上安装初始组件或更新组件(加密钥的映象子组件，此处也成为包)，则该安装会失败。此外，即使通过某些其它装置，如通过硬件JTAG探针，将加密钥的映象应用到该设备，该软件也不会在非法的设备上运行。为此，没有正确的密钥口令，设备无法引导。注意，映象加密钥可应用到初始制造映象以及可更新包。

在一个实现中，基于包以及与设备相关联的全局唯一标识符(UUID)对包加密钥。UUID允许包对单个设备或设备类加密钥，取决于该UUID是对应于设备还是设备类。采用UUID，加密钥过程能够安全地将设备的UUID与映象相关联，使得安装程序核实器和/或引导时核实器可基于该UUID确保加密钥对该设备是适当的。安装程序和/或引导时核实器然后允许或禁止映象更新/引导，取决于该设备是否被授权用于该映象。

为对包加密钥，将设备的UUID传递到拥有该映象的服务器，服务器然后对UUID和与包相关的数据应用散列算法，然后签署结果。签名储存在映象的已知位置中，并将加密钥的映象提供给设备。

对于在安装或引导时要核实的加密钥的映象，安装代码或预引导代码被设计成检测未加密钥的任何映象，并在适当时暂停安装或设备引导。这可通过向映象并向用于在(如，提供商或制造商的)服务器上对映象加密钥的UUID应用同一编码算法来实现。

在一个实现中，映象的加密钥是可任选的，使得软件销售商和/或制造商可确定是否要对映象加密钥。为具有被可任选地加密钥的系统，该系统具有一种用于表示对在特定映象(或映象的一部分)上加密钥的要求的机制。对加密钥的映象的要求可来自同一包内，或来自同一设备的不同包内。注意，包的提供商可对包加密钥，或者制造商可对包加密钥，即使制造商不是该包的提供商。

在一个实现中，在散列中使用的包数据对应于在包安装之后在设备上维护的包的描述。包所附带的向系统描述该包的内容的清单文件通过在包内包括包标识符、版本号和文件列表，提供了用于散列的与包相关的数据。

一旦包被加密钥并在设备上获取，则设备确定它是否具有在安装的包上加密钥的要求。该要求可从包内形成，或可以是来自另一先前安装的包的要求。如果存在加密钥要求，则用于计算散列的算法被重新应用到包内容和设备UUID，并且将结果与在服务器上确定并储存在包内的结果相比较。如果结果一致，则认为密钥上的签名是有效的，并允许安装。

也可采用引导时实施机制，以确保映象不会通过不同于正常映象更新机制的手段，如通过硬件JTAG探针，或通过经由总线对闪存中的数据的物理操纵。而被恶意地更新。如果引导时检查过程发现密钥无效或丢失，则它暂停引导过程。

当结合附图阅读以下详细描述时，可以清楚其它优点，附图中：

附图说明

图1是一般表示可结合本发明的计算机系统的框图；

图2所示是依照本发明的一个方面为在特定设备上安装和操作而加密钥的包的框图；

图3所示是依照本发明的一个方面，用于基于对设备的正确密钥确定是否在该设备上安装加密钥的包的逻辑的流程图；

图4所示是依照本发明的一个方面，用于基于设备是否具有一个或多个加密钥的包确定是否引导设备的逻辑的流程图；以及

图5所示是依照本发明的一个方面信任链的概念的框图。

具体实施方式

示例性操作环境

图1示出了一个这样的手持式计算设备120的功能组件，包括处理器122、存储器124、显示屏126和键盘128(可以是物理或虚拟键盘，或表示两者)。可存在麦克风129以接收音频输入。存储器124一般包括易失存储器(如，RAM)和非易失存储器(如，ROM、PCMCIA卡等等)。操作系统130驻留在存储器124中，并在处理器122上执行，如微软公司的Windows^操作系统或另一操作系统。

一个或多个应用程序132被加载到存储器124中，并在操作系统130上运行。应用程序的示例包括电子邮件程序、调度程序、PIM(个人信息管理)程序、文字处理程序、电子表格程序、因特网浏览器程序等等。手持式个人计算机120也可包括加载到存储器124中的通知管理器134，它在处理器122上执行。通知管理器134处理如来自应用程序132的通知请求。同样，如下所述，手持式个人计算机120包括适用于将手持式个人计算机120连接到网络(包括作出电话呼叫)的网络软件136(如，硬件驱动程序等)和网络组件138(如，无线电和天线)。

手持式个人计算机120具有电源140，它被实现为一个或多个电池。电源140还可包括取代内置电池或对其重新充电的外部电源，如AC适配器或加电对接托架。

图1所示的示例性手持式个人计算机120被示出为具有三种类型的外部通知机制：一个或多个发光二极管(LED)142和音频生成器144。这些设备可直接耦合至电源140，使得当被激活时，即使手持式个人计算机处理器122或其它组件被关闭以保存电池能量时，它们也保留一段由通知机制指示的持续时间。LED 142较佳地不确定地保留，直到用户采取行动。注意，音频生成器144的当代版本使用当今手持式个人计算机电池的太多能量，因此它被配置成当系统的剩余部分工作时，或者在激活后的一段确定持续时间之后被关闭。

注意，尽管示出了基本手持式个人计算机，然而，为实现本发明的目的，实际上能够以可由程序使用的某一方式接收数据通信和处理数据的任何设备，如移动电话，都是等效的。

设备专用更新

本发明一般针对安装和/或更新储存在小型移动计算设备上的软件，这些设备如基于微软的Windows^CE的设备，包括在其中将初始软件或软件更新写入嵌入式设备的非易失存储，如闪存中的那些设备。尽管如此，本发明提供了在总体上计算的益处，并由此可应用到其它计算设备和其它类型的存储，包括各种类型的存储器和/或其它类型的存储媒质，如硬盘驱动器。为简化目的，术语“闪存”在后文对照设备的可更新存储，尽管可以理解，任一存储机制都是等效的。此外，术语“映象”一般包括初始软件安装映象以及对该映象的随后的软件更新的概念，即使仅更新该映象的一部分。

软件更新是可包含对某一软件组的完整更新，和/或仅对前一更新或映象的改变的自包含的、安全的实体。软件更新可包括可执行代码和数据。注意，为描述本发明的与加密钥相关的过程和机制的目的，初始制造映象和可更新映象组件(在产品售出之后实地安装)被同样地处理，并在后文被一般地称为“映象实体”，它可以是一个映象(用于整个映象)或映象子组件/包(用于映象的子组件)。

依照本发明的一个方面，提供了一种当通过常规装置试图安装时防止加密钥的软件映象被安装在未授权的设备上的映象加密钥方法和系统。此外，该方法和系统防止以某一其它方式(如，通过硬件窃用)安装的加密钥的软件运行在未授权的设备上。本发明可应用到初始制造映象以及可更新包。如可容易地理解的，加密钥允许设备制造商/OEM/软件销售商严格地控制被允许安装或运行初始制造映象和/或可更新包的设备的阵列。

如图2所一般表示的，映象中的包202(如，.CAB压缩文件)具有包括至少一个签名的签名数组204，它用于核实包202是对设备的有效映象(如，更新)。第二签名或口令(如果存在的话)是用于将该更新关联到特定设备的密钥206。该口令在本发明中一般被成为“密钥”。最初作出该包的提供商和具有关于该设备的密钥信息的实体(如，OEM)可对包加密钥。密钥206使用关于包和设备ID的信息来构造，如后文所描述的。

如上所述，加密钥过程依赖于唯一地标识对该影响要对其加密钥的设备的能力。为此，每一设备需要提供一全局唯一标识符(UUID)208。为正确地起作用，该UUID应当对所有可被在其上安装映象的设备组是由硬件生成的、永久的、确保为唯一的，并无法由其它机制设置。另外，设备需要在无论何时被要求时能够通过在设备上当请求时负责获取并提供UUID的系统软件返回同一UUID值。注意，设备通常已具有这一UUID，如设备ID，尽管应当注意，为安全原因，可能期望阻止设备ID能被未授权组件访问。

如所理解的，UUID 208允许包对应于小至每设备一个包的粒度来加密钥。然而，如期望，UUID可用于一类设备。例如，制造商可构建许多这样的设备用于单个顾客，并且UUID可应用到销售给该顾客的设备类，而非一个设备。例如，这可通过令该设备类共享UUID中的最高位，令最低位用于标识该类中的设备来实现。然后，仅每一UUID的最高位用作用于加密钥目的的(类)UUID。注意，当确定更新是否被允许时，检查机制可使用设备UUID和类UUID来确定是否允许更新。结果，与需要每一设备单独地请求加密钥的更新不同，制造商可允许单个加密钥的更新被安装到同一类的多个设备上。此处，为简化目的，UUID主要相对单个设备来描述，然而，如所理解的，对于令UUID在多个设备的类之间共享的情况，这一概念是等价的。

采用这一UUID，加密钥过程能够安全地将设备的UUID与映象相关联使得安装程序核实器和/或引导时核实器可确保加密钥对该设备的UUID是适当的。安装程序和/或引导时核实器然后允许或禁止(倘若预引导确认代码是硬件安全的，如后文参考信任链所描述的)映象更新/引导，取决于该设备是否被授权用于该映象。

对于在安装或引导时核实的加密钥的映象，安装代码210或预引导代码212被设计成检测未加密钥的任一映象，并在适当时暂停安装或设备引导。这可通过向映象和由映象的提供商使用的UUID应用同一编码算法，并通过核实该结果与如由提供商的服务器储存在映象中的密钥相匹配来实现。以这一方式，如果检测到未加密钥的映象或为另一设备加密钥的映象，则该映象将无法被初始安装，或者，如果绕过了安装过程，并且使用了诸如硬件JTAG探针等另一机制来闪存该映象，则该映象将无法运行。

在一个实现中，映象的加密钥是可任选的，使得软件销售商和/或制造商可确定是否要对映象加密钥。为具有可任选地加密钥的系统，该系统具有一种用于表示对在特定映象(或映象的一部分)上加密钥的要求的机制。对加密钥的映象的要求可来自同一映象内，或来自同一设备上的不同映象子组件内。注意，例如，这允许制造商即使在他不是映象的提供商时也能够对该映象加密钥。

加密钥签名可由映象的所有者或发出对加密钥的要求的实体签署。这一重复确保了生产在设备上的软件的另一实体能够要求对他们不控制的映象的密钥，但也确保了映象的所有者不丢失对其映象的更新控制。此外，如可容易理解的，在内部，销售商在构建系统内可同时担当创建者和OEM的角色。由此，例如，在映象离开构建实验室之前，构建实验室担当OEM并对构建加密钥。然后将包约束到它们对其加密钥的设备上，并且无法被闪存到另一设备上。除其它优点之外，这将防止日常构建的泄露。

为如按要求提供适当加密钥的映象，要加密钥的映象最初储存在服务器220上。通过安全机制，将设备的UUID传递到服务器，然后用于对映象加密钥。例如，设备所有者在请求更新时可安全地发送UUID，或者设备制造商可维护被授权来接收更新的UUID的内部数据库。由于采用了对敏感数据的其它受控访问，对服务器220的经验证的访问、UUID交换的安全性以及服务器的处理是确保加密钥过程安全并确保交换无法被欺骗的需求。

一旦服务器220获取了设备UUID，并能够访问映象20，在一个实现中，服务器向这两个实体应用一散列算法，以获取(如，通过串联)单个实体，它进而可被签署。这本质上可被表示为以下公式：

签署_密钥(散列(散列(包数据)|散列(设备ID)))。一旦从散列结果生成签名，将签名储存在映象内的已知位置中，然后，令加密钥的映象准备好被下载到设备。

散列中使用的包数据可基于包内容的实际散列，尽管如后文所描述的，包在安装之后不由设备保存，由此这会导致困难，并使加密钥机制易受欺骗的攻击。作为使用内容作为包数据的替代，在安装之后维护的包的描述是散列的更合乎需要的实体，在一个实现中，使用包描述来替代包内容。更具体地，如在上述名为“自描述软件映象更新组件”的相关专利申请中所描述的，映象可安排在包内用包所附带的并向系统描述包内容的清单文件230中。清单文件230包括包标识符、版本号和包内文件的列表。此外，清单文件230在包安装之后保留在设备上(如图2中由安装的清单文件230i所表示的)，这意味着即使包本身在安装之后被丢弃，也可在引导时获取其散列。结果，清单文件230担当用于在上述公式中散列(作为包数据)来表示包的很好的实体，它然后如上所述地与具有签署结果的设备UUID的散列相组合。

一旦添加了密钥，包被下载到设备。设备将确定它是否具有对在要安装的包上加密钥的要求，它可以是包内的要求，或者是来自先前安装的另一包的要求。也可以是来自在同一时刻安装的任一其它包的要求。如果存在加密钥要求，则将用于计算散列的同一算法重新应用到映象和设备UUID，并将结果与在服务器上确定的并储存在包内的结果相比较。如果结果一致，则认为密钥上的签名有效。假定其它映象确认检查成功，(如，满足映象依赖性需求、映象是完整且正确的等等，如在上述名为“确定对安装有效的最大依赖软件更新组”的相关专利申请中所描述的)，则映象将被安装到设备上。

在安装时核实包被正确地添加了密码的一个益处是安装或更新可被取消。在安装之前取消更新为用户留下了一个可引导的设备。当然，设备不具备用户试图安装的更新，但是至少能够引导到其先前的状态。如可容易地理解的，如果仅通过仅在引导时检查正确的加密钥来实现保护，则诸如用户安装错误的更新等情形将导致向用户留下无法引导的设备，除非且直到它被刷新。

也可采用第二种实施机制。更具体地，检查映象的加密钥的过程也可在引导过程中应用，以确保映象不会被通过不同于正常映象更新机制来恶意地更新，如通过使用硬件JTAG探针或通过经由总线对闪存中的数据的物理操纵。注意，令核实在其它地方和某一其它时刻(如在对应于加密钥的包的每次程序引导之前)执行是可行的，然而，为简化目的，将参考引导时核实来解释该实施。

引导时检查过程需要预引导授权机构(如，在引导加载器内)被设计成确认一个或多个映象内的密钥(或多个密钥)(如由安装程序核实器所完成的)，并且如果发现密钥无效或丢失，则暂停引导过程。为防止硬件级攻击，预引导核实授权机构212也需要硬件是受保护的(如，在只读ROM中或其类似物)，使得它无法被替换/覆盖(由于ROM中的引导加载器可被黑客用对设备的硬件访问来替换)。这是后文所描述的信任链描述的一部分，并通过使用具有在CPU引导之前核实引导加载器上的签名的安全引导特征(如，类似于为移动电话所设计的)的CPU来实现。信任链确保通过在操作系统下运行的应用程序基于CPU的安全引导。

图2示出了一个示例存储器布局240，其中，包括代码232i、清单230i以及(可能)密钥信息文件234i(后文描述)的某些包版本V1的内容被安装到被称为ImageFS的系统分区236中。注意，在本示例实现中，包也可被安装到被称为NK区域或分区的另一内核分区中；分区一般在上述名为“以存储技术抽象方式在文件内创建文件系统”的相关专利申请中描述。

如图2所示，诸如包202等每一包可被加上密钥，即，具有关联的口令206，它如上所述地为设备ID的散列和包相关数据(如，包含包信息的清单文件)的散列。结果，不仅是约束到该设备的包，而且来自该包的密钥无法用于另一包，即使它们在同一设备上。

为实施加密钥保护，在安装或引导时，如服务器220一样，设备同样地散列包清单文件230i，并将该散列串接到UUID 208的散列。该结果被散列(如，用公钥签署)并用作口令。

在一个实现中，口令是PKCS7签名。构建并确认签名的证书链所必须的证书可在PKCS#7数据结构内找到。密钥签名需要用来对照签名的证书可储存在包的清单文件(在加密钥者是包的所有者的情况下)或密钥信息文件中(在加密钥者是要求加密钥的实体的情况下)。

为核实这是正确的文件类型，密钥信息文件234是包含仅可用于这一文件类型的魔法数字的二进制文件格式。密钥信息文件也包含结构的大小、要求计数、到公钥数组的索引以及证书的数量。在一个实现中，扫描数组中所有的密钥以找出加密钥的签名，它可以通过一未被验证属性来标识。

密钥信息文件是包含对设备上的任一包加密钥的要求的列表的系统文件。当将包安装到设备上时，枚举映象中的密钥信息文件。这包括在新包中的密钥信息文件234i，加上对应于先前安装的一个或多个其它包的当前映象中的任何密钥信息文件，如密钥信息文件238i加上来自要安装的包的组内的其它包的任何密钥要求。如果当前映象中的任一密钥信息文件或新的更新包上的密钥信息文件要求对该包加密钥，则需要对该包加密钥。结果，制造商可以要求对包加密钥，即使提供包的软件销售商不需要对该包加密钥。注意，不可能有冲突的加密钥需求，因为一个密钥信息文件只能要求对一个包加密钥，而不能要求不对包加密钥。例如，销售商无法包括要求从不对特定包加密钥的密钥信息文件。由此，包可由最初制造该包的实体加密钥，或由具有设备上的密钥信息的实体加密钥。

如图2所示，在一个名为wincertArray的实例中，签名保留在证书数组204的经签署的文件中。用于用密钥将包连接到设备的口令206包含具有受保护的属性的签名。该受保护的属性是已验证的属性(它是新的)。为确定包是否包含有效签名，枚举证书数组204，并检查数组中的每一元素的已验证属性206。如果找到该属性，则它是加密钥签名。

为确认每一签名，将证书数组中的口令206与来自表示必须对包202加密钥的密钥信息文件(如，234或238i)的证书相比较。公钥文件位于包清单内，包清单位于包内，或可附加到包本身。如果签名的任一个被确认并起作用，则将包202应用到该设备。如果没有签名被确认，则通过合适的用户界面对话框或其类似物向用户通知错误。

图3示出了当在设备上安装包时可被执行来核实加密钥信息的各种示例性步骤，它在步骤300开始，枚举密钥信息文件。步骤302评估是否存在要求对该包加密钥的任一密钥信息文件。如果不存在，则不需要额外的加密钥工作，过程结束，如由步骤304所表示的。否则，要求加密钥，并通过步骤306和308确认签名组(在证书阵列中)。如果在步骤310该组不包含任何有效的签名，则在步骤312，由于没有有效的密钥，包确认失败。

注意，在包(而非清单文件)用于散列计算一个替换实现中，签名以及包的散列需要在安装之后被保存，因为包(如，压缩的CAB文件)在安装之后不被保留。由此，如由可任选步骤314所示的，在该替换实现中，从新包提取有效签名，并通过将其写入系统的文件中来储存该签名。在该替换实现中，在核实特定包的加密钥信息并执行包更新之后，更新应用程序可将包的散列以纯文本写入与安装时的其它散列相同的文件中。当包散列不再可访问时，需要这一包加密钥信息文件(如，名为[GUID].pki)用于引导时核实。

密钥信息文件在更新过程中担当常规文件。更新中的密钥信息文件(或缺乏该文件)将替换原始在包内的所有内容。如果包最初未加密钥，并且包创建者或OEM决定对包加密钥，则可用包括要求对包加密钥的密钥信息文件的包来更新该包。也可用不包括密钥信息文件的包来更新包(具有声明要对包加密钥的密钥信息文件)。这意味着包不再要求它是加密钥的。然而，注意，这并不确保设备(对应于某一其它包)上没有要求对特定包加密钥的另一密钥信息文件。

依照本发明的一个方面，如上所述，在引导时也对照所有的密钥信息文件来核实要求加密钥的每一包的加密钥信息，如一般在图4的流程图中所表示的。在一个实现中，对任一密钥信息文件(步骤400)指示需要加密钥(步骤402和408)的每一包执行(步骤404)同一评估，即，获取清单文件和UUID的散列、签署该散列并将其与密钥相比较。如果比较对任一包都无效，则设备不引导(步骤406)，否则设备引导(步骤410)。

在设备清单文件不用于散列计算的一个替换实现中，回想在安装时，从新包提取签名并将作为文件其放入文件系统中。在这一情况下，除签名之外，还储存包的散列。需要储存签名用于引导时核实，即使包数据是清单文件的散列。在引导时，扫描密钥信息文件以确定需要对哪一包加密钥，然后扫描、打开包含提取的签名的对应文件，并核实签名内容。

注意，密钥信息文件也包含签名。仅当所有的事情都有效时设备才引导。此外，注意，为处理RAM阴影问题，在引导时打开密钥信息文件和签名，并检查文件属性。如果该文件不在ROM中或不是系统文件(在ImageFS中)，则引导核实机制将试图删除该文件。如果这一文件既不是系统文件也不在ROM中，而且无法被删除，则设备不引导。

信任链

如上所述，为真实的安全性，预引导确认程序需要是硬件安全的，否则，例如，硬件黑客可覆写确认程序。这一真实安全性依赖于具有安全引导特征的CPU，因为如果CPU安全地引导，可引导可信的程序代码。之后，信任链的概念可基于转移性的前提为其它组件提供这一核实机制。即，如果用户信任组件A，组件A信任组件B，组件B信任组件C，则用户可信任组件C。由此，采用本发明的组件，如果用户知道初始的程序加载器是可信的，且初始程序加载器可核实主引导记录和NK区域是可信的，并且NK区域(如，其中的安全加载器)核实其它组件是可信的，则用户可信任那些组件。

由此，在本发明中，信任链依赖于保护初始程序加载器，如图5中块502所表示的。为此，CPU可具有可确认初始程序加载器的签名的安全引导特征。如果签名无效，则设备不引导。这取决于CPU的安全引导特征。

CPU用于核实初始程序加载器上的签名的确切机制是CPU相关的，并可在各个制造商之间不同，但是作为规则，如果复位矢量处的代码不包含正确的签名，则CPU不引导。

如图5所示，初始程序加载器502包含被授权来签署映象更新中的已签署的组件的剩余部分，即主引导记录506、更新加载器代码508和NK代码510的根证书列表504。该列表中的根证书是可信的，因为它们包括在初始程序加载器映象502内，该映象由CPU本身核实。

根证书列表504应当包括用于核实NK分区中的销售商提供的包内的文件上的签名的操作系统销售商证书，以及用于核实主引导记录、更新加载器代码和保留区域上的签名的至少一个OEM提供的证书。为保护主引导记录506，初始程序加载器502使用以公钥签署的整个主引导记录506的散列来确认主引导记录506上的签名。

主引导记录506也可包含安全目录，其中，安全目录是在图5中结合进主引导记录506中的新结构(另外，安全目录也可在别处找到)。安全目录包含用于确认未被内部地签名的现有分区的签名数组。安全目录中的签名用于签署保留区域。

为保护更新加载器508，初始程序加载器502使用以公钥签署的整个UL的散列来确认更新加载器508上的签名(本质上以确认MBR的相同方式)。确认更新加载器508的另一选项是通过内部签名(如下文对NK分区所描述的)，例如，更新加载器508可包含一个分类表文件，它可包括UL更新加载器508中的每一文件。对于每一文件，计算散列并对照分类表文件中的散列来核实。分类表文件中的签名由根位于初始程序加载器502内的证书链来核实。

为保护NK分区，在控制从初始程序加载器502转移到NK分区中的内核之前，由初始程序加载器502确认NK分区。

如上所述，NK分区由包组成，每一包的清单文件包含指向包含经签署的文件名和散列的列表的单个分类表文件的指针。为保护NK分区，枚举每一清单文件和分类表。对于分类表中命名的每一文件，计算散列，并将其用于核实分类表中的散列。分类表文件中的签名由证书链核实；签名应当是支持证书链接的PKCS#7签名块。根证书需要必须在初始程序加载器根证书列表504中。然后，枚举NK分区中的文件，并且保护过程确认文件由分类表覆盖。如果签名的任一个不匹配，或存在未在分类表之一中列出的任何文件，则对分区的签名检查失败，设备不引导。

一旦控制从初始程序加载器502转移到内核，系统在内核的控制下运行。从这一点开始，为保护IMGFS分区512，基于信任链的过程依赖于作为安全加载器的一部分发生的签名确认，以及与安全加载器相关联且执行签名核实的证据生成器，签名核实包括核实对应于组成系统中的大部分模块的多流(multi-stream)rel merge模块的签名格式。

设备上定义的任何其它分区需要遵从这些安全检查，包括无线电和其它保留分区。更具体地，具有OEM专用分区(如，测试代码或无线电栈)的OEM需要令这些分区由签名来确认。保留分段的签名可在安全目录中找到，并且应当是PKCS#7签名块，并向上链接到初始程序加载器的根证书列表504中的根。

总结

如从以上详细描述可以见到的，提供了一种使用加密钥来控制对初始映象和/或更新映象的访问的机制。该机制是灵活的，并且通过应用到安装和引导时实施，无法被容易地击败。

尽管本发明易受各种修改和替换构造的影响，然而在附图中示出了某些说明的实施例并在上文详细描述了它们。然而应当理解，这并非将本发明限于所揭示的具体形式，而是相反，本发明覆盖落入本发明的精神和范围之内的所有修改、替换构造和等效技术方案。