CN103716797A - 执行wtru的确认的方法以及设备 - Google Patents

Abstract

本发明公开了一种执行WTRU的确认的方法以及设备。该方法包括：测量WTRU的至少一个预先指定组件的完整性测量；获取WTRU的组件的可信参考值；使用位于WTRU中的TrE执行组件的完整性检查，并存储完整性检查结果；完整性检查包括TrE比较完整性测量与组件的可信参考值；使用TrE在WTRU上执行安全启动检查，并存储安全启动检查结果；启动检查确定组件是否达到安全启动的状态，启动检查结果包括当组件没有达到安全启动的状态时的指示；使用TrE基于完整性检查结果和安全启动检查结果形成确认消息；使用TrE将确认消息从WTRU转发到PVE，PVE在WTRU外部。

Description

执行WTRU的确认的方法以及设备

本申请是申请号为201080010759.8、申请日为2010年03月05日、发明名称为“无线设备的平台确认和管理”的中国发明专利申请的分案申请。

相关申请的交叉引用

本申请要求2009年3月6日提交的美国临时申请No.61/158,242、2009年4月28日提交的美国临时申请No.61/173,457、2009年6月30日提交的美国临时申请No.61/222,067、2009年8月21日提交的美国临时申请No.61/235,793的权益，其全部内容通过引入结合于此如同在此全部提出。本申请与同时提交的题为“Method and Apparatus For H(e)NB Integrity Verificationand Validation”的美国专利申请No.12/718,572相关，其通过引用的方式结合于此如图在此全部提出。

技术领域

本申请涉及通信。

背景技术

移动通信网络的现有技术或标准化技术不能向网络提供对设备整体性进行认证和确认（validate）的方法，或提供对这些设备进行管理和规范的方法。同样，需要连接至网络的设备也不能确认其所连接的网络实际是否为有效的或可信的供应商网络。

发明内容

公开了用于实现平台确认和管理（PVM）的方法、组件和装置。PVM的实施使得平台确认实体的功能和操作能够通过设备管理系统（例如家庭节点B管理系统）对设备进行远程管理。示例的PVM操作使设备在允许连接和接入核心网之前处于安全目标状态。

附图说明

在以下的描述中，可结合附图，以示例的方式获得更详细的理解，在附图中：

图1示出了表示可信子系统的域分隔的示例框图；

图2示出了表示通过组织和技术方法在平台间调解信任的示例框图；

图3示出了与增强型家庭节点B（H(e)NB）之间的半自主确认的示例流程图；

图4示出了四步安全启动方法的示例流程图；

图5A示出了示例实体集合及它们之间的关系和用于平台确认和管理（PVM）的接口的框图；

图5B示出了示例实体集合及它们之间的关系和用于PVM的接口的另一个框图；

图6A、6B和6C示出了使用了平台确认实体的示例确认方法的信令图；

图7是示出了显示H(e)NB通信场景的示例框图；

图8是示出了H(e)NB中“弱”可信环境的示例框图；

图9A示出了间接设备连接的示例框图和方法；

图9B示出了直接设备连接的示例框图和方法；

图10示出了处理各个证书的示例流程图；

图11A示出了在整体性确认失败之后，通过由回退代码库实现设备修正（remediation）的示例确认方法；

图11B示出了根据图11A的方法的示例流程图；

图12示出了用于参考完整性度量屏蔽报头的示例格式；

图13示出了使用了虚拟平台配置登记值的确认的示例流程图；

图14示出了在完全半自主确认期间加载组件时，模块分级的示例图；和

图15示出了分别用于提供、执行和实施PVM的无线发射/接收单元和基站的示例功能性框图。

具体实施方式

当下文中涉及时，术语“无线发射/接收单元（WTRU）”包括但不限于用户设备（UE）、移动站、固定或移动用户单元、寻呼机、蜂窝电话、个人数字助理（PDA）、计算机或任何其他类型的能够在无线环境中进行操作的设备。当下文中涉及时，术语“基站”包括但不限于节点B、站点控制器、接入点（AP）、网关、用户端设备（CPE）或任何其他类型的能够在无线或有线环境中进行操作的接口设备。当下文中涉及时，术语“HMS”包括但不限于家庭节点B管理系统（HMS）、家庭增强型节点B管理系统（HeMS），其中以上两者可统称为H(e)MS，设备管理系统（DMS）、配置服务器（CS）和自动配置服务器（ACS），或任何其他类型的管理“基站”的配置或功能的系统。术语“WTRU”和“基站”不相互排除。举例来讲，WTRU可以是增强型家庭节点B（H(e)NB）。当下文中涉及时，术语“理论信息安全（information-theoretically secure）”包括但不限于完全安全、无条件安全和接近理论的信息安全。当下文中涉及时，术语“信任”、“可信的”和“值得信赖的”及其变形，表示对单元是否能以特定方式工作进行评估的可计量和可观察的方式。

公开了用于实现平台确认和管理（PVM）的方法和装置。PVM通过设备管理系统（例如家庭节点B管理系统（HMS））使平台确认实体（PVE）的功能和操作能够对设备进行远程管理。PVM操作使设备在允许连接和接入核心网（CN）之前处于安全目标状态。

PVM操作是完备的（self-contained），并且在不同的技术环境中同时允许多种变形和多种实施方式。虽然在需要描述实施例时，针对特定情况会提及示例的协议，例如互联网密钥交换（IKE），但并不能将其解释为对本发明整个范围的约束或限制。虽然在一些地方使用H(e)NB作为例子，但并不能将PVM限制为H(e)NB。可不偏离主旨地直接进行技术改造，将PVM扩展到机器对机器（M2M）和其他无线和/或网络设备。

描述是自上而下的，因为始于开始的结构假定了大多数可信计算技术核心概念的可用性，该可信计算技术涉及但不限于由可信计算群组（TCG）所规定的技术标准。例如，此处所描述的实施例基于由可信环境（TrE）和参考完整性度量（RIMs）所执行的安全启动来为PVM的所有操作和方法构建基础。这并不排除基于较低信任度的技术的进一步改变的实现方式。其他实施例还可在多个PVM步骤中不使用RIMs。

通常，在技术系统中，PVM包含了集成到技术系统中的信任综合定义中的信任语句（notion），其中重点是在系统中建立信任的方法。PVM使用任务的分散和分隔作为核心范例。这应演进的通信网络和互联网所需而实现了可调节（scalable）的信任，在所述演进的通信网络和互联网中，节点更加多样而连接时间更短暂。

以下对信任的一致的操作解释可用于技术系统（例如PVM）之间以及技术系统与人类之间的关系和交互：“如果实体可预测地并可观察地为了预定目的而按照预期方式进行操作，则该实体可信”。该操作解释包括三个显著特征，即，可预测性、可观察性和环境性。

可预测性表示对系统的预先认知，该预先认知可用于a）评价与该系统进行交互所产生的风险，和b）通过对观察结果进行推断，而在交互过程中获得系统情况。可观察性特指通过该特征可在交互过程中获得系统情况。其与可预测性紧密相关，从观察结果中，结合预测，可对系统状态和下一步的行动做出进一步判断。环境性是指描述了与系统进行交互的环境的信息，在该环境中，可以做出预测和进行观察。总的来说，三者实现了对其可信度的估计，或反之，能够对其对交互实体所产生的威胁进行估计。

由于缺少建立操作信任的方法，而在信任和强制（enforcement）之间造成了概念上的差异。随着互联系统多样化，已经不再限于客户-服务器的关系，这种问题变得更加突出。在这种情况下，考虑到现有（安全）技术的发展水平，无论是强制还是信任的操作方面都不能实现。系统缺少a）用来建立可操作的信任的普遍的技术方法，b）用于强制的首要基础结构，和c）用于将有关可信性和适当的安全等级的信息发送到外部实体的方法。只有上述基本结构块才能够在系统中实现可反映现实需求的信任和强制的动态平衡，也就是可调节的信任。

PVM也是根据上述构造块而建立的。可信系统的结构块构造了其信任边界，并且有时提供了可扩展该边界的方法，并通过使其性能和操作在一定程度内可预测和可观察，而向外部实体传送该信任。构造块可包括（硬件）安全锚、信任根（RoT）、可信（子）系统，及所有关系、安全存储及路径、授权、认证及安全启动进程和证明。通过把上述方法相结合，可以以多种方式构建结合了信任和强制的特征的系统和各种组件，从而实现可在这两个极端之间进行调节的技术。下面描述基本的功能构造块。

硬件安全锚对于保护系统性能非常重要。硬件安全锚是系统中用于通过硬件手段来保护其不受到未授权的访问的部分，从而有效地降低对该其的攻击威胁，其中所述硬件手段已知对预期目的是足够安全的。特别是，其保持用于其安全操作的RoT。该RoT是抽象的系统组件，其实现a）确保内部系统操作的安全，和b）以安全和认证的方式向外部实体告知系统的属性和/或标识（单个地或作为组成员，例如构造和型号）。

一个系统为不同目的可包含多个RoT。例如RoT可以是结合了其可信第三方数字证书的非对称密钥对。同时，蜂窝网络的用户识别模块（SIM）中的对称秘密也可看作是以SIM卡来实现的封闭的可信系统中的RoT。

其次，系统中的认为可信的（即为了预定目的而按照清楚的方式进行操作）功能构造块组成了该系统的可信计算基础（TCB）。该TCB所包含的系统组件在域中调用系统时和在操作期间，不能检测其操作可信特征，而只能被例如兼容和一致性检测和证明的带外进程检测。这种证明通常是由独立的评估器来执行的，例如是根据所建立的安全评价标准的，代表TCB特定技术组件的制造商或整体TCB的制造商。为了使这种证明有用，TCB的每个组件都应该具有将其标识为是这种证明技术组件的信息。

具有所述安全锚、RoT和TCB的系统称为可信系统（TS）。这里对通常可信平台的概念有一点改进，通常的可信平台指的是“具有通常使用内嵌硬件的方式的可信组件的计算平台，该计算平台使用所述可信组件来建立用于软件进程的信任基础”。当TS中存在一个或多个可信系统时，这些可信系统称为可信子系统（TSS）。其例子包括个人计算机平台上的虚拟执行环境，该个人计算机平台从主机的可信平台模块硬件（TPM）接收特定信任。另一个例子是结合了其TCB的可信引擎的规定。在下文中，除非明确指出，否则“TS”可以互换用作“TS或TSS”的缩略语。TS可以在如图1所示的各种设备中实现。

下面，对TS中总称为术语可信资源（TR）的各种能力、进程和结构组件进行描述。TR通常可以分为：1）属于TCB的TR；和2）TCB外的TR。后者的例子是操作系统的可信组件和通过使用TCB性能而构建在TCB上的可信应用程序。对TCB中TR可信度的认定依赖于TCB所定义的安全，而其他TR的可信度至多可以从来自TCB的可信度得到。在这种情况下，TCB必须将能够允许对信任边界（即能够在指定环境中认为可信的TS组件的总数）进行扩展的特定内部TR提供给TCB外的TR，例如如下所述的确认或安全的启动。TCB内的TR通常与所述RoT共用相同的硬件保护，例如位于同一块防干扰芯片上。TCB外的TR可以以软件内的逻辑单元来实现。注意，信任边界，尤其是涉及TCB外的TR的信任边界，可以是短时的。其可在一段时间内为特定目的而存在，并可以在之后不再存在。

用于扩展TCB信任边界的过程的通用模型是验证（verification）。其本身就是用来执行验证过程的TR。将其标识为验证进程和相应的TR验证实体或验证器，以区别于由外部实体（即确认器）对TS进行的确认过程。验证作为进程包括在信任边界中至少以两种不同形式出现的新组件。首先，验证器在其初始化时测量新组件。也就是说，该组件、该组件的状态和配置是唯一标识出的。之后存储该测量结果。作为其扩展，验证器可以将该测量结果与参考值进行比较，并判断是否扩展信任边界。也就是说，验证器可以做出并执行策略决定。从操作的角度来说，由于在完成验证过程后，可认为其处于特定的预定状态，因此验证对应于TS的可预测性。而另一方面，确认则使该属性可观察，从而可信。这表示，存在报告实体将验证结果发送给另一方。第三，由该报告实体所执行的中间步骤为证明。证明是验证的逻辑结果，还是确认的逻辑前提。证明是确保所测量信息的准确性的进程，从而可靠方——确认器——可以使用该信息来决定其是否该信任远程TS。验证、证明和确认是可操作信任的核心概念，其与TS的存在周期紧密相联。

TS由被授权访问信任边界内的特定TR（例如由RoT）的实体（个人或其他技术系统）所具有。该所有关系可以通过直接地物理具有TS而隐式的存在，即该平台包含TS，或例如通过特定凭证（credential）对所有者进行认证而显式的表明。在可信计算群组（TCG）可信平台模块（TPM）规范的环境中，提供这种认证数据称为获得所有权。直接与TS进行交互的所有者称为本地所有者，而要通过任何方式中转，例如通过通信网络中转，来与TS进行交互的所有者称为远程所有者。当TS中包含多个TSS时，每个TSS都可以具有相同或不同的所有者。

图1表示若干个TSS110、130、150和170的计算域的分隔。TSS110、130、150和170分别包括专用移动可信模块（MTM）112、132、152和172。移动电话工作组（MPWG）规范的硬件安全锚包含所提及的RoT、TR（可信资源114、134、154和174）和可信服务116、136、156和176。通常的软件服务和组件118、138、158和178分别位于信任边界120、140、160和180之外。所谓的可信引擎122、142、162和182（所有这些都位于安全计算环境中）依赖RoT在不同TSS110、130、150和170之间分别特别提供分隔和可控通信。在使用域间确认和授权的条件下，TSS可以与其他TSS共享TR，甚至共享MTM的功能。只要至少存在一个硬件保护的RoT（从该RoT生成基于软件的MTM的RoT），就可以以软件的形式来实现可信引擎以及一些MTM。每个TSS可由本地或远程相关方（stakeholder）或所有者来控制。在移动设备的存在周期中，并不是所有相关方TSS都存在，且存在进程使得（远程）相关方能够初始化新TSS的创建并获得其所有权。

PVM部分依赖于信任的建立。在信任与强制之间，主要的连接概念是任务分隔。任务分隔通常认为是涉及强制的任务。但是其与信任有天然的联系。依赖方只有在其操作可信时，才会将强制委托给其他系统。在TS间建立操作信任依赖于为实现可观测性和预建立可预测性而进行的可控信息交换。后者只能在TS之外完成。

图2所表示的示例模型展示了向TS200、202提供组织保证的外部实体的角色。TS200、202包括正常应用程序260、262，该正常应用程序位于信任边界270、272之外。在信任边界270、272内，有TCB216、218，该TCB反过来包括RoT208、210和TR212、214。信任边界270、272可进一步包括可信操作系统230、232或其中需要保护的部分以及可信应用程序234、236。

TS200、202的安全属性位于硬件信任锚204、206和RoT208、210中。当部署和操作系统时，上述技术组件是不能被检测的。因此，其在设计和开发过程中需要接受安全评价。这是由独立的机构所执行的，一旦评价成功，该机构便向安全性重要组件的制造商颁发安全性证书。

除RoT208、210和信任锚204、206以外，安全性进程还可在TCB216、218中包括其他TR212、214，并涉及不同的证明机构220、222。为了确保评价过程和不同证明机构的质量的一致性，其反过来由鉴定机构224进行评定和证明，该鉴定机构可以例如是半国有的或由国家承认的私人实体。该鉴定机构224还可在证明机构220、222之间提供连接信息。

证明机构220、222或收到其通知的技术实体向TS200、202颁发供TR212、214所使用的凭证226、228。这些凭证226、228能证明其完整性和来源都是可证实的。最重要的例子是由制造商颁发给TPM的主RoT（EK）认可（endorsement）密钥（EK）证书，以及平台证书和其他组件的证书。之后还使用加密方法使从这些证书中所获得的凭证和秘密都用于与外部实体（特别是其他TS）进行交互。TS200、202的确认240通常需要认证，并且在许多情况下，还需要保密。并且，具有从TS凭证中得到的信任的秘密和凭证对于操作系统230、232和可信应用程序234、236分别建立安全性关联242、244来讲是非常重要的，所述安全性关联也就是能够对通信提供认证、机密性和完整性的信道。在安全性关联242、244之上，扩展信任边界内的应用程序可以与定义好的操作信任属性建立起安全的通信信道。

调解（mediation）实体250促进在图2所示的各种交互之间建立信任。调解实体250的一个例子是私人证明机构（PCA）。调解实体250将关于TS可信度的基础声明发送至另一个TS或依赖方。调解实体将TCB216、218或所选组件（例如信任锚204、206等）标识为可信的且被证明的组件。此时，调解实体250需要知道由证明实体所颁发的证书，当从TS收到证书时验证该证书，并向依赖方签署保证声明。调解实体250可以按照与公共密钥基础构造（PKI）中的证明机构（CA）类似的方式完成之后的安全性关联和安全通信。

现在描述PVM所需的用于建立信任的构造块。

本质上，验证是对TS的状态变化进行记录并控制为所期望的粒度（granularity）。同时，从开始到结束，其都要与TS所处的平台的操作周期紧密相连。因此，实际的验证方法大多与物理设备（例如WTRU）的一个或多个处理器所执行的平台的启动进程和操作周期进行集成。

一种对TS进行内部验证的方法是认证启动及在TS初始化时（例如WTRU上电时）使用TCB的能力来评定所加载或所启动的软件或硬件组件的可信度。认证启动是通过在启动TS的其它部件之前，先启动RoT和TCB的特定功能来实现的。这些部件操作为用于测量的RoT（RTM）。这表示，之后所启动或加载的组件都要经过测量，即所述组件及其状态和结构在启动后都要通过例如对硬件组件的内嵌代码和所加载的程序的（二进制）表示生成加密摘要值（例如，加密哈什值）而唯一地标识出。根据特定要求，可将测量值存储在安全存储器中。所述度量值与从其中追溯系统状态所需的数据（例如软件名称和版本）一起形成TS的存储测量日志（SML）。在PC平台上，认证启动可以包括从BIOS到操作系统（OS）加载器所有组件以及OS本身。

在认证启动的一个例子中，由报告进程来测量系统状态，其中TPM作为中心机构来接收测量值并使用哈什值来计算该状态的唯一表示。为了清楚起见，TPM可以接收1）应用程序或文档的哈什值，即由外部（软件）实施所计算出的应用程序的测量值，或2）TPM可以计算哈什值，即使用内部哈什算法实施所算出的测量值本身。为此，TPM具有多个受保护的平台配置寄存器（PCR）。从上电时系统进行初始化开始，对于每一个所加载的或所启动的组件，都使用RTM向TPM报告其测量值，例如通过BIOS的哈什值，并安全地存储在SML中。同时，由扩展过程对活动PCR进行更新，这意味着，将测量值附加在当前的PCR值上，通过该数据建立摘要值，并存储在PCR中。这样就建立了可传递的信任链，该信任链包含所启动和加载的所有组件。如果单个PCR仅存储一个值，则只能够提供“足迹式”的完整性确认数据。该值使得确认器只能通过结合SML来重新计算该足迹才能验证该信任链。

安全启动是认证启动的扩展。对于类似机顶盒或移动电话这种有待机和离线功能需求的设备来说，安全启动具有特殊的重要性。能够安全启动的设备的共同特征是在其不能在例如网络连接前将有关其信任度的证明向外部发送时，它们需要在一组可信的状态中进行操作。在安全启动中，TS具有本地验证器（验证实体）和本地强制器来监管启动进程，其同时建立了策略强制点（PEP）和策略决定点（PDP），以控制安全启动进程。该本地验证器将新加载的或启动的组件的测量值与位于TCB中的或由TR在TS中进行保护（例如位于受保护的存储空间中）的可信参考值（TRV）进行比较，并决定其是否已加载、启动或还未启动。这样，可以确保该系统启动至定义的、可信的状态。

可信参考数据是用于将确认数据与已知良好值进行比较的数据。构成可信参考数据的这些值称作可信参考值（TRV）。其最著名的例子是在TGG的MPWG规范中所定义的参考完整性度量（RIM）。其实际可用作a）由平台本身在安全启动时使用，以确保只启动那些度量值与TRV一致的组件，或b）由确认器使用，以将确认数据与已知良好值进行比较，从而在评价正在进行确认的平台状态。术语RIM可以作为非限制性的示例用于描述可信参考数据。

这样，可信参考数据通过对其特定的安全声明而可信，其由确认器或代理使用所考虑的TRV来进行确认。这种可验证的声明可由例如数字证书来实现，该数字证书是由可信第三方（TTP）所颁发的例如成为RIM证书的数字证书。可信参考数据的信任声明还可以包含例如有关计算机或平台的外部评价（例如，根据通用标准评价保护级别，EAL）的附加信息。

需要重视TRV的双重性。一方面，其在安全启动进程中用于本地验证。在该过程中，其由提供的基础结构的TRV所执行，该结构能够例如通过向TS提供对应于所更新软件的新TRV，来对所测量的组件进行更新。对于用来在安全启动后确认TS的外部实体，则需要将所接收的确认数据（例如所谓事件结构）与所存储的TRV进行比较，并验证相关联的TRV证书。这样，TRV和相应的证书不仅对验证很重要，对确认也很重要。

对于确认来讲，证明信息的时新性十分重要。这就需要将验证过程从启动扩展到TS的操作时间，这在复杂的开放系统中是一项技术上很困难的任务。

所提到的任务分隔也存在于对TS进行确认的进程中。即，基于验证结果，可以评价系统的可信度，并且可在确认过程中进行相应的策略决定。该进程中，在TS和确认器之间所进行的任务分隔将导致三种类型的确认。现在首先描述各类确认所需的共同基本概念。

TS的确认进程必须得到确认标识的支持，其中该确认标识被展示给确认器。该确认标识必须直接或间接地来自RoT，即用于报告的RoT（RTR）。如果没有调解器（mediator）则不能进行确认。确认标识的提供者必须声明该确认标识的所有者为TS。提供确认标识是在标识管理（IdM）系统中提供标识的扩展。提供者必须对TS（包括TCB中一些或全部TR）的凭证进行检查，以评定该TS是否处于针对确认为可信的状态。并且，必须在安全进程中提供确认标识，例如专用安全信道中的安全协议。在远程确认的情况下，该确认标识与TS的全局标识相一致。

使用唯一的永久确认标识进行确认对安全性是非常重要的。会由于各种目的而频繁且任意地在多个确认器上进行确认。虽然所用的确认标识不会每个都易于与用户标识相关，但是其通常能实现对TS的行为进行追踪。由于安全原因，对一组或所有TS都使用相同的确认标识并不是解决该问题的选择。这种组标识是攻击/失败的单点，也就是说，如果该组中的一个TS受到损害，则所有其他TS也不能进行确认了。另一种选择是使用按确定的频率所生成的或由RTR为每次确认所生成的短时确认标识，例如，每个启动周期生成一个。

自主确认是在假设TS的验证肯定已经在本地完成（即，限制在该设备内，也就是以不依赖于外部实体的方式）的基础上，由外部确认器隐式地完成对TS的确认的过程。在这种情况下，假设在TS允许与外部或其他操作进行进一步的通信尝试之前，已经进行了成功的验证。因此，在这种情况下，假设验证进程是绝对安全的，这是因为没有向外界提供该验证的任何直接证据。外界进行如下假设：根据TS所进行规范和执行的方式，TCB将阻止验证失败的TS执行其他对外界可见的任务，例如将该TS自身连接至网络，或从远程实体获取认证连接。自主确认将所有强制任务都放在TS上。

自主确认向TS使用了封闭不变的系统模型，该模型基本就是智能卡中所用的信任模型。TS使用TCB来对自身进行验证，结果是二进制的“成功”或“失败”值。而确认是间接的进程，TS在该进程中允许与外部进行特定交互，例如网络附属。一个典型的例子是由智能卡释放认证秘密，例如密钥。

仅依赖于设备的安全在过去已被破坏，并且随着例如移动设备已成为开放的计算平台，其很可能还会被进一步的破坏。自主确认基本不传递高级安全需求的信息；特别是，如果TS部分受损，则外部得不到任何关于其状态的信息。因此，不能标记出受损的设备，这就意味着在被控制之前，还会继续进行开发，而不会被注意并不会对其他相关方（例如网络运营商）造成严重损害。根据失败策略，可将自主确认实现为使验证而对特定条件进行反应，所述特定条件为例如不允许特定功能，或关闭设备进行重启。这避免了网络连接，看起来由优越性。但是，这同时对拒绝服务（DoS）攻击又是一种媒介。设备在受损状态时必须不连接到网络，因此几乎没有机会恢复至安全状态。远程管理也很困难；特别是由于在软件下载和安装的过程中可能向受损设备发送数值（软件、秘密），因此可能会造成安全性的损失。因此，自主确认倾向于进行带外维护。例如，TR软件更新的失败可能会导致在该设备状态中不能进行网络连接。

使用自主确认，证明数据的时新性是不能由其自身进行保证的。为了满足这种安全属性，每次系统状态发生变化时，都需要自动进行自主确认。由于自主确认在操作期间，例如在网络附属期间，进行得并不频繁，因此TS状态可能会在TS操作期间发生重大变化，而确认器观察不到。因此，攻击者会利用该间隙，例如植入恶意软件。自主确认非常可能受到这类定时攻击。

在远程确认中，确认器直接根据其所接收的用于验证的证据来评价TS的有效性。在这种情况下验证是完全被动的，并且必须向确认器发送完整的SML。这种情况的模型是由认证启动所进行的验证和随后的确认。所有策略判断都位于确认器。

现有技术中用于确认的技术是远程确认，特别是用于TCG远程证明的远程确认。在远程证明中，由TCG可信平台向外部确认器显示SML和PCR、由证明标识密钥（AIK）签名的远程证明的确认和验证数据。该AIK是经PCA证明的短时非对称密钥对，该PCA用作确认标识提供者。在远程证明中提供的伪名并不是在所有情况下都够用。TCG额外定义了根据零知识证明的直接匿名证明（DAA）。

由于远程和自主确认是半自主确认所纳入的多个选择中的极端情况，远程确认也有其不足。由远程证明所表示的远程确认，由于其对连接至网络或服务的（中央）接入点施加了用于确认的完全计算负载，因此其在调节度和复杂度方面表现出了操作上的问题。特别是，对于类似个人电脑这种具有大量各种版本和结构的软件和硬件组件的平台，确认SML的耗费很大。这同时还需要有巨大的TRV数据库，例如RIM，其与基础结构一起，来使相关方能够定义所需的TS目标配置。相同的原因还会远程确认对TS远程管理（即配置的可控和确认改变）来讲显得不够实际。此外，运行验证期望进行远程确认，否则只能向确认器显示启动后的状态。SML会在确认时“消失”。因此，如果之后不立即进行确认，运行验证就没有意义，而确认需要非常频繁地进行远程确认。最终，由于所显示的SML可能对TS几乎是唯一的，因此复杂的开放TS的远程确认只能向秘密性妥协，而不顾是否使用PCA。类似的经济上的原因是可能存在远程证明所造成的歧视，即，由于担心只有主要卖家最新版本的软件才能进入TPV数据库（例如RIM数据库），因此使得其他程序的用户转而使用这些软件版本，或放弃服务连接。可以通过修正远程证明方式来减少一些缺陷，例如基于语义或属性的认证，其目的是展示组件特征而不是具体实施。

半自主确认是另一种在验证期间评价TS有效性的过程，该评价是在该设备自身内本地地进行，而不依赖于外部实体，且在验证期间进行策略判断。但在这种情况下，需要向确认器发送特定信息，下面称为“确认消息”，例如是验证结果和所需证据，该确认器可以根据来自TS的确认消息的内容来进行判断。必须对从TS至确认器的信令进行保护，以提供认证、完整性和如果需要的话，还有机密性。半自主确认的一种模型是安全启动，之后向确认器发送关于事件结构和TRV指示的信令。半自主确认在TS和确认器之间分配验证和强制任务。特别是在安全启动进程中，前者在加载组件时进行决定，而后者则根据所提供的状态证据，在确认时强制TS所允许的关于交互的决定。

半自主确认可以提供优于另两种选择的长处。其可能以验证时所用的RIM指示符的形式来更有效地传输确认信息。例如，当这种指示符表示一组具有相同功能和可信度（例如版本）的组件时，这种方法还可用于保护隐私。这与基于语义和属性的认证类似，并且还可将半自主确认与上述远程确认的改进方式相结合。在对确认器进行验证过程中的强制执行所带来的相互作用还使得能够对TS进行远程管理。

在技术实现的过程中，可以使用修正来实现“对由于完整性验证失败而没能成功获得网络连接许可的AR（接入请求者）进行隔离和修正的支持”。理论上，可如当前授权策略的定义，向AP提供所有最新的有关完整性的信息。其例子包括OS补丁、防病毒（AV）更新、固件升级和其他类似的软件或固件更新。实现远程管理的具体概念可能需要依赖能够有效地表示和发送TRV信息（例如RIM信息）的基础结构，如此处用于PVM的所述。

非常需要在此处强调RIM证书在半自主确认中的角色。RIM证书是由已经直接评价或委托评价了相应TR的证明机构所提供的。证明方法和实体可以是多样的，并且涉及不同的操作可信度级别。这使得半自助确认器更加具有灵活性，其中所述半自助确认器获得了关于TS更细的信息。如此所述，RIM证书被用作可支持对组件进行设备接通（on-device）确认的数据的示例。尽管在此描述的是基于RIM证书的SAV方法，但是也可使用其他SAV形式。

对于资源受限的系统，半自主确认也是唯一可操作的确认选择，这时因为对于资源受限系统来讲：a）其缺乏进行自主确认所需的处理能力，和b）缺乏执行远程确认所需的众多报告的存储和/或通信能力。例如，在无线传感器网络的上下文中，传感器节点同时受到这两种限制。在这些情况下，一种方法是向传感器发送存储器探测代码，该存储器计算出静态存储内容（代码和参数）的摘要值，从而生成可预测的结果，该结果被发回基站以用于确认。攻击者显然可以通过使用所存的原始存储内容生成正确结果来避开该“认证”。只要该攻击是在传感器本身上进行的，则该传感器会不可避免地产生延迟，该延迟会由于随机化、自修正探测路径和混淆方法而加强。因此，如果传感器应答中显著的延迟超出了预定阈值，则传感器失效。

在半自主确认中，在安全启动期间内部评价H(e)NB的有效性，而不依赖于外部实体，且在该评价期间进行策略决定，特别是根据各个组件的所测量的的完整性来做出关于加载/启动哪些组件和不加载/启动哪些组件的策略决定。在半自主确认中，向平台确认实体（PVE）发送评价结果和所需证据，该平台确认实体根据确认消息的内容自己进行决定。应当对向PVE发送的信令进行保护，以提供认证、完整性和如果需要的话，还有时新性和机密性。半自主确认在H(e)NB和外部确认实体（例如PVE）之间分配完整性验证和强制任务。特别是在安全启动过程中，H(e)NB在组件加载/启动时在本地进行决定，而PVE可根据所提供的状态证据，在确认时强制进行关于H(e)NB所允许的交互的决定。根据PVE的决定的结果，或者授予对网络和服务的全接入，或者可以提供更多受限条件，例如隔离网络接入和强制配置变化。

称为可信环境（TrE）的可信实体对半自主确认非常重要。用于半自主确认的过程可以不同。在一个实施例中，H(e)NB可按图3所示的流程图300执行对H(e)NB完整性的半自主确认。在执行设备认证过程之前，H(e)NB的TrE首先对H(e)NB的特定的预先指定组件（例如启动代码）的完整性进行检查（305）。之后，至少暂时地记录或存储该完整性检查结果（310）。这一步可在H(e)NB上电后，在认证的第一时刻（例如，为了建立安全回程链接）之前，由TrE自身自主启动。可将其认为是“安全启动”。TrE通过仅将注册组件加载和/或启动至完整性证实状态，来确保H(e)NB的完整性。如果需要重新评价所建立的信任（例如由于在之前成功的网络连接会话后H(e)NB的配置发生了变化），则可以以两种方式来对这种完整性证实启动状态进行检查。在第一种情况中，可由TrE自身自发地启动该检查。另一种可由来自网络（例如，安全网关（SeGW）或平台确认实体（PVE））的请求启动，该请求要求TrE之后完成。

之后TrE可检查H(e)NB的剩余部分的预定部分是否已经达到安全启动状态（315）。该进一步检查可以由TrE自身来启动，或由H(e)NB中的度量组件来启动，该度量组件在TrE外部，但由TrE进行完整性保护（320）。在这种后阶段检查中，只要对度量组件可行，则当加载或启动、或在其他预定运行事件时，就检查H(e)NB的剩余部分的其他组件、配置或参数的完整性。至少暂时地记录或存储安全启动检查结果（325）。优选地，采用由TrE或由其他方式的完整性保护（例如密钥哈什值）所提供的受保护的存储器来记录安全启动检查结果以及完整性检查结果。

在进一步的方式中，除了在已有PVE协议中所提供的时新性之外，可对结果（即单独的测量结果）额外加上安全时间戳以便为测量本身提供时新性和重放保护。可以通过在执行哈什功能前加上时间戳的值并之后将该结果存储在受保护的寄存器（例如PCR）中，来将时间戳的值包括在测量值中，从而实现这种时新性信息。

之后TrE对检查结果进行处理，以从该检查结果中生成要发送至PVE的确认消息（330）。一旦接收到的该消息，PVE便使用该消息来评价H(e)NB的信任状态（335）。在一个处理实施方式中，TrE使用签名密钥签发声明，声明H(e)NB已通过自主确认检查，该签名密钥受TrE保护并从而保护了该声明的完整性。该声明还可包括可供PVE用于对TrE对H(e)NB预定组件所执行的完整性检查的状态或结果进行评价的证据，还可包括关于自主确认检查和之后的设备认证过程之间的任何绑定的证据。TrE也可对该声明加上时间戳以确保其时新性。这种签名的声明证明由TrE从重排序的数据或结果所获得并发送至PVE的消息是在安全启动进程后来自H(e)NB的TrE的消息。对于签名的验证，应当将确认结合至设备认证，或使用单独的TrE标识。由于认为H(e)NB启动配置的TrE自主检查的结果是可信的，因此该签名通过增加某些可追溯性而增强了纯自主确认检查的安全性。

TrE通过SeGW将所述签名的声明发送至PVE，之后PVE可使用该来自H(e)NB的签名声明，并决定是否允许H(e)NB继续进行认证（340）。PVE可以以多种方式来使用签名的声明中的信息。在一个实施方式中，PVE可以将TrE自身的完整性与单独的静态配置进行核对，在核对失败时拒绝接入连接。在另一实施方式中，可将PVE配置为对接入控制做出更细的判断。特别是，这表明根据TrE内部或外部单个/多个组件的存在/不存在和完整性，可拒绝接入。而在另一实施方式中，根据确认声明中所包含的指示，可将PVE配置为从可信第三方获得关于H(e)NB组件的完整性和安全性属性的信息。这表明可将PVE配置为能够获取有关设备上的组件的参考值（即有效数据）的信息。之后，通过将确认数据与从设备所接收的数据进行比较的过程，而得出有关组件实际完整性的信息。PVE不会直接从TTP获取关于组件完整性的声明，而仅从可以比较报告值的TRV获得。而在另一个实施方式中，可将PVE配置为在允许接入前，进行配置变化。这种修正过程可包括强行的软件更新。

如上所述，TrE能够生成可信且精确的时间戳，并可使用在其中或受其保护的密钥进行签名。在一个实施方式中，当TRE执行本地自主设备完整性检查时，外部确认器可验证“时间”。这表示，在第一次或最后一次测量时，获得时间戳。还可表示，当在PVE开始运行协议时，使用时间戳。还可表示，在每次测量中都包含时间戳。所期望的“时间粒度”可指示使用哪种方式。在另一实施方式中，可将TrE配置为插入两个时间戳，一个在TRE执行本地自主设备完整性检查之前获得，一个则在所述完整性检查之后获得。这种时间戳有效地“锁定”了本地自主设备完整性检查实际发生的时间范围，而通过在发送表示本地自主完整性检查结果或过程的数据的同时发送这种时间戳，TrE可以使外部确认器不仅能评价设备的完整性状态，还能得知关于H(e)NB的完整性是在何时和怎样由TrE进行本地测量和验证的时间历史。这样，根据时间1）获得该声明的时间（由第二个，即后一个时间戳所指示），以及当接收到该带有时间戳的确认消息时，确认器自身的时间标记，和2）进行本地自主完整性检查的时间（锁定在两个时间戳所指示的两个时间之间），确认器便能够使用其自身的“时间窗”，来判断怎样对其从TrE所接收的涉及设备完整性状态的签名声明进行处理。

可以通过使用此处所述的PVM方法、装置和结构，来使用PVM，从而实现此处所述的策略和方法。PVM通常在活动实体间使用最大任务分隔。该方法清楚地定义了在平台确认和管理过程中所涉及的每个实体的活动区域。PVM方法的优点在于：1）可以分别为每个实体实现最优化处理；2）具有PVM的设备可不同时运行（有限制）；3）目前对于所涉及的网络实体来讲，PVM方法可无国家区别地操作；4）可单独对实体进行维护和管理；和5）更容易进行备份和故障恢复。特别是，对于有效地执行设备的确认和远程管理来讲，性能和可用性是非常重要的。在具体情况中，会存在设备组件大量更新的事件，或大量设备变更所选的归属运营商（SHO）。可将PVM结构配置为由单个运营商（通常为SHO）对一个设备执行确认和管理。作为例外，如此处所述，PVM的特殊形式可能会对漫游接入和运营商变化产生影响。

部分依赖于根据可信计算的安全技术，当设备首次尝试连接至通信网及之后对设备完整性进行监视时，PVM提供了系统的方法来对设备进行确认和管理。PVM可提供：1）在网络连接前确认设备；2）以无线方式（OtA）管理设备配置；3）通过在加载/启动组件时检查TRV（例如RIM）来实现安全启动；和4）为配置改变而在设备上安装新TRV（例如，RIM）——TRV获取（ingestion）。

在此处所述的PVM的示例实施方式中，对其所确认的设备和网络进行以下技术上的假设和预处理。对于网络，首先假设所有实体都作为相同核心网（CN）的一部分由同一个的移动网络运营商（MNO）来进行操作。因此，在这些实体之间不会因为要建立信道和实际通信而进行额外安全保护（例如，相互认证、消息的完整性保护、加密）。在需要时，如果为特别用途，还会描述额外的安全特征。不管怎样，PVM的适用范围可扩展至这些实例，这是因为该PVM方法可由MNO的CN以外的实体，甚至是由MNO以外的另一方所管理的实体进行使用。

对于设备，设备可有多种风格和多个名称。PVM可用于演进型通用移动电信系统（UMTS）陆地无线电接入网络（E-UTRAN）的H(e)NB和机器对机器（M2M）设备，还可用于多种其他满足特定条件的网络设备。这些条件基本与可信系统（TS）的相同。当使用PVM时，各个设备被配置为使用PVM方法，从而成为PVM设备。

作为确认过程的前提条件，确认需要有标识，设备可对该标识进行认证。需要该认证来保护PVM基础结构不受到特定假冒设备的攻击，并且不能把该认证与设备向CN的认证（该认证在确认后，或与确认过程一起进行）相混淆。这表明，只有在PVM认证了设备标识后，该设备才被PVM允许，从而避免了不能执行PVM协议的未知设备对PVM系统施加例如DoS攻击。

为了PVM的目的，设备标识Dev_ID是设备中与可信环境（TrE）、通用集成电路卡（UICC）或智能卡、或是设备本身（例如H(e)NB）相绑定的标识，都没有关系。假设该设备能够安全地管理与Dev_ID有关的认证证书，从而能够对Dev_ID进行认证。该Dev_ID可以是正式域名（FQDN）、统一资源标识符（URI）、统一资源定位符（URI）、统一资源名（URN）、媒介接入控制（MAC）地址（例如扩展的唯一标识符（EUI-48），EUI-64）、IPv4或IPv6地址、包含子网地址的IPv6主机标识符（例如64LSBs）、国际移动设备标识（IMEI）、IMEISV（例如gsm/umts）、电子序列号（ESN）、移动设备标识符（MEID）（例如cdma）、国际移动用户标识（IMSI）、临时移动用户标识（TMSI）（当由于用户和设备间1：1的映射而可由用户标识出设备时）、IMS用户id（例如IP多媒体个人标识（IMPI）或IMS用户公共标识（IMPU））、移动站集成服务数字网（MSISDN），或任何其他字母数字形式或机器可读格式的标识符，该标识符能够对例如每个运营商实现唯一的（例如全球或至少域内唯一的）可靠和明确的对单个设备进行标识。

该设备可具有值得信任的TrE。可在安全启动进程中，从不可变信任根（RoT）构建设备中的TrE。该TrE提供了安全的执行环境和其他基本的受保护的性能。该TrE可以是受管理的组件，例如可变的，这样只有RoT保持不变。

从可信计算的角度来看，可将TrE看做TCB，该TCB由一些安全执行环境和特定受保护接口所扩展的TPM或MTM构建而得。作为从TPM或MTM所构建的TCB的TrE属于非限制性的示例，其他信任实施方式同样适用。

对于PVM，TrE提供了能够无条件可信的TCB。但是，作为传统可信计算的变化方式，由TrE所构建的TCB在PVM中不是不变的。这是因为在PVM中，TrE及其在设备中的周围环境都是不同的。将关于这两部分专门的不同的信息发送至基础结构，并根据不同策略使用该信息对其进行确认和管理。TrE是PVM基础结构最主要的通信方，并被认为能正确执行与PVM有关的任务。

H(e)NB和TrE可以在启动时，在连接至核心网之前或H(e)NB连接至H(e)NB管理系统（HMS）之前，执行设备完整性检查。该设备完整性检查可以基于一个或多个可信参考值和TrE。可以要求TrE每次都安全地存储所有可信参考值。可要求TrE安全启动。还可要求TrE支持单组件或多组件完整性检查。

在单组件完整性检查中，可要求TrE为作为单组件的设备的可信操作加载所需的完全代码。在启动该组件前，可要求TrE来执行完整性检查（例如通过将该组件的加密哈什测量与所存储的可信参考值相比较）以确定该组件的完整性。如果该单组件通过了其完整性检查，则可启动该组件。如果完整性检查失败，则不能启动该组件。

在多组件完整性检查中，可根据设备功能而对用于该设备可信操作所需的设备完全代码库进行分割，并按顺序放入多个组件中。可要求TrE按顺序加载每个组件，并在启动任何一个组件前，可要求TrE执行完整性检查（例如通过将该组件的加密哈什测量与所存储的可信参考值相比较）以确定该组件的完整性来。如果单个组件通过了其完整性检查，则可启动该组件，且TrE可继续对下一个组件进行完整性检查。如果任何一个组件的完整性检查失败，则不能启动该组件，但TrE可以继续检查下一个组件的完整性。

对于组件完整性检查中的每一种，可以要求TrE从安全存储器中查找相应的可信参考值并将完整性测量与可信参考值进行比较，其中该安全存储器对TRV提供完整性保护。该安全存储器包括但不限于TrE的受保护存储器。如果该设备可信操作所需的所有组件都经过验证了，则该设备的完整性就经过验证了。

对于安全启动，通过构建信任链，安全启动进程在几个步骤中从RoT进入全功能状态。图4表示了四阶段安全启动方法400的示例流程图。在阶段1，在安全启动中从RoT405构建TrE410。所有加载或启动的组件都要经过验证，并且只有通过了验证的组件才能加载和启动。只有阶段1成功时，才控制TrE410执行安全启动的阶段2。

在阶段2中，TrE410进一步对执行PVM所必需的组件进行验证、加载和启动。例如，这可以包括通信和协议栈及无线电接入网（RAN）通信模块。所有加载和启动的组件都需要经过验证，且只有通过验证的组件才能加载和启动。

只有阶段2成功时，才启动安全启动的阶段3。在阶段3a中，TrE410进一步验证、加载和启动组件。只有通过了验证的组件才能加载和启动。在阶段3b中，TrE进一步测量和加载组件。

假定对组件进行验证是通过获得其测量值（415所示），并将该测量值与存储在RIM存储器420中的RIM进行比较（425所示）而完成的。如图所示，图4包含RIM存储器作为示例或实施方式。但是，如此处所述，RIM和RIM证书只是结构数据的一个示例方式，也可使用其他方式的结构数据。此处的描述允许使用RIM以外的方式和实施方式的结构确认数据。认为所有阶段中的加载顺序是由本地可用列表所管理的。假定3a和3b中组件之间的区别是由本地可用策略所管理的。可选地，可将加载和验证合并在一个阶段中。

在图4中，使用术语“TrE”来描述包含了PVM功能所需的最少功能的实体，该实体包括所有安全启动所需的功能，例如测量415、RIM存储420、将RIM与实际测量进行比较的验证引擎425。显然，这里对TrE的描述是为了简洁，而TrE可以更复杂，并包括其他组件，例如密钥生成器或随机数生成器（RNG）。所示的TrE可以包括实现安全启动所需的所有功能。可在TrE外部存储RIM，但由TrE保护其完整性和（可选地）机密性。用于测量和验证的引擎也可作为TrE的外部组件来实现。之后TrE可确保这些组件的完整性，并提供安全操作环境，使得这些组件不被修改。

在阶段3中可能会因策略不同而有更精细的粒度。例如，如果组件的验证失败或RIM不可用，则可将该组件加载至沙箱（sandbox）环境中。可将阶段3a和3b之间的区别与移动电话工作组（MPWG）参考结构的安全启动中的可信服务和测量服务之间的区别进行类比。

可为“用户空间”中没有通过验证的组件增加第四阶段。

在阶段2中单个或多个组件（通信模块或其他类似模块）的失败并不表明该设备不能进行通信。可将该阶段理解为属于特定种类的组件类型。只要加载了阶段2的最基本的组件，设备就能将其状态和失败组件发送给PVM系统。这样的设计使得如果一些组件的内部验证失败，该设备也能执行PVM（以及修正过程），而不需重启。

在另一实施方式中，当在安全启动期间检测到攻击时，可使用回退代码库（FBC）来使设备执行PVM。该设备会在检测到攻击时使用FBC进行重启，之后进入能修正设备的预定状态。

在安全启动期间，TrE记录并保护以下信息不受到篡改：1）所加载的组件的列表（Clist）；2）所加载的组件的参数；3）与一些或全部组件相关的测量值；和4）对一些或全部测量值的结果（例如平台状态）进行的唯一标记（例如加密）的验证数据。根据PVM所用的确认方法，一些或全部记录是可选的。例如，自主确认（AuV）都不使用。

PVM可使用以下术语。术语“验证”可用于表示安全启动期间设备组件内部的验证，而术语“确认”用于表示由外部实体进行的设备检查过程。从而避免了引入“内部”确认和“外部”确认的概念。验证是按通常意义的加密检查或数据匹配来进行的，此处明确指出以避免产生混淆。

PVM至少使用安全网关（SeGW）、平台确认实体（PVE）和设备管理服务（DMS）。由于由设备中的TrE来执行设备内部的确认重要任务，因此通常由该TrE与其他实体进行通信。虽然此处通信所需的其它设备组件（例如网络接口）并不一定是TrE的集成部分，但是TrE应当能够评价这些组件的完整性以确保端对端的安全。

对任务的严格分隔要求每个实体都限制在其核心任务之内。例如，SeGW在（不）可信设备与MNO的CN之间建立安全接口。其用作MNO的CN的屏障和网络接入控制及强制实例。其同时还执行作为屏障所需的所有安全相关功能，包括认证、对与设备的通信的加密/解密、安全性关联和会话建立。可将SeGW用作能够在MNO的CN与外部世界（例如外部设备）之间建立边界的网络实体的实例。也能不用SeGW，而使用PVM方法来进行设备确认。为此需要使用安全连接将设备直接连接至DMS，该安全连接例如是传输层安全性（TLS）。

对于PVE，其用作CN中的确认实体，并执行完整性确认。其接收完整性验证数据，并检查所报告的值是否已知并良好。其向CN中的其他实体发布关于设备完整性的声明。

对于DMS，其用作用于管理设备组件的中心实体，包括软件更新、配置变化、OTA管理和失败模式修正。DMS通过基于平台确认而实现该功能，而与HMS的增强型版本相类似。

除上述实体以外，PVM还包括RIM管理器（RIMman）。RIMman执行以下功能，包括：为在确认中进行比较而管理和提供可信参考数据和TRV。其还管理证书，特别是获得外部RIM证书、验证RIM证书、生成（运营商专用的）RIM证书，并通过例如撤销、时间限制和信任关系等手段来检查证书有效性。也就是说，RIM管理器是唯一一被授权管理确认数据库（V_DB）的实体。该V_DB和RIMman受到CN组件保护。向V_DB的写入仅受到RIMman的限制，因此PVE不能写入V_DB。RIMman对安全有特殊的重要意义，因为其管理着PVM所需的（SHO-CN）外部信任关系。如此所述，RIMman是一种实施方式，其可扩展为包含其他实施方式的用于（分级）结构数据的参考值和证明参考值的管理器。

PVM还包括配置策略管理器（CPman），用于执行设备配置的管理和提供。其还管理策略，特别是外部（例如从可信第三方（TTP）获得的）配置和策略，和生成（运营商专用的）目标设备配置和策略。也就是说，CPman是唯一一个被授权管理配置策略数据库C_DB的实体。该CPman对安全有特殊的重要意义，因为其管理PVM所需的（SHO-CN）外部信任关系。

图5A和5B示出了PVM的最小实体集合、其相互关系和接口的示例。还示出了其它实体，例如认证授权和计费（AAA）服务器和无线发射/接收单元（WTRU）及其接口。

图5A的PVM结构或系统500包括设备505，该设备505具有TrE510。WTRU512可以通过I-ue接口514与设备505进行通信。设备505通过I-h接口515与SeGW520进行通信。通常，设备505与SeGW520之间的接口I-h515不需要保护，可以采取特别措施来保护该信道的真实性、完整性和可选的机密性。可以使用I-h515来建立设备505与SeGW520之间的链路（从而建立与CN之间的链路）。例如，SeGW520可以通过I-aaa接口575来与AAA服务器进行通信。运营商可以采用适当措施来保证接口的安全。

确认期间，SeGW520可以使用I-pve接口522来联系PVE524。PVE524可以使用I-pve接口522来将确认结果发送给SeGW520。可使用I-dms接口530来进行在DMS535和SeGW520之间的涉及设备配置的通信。PVE524可使用I-pd接口532来与DMS535进行通信，反之亦然。可在设备管理过程期间使用接口I-pd532，来用于例如设备软件更新和配置变化。

PVE520可使用接口I-v526和I-d538来从V_DB540读取RIM，而DMS535可使用上述接口从C_DB550读取所允许的配置。在例如V_DB540中发生RIM丢失的情况下，PVE520可使用接口I-r528和I-c534来与RIMman560进行通信，而DMS535则可使用上述接口与CPman570进行通信。RIMman560和CPman570可使用接口I-rdb562和I-cdb572来分别读取、写入和管理数据库V_DB540的确认和配置策略数据库C_DB550。

图5B示出了PVM582，其中设备505可直接连接至DMS535。例如，是在回退模式的情况下，设备505在该模式中不能与SeGW执行安全性协议。在这种情况下，DMS535可通过接口I-dms_d584作为设备505的第一连接点，并通过接口I-pve586和I-pd588与PVE524进行通信以执行确认，或者至少获知在安全启动期间是哪些组件失败了。DMS535可在收到该信息后立即进行修正。

通常，各个组件，例如包括TrE510的设备505、SeGW520、PVE524和DMS535都优选地被配置为在处于活动状态的实体之间使用PVM最大类型的任务分隔的方法。如下详细描述的，这可通过使用PVM令牌在各个实体之间传递特定信息来实现。

如此处所述，PVM可使用各种版本的确认。此处所述的是与PVM一起操作的半自主确认（SAV）。在本实施方式中，设备包含TrE和RoT，并且能够进行安全启动。该设备具有RIM，该RIM能够实现对TrE组件和TrE外部组件进行本地确认。在本实施方式中，该设备可以是H(e)NB。如此所述，RIM只是结构数据的一种形式和示例，其在此用作非限制性的示例。

该设备可通过3个阶段执行安全启动，确保在并且只在所要加载的组件的本地确认成功时才加载每个组件。在阶段1中，通过依赖于RoT的安全启来加载TrE。在阶段2中，加载TrE外部的所有执行基本通信所需的组件。在阶段3中，加载所有剩余的设备组件。

之后，该设备可与SeGW开始进行网络认证。在认证期间，发送以下数据中的一个或多个：Dev_ID；设备的安全策略；关于在安全启动期间已由TrE检查了完整性的设备模块的信息；硬件/软件构建版本号；设备制造商；模型和版本号；设备和TrE的证明信息；以及TrE能力和属性。

可使用不同选择来将该数据发送至PVE（通过SeGW）。可在互联网密钥交换版本2（IKEv2）认证协议的通知字段发送该数据，并在之后由SeGW转发给PVE。之后PVE对所接收的信息进行检查。PVE检查Dev_ID是否列在黑名单中，如果是，则拒绝接入。其检查安全策略是否与该设备所需的策略不匹配。如果不匹配，则可执行修正步骤。PVE可检查是否加载了未标记的/不想要的模块和组件。

在上述每个检查中，如果得到表明设备TS的验证失败的肯定回答，则PVE可拒绝或限制（例如，隔离受限的使用或资源）对该设备进行网络连接。PVE向SeGW发送关于对该设备的有效性和可信度的决定的消息。SeGW根据该消息进行操作。

在第一种方式中，将数据存储在可信第三方（TTP），由设备发送对TTP的指针，PVE可从其中获得所需信息。可在IKEv2的通知负载中发送该指针。

在第二种方式中，只要所有数据是静态的，就可在认证期间将其包括在（可能是增强的）设备证书中。组件的任何更新都会使测量值产生变化，因此，安全启动中所用的RIM会需要新的设备证书。

此处所述的实施方式是与PVM进行操作的远程确认或半自主确认（F-SAV）。在阶段1中，可在安全启动期间从RoT构建TrE。TrE的所有组件都可以是经完整性验证的，并在验证成功时加载。在阶段2中，TrE可对设备剩余部分的预定部分的完整性进行验证，并加载。进行完整性检查的代码可包括例如基础OS、与SeGW的基础通信和安排（format）执行PVM报告消息的代码。可将测量值存储在TrE的安全存储器中。

如果阶段1或阶段2的检查失败，则TrE可停止进行认证。如果阶段1和阶段1都成功了，则可以进行阶段3。例如，可对例如包括无线电接入码的设备剩余模块代码进行完整性检查，但可不加载。可以准备确认数据，并在合适的通信协议中将确认数据发送至SeGW。该数据可由例如TrE所存的密钥进行签名，以提供该数据的真实性和完整性。该数据可包括完整性检查失败的阶段3模块的列表。

可使用IKEv2AUTH_REQ消息的通知负载来发送该数据。除由IKE安全关联所提供的对整个消息的保护以外，还可由TrE的签名密钥对通知负载中的数据进行签名，以提供该数据的真实性和完整性。该通知负载可包括完整性检查失败的阶段3模块的列表。可以使用合适的IKEv2消息的任何其他合适的负载或字段、或除IKEv2协议以外任何合适的协议（例如是TLS、TR069、OMA-DM、HTTP、HTTPS或其他类似协议）消息的其他合适的负载或字段来发送该确认数据。

SeGW可将数据转发至PVE进行判断。认证过程可继续进行，但是对网络连接授权的决定可一直等到PVE已经检查了确认消息，并且做出或获得关于被报告为确认测试失败的模块的基于网络的策略决定。

在第三种方式中，与测量和执行所述代码不同，可以在不加载所述代码的情况下加载所述代码的测量和完整性检查。SeGW可将该确认消息转发至PVE，PVE可对所接收的列表进行确认。当设备从PVE接收到成功确认的结果时，就可以加载剩余的阶段3模块。

测量完整性和等待PVE决定是否执行代码的过程可以包括假设一旦代码经过测量就不再发生变化且如果PVE对其授权则可执行该代码。因此，需要具有安全存储器，用于阶段3中的所有组件代码。另外，执行环境可支持授权执行，该授权执行允许先加载代码，在授权后再执行该代码。可能会加载大量代码，因此安全存储器和执行环境应当具有足够大小。

F-SAV可向CN提供灵活性以获知在“本地完整性检查”中的实际情况。设备可发送关于阶段1和2中代码通过/失败的指示，以及可选的，如果存在失败模块的话，还可发送失败模块的列表。F-SAV可对设备安全属性和确认测量提供更细的粒度和更清楚地认识，可对受攻击的设备提供更快更好的检测，可为受攻击的设备支持由网络发起的修正，并且可在设备安全管理中为运营商提供灵活性。

TrE也可以在消息中加入时间戳以确保时新性。时间戳的替代做法是由网络提供现时（nonce），TrE在网络接入协议启动后，将该现时合并至前述消息中。这也是将设备认证与确认进行绑定的特征。

认证失败修正可以是在例如阶段1或阶段2的完整性检查首次失败后激活回退模式，从而使设备具备足够的功能性来连接至SeGW，以向其通知失败。这之后会触发操作和维护（OAM）过程，以允许设备软件根据诊断进行更新。该回退模式需要具有足够的功能性，以在TrE的监控下，以安全的方式实现代码的完全重建。

在第一种方式中，可在IKEv2AUTH_Request的通知字段中发送测量消息数据（与设备证明一起）。在第二种方式中，可在启动基于IKEv2的设备认证之前，由适当的安全协议来发送该测量消息数据。在第三种方式中，如果阶段1或2的任何部分的检查失败，且如果失败的模块是对设备基本功能不重要的辅助功能，则可使设备继续进行/附属，而不加载这些模块。同时，可安排进行一些OAM过程以更新设备软件。

此处所述是对所有相关实体中的功能的高度概括。描述了H(e)NB设备的系统结构，在这种结构中确认和远程管理起着重要的作用。所述方法可直接用于H(e)NB网络结构中的实体。通过使用更通用的方法，以及根据任务分隔的角色定义，此处用于平台确认和管理的方法可以很容易地用于或扩展至其他网络连接设备。如果实体根据其功能进行映射，则可以类似的方式在其他环境（例如M2M）中实现。

在此处描述PVM功能的实施方式中，使用了SAV。SAV能够保护CN完全避免免遭恶意设备的攻击。在SAV中，可由SeGW有效地建立隔离网络。由于只接收限制在其任务之内的数据，且只通过与SeGW的或由SeGW所建立的安全连接进行接收，因此对PVE和DSM没有直接来自设备的攻击。执行PVM中的确认过程不需要在设备与CN的任何实体之间直接通信。只有在使用SAV的确认成功后，才允许对CN进行连接。这就确保了只有在证实安全状态的设备才能与CN中的实体通信。

图6A、6B和6C表示了使用PVM基础结构的SAV确认方法的示例。PVM基础结构包括此处所述的实体，包括TrE605、SeGW607、PVE609、DMS611、V_DB613和C_DB615。在相互认证后（620），TrE605收集以下数据中的一些或全部：设备信息——例如Dev_ID、制造商、设备能力（包括但不限于通信能力（例如支持的数据速率）、发送功率等级、信令特征和其他能力）、TrE能力和属性（包括RoT）；TrE信息（TrE_infomation，TrE_info）——包括ID、证明信息、制造商、构建版本和模型、构成、序列号；验证数据——包括平台配置寄存器（PCR）值；验证绑定——例如PCR值上的签名；组件指示符（Clnd）-组件Clist有序列表，还可包括组件参数；时间戳（可信或不可信）（622）。从TrE605发送至SeGW607的确认消息/数据可以包括上述日期（624）。

SeGW607将所接收的时间戳与本地时间进行检查/比较，以检测变化（626）。如果所报告的时间戳与本地时间不一致，则SeGW根据所报告的时间戳的属性来进行操作。如果设备的时间戳是可信时间戳，并且出现了变化，则SeGW6070应当触发对TrE及其可信时间源的再次确认。在不可信时间戳的情况下，SeGW607将其自身的可信时间戳添加在消息上。如果设备不能提供可信时间戳，则可由SeGW607添加可信时间戳，以提供对重放攻击的防护。

当接收到该消息时，SeGW607可检查是否存在验证绑定（628）。这确保了验证数据的真实性。之后，SeGW607创建PVM令牌（T_PVM）（630），并在发送前向该T-PVM添加时间戳，以确保其时新性，并防止异步消息流（632）。

SeGW607将T_PVM转发至PVE609（634），该PVE609反过来使用TrE信息查询V_DB613（636）。如果向PVE609返回不可信的判断（638），则PVE向T_PVM施加时间戳（640），并将其转发至SeGW607（642）。之后，SeGW607停止设备认证，阻止了设备附属到网络，并向TrE605发出警报（644）。

如果向PVE609返回可信判断（646），则PVE使用Dev_ID查询C_DB（648），该C_DB随即向PVE609返回配置策略（650）。PVE609评价该策略配置（652）。

如果PVE609判断该配置不可信（654），则PVE609修改T_PVM并添加时间戳（656）。之后，PVE609将该T_PVM转发至SeGW607（658），该SeGW随即停止设备认证，阻止设备附属到网络，并向TrE605发出警报（660）。

如果PVE609判断该配置可信，并且允许该配置（662），则PVE609从V-DB613中取回（retrieve）用于Clist或C_List中所有项的RIM（664）。PVE609从RIM中重新计算出正确的验证数据，并将所计算的验证数据与所报告的验证数据进行比较（668）。之后，PVE609修改T_PVM，并施加时间戳（670）。之后PVE609将该T_PVM转发至SeGW607（672）。SeGW607在该V_PVM中检查（或从该T_PVM中获得）PVE确认结果（674）。SeGW607将对设备认证是拒绝还是同意发送到TrE605（676）。如果PVE确认结果是拒绝，则TrE605执行重启并进行重新确认（690）。

可选地，在PVE609对所计算的验证数据与所报告的验证数据进行比较之后（668），PVE609可向DMS611发送失败组件列表（678）。由DMS611来判断是否能够进行更新（680），如果是的话，则准备OTA更新（682）。还由DMS611来确保在V_DB613中存在用于更新的RIM（684）。DMS611向SeGW607发送带有重新确认指示的T_PVM（686），并向TrE605发送重新确认触发（688）。TrE605执行重启并进行重新确认（690）。

现在描述关于图6A、6B和6C的过程的细节。为了执行平台确认，TrE要收集以下数据，将其包括在确认消息中，并将消息发送至SeGW：设备信息——例如Dev_ID、制造商、TrE能力和属性（包括RoT）；TrE信息——包括ID、证明信息、制造商、构建版本和可选的模型、结构、序列号；验证数据——可包括平台配置寄存器（PCR）值或简单的包括在本地验证中失败的组件的列表或受本地验证失败的组件影响的功能列表；验证绑定——例如通过PCR值的签名或失败组件或受影响功能的列表；组件指示符（CInd）-组件Clist有序列表，还可包括组件参数；以及时间戳（可信或不可信的）。

所述指示符-组件有序列表及其参数可以包含例如以下数据字段的项：索引、组件指示符（component_indicator）CInd、组件参数（component_parameters）。CInd提供了对组件的参考，其可以是URN形式的（例如URN：//vendor.path.to/component/certificate）。组件列表可以通过例如指向RIM证书、RIMc来指示用于确认的RIM。

在设备中，确认消息可以额外包括设备信息——例如ID、证明信息、制造商、模型、版本、结构、序列号、TrE性能和属性（包括RoT）、在阶段（1、2、3）进行了完整性检查的设备的安全策略和模块、硬件（HW）构建版本号，并且可以包括软件（SW）版本号和完整性测量数据。

如果需要TrE特定信息，则该TrE特定信息可描述是怎样在设备中实现TrE的。同样地，TrE信息可提供关于设备的信息和关于可信环境的分隔信息，例如，TrE是否是经认证的IP组件。因此设备的证明机构可以是有用信息。

尽管对SAV优选地采用使用RIM进行确认的方法，但其完全是可选的。其在此用作基本例子，其他方式可与此不同。例如，有的确认方式不从RIM重新计算验证数据，有的甚至执行PVM时完全不需要RIM。

如果确认信息与认证绑定（例如通过安全信道），则验证绑定也是可选的。

SeGW会对所接收的时间戳与本地时间进行检查/比较，以检测差异。如果所报告的时间戳与本地时间不符，则SeGW根据所报告的时间戳的属性来进行操作。如果设备的时间戳是可信时间戳，并出现差异，则SeGW会触发对TrE及其可信时间源的重新确认。在不可信时间戳的情况下，SeGW将其自身的可信时间戳施加在消息上。如果设备不能提供可信时间戳，则SeGW可添加可信时间戳，作为对重放攻击的防护。

设备信息和TrE信息是可选的。Dev_ID提供对设备信息和TrE信息的参考。由于并不是所有MNO都知道会连接至网络的设备以及所有的TrE，因此，可由数据库来提供所有TrE信息数据，例如映射，该数据库可由MNO查询，以获取任一特定Dev_ID的TrE信息。TrE信息可位于TrE_certificate中。该TrE_certificate应由TrE或TTP的卖方签名。

在第一种方式中，如果确认消息中没有验证数据/绑定，则可以简单的方式来执行PVM。只有验证了TrE的属性时才能这样操作。策略判断必须只依赖于TrE信息和组件列表。

这种方式的前提是在SeGW和设备之间进行相互认证。否则，如果例如设备改变运营商，则会发生信任问题。例如，其可能之前在远程管理过程中，从假冒SeGW/MNO处接收了假冒RIM。

将URN用作对组件的指示符是有好处的，这是因为其使用唯一标识同时表示了组件和可获得RIM或RIM证书的位置。

在设备确认期间，设备向SeGW发送确认消息。当接收到该消息，SeGW检查是否存在验证绑定。该步骤确保了验证数据的真实性。之后，SeGW创建PVM令牌（T_PVM）。该令牌T_PVM可用作令牌环（rolling token），在通信中从一个实体发送至另一个实体。每个实体都在发送该令牌前向其添加时间戳，以确保其时新性，并防止异步消息流。令牌上的时间戳可提供用于跟踪令牌状态的方法。该令牌在CN中从一个实体传递至另一个实体，甚至好几圈，因此可由实体追踪。

可选地，可在加载了时间戳的数据的链中加入实体ID。

T_PVM可包括Dev_ID。如果原始时间戳不存在或不可信，则T_PVM还可包含由SeGW所发布的新的时间戳。或者，T_PVM可包含来自确认消息的原始时间戳。

可以使用时间戳来防护重放攻击。该攻击可与现时或单增计数器相结合，或甚至由其替代。还可使用时间戳来评价确认数据的时新性。最好将上述两种目的相结合，并且这也是可由时间戳提供的。

假设SeGW、PVE和DMS之间的所有通信对于完整性、真实性和机密性来说都是安全的。因此，对于任何内部消息，都不采取强制措施来建立这些安全属性。但是，如果需要的话，也可以采用适当措施来保护整个或部分消息。这些措施可以包括加密通信信道、相互认证和消息上的签名。SeGW维护令牌数据库T_DB，该数据库中包含所有处于活动状态的T_PVM。

在第一种方式中，为了之后由DMS进行的设备管理，T_PVM可包含通信秘密，以用于在DSM和TrE之间构建安全通道，例如TLS证书。

SeGW从确认消息中获取下列数据：确认数据、TrE信息和Clist。在将这些数据与令牌T_PVM一起发送之前，SeGW在T_PVM上添加时间戳，并将其转发至PVE。SeGW可检查确认消息的格式和其中的部分，以减轻不良形式数据攻击的威胁。否则，攻击者可能会试图修改受攻击的TrE的确认消息中的数据，从而在PVE处对该数据的完全检查会使系统产生错误或失败。

在Dev_ID与相应H(e)NB的标识（H(e)NB_ID）之间进行分隔是有用的。虽然两者之间的关联是一对一的，但是从任务分隔（SeGW了解TrE，PVE了解H(e)NB），以及可能的寻址/管理角度来看，这种分隔是有意义的。在这种情况下，会存在中间步骤，其中PVE使用所接收的H(e)NB_ID从数据库HNB_DB中查找Dev_ID。

PVE是决定设备有效性的实体。即，在策略系统的语言中，PVE是策略决定点（PDP）。在严格的任务分隔方法中，其是PVE系统中唯一的PDP。其依赖SeGW和DMS来强制策略，例如用作策略强制点（PEP）。在通常描述中，PVM不了解策略是怎样生成的，以及该策略在哪进行存储/管理的问题，例如，PVE是从哪里获得策略的。在下述一些更具体的方式和次要的方法中（特别是参量确认和最小确认），给出了一些策略情况和操作的示例。通常，对确认策略的判断不仅依赖于单个组件的有效性，还依赖于Clist中所包含的其他数据。特别是，需要评价允许的参数（范围）和加载顺序（Clist是有序的）。

由PVE所执行的确认过程中所出现的失败情况有一些基本类型。例如，失败情况F1表示“TrE失效”的情况。通过其认证的Dev_ID和所发送的TrE信息，PVE将该设备和/或TrE标记为不可信。

另一种例子失败情况F2表示三种情况的“验证数据失败”。情况F2a表示完整性测量/验证数据不匹配。这表示设备安全启动进程失败，和/或设备中存在错误和/或超期的RIM和/或RIM证书，之后该设备启动无效组件。情况F2b表示RIM丢失，即，用于组件的RIM丢失，需要从别处获得。情况F2c表示RIM证书超期。

失败情况F3表示两种情况的“Clist策略失败”。对于情况F3a，单个组件有效，但配置不符合策略，例如加载顺序，或不期望的组件或参数。情况F3b表示配置未知，这样就不存在可用的Clist的“已知良好值”。

失败情况F4表示“确认前设备认证失败”，当将认证与确认绑定，并且设备认证在确认之前时使用该情况。F4情况包括指示了设备证书超期的F4a情况。

现在描述对所述失败情况进行检测和处理的方法。对于失败情况F1，PVE使用所接收的TrE信息来查询本地确认数据库（V_DB）。该TrE信息结构包含关于TrE的证明、制造商、结构、模型、序列号的详细信息。该确认数据库V_DB存储关于哪个TrE可被认为可信的信息。例如，其可以执行策略以信任特定卖方、模型或其他类似标识。如果根据TrE信息的评价结果，TrE不可信，则PVE可向SeGW发送包含该信息的消息。之后，SeGW可根据该消息进行适当的操作。PVE向T_PVM令牌添加声明（例如附加数据字段），该声明包含拒绝接入的原因，例如错误/不可信的制造商。PVE在T_PVM上添加时间戳和签名。将该T_PVM转发至SeGW。之后，SeGW可验证该时间戳（重放防护）和签名（防止假冒发送者）。之后，SeGW拒绝网络接入和设备认证，并阻止进一步认证尝试。

在拒绝进行网络接入和设备认证的情况中，如果确认和认证是绑定的，则需要停止认证过程。

在第一种方式中，可以使用根据特定属性的设备黑名单，该属性例如是制造商、设备版本和其他属性。

PVE也可使用Dev_ID和TrE信息，对未知TrE首先触发与RIM更新过程类似的V_DB更新过程。

对于失败情况F2，PVE从V_DB为所接收的Clist中的所有组件获取RIM。确认数据库V_DB中只存储经过证明的RIM。必须将相应的RIM证书安全地存储在V_DB中。

在一个实施方式中，可在查询V_DB前检查RIM证书，随后可对其进行丢弃。可替换地，可为安全目的存储RIM证书。例如，由于MNO持续地从可信第三方获取RIM及其证书，因此MNO可使用该证书来向检查方证明其在设备管理中的服从性。

对于失败情况F2a，PVE可从所查找的RIM计算出正确的验证数据，并将其与在确认消息中接收的验证数据进行匹配。

如果所计算的正确的验证数据与确认消息中的验证数据不匹配，则设备的安全启动进程可能已经受到攻击，或可能在设备中存储了错误的RIM，并可能已经在安全启动进程中加载了无效组件。PVE可将在确认消息中或对PVE单独请求的应答中所发送的测量值与RIM进行比较，以检测失败组件。

根据F2a策略，可应用多种选择。在拒绝的情况中，PVE可以将确认的结果发送给SeGW。SeGW可拒绝网络连接或将该设备至于隔离网络中。在更新的情况中，在接收到指示验证数据失败的确认结果（T_PVM）之后，DMS可根据管理过程来启动管理进程，以替换确认失败的组件。DMS可将T_PVM和指示符一起发送至SeGW，该指示符表示确认失败，设备将重新确认。DMS可向设备发送正确的RIM，并触发重启。当重启时，设备可使用新的RIM重新认证和重新确认。如果验证数据再次错误，则该设备可能不能通过远程管理过程恢复。为了防止无限的重启循环，DMS可将Dev_ID与时间戳一起存储，该时间戳表明发送远程重启触发的时间。如果DMS接收到命令要再次执行更新，则DMS可检查是否已经存储了Dev_ID。如果存在多个存储项，则时间戳可指示短重启周期，表明该设备不能被恢复。如果在确认中没有使用RIM，则此处所述的用于对失败情况类型F2进行处理的方法是可选的。

在另一种方式中，根据验证数据，例如PCR值，PVE可使用数据库V_DB的特殊部分，该部分通过PCR值缓存了可信配置。PVE可为有效配置查找验证数据表，例如在PCR值的情况中为哈什表。如果找到了匹配，则确认立即成功。在V_DB中为有效配置存储预先计算的PCR值对以相同配置运行的设备类型非常有用，其中哈什值是相同的。不同于将所有组件与RIM进行比较，可比较单个合成哈什值，从而降低了计算开销，加快了确认进程。

如果没有发生策略失败的情况，则该设备有效。PVE可将该消息发送至SeGW，SeGW可以允许对CN进行连接。

对于失败情况F2b，可从可信第三方（TTP）处获得RIM。如果一个（或多个）组件的RIM没有存储在V_DB中，则PVE将丢失RIM的列表发送至RIMman。之后，RIMman尝试从TTP获得（经证明的）RIM。Clist包含组件指示符CInd（例如URN），RIMman可通过该指示符标识出组件，并获得关于查找相应RIM证书的位置的信息。RIMman为新RIM执行RIM获取，包括对存储到V_DB中的RIMc进行验证。RIMman对存储CInd、RIM和RIMc的V_DB执行更新。RIMman向PVE通知V_DB的更新，之后PVE可从V_DB获取丢失的RIM。

可替换地，可从设备处获得RIM。如果在确认消息中，设备表明其能够向网络提供所存储的RIMc（包括RIM），则PVE可向该设备请求确认时丢失的RIM和RIMc。这可作为找回RIM的备用办法。由于设备在安全启动中已经使用过所有RIM，因此，设备中存在全部RIM。如果PVE不能找到一些组件的RIM，则PVE将丢失RIM的列表与T_PVM一起，加上新的时间戳，发送至SeGW。SeGW执行与设备的协议，以查找RIMc。SeGW将所接收的RIMc添加上时间戳，并加载T_PVM上，并将该T_PVM令牌转发至PVE。PVE将所查找到的RIMc转发至RIMman。之后，RIMman验证所接收的RIMc是由可信实体所发送的，并且有效。RIMman对该新RIM进行RIM获取，包括将对存储到V_DB中得RIMc进行验证。RIMman执行V_DB更新，之后向PVE通知该V_DB更新。之后，PVE可从V_DB中获得经验证的RIM，并接着进行确认。如果在查找和获取步骤后，该组件的RIM依然丢失，则PVE不会再向设备请求RIMc，而是从TTP请求获取RIM，正如上文所述。任何从设备或TTP获得的RIM都一样可按照数字证书的方式对可信度进行验证。

PVM组件之间的信任模型决定了从设备获取RIM的操作顺序。PVE不信任来自设备的RIM/RIMc，而要等待其进入V_DB，进入V_DB只能由RIMman在检查了该数据的可信度后才执行。PVE也可在与RIMman获取RIM同时，开始根据从设备所接收的RIM重新计算验证数据，但必须等待RIMman对其可信度的决定结果。

由于其仅在CN内部发送，因此可在受到整体性保护的附加消息中发送该RIMc。该包含RIMc的消息必须可与T_PVM链接。

对于设备，可由外部实体来进行获取RIM的进程，且该进程可扩展为设备和PVM结构完全获取进程。这可在PVM结构内标记为分布式RIM获取。

所有从PVE发送至RIMman的消息都必须受到格式和内容的限制，以确保消息的整体性并减轻例如错误消息的攻击。消息必须包含用于组件的单独URN，用于指示可取回参考测量的位置。

对于失败情况F3，PVE从配置策略数据库C_DB中获取关于允许配置的策略。该配置策略数据库C_DB包含了根据Dev_ID的所允许的配置。由CPman对该C_DB进行管理。该C_DB还可包含策略操作，例如对一段时间内断开连接且没有进行确定的设备进行所期望的更新。PVE根据Clist中的信息对从CPman所接收的策略进行评价。如果评价结果产生F3a或F3b中任一种失败情况，则可使用不同操作。

对于拒绝，PVE将关于失败的配置策略的消息加载在T_PVM上，并在该T_PVM上添加时间戳和签名，并将其发送至SeGW。之后，SeGW验证时间戳（重放防护）和签名（防止假冒发送者）。之后SeGW拒绝网络接入和设备认证（并阻止进一步的认证尝试）。如果确认和认证绑定，则停止认证过程。

如果Clist未知，并从而在C_DB中找不到（失败情况F3b），或对于Clist中的组件不存在策略（F3a的特殊情况），则PVE调用CPman从TTP中查找配置策略。如果CPman能够获得新的配置策略，则CPman更新C_DB，并向PVE发送带有指示符的消息，该指示符指示所更新的配置策略。

如果该更新包含新组件（参考F3a）（通过从CPman向PVE发送包含该新组件标识符的消息），能够保持C_DB与V_DB的一致。之后，PVE将关于该新组件的必要信息转发至RIMman，以获得该组件的更新或新的RIM。在此，我们希望能够保持配置和RIM管理的管理过程相互分离，从而可独立地操作组件Cman和C_DB与RIMman和V_DB。如果策略需要对设备更新，则由PVE触发该更新过程。

作为一个简单策略的例子，C_DB可包含允许配置的列表。PVE将所接收的Clist转发至CPman，该CPman反过来将该Clist与所存储的允许配置进行匹配。如果没有找到匹配，则检测到失败情况F3b。由于在设备管理过程中当前确认进程可能是设备更新之后的重新确认，因此可能需要检查更新。在该管理过程期间，设备配置可能发生了变化，并可能需要与C_DB中新的配置进行验证。

此处所述是重新确认过程的例子。可使设备一旦经网络认证，就几乎不再重启，除非出现没电这样未安排的情况。对设备进行重新确认可以是执行环境的常规部分。周期性的重新确认可使网络确信设备正以预定状态进行操作，从而减小了执行恶意代码的风险。重新确认还能使认证过程再次启动，从而保持了密钥交换的更新，并重新建立了安全通信通道。设备重新确认存在两种触发，一种是由网络触发，另一种是由设备触发。此处所述的重新确认的方法可用于任何确认方法。

此处所述的是由设备启动的重新确认的示例。可以按周期性的机制来进行设备启动的重新确认。根据设备的使用频率，MNO可以在设备的设置过程中设定周期性重新确认安排。在所安排的时间，设备会启动重启顺序，该重启顺序会触发再次进行确认进程以及认证。同时，如果设备需要进行软件更新，则还可启动相应的OAM过程。如果设备在期望的时间范围内不进行重新认证/重新确认，则可由CN触发重新确认。对于只能由设备启动的重新确认，运营商对重新确认过程不具有控制力。如果大量设备按相同安排进行操作，例如每月第一天，则会增加CN结构的载荷。

此处描述的是由网络启动的重新确认的示例。与由设备启动的情况一样，网络启动的重新确认可以按周期性的机制进行，但是也可在网络由于安全原因而认为需要的任何时间进行。运营商还可将重新确认设置为策略的一部分，从而运营商将设备中的模块编程为在所编程的时间间隔内执行重新确认。可通过向设备发送指示重新确认请求的IKEv2消息来触发重新确认。可使用通知负载来承载为设备新定义的重新确认触发代码。

PVE可周期性地向SeGW发送重新确认指示符。为了对所发送的所有请求保持追踪，PVE将其与DEV_ID和时间戳一起存储。之后，PVE周期性地检查是否有任何设备忽略了该重新确认请求。SeGW可通过IKEv2协议将该请求转发至设备。可在安装时，根据主机方的请求设置重新确认消息，从而降低设备中断的风险。

设备接收IKE消息，该消息的通知负载指示重新确认请求。之后，设备启动重启顺序，其中重新建立对网络的确认和认证。如果设备受到攻击以至于忽略了该重新确认请求，则PVE可在监视所有处于活动状态的重新确认请求的过程中，检测到该情况。PVE可将失败的重新确认发送至SeGW，SeGW可采取适当的操作，例如将该设备置于隔离网络中。

另一种由网络启动的重新确认的方法涉及向设备发送重启信号，触发重启，从而在安全启动进程中进行重新确认。

在另一种方法中，还可通过来自其他网络实体的请求来进行设备的重新确认。如果设备制造商怀疑其设备已经受到大范围的攻击，则制造商可联系MNO，并请求重新确认。这可通过由MNO战略部门的处理来判断是否进行重新确认而完成。PVE或HMS可以启动重新确认和重新认证。

此处所述是平台管理的示例。DMS是负责设备管理的主要实体。根据所接收和所存储的设备信息，例如卖方、硬件/软件配置/TrE能力等，DMS能够启动软件更新、配置改变和OTA设备管理过程。管理操作通常是由所发送的确认数据、来自PVE的确认结果和C_DB中的策略（例如所需目标配置）来决定的。

DMS可以与设备的TrE建立安全通道。DMS可使用T_PVM令牌来获取设备的Dev_ID、最近报告的确认数据和Clist。通过发送带有指示符的T_PVM，DMS使用Dev_ID来询问SeGW，以与设备TrE建立安全通道，其中该指示符指示将设备的状态从“工作”设置为“管理”。从而，SeGW保存该令牌，可不提供回程链接（例如通过隔离），并等待DMS确认管理操作结束。

根据DMS的管理操作，设备可在软件更新之后，例如通过重启来进行重新确认。之后可进行重新确认，其中，通过使用来自之前确认的T_PVM来维持PVM系统的状态，并可以不再生成新T_PVM。在这种情况下，DMS向SeGW发送经过更新的T_PVM令牌，其中的设备状态指示符从“管理”变为“重新确认”。SeGW保有等待进行重新确认的设备的列表，当设备请求网络接入时，其从该列表中查找设备。之后SeGW可等待设备一段特定时间进行重新确认。之后，将重新确认的结果发送回DMS，以确认管理过程成功结束。

在设备的系统模型中会产生进行重新确认的需求。从DMS下载的新组件恰好在下一安全启动进程之前插入设备配置。因此，需要触发重新确认，以作为平台管理的结束步骤。由于设备必须重启，且若平台确认进一步与平台认证绑定，则重新确认可以包括切断现有用于平台确认和管理的连接。在这种情况下，像上一段描述的那样，SeGW可以为重新确认维持状态。

随着与设备的TrE的安全通道的建立，DMS可以安装/卸载软件（SW）组件（例如新SW组件）、改变配置和触发重新确认。

在另一种方式中，设备可以通过确认消息中的标记（flag）来指示重新确认。这避免了对接近SeGW的每个设备查找重新确认列表。可在安全进程，（例如由TrE组件所执行的进程）中设置该标记，这样任何设备都不能通过不设置该标记而进行重新确认。

该步骤和以上步骤可在SeGW端而不是PVE端进行，否则SeGW会自动生成新的令牌。特别是，这些步骤包括进行设备管理的协议步骤，在该步骤中，SeGW必须对要求进行设备重启的重新确认进行追踪。由于设备在重启后，会再次连接从而再次认证，因此，SeGW必须对将要重启进行重新确认的设备进行追踪，否则，SeGW会将其连接和认证尝试认为是首次连接，从而发布新的令牌。因此，在SeGW中包括维护重新确认列表。

连续在多轮重新确认中使用T_PVM有助于检测重复出现的更新失败和其他类型的操作异常。

如果DMS向设备安装新组件，则需要确保在从DMS发送至TrE的相同管理消息中，包含用于软件的RIM。可由TrE负责RIM的安全存储和其本地管理。如果需要的话，在安装组件后，由DMS触发重新确认。可向PVE发送用于该新软件的RIM，PVE通过RIMman将该RIM存储至V_DB中。DMS相应地使用CPman更新配置策略数据库C_DB。可在设备进行重新确认前，能够在V_DB中使用用于新组件的RIM，以使PVE对新配置进行确认。在配置变化的情况下，例如，如果DMS改变了用于给定组件的参数，则DMS可通过CPman对C_DB进行更新。

TrE可为安全更新和管理功能提供安全运行环境。该功能确保了受攻击的设备在软件或组件更新失败的情况下，至少能进入救援模式。在失败情况下，DMS可使用回退代码机制（FBC）用于设备恢复。这使设备能够变为原始状态，在该状态中，可通过DMS管理方法对主要代码进行更新。

为了避免出现竞争情况，可在令牌传递后，由DMS发送至TrE的消息来触发重新确认。否则，设备可能会在SeGW接收到令牌并准备进行重新确认之前，尝试进行重新确认。

在另一种方式中，SeGW可为重新确认列表中每个设备的重新恢复尝试或失败尝试次数计数“n”，在达到计数后可将设备列入黑名单、隔离或触发字段内维护，或其结合。

在另一种方式中，可在T_PVM中包含，或可从T_PVM中获取用于建立安全通道的通信秘密，而不涉及SeGW。

另一种方法可以不拒绝连接到设备，而是禁止PVM中不能通过确认或不能替换或更新的组件。通常，DMS可发送禁止CInd和重新确认消息，其有助于减轻经历如下所述的运营商锁定的风险。PVE可用于防止在设备和运营商之间出现“信任之争”。各种用于防止出现“信任之争”的方法都可用。在一个示例方法中，可通过强制进行重新确认时不包括Clist中的该组件来禁止设备组件。这可当组建的有效性更新不可用时使用。在另一方法中，可强制改变加载顺序。在另一方法中，强制改变参数，其可影响或不影响RIM。强制改变参数需要DMS从PVE获得有关所有设备组件的所需信息，而并不仅是那些确认失败的设备组件。

在PVE中，通常不需要向设备发送RIM证书。在现有PVM结构中，验证和管理是运营商网络的任务，其位于RIMman中。因为设备信任网络，所以设备可信任在管理过程中所接收的RIM和CInd。而另一方面，可信计算群组（TCG）移动电话工作组（MPWG）将由可信设备所执行的RIM获取定义为分散（de-centralize）过程，其中设备还要对所获得的由MTM保护的RIM证书进行验证（在对其安装之前）。这两种形式不是相互排除的。DMS可将RIM与其他数据一起发送，而TCG MPWG兼容设备可根据TCG规定来安装。这是PVM与TCG MPWG为安全启动所定义的设备管理之间的不同点。

现在描述验证数据的示例。发送验证数据（例如以PCR值（其为单个测量的聚合哈什值）的形式）以及为认证绑定验证数据是TCGTCG规范所提供的技术标准。但是，根据TCG规范建立验证数据和进行绑定计算的耗费很大，特别是对有很多待测量组件的设备。这通常通过此处所述的加密扩展操作来解决——基本上为从两个旧哈什值创建新哈什值。这会显著减慢设备的启动进程，这在例如家庭环境中是不希望的。

同时，由于其发送与关于测量结果的信息相类似的信息，因此在RIM和验证数据之间存在冗余。如果正确执行了安全启动，则TrE将测量值与RIM进行比较，并且只加载两者都匹配的组件。因此，Clist中所分配的RIM承载了所有有关验证数据的信息。事实上，由于验证数据被认为是所述测量值的集合，因此，RIM可承载比验证数据更多的信息。验证数据是实际测量值的唯一加密简略形式。在一个实施方式中，可将PCR值用作验证数据。

针对验证数据的争论的基本假设是安全启动进程正确地将实际测量与Clist中所示的RIM进行比较。因此，从安全的角度来说，存在一个重要的原因，即为什么验证数据能增加被确认的设备的信任度。当设备具有错误的RIM，或将测量值与假冒RIM进行比较时，会出现这种情况。

还有进一步的观点支持保留验证数据——由于在安全启动进程中所产生的，具有高保护性的数据，唯一地标识了所达到的系统状态——即使是在安全启动或一元（monadic）方法（例如AuV）的情况中。事实上，安全启动本身并不能对其他确认数据进行完整性保护，在本情况中，确认数据可以仅是没有测量值的组件列表。该CId列表还告诉确认器在哪里和怎样获得有关组件的信任信息（例如从TTP处）。

攻击者会试图操纵确认数据（Clist），将较低信任度的组件标识替换为（所获得的）具有较高信任度的组件的CId（“组件信任评价”）。确认设备（TrE）对该伪造数据签名，并进行正确的确认——如果没有验证数据，则没办法在内部检测到该操纵。

在一定程度内减轻该攻击的方法是安全启动引擎通过将数据封闭（seal）至所述状态而使该数据为静态（最新的PCR数据）。确认时，需要解除对该数据的封闭，因此再次出现相同的安全缺口。并且，由于需要系统在SML封闭后保持静态，因此限制了这种方法的灵活性。

因此，设备和确认器都非常需要具有验证数据的确认数据，即使是在安全启动的情况下。

此处所用的“验证数据”与“对原始测量数据进一步处理所产生的数据（例如哈什）（之后对其进行验证以找到匹配的RIM）”同义。在完成安全启动后，该验证数据唯一标识了平台状态。错误RIM的出现可能是例如来自受攻击的源，其可能对PVM系统整体产生更大影响，因此造成了极大风险。

一个具体的场景是其中位于运营商CN以外的可信RIM源受到攻击，例如被另一方拦截或欺骗。在检测和纠正该攻击之前，RIM源会在正常的PVM平台管理中向大量设备以及受攻击的组件发送假冒RIM。

在这种情况下，通常的修正办法是（即，在公共密钥基础结构（PKI）中的共同做法）废止相应的RIM证书。由于可信参考数据会位于设备中，因此这种做法会对设备增加负载。TRV修正会对整个设备范围内的RIM、RIMc和组件进行强制更新，但是实际上只有一小部分会受到攻击的影响。这会引起巨大的网络流量，对用户造成不便。该设备支持能够执行授权TRV修正的机制和协议。

在这种情况下，在确认中可以生成和使用验证数据。PVM系统可根据策略，为每个单独的确认设备调用验证数据使用。之后，PVE可以检测受攻击的设备，并仅管理该设备。在此称之为“最小确认策略”。

现在描述基于令牌传递的PVM操作的示例。此处所述的PVM是异步进程。因此，受各种实体攻击的PVM系统应有多种状态，且其应能从进程的当前状态中进行恢复，以减轻对分布式系统及其失败状态进行的各种已知的攻击。

在一个例子中，可使用令牌传递来进行以下操作。可将SeGW配置为是负责生成和管理令牌的实体，该令牌唯一地与确认进程相关。该PVM令牌不仅可以与确认TrE的标识绑定，还可以与有问题的单一确认进程绑定。该令牌传递方法包括重放/重新确认防护。确认尝试能够唯一地防止对旧认证进行重放，并通过频繁的重复确认来提供一种检测DoS攻击的方法。通过令牌可以建立确认会话，从而允许PVM相关数据和消息与唯一确认之间建立唯一关联。这也是评价时新性的前提。

由于可根据时间戳（不必被签名）来生成确认令牌，因此可以控制确认数据的时新性，该时间戳最初是由SeGW生成的，之后在每个实体传递该令牌时，会被附加到时序列表。

另一种加入时新性的方法可以是在加载RoT后，立即从安全实时通信（RTC）中读取时间，并使用该时间戳来建立聚合哈什链。另一种替换方法可以是使用顺序计数器，该计数器在每个重启周期增加，RoT可使用该计数器建立哈什链。

而另一种加入时新性的方法是完成阶段1和阶段2的检查，开始与SeGW和PVE进行通信，之后使用SeGW/PVE所提供的现时，在将阶段3的确认结果数据发送给SeGW之前，与阶段3的检查的进一步验证绑定。这就确保了确认数据的时新性。

与在标准PVM中一样，在多轮重复确认中连续使用T_PVM有助于检测重复出现的更新失败和其他类型的性能异常。SeGW可根据确认令牌的各种情况进行检测和操作。例如，保持活动时间过长的令牌可以表明PVM普通失败。SeGW可以在PVE和DMS中查询该令牌的状态，并根据该状态进行操作。可将这种情况标记为确认超时。在另一例子中，在令牌处于活动状态时可能会出现重新确认。这可以表示各种情况，例如意外重启、电源用尽或DoS攻击。在另一例子中，可能会在入侵检测系统（IDS）中检测到基于时间的形式，例如随机的或周期性行为。可将该设备隔离或列入黑名单，还可触发字段内维护。

还可使用令牌来保护在PVM系统实体之间和PVM系统与设备之间所传递的数据的完整性。为此，其可以包含所要保护的数据的哈什值，例如Clist，或在处理失败情况F2a时，丢失的RIM的列表，以及指向该数据的指针。T_PVM中数据对象并不是作为整体存在的，因为这会对其造成过载，产生大量开销，实际上，该开销可能会产生特定DoS攻击。

现在描述运营商RIM屏蔽方法的示例。运营商RIM屏蔽将大量来自各种外部源的用于设备组件的RIM证书替换为由运营商（或等同的“选择归属运营商”（SHO））所生成的RIM证书，该运营商是设备希望与之建立回程链接的运营商。对于V_DB中的相同组件，只要这些SHO RIM证书（SHORIMc）可用，在确认中该证书就优于外部RIM证书。在设备管理中，由DMS向设备安装SHORIM，在由TrE执行的设备安全启动中，其在设备本地依然优于外部证书。

该SHORIM可用作“第一级缓存”，以用于在确认中获取RIM证书。可将其与在本质上指向技术上分隔的、高性能的V_DB子数据库的特殊CInd相关联。

运营商RIM屏蔽适用于任何类型的高度移动设备，例如M2M设备（M2ME）。当移动设备进入新运营商的领域并进行确认时，可向该运营商提供指向另一运营商的CInd。该运营商可以以与移动设备漫游类似的方式接受该CInd，或按此处所述方法进行替换。

在运营商屏蔽的另一种方式中，当SHO决定不释放由该SHO所生成的SHORIMc的签名密钥的公共部分时，另一运营商很难，或甚至不能对来自该SHO的设备组件进行确认。可将这种机制扩展为与传统SIM锁定过程所提供的锁定具有相同级别的锁定。可在区域中首次部署设备时将运营商RIM屏蔽用作存在周期的管理工具，以在设备首次与SHO进行联系时，远程“标记”该设备。

为了根据PVM建立运营商RIM屏蔽，描述以下附加步骤，并参考上述原始PVM过程。在用于RIM屏蔽的PVM设置中，RIMman将PVE和DMS配置为各自执行在运营商RIM屏蔽中的功能。在平台确认中，PVE发送（单独或与关于组件有效性的消息一起）消息，该消息包含目前V_DB中的SHORIM所涉及的组件列表。将DMS配置为，对设备中将安装该新SHORIMc的组件执行证书更新操作（不需要更新组件自身）。

在确认期间，PVE对SHORIM不在V_DB中的组件进行标记（这与组件的任何RIM和RIMc的可用性（例如正常PVM进程）不相关）。PVE向RIMman发送所标记的候选组件列表，该列表包含CInd和实际RIM（RIM需要该数据来生成相应的SHORIMc（通常通过对其签名而实现）），以进行运营商RIM屏蔽。RIMman根据本地可用策略来判断对所接收的列表中的哪些组件应用运营商RIM屏蔽。

RIMman通过对各个RIM签名来生成用于这些组件的SHORIM。根据本地运营商策略来确定证书参数，例如有效性周期。RIMman生成指向V_DB中SHORIMc的SHOCInd。RIMman向V_DB中附加新的SHORIMc和SHOInd。在一种实施方式中，存储所有的“旧”数据，例如V_DB中原始的CInd和RIMc，以为之后的可追溯性和回退所使用。RIMman向DMS发送（CInd、SHOCInd）对的列表，指示DMS强制对有问题的设备进行RIM指示符更新。DMS在正常的设备管理中，向设备TrE发送RIM指示符更新消息以及SHO数据，但是不进行组件更新。通过该消息，DMS可要求设备在之后的确认中仅使用SHOCInd。

除了安装SHOCInd（也可能是SHORIMc）以外，在设备上所进行的操作都取决于本地策略。精巧的设备会保存其原始制造商CInd，还可能保存相应的RIMc。为了实现灵活性，设备会尝试至少为每个组件保存用于各个运营商以及原始组件制造商/证明方的多个不同CInd。

DMS可强制设备进行状态重新确认。当设备的RIMc更新失败时，需要进行状态重新确认来避免循环操作。

现在描述运营商组件锁定的示例。作为运营商RIM屏蔽的扩展，运营商可能够对设备或其组件在外部网络中的操作进行控制和限制。这可按以下方法扩展为运营商组件锁定。应被锁定的组件部分被SHO使用例如对称密钥进行加密。对该修正过的组件执行运营商RIM屏蔽。在受保护和受控的空间内，将解密密钥发送给TrE（或UICC），该空间只能由SHO授权接入。在确认时，当PVE接收到用于该组件的SHOInd时，SHO向TrE发送授权数据。之后，将组件的加密部分发送至TrE的安全操作空间，在此进行解密和操作。

因此，SHO锁定的组件只能在设备对特定SHO确认时才能工作，该相同设备不能对另一运营商进行确认。

在另一种形式中，释放解密部分，以在TrE外部进行操作。这样做在安全性方面要弱于之前的方式，因为可通过转储（dump）设备存储器而恢复全部组件。通过所获得的完整组件，可重新生成RIM，并可成功进行对另一运营商的确认，从而解除锁定。

另一种实现组件锁定的方式不需要在TrE中管理加密秘密，或由其他安全组件（例如通用集成电路卡（UICC））保护加密秘密。可通过使用组件修改来生成运营商唯一的SHORIM、SHORIMc和CInd。之后可将该数据用于代码混淆和水印领域。

一种运营商组件锁定的示例可涉及漫游运营商拦截另一运营商的设备组件或整个设备。期望上述基于TrE的方法来保护其余自由用户设备免受此拦截。本质上，设备应当针对该过程向用户/主机方/原始SHO发出警告，并维护关于何时允许对组件进行锁定和何时不进行锁定的策略。

现在描述的示例方法用于在设备管理中，通过使用涉及特定PVM系统和运营商的特征的PVM，来对设备进行个别化。由PVM所管理的设备可处于与特定PVM系统和管理运营商相关联的可信状态。当漫游设备进入另一PVM系统和运营商的领域时，该漫游设备会出现问题，即，需要该设备证明之前由谁管理其配置和可信度。一种为该设备实现独立措施，以向另一端提供证据的方法是向该数据提供已经签发了该设备的寻址的数据。该消息的个别化证明了发送方的有意签名。一种方法可以是在数据中包含由运营商签发的Dev_ID。任何接收到该签名数据的一方都可认为其相应消息及其内容都是由进行签名的运营商专用于该特定设备的。在对方相信该进行签名的运营商正确实施了对设备认证的验证（例如，通过Dev_ID）时，这样做有效。如果这样做不合理，则可由签名运营商对Dev_ID的整个认证证书签名来代替。所签名的数据还可包括实际的RIM，由于这将建立另一个RIMc而导致添加特定的冗余，其使用Dev_ID进行扩展。

现在描述两种根据PVM建立个别化的有效方法。在一种方法中，RIMman在SHORIMc中包含Dev_ID，只有在由设备维护RIMc时，SHORIMc才可用，因此，在设备内部存储SHORIMc（其中包括Dev_ID）。在另一种方法中，RIMman或DMS向（Dev_ID、CInd）对使用运营商签名，且如果使用了SHOInd，则向该SHOInd使用相同的运营商签名。

现在描述将设备列入黑名单的示例。可以为设备建立黑名单，并根据该黑名单禁止网络接入。该黑名单可至少包括Dev_ID，可选地包括TrE信息（证明、结构、制造商、模型、序列号）。这种名单通常可由DMS访问。在一个实施方式中，每个MNO管理其自身的黑名单，而DMS可访问该名单或数据库。使用Dev_ID来查询特定设备是否被列入黑名单。之后，拒绝对该设备进行网络接入。在另一实施方式中，可维护一个通用黑名单，其中每个MNO都列出恶意设备，该数据库可由所有MNO读取。必须保证每个MNO都只能将其自身的设备列入黑名单，但所有MNO都可读取所有条目。这种通用数据库需要更多的管理和维护工作。可将上述实施方式与替换实施方式相结合。

当PVE接收到令牌T_PVM时，PVE在该T_PVM上加上时间戳，并将其转发至DMS，DMS从该令牌中获取Dev_ID，和可选地获取TrE信息。DMS通过使用Dev_ID（且如果需要或存在的话还包括TrE信息）来查询黑名单。如果设备在黑名单中，则DMS将包含T_PVM的消息作为黑名单项发送至SeGW。该消息可包含DMS的时间戳。之后SeGW可拒绝对CN的连接。

可通过使用TrE信息字段的扩展信息来实现另一种方式。其可将特定卖方、模型、序列号范围等列入黑名单。根据黑名单行为的复杂度，本地以MNO为中心的方案会比中央式黑名单更容易实施。

现在描述将设备列入白名单的示例。可为设备建立白名单，根据该白名单允许网络接入。白名单通常至少包括Dev_ID，可选地包括TrE信息，例如结构、制造商、模型、序列号。这种名单通常可由DMS访问。

当PVE接收到令牌T_PVM时，PVE在该T_PVM上加上时间戳，并将其转发至DMS。DMS可从该令牌中获取Dev_ID，并可选地获取TrE信息。DMS通过使用Dev_ID（如果需要或存在的话，可选地使用TrE信息）来查询白名单。如果设备在白名单中，则DMS将包含T_PVM的消息作为白名单项发送至SeGW。该消息可包含DMS的时间戳。之后SeGW可允许对CN的连接。

可通过使用TrE信息字段的扩展信息来实现另一种方式。其可将特定卖方、模型、序列号范围等列入白名单。根据白名单的行为的复杂度，本地以MNO为中心的方案会比中央式白名单更容易实施。另外，调节器可能会要求MNO维护黑名单，而不是白名单。

在另一实施方式中，每个MNO都维护白名单或数据库，而DMS可访问该名单。使用Dev_ID来查询特定设备是否被列入白名单。之后，授权该设备进行网络接入。

在另一实施方式中，可维护一个通用白名单，其中每个MNO都列出其自身的可信设备，该数据库可由所有MNO读取。必须保证每个MNO都只能将其自身的设备列入白名单，但所有MNO都可读取所有项。这种通用数据库需要更多的管理和维护工作。通用白名单设备的数据库会需要MNO之间建立额外的可信关系。MNO A认为可信的设备能列入白名单，并能进入MNO B。这需要标准的和/或经证明的设备确认过程来比较设备的可信级别。可选地，可以将上述方式结合实施。

现在描述用于设备的隔离网络的示例。建立用于设备的隔离网络可能需要对运营商网络进行额外改变。在该新网络中，SeGW仍可用作CN的执行屏障。由SeGW决定将哪些设备进行隔离。

隔离中的设备对CN没有直接接入，且向用户不提供或提供受限的服务。在PVE评价验证数据时，会发生确认。可根据评价结果触发新的操作。例如，可认为设备可信，并可连接至CN。在另一示例中，可检测认为设备受攻击或不可恢复。将该设备列入黑名单，并阻止其进行进一步的连接尝试。在另一示例中，SeGW将确认结果与Dev_ID和TrE信息一起转发至DMS。DMS可提供适当的更新/软件变化，来对设备进行恢复。可向SeGW通知更新，并由SeGW触发对设备重新确认。如果应用更新成功，则确认成功，可授权进行网络接入。

可将上述黑名单方法与隔离网络结合使用。这能使运营商在可能的情况下，例如通过经由OTA提供更新，来利用对设备的连接。可替换地，可使用黑名单来完全阻止设备。例如，如果设备不能被OTA措施恢复。字段内替换/服务必须重视这种设备。

如果其他设备被列入灰名单中，则将其隔离。该灰名单中所包含的设备例如是新加入网络的（来自另一MNO的）；其连接时间还未达到足够长的设备；具有可疑性能的设备；和存在安全警告（由卖方或独立制造商发出）的设备。

现在描述参量确认的示例。在PVM期间，对于所加载的组件，验证数据可能会依赖于配置参数。由于这些参数可能会频繁变化，并在同样两个设备之中不同，因此，PVM的基本实施方式允许在确认期间明文发送参数。但是，这需要保存完整的参数数据库，并要求同时在设备端和确认器端进行记录。这会产生如下影响：1）参数设置会占据大量存储器空间，并且当对其进行评价时，会减慢确认过程；和2）对每个设备大量存储和评价参数会向第三方过多暴露设备配置，造成外泄。

一种在PVM进程中包含参数的方法是基于扩展哈什值的方法，即，将参数的哈什功能结果与组件的测量相连接。参数摘要值是对组件参数值进行顺序化和二进制再现而生成的，之后使用该参数摘要对该组件现有的测量值进行扩展。因此，为了进行确认，可以以相似的方法来处理所有测量和参考值、RIM和RIMc，从而实现多种方式的参量确认。

在证书（例如X.509）与属性证书（例如，参照参数来看待的属性）的关系之间存在的类似问题，在此被表示为“属性证书的非法（rigged）哈什值”，该问题可通过在参考测量和RIMc中包含参数来解决。

现在描述诊断确认的示例。一种基于PVM概念的验证的实施方式包括在设备中不具有RIM的情况下允许加载组件的选择。可以在设备上没有运行重大安全软件和足够安全时，下载特定组件，但网络需要知道该变化。在另一实施方式中，MNO建立了策略，即通常由设备对特定组件（例如由于频繁变化）进行测量，但由网络进行确认。并且，加载和测量未知组件可以是设备的默认操作，并将确认的任务交给网络。网络可将设备隔离，该设备反过来启动设备的远程OAM修正。例如，其可返回原始状态，移除组件或采取其他措施。

现在描述对失败情况F2a的PVM诊断的示例。当PVE没有向DMS发送产生了F2a失败的组件的列表时，可按如下来查找失败组件。例如，设备可能没有保存可用于向PVE示出以便与RIM进行比较的SML。在这种情况下，DMS可以不替换设备中的失败组件——因为其不知道该失败组件——而是在正常管理过程中，将Clist中的所有组件都替换为正确组件。一旦重启和重新确认，由于未加载的组件在内部验证中失败，因此设备还可将该未加载的组件列表包含在确认消息中。PVE甚至可以通过将之前确认的Clist与RIM更新后的Clist进行比较来进行诊断。当在本地与正确的RIM进行验证时，现在丢失的组件在安全启动中是没有被加载的。这样，丢失的组件就是需要替换的组件。之后，可在第二管理周期中对这些实际需要替换的组件进行替换。

如果设备报告无法加载组件（例如RIM丢失或错误），并将该组件的测量值发送给CN，则可以使用另一种方法来进行诊断确认。根据MNO策略，可触发OAM修复进程来移除或修复组件。在另一种方式中，如果TrE检测到组件的RIM丢失或错误，则允许设备直接请求进行OAM修复。

另一种方法可禁止组件而不是对设备拒绝连接，该组件在PVM中不能确认，且不能替换/更新。在这种情况下，DMS可发送用于组件的“禁止CInd”消息，并触发该设备的重新确认。这可适用于加载了未知组件的情况。

另一种方法可由DMS指明在特定设备中允许哪些组件。如果设备在安全启动期间加载和确认了所有组件，包括不允许的组件（例如，由于最近发现了安全漏洞，但还没有可用的更新），则DMS可通过SeGW向设备发送消息，该消息使设备禁止该组件。要求该设备进行重新确认。如果在重新确认期间没有加载该组件，则DMS将该情况通知SeGW，SeGW随即允许完成认证/确认。

现在描述最小确认策略的示例。由于启动时的组件测量（例如，扩展PCR值，和将测量写入生成Clist的SML中）会在启动进程中产生一些延迟，因此，最小确认机制仅在特定情况下才要求设备进行确认。由于RIM和所存储的测量值（例如PCR值）发送部分相同的或冗余的信息，因此，消除该冗余能够节省消息和存储容量。

如果可在设备上建立本地完整性测量、验证和强制进程（例如，安全启动），则由于验证数据（例如PCR值）会包含与RIM本身相同的信息，因此仅发送在此次本地验证进程中所用的RIM就足够了。因此最小确认可以不发送验证数据，而是只发送在本地验证过程中所用的参考值。在另一种方式中，不发送RIM，而是当且仅当RIM具有唯一标识符时，仅发送对RIM的指示符。

最小确认的两个条件包括：1）本地测量、验证和强制（MVE）进程可信；2）用于在设备上存储的RIM的RIM源可信。可以将本地MVE进程的验证数据报告给外部实体进行评价。这用于信任的显式建立。可将MVE进程实现为使其不受攻击。设备稍后报告RIM的情况表明MVE进程可信。这用于信任的隐式建立。

为了评价所报告的RIM的可信度，还可以发送由卖方、其他MNO、TTP和其他方所签发的RIM证书。如果RIM证书的签发者可信，则认为RIM可信。如果所报告的任何一个RIM不可信，则可采取措施，例如将设备置于隔离网中或列入黑名单。

可对RIM和验证数据的冗余进行调整，以增加效率。例如，可要求设备仅在特定情况下，或仅以特定频率发送验证数据。例如，如果PVM系统已经检测到了受攻击的RIM；新设备漫游至该运营商区域或SHO在一段时间内未发现该设备。在另一示例中，可要求仅每进行“N”次确认发送一次验证。

现在描述用于PVM的修正示例。修正或软件更新都是设备持续服务所需的操作。设备需要修正的原因很多。除了正常的软件升级维护、漏洞修正和增强以外，修正可以是集成在设备一般的安全进程中的部分。在确认过程期间，对设备上的软件进行测量并验证其完整性。将该测量值与位于TrE中的RIM进行比较。如果验证失败，则该代码已被篡改，或RIM对该特定代码库出现是不正确的。可以启动修正过程来更新代码库或RIM，以确保设备的正确确认。

如果对一个或多个组件的设备完整性检查失败，则这表明要么是这些组件受到了攻击，要么是相应的可信参考值与设备上的代码库不一致。可以启动修正过程，至少向CN表明设备不能对SeGW认证，同时还能有助于由网络所启动的对代码库或对应于所安装的代码库的新可信参考值的更新。可通过SeGW在DMS与设备之间进行修正。

对于启动任何修正，一些共同的安全要求都是适用的。这些要求是由发生失败的安全启动进程的阶段所决定的。所考虑的最坏情况是在安全启动的阶段2所发生的失败，该失败表明建立了TrE，但没有与外部实体进行连接。因此，在这种情况下，设备不能在正常的启动中请求修正。可安全地将额外的代码库，例如FBC，加载至TrE中，用来进行修正。这种进程的安全性是以以下为特征的：1）可将FBC完全地且无变化地加载至TrE中；2）TrE可安全地执行该FBC；3）与网络实体（例如DMS）为进行修正所进行的通信会受到完整性和保密性的保护；和4）在整个过程中保护用于修正接入网络的凭证。可替换地，不用将FBC加载至TrE。FBC可与TrE同时存在，例如，作为另一个用于单独的修正目的的（可信）代码库。由于FBC存储在安全的存储器中，或受到HW安全秘密的保护，因此可产生对FBC的信任。这样，TrE就不需要运行FBC。该FBC可以是独立的，可直接运行，而不需建立TrE。

现在描述由设备启动的修正示例。在设备确认的范围内，修正可以作为检测到错误时，立即对设备进行隔离的替换方式。在自主确认的情况中，TrE是首先被验证的部分。如果其验证正确，则表明设备已经达到了预定的安全启动状态。能够这样认为是因为TrE是可靠的，且存储在TrE中的RIM是可信的。但是，这并不表明对于目前加载到设备中的特定版本的代码来说，RIM是正确的。

现在描述由网络启动的修正示例。在自主确认的情况中，如果设备确认过程失败，则可启动FBC，对包含RIM的主代码库触发软件更新。设备可发送IKEv2消息，该消息的通知负载表明设备正在执行回退模式，需要立即进行修正。

对于半自主确认方法，修正过程不需要对软件或可信参考值（TRV）进行全部更新。当设备通过了阶段1和2的确认但阶段3确认失败时，可在IKEv2协议的通知负载或证书中将涉及失败模块的信息返回给PVE。如果PVE认为所述失败模块不重要，则可继续进行确认和认证，同时所述失败模块被禁止/卸载。但是，如果所述失败模块重要，则PVE可向DMS发送信息，表明需要进行修正。

另一种情况是对于特定代码库，存储在TRE中的RIM不正确。可将失败的测量返回PVE，PVE中对信息的分析表明错误出现在RIM中，且只有这些值才需要在TRE中安全地更新。

现在描述用于呼救信号和回退代码的示例和实施方式。设备可具有回退代码（FBC）图，该回退代码图的目的是在设备完整性验证失败时，便于设备进行修正。可将该FBC存储在安全存储器中，例如只读存储器（ROM）。如果本地设备完整性验证失败，则可调用该FBC。该FBC可至少包含用于与CN中负责对受影响的设备进行修正的实体进行通信所需要的所有必需功能、方法和证书。并且，FBC还可包含用于从网络接收全部软件更新的功能。还可考虑一个特殊的“修正”DMS。

设备和TrE可在设备完整性检查失败时，执行以下修正指示过程。首先，TrE可启动对可信码进行操作，该可信码称为回退代码（FBC）。可将该FBC存储在安全存储器中，例如ROM。第二，FBC可以与预先指定的“修正”DMS建立安全连接。第三，FBC可以向DMS发送呼救信号，该呼救信号可包括设备ID。当接收到该呼救信号时，DMS就可知道该设备发生了例如完整性检查失败并请求进行维护。可选地，DMS可在接收到该信号时启动完整的固件更新过程，或执行诊断以便执行部分代码/数据更新。

现在描述不需要RIM的确认示例。不需要RIM的确认可包括在负载TrE的控制下，将组件代码安全发送至安全存储器，例如安全存储卡。不需要RIM的确认还可以包括通过加密对摘要值进行替换，从而在普通存储器中存储加密组件，例如代码。其还可以包括使用密钥或加密密钥进行加密，该密钥可以是受TrE保护并与DMS共享的，该加密密钥是由非对称密码算法得出的，其中，DMS和TrE可具有公共和私人密钥对。不允许对加密代码进行定向修改。由于对篡改数据进行解码不产生意义，因此任何对代码的操纵在解码时都会被检测出，例如在安全启动的方式中。检测这种变化可通过在加密代码中包含摘要值来实现。可使用进一步的选择，例如纠错码。

现在描述在确认过程中包含基于位置的信息的示例。一些设备可用于基于位置的信息占非常重要的地位的应用场景中，例如防盗、货物追踪、车队监控或监视。通常设备可装有全球定位系统（GPS）模块来提供地理位置数据。安全启动也可包括GPS模块和组件，来确保对基于位置的信息进行可信的生成和存储。还可额外地将位置信息安全地存储在TrE安全存储器中。之后可将位置信息包含在确认消息中。该消息可例如用于：如果所报告的位置与所需位置不符，则可通过OAM过程改变设备配置。如果设备报告了新位置，则可将其配置改变为使其使用不同的参数来连接网络、触发软件事件（例如登录、报告或关机）。可假设位置信息由可信应用安全地进行操作。

现在描述PVM在H(e)NB和M2M情况中的应用和实施方式，其提供了从通常PVM结构到现有的标准化得网络实体、协议和机制的映射。这两种应用都显示了特殊的安全需求。这两种应用具有共同点ⅰ）随着移动电话已经被看做是成熟的经典技术，对于存储和处理敏感数据来说，所述设备不再是封闭、不可变的环境；和ⅱ）通常，这些特殊设备受到移动网络运营商（MNO）以外的相关方的控制，并仅通过间歇的和不安全的链路连接至核心网。

第一种应用涉及H(e)NB，即熟知的毫微微蜂窝基站。H(e)NB是小型的便携式接入点，其向终端设备（例如移动电话）提供对3G网络的连接。H(e)NB通常设置在室内，或称为主机方（HP）的相关方的屋内。该HP在小型的指定地理区域内，用作移动通信和服务的调解器。可使用该HP在目前无法接入的区域（由于不良的无线电状况）（例如室内或工厂的环境中）提供移动服务。由于H(e)NB可以作为对宽带互联网和移动网络统一的接入点，因此其同时也是私人家庭或在家上班族（SOHO）这部分的选择。

在H(e)NB使用环境内，通过服务级别和使用协议将三个相关方，用户——HP——MNO，联系在一起。在本文中，H(e)NB存储大量敏感数据，例如表现为移动网络定制的HP认证数据、允许连接至H(e)NB的无线发送接收单元（WTRU）或用户设备（UE）列表（该列表存储为封闭用户组（CSG））、和接入控制列表（ACL）。这些数据中的一些可专门用于HP和/或用户。同时，需要对H(e)NB的位置进行控制，以保护移动网络不受干扰，和防止对服务的非法扩展。

图7表示在H(e)NB705、WTRU或UE710和运营商核心网络730之间的示例通信环境。其引入了两个网络实体，一个负责安全，一个负责对H(e)NB进行服务。操作、管理和维护735（OAM）是位于核心网回程中的功能，其向H(e)NB705提供远程管理功能。特别是，其提供软件下载和更新、无线电和其他参数设置、以及其他类似功能。安全网关（SeGW）740是H(e)NB705进入运营商核心网络730的主要进入点，其主要功能是保护网络730免受非法连接尝试和从欺诈H(e)NB或假冒H(e)NB所发出的任何类型的攻击。

第二种预期应用涉及M2M通信。M2M设备（M2ME）典型的例子是贩卖和售票机。更高级的情况还包括，对综合热电厂的遥测、设备维护和设备管理等等。如果通过移动网将M2ME连接至备份网络，则MNO能向M2ME的所有者提供增值服务，首先是通过空中（OTA）的管理。与H(e)NB类似，M2ME受到不同于MNO的相关方的控制。该相关方具有特定的与MNO不同的安全需求。H(e)NB和M2ME的安全性是重点。在这两种情况中，其各自的威胁、风险和之后的安全需求是类似的。

可将威胁分为六个顶级组。组1包括攻击证书的方法。这些方法包括对令牌和（弱）认证算法的暴力攻击、物理入侵、边信道攻击。和恶意的主机方复制认证令牌。组2包括物理攻击，例如向被操纵的设备中插入有效的认证令牌、启动欺诈软件（“重新刷机（reflashing）”）、物理篡改和环境/边信道攻击。组3包括配置攻击，例如欺诈软件更新/配置改变，HP或用户的错误配置，对ACL的错误配置或攻击。组4包括对设备的协议攻击。这些攻击威胁了功能性，并直指HP和用户。主要例子包括在第一次接入网络时的中间人（MITM）攻击、拒绝服务（DoS）攻击、通过利用工作的网络服务的弱点来攻击设备和对OAM及其流量的攻击。组5包括对核心网的攻击。这是对MNO的主要威胁。其包括模拟设备、在设备间开通流量隧道、对调制解调器/路由器中的固件进行错误配置以及对核心网的DoS攻击。在H(e)NB的情况中，其还涉及以不允许的方式改变位置。最后，其包括使用恶意设备对无线接入网的攻击。组6包括用户数据和标识隐私攻击，包括窃听其他用户的通用移动电信系统（UMTS）陆地无线电接入网（UTRAN）或演进型UTRAN（E-UTRAN）的接入数据、冒充其他用户、向H(e)NB所有者公开用户的网络ID、冒充有效H(e)NB，和通过CSG提供无线电接入服务。

核心功能性需求对H(e)NB和M2ME来说是新的，其主要涉及对不同相关方的认证和在相关方之间功能和数据的分隔，即域分隔。特别是，对HP或M2ME所有者的认证应当与设备对网络的认证相独立。并且，必须保护HP的秘密数据不被另一方（即使是MNO）访问。设备必须执行对安全性敏感的任务，并同时对接入网和所连接的WTRU执行安全策略。这必须能够至少按半自主的方式来进行，以提供服务的连续性，并避免回程链路中不必要的通信。另一个重要的安全领域是分别由OAM或OTA进行远程管理。设备需要安全地下载和安装软件更新、数据和应用程序。

这需要分隔认证地位，同时还要将对核心网的变动减到最小，从而重新使用标准的3G认证协议，例如可扩展认证协议-认证和密钥协议（EAP-AKA）。至此所构想的方法包括用于HP和/或M2M所有者的分离的认证载体。在前者中，可将其实现为所谓的HP模块（HPM），在后者中为受管标识（MID）。这两者都可以是通用集成电路卡（UICC）（即3G用户标识模块（SIM）卡）的假名。在M2M的情况中使用可拆除的智能卡产生了各种安全担忧。一方面，需要避免必须交换这种智能卡的维护操作，例如用于更新或运营商变化，因为对于在地理上分散的大型M2ME队列来说，这样做花费很大。另一个最近需要慎重考虑的选择是向设备中的安全环境下载AKA证书。一种该选择所允许的使用真正TC技术的可能结构是虚拟SIM。

在任何情况下，安全性需求以及高级OTA或远程管理，都需要M2ME和H(e)NB有特别的安全性特征。可将TrE用于该目的。TrE需要安全地与系统其他部分进行交互。观察TrE的接口很有意思，因为这些接口是TS的TCB与平台剩余部分进行通信的通用模型。基本上，在TrE的安全启动进程中初始化所有TrE接口，因此认为其正确操作。TrE接口有两种宽泛的安全类型。第一，有未受保护的接口。这些接口使得具有设备通用源的TrE免受篡改和/或窃听，所述设备通用源被认为是不安全的。即使是未受保护的接口也可从其他安全措施中获益，例如数据加密，或仅在TrE在例如安全启动期间，对经过接口的对端资源的代码进行检查后，才允许该接口可用。

第二，有受保护的接口。这些接口或使用安全协议或使用安全硬件，来对在其上运行的数据的完整性和/或机密性提供保护。如果使用安全协议，则其还可以提供认证和消息认证和/或机密性。

可在通信实体不对通信数据提供保护时，选择未受保护的接口。可当需要对TrE与该TrE需要进行通信的另一资源之间的数据的完整性和/或机密性提供保护时，选择受保护的接口。因此，TrE性能会有所不同。图8表示了H(e)NB内的TrE示例，以及其可能连接的其他资源。这是最小化的配置，该配置包括计算并向SeGW发送H(e)NB设备认证所需参数的功能、进行H(e)NB确认的功能（包括在启动时，对H(e)NB剩余部分进行码完整性检查）和最小加密功能（真实随机数生成器）。对于认证，可认为TrE可逻辑包含HPM。

可以很容易地将通用PVM描述的结构映射至现有H(e)NB结构。其数据库（V_DB和C_DB）及其管理组件对现有H(e)NB基础结构来说是新的。图9A和9B同时表示了这两种情况，通过SeGW的H(e)NB连接，和H(e)NB与HMS通过接口I-hms_d的直接连接。

图9A的PVM结构或系统900包括H(e)NB905，该H(e)NB905包括TrE910。WTRU912（或用户实体（UE））可通过I-ue接口914与H(e)NB905进行通信。H(e)NB905通过I-h接口915与H(e)NB网关（GW）918进行通信，该H(e)NB网关包括SeGW920。通常，H(e)NB905与SeGW920之间的接口I-h915可以是未受保护的，并可采用特殊措施来保证该信道的真实性、完整性和可选的机密性。可以使用I-h915来在H(e)NB905与SeGW920（从而与CN之间）建立链路。例如，SeGW920可以通过接口I-aaa975与AAA服务器进行通信。运营商可以建立适当的测量来保证接口的安全性。

SeGW920可以使用I-pve接口922来在确认期间与PVE924进行联系。PVE924可使用I-pve接口922将确认结果发送给SeGW920。可将I-dms接口930用于在H(e)NB管理系统（HMS）935与SeGW920之间所进行的与设备配置有关的通信。PVE924可使用I-pd接口932来与HMS935进行通信，反之亦然。可在设备管理过程中使用该接口I-pd932，用于设备软件更新和配置变化。

PVE920使用接口I-v926和I-d938来从V_DB940中读取RIM，HMS935可使用接口I-v926和I-d938从C_DB950中读取允许配置。接口I-r928和I-c934可由PVE920用来（例如在V-DB940中丢失RIM的情况下）与RIMman960进行通信，和由HMS935用来与CPman970进行通信。RIMman960和CPman970可分别使用接口I-rdb962和I-cdb972来读取、写入和管理对数据库V_DB940和配置策略数据库C-DB950的确认。

图9B表示了PVM982，其中H(e)NB905可直接与DMS935连接。例如在回退模式情况下，在该模式中，H(e)NB905不能与SeGW执行安全协议。在这种情况下，HMS935可通过接口I-dms_d984作为H(e)NB905的第一连接点，并通过接口I-pve986和I-pd988与PVE924进行通信，以执行确认，或至少获知哪些组件在安全启动中失败。HMS935可根据该信息进行修正操作。

可以多种方式将使用PVE的确认直接映射至H(e)NB情况。由HMS或能访问C_DB的适当扩展的实体（演进的HMS（eHMS））来执行DMS功能。

对于基于策略的更新，C_DB提供了策略，能够指明模块的重要性和模块的各个发布版本的互操作性，例如一些模块对于操作来说是重要的，而一些不是。这有助于限制更新的大小，并提供补丁，而不是整个固件更新。最简单的策略可以是将所有模块都定义对H(e)NB操作重要，这样就会执行固件更新。

当模块测量失败时，eHMS检查策略，以查找该模块的危险程度，及其对模块互操作性的影响。根据该检查，建立可用补丁列表。该补丁可以集中或单独地发送至设备，以用于应用。在其他情况中，每个传输单元都是受到完整性和机密性保护的。链路必须按顺序发送数据包，且不能丢失。当接收到所有补丁时（例如由eHMS通过终止数据包或标记来指示），如果需要的话，设备向eHMS发送所接收的补丁列表，以及其测量值，以验证更新信息，或如果由eHMS发送集中的和单独的补丁测量，则设备对补丁执行本地验证，并开始应用。在应用该补丁之后，系统在正常模式中启动，开始设备确认过程。

也可进行以下过程，每当制造商发布新的固件版本时，使eHMS向设备发送更新通知，设备使用ECB进行启动，并向eHMS发送测量。该eHMS提供补丁或完整的固件更新，之后进行相同过程。

在非基于策略的更新的情况中，一旦发生任何测量失败，HMS都通过安全链接发送完整的新固件。设备对该固件进行验证，将其应用，并在正常模式中启动。

在处于之前已知的良好状态的情况中，如果H(e)NB支持存储系统状态，则eHMS可在撤回测量失败的补丁时，要求H(e)NB返回之前已知良好状态。可使用该方法来将系统返回出厂状态。该之前已知的良好状态可以是经PVE、eHMS或S(e)GW证明的状态。

H(e)NB可返回之前已知的良好状态，可对系统状态提供完整性保护，可对之前所存储的系统状态提供恢复操作，以及可能需要在设备受攻击的情况下保护该恢复操作。

现在描述对通过公共互联网连接的设备进行确认的示例。对于通过不安全的初始链路，例如公共互联网，分别连接至SeGW、CN的设备，需要采用特殊的要求来确保确认初始步骤的安全。这些特殊要求同时还可用于H(e)NB类设备，这类设备请求从SeGW建立这类连接，并通过该连接进行确认。尽管这里描述了网络实体的H(e)NB对等物（counterpart）（例如HMS而不是PVM的普通实体），但是应当清楚，一些方法和装置只能用于非H(e)NB的设置中。通常，需要将确认和认证与初始连接的前几步相绑定，或甚至绑定到相同的数据结构中。现在描述两种方式来将确认和认证与专门协议，例如TLS和IKEv2进行绑定。

IKE、ISAKMP的传输协议定义了大量可用的证书简档，该简档允许使用正式域名（FQDN）作为ID。可将设备证书和TrE证书分开保存。但是，也可将TrE证书放入设备证书中。如果TrE具有单独的ID（TrE_ID），则可使用FQDN，但是可由制造商来对TrE进行标识，而不是运营商域名。

在IKE_SA_INIT阶段，并且在IKE对话的第1阶段完成了Diffie-Hellmann密钥交换时，一种方法可使SeGW发送第一认证交换消息来请求Dev_CERT，该消息包含CERTREQ负载。之后，设备在下一消息中使用两个CERT负载进行回复，一个使用Dev_CERT，一个则是TrE_CERT。在这种情况下，SeGW延迟Dev_CERT验证，直到PVE已经验证了TrE_CERT和评价了确认数据。之后，继续进行认证。在回复仅包含Dev_CERT的情况下，SeGW回到AuV。

如果各个ID用于不同的操作目的，则Dev_CERT和TrE_CERT之间的区别是有利的。例如，运营商可能向设备分配了网络地址，例如IP地址，Dev_CERT可对其认证，并从该地址直接建立IPSec通道。而一些类型的网络地址可能不适用于TrE_CERT。因此，设备中两个ID是有帮助的。SeGW/PVE基础结构的进一步任务是通过根据TrE_CERT，应用执行PVM和辅助认证，来为Dev_CERT交换服务。

IKE认证消息可携带任何数量任何类型的负载。在每个负载的报头，该消息可包含“下一负载类型”字段。这样，就可在一个ISAKMP消息中发送整个负载链。这可用于将证书分隔至一个或多个初始IKE会话第2阶段的ISAKMP消息的负载字段内。在图10中表示了设备1005、SeGW1010和PVE1015之间的示例进程1000，该过程使用IKE会话，将用于TrE和设备认证的证书完全分隔。从设备1005向SeGW1010发送消息，该消息包含（TrE_Cert、VAL_DAT）（1）。SeGW1010对所获得的TrE证书（TrE_Cert）进行验证（2）。如果TrE_Cert验证成功，则SeGW1010向PVE1015发送确认数据消息（VAL_DAT）（3）。PVE1015对设备1005进行确认（4），并向SeGW1015通知成功（5）。SeGW1015向设备1005发送证明请求（CERTREQ）（6）。响应于所接收的证明请求，设备1005向SeGW1010至少发送设备证明，（Sig_Dev(Dev_ID)、Dev_Cert）（7）。SeGW1010对Sig(Dev_ID)进行验证（8）。如果验证成功，则向AAA基础结构发送设备证明（Dev_Cert），该AAA基础结构回复该设备是否已知。根据本实施方式，只有通过发送由TrE所签名的确认数据以及由TrE_CERT所证明的标识而被认为确认可信的设备，才能进行设备认证。这在SeGW后对网络组件提供了扩展保护，有助于减轻DoS攻击。

在另一示例中，用于补充数据（supplemental_data）的TLS握手消息对TLS问候握手消息定义了扩展，该扩展能够在TLS握手中发送应用特定数据，例如来自PVM的确认消息。该补充数据不能由TLS协议使用，而是由应用程序使用，例如PVE确认引擎。有可能只允许存在一个补充数据握手消息，而接收到多个就可看作失败。可将所携带的数据的类型和格式指定为补充数据类型（SupplementalDataType），并可对发送方和接收方已知。

在一种方式中，可以执行双握手，从而对补充数据握手消息中所携带的执行PVM数据提供保护。并且需要确保在任何一方提供补充数据信息之前，双方经过了相互认证。

可以定义新的补充数据类型来承载执行PVM确认消息。则H(e)NB可将第一个TLS握手用于与SeGW进行相互认证。这样可使用第一个TLS会话来保护第二个握手，并在补充数据字段中向SeGW发送确认数据。

在另一种方式中，可通过在第一个握手消息中发送补充数据来在一次握手交换中发送确认数据，而不是两次。对于使用TLS会话票据（session ticket）扩展的确认连接，SeGW可在确认中使用TLS扩展，来将确认结果存储在TLS会话票据中，该TLS扩展允许服务器向客户发送会话票据，用于恢复会话和保存每个客户的会话状态。

在PVM中可使用这种会话票据用于平台管理。当特定失败组件列表的确认失败时，SeGW从PVE接收该通知，并生成会话票据。使用128位的AES对称密钥对该票据加密，该密钥不对H(e)NB公开，且该票据的完整性受到基于哈什的消息认证码（HMAC）的保护。这样，该票据就不会被H(e)NB修改，且当由H(e)NB发送时，其他网络实体能够认出该票据。之后，TrE可将该票据安全存储，并在新的TLS会话中使用该票据用于平台管理，而不需要例如再次发送确认数据。SeGW还可决定会话票据的存在时间。

之后可将AES票据加密密钥放在T_PVM中以进一步使用，或直接发送给其他实体。之后，可以将该密钥以及例如票据时间戳和详细的确认结果，从PVE发送至HMS。通过使用该TLS会话票据，H(e)NB可直接建立用于进行平台管理的安全连接。这将依赖于H(e)NB及时地跟踪平台管理，并在票据超期前联系HMS。

当H(e)NB已经通过使用会话票据所建立的连接与HMS完成修正时，可将会话票据用于重新确认。第一步是使用旧的票据从H(e)NB向SeGW建立新的TLS连接。之后，SeGW可控制该票据是来自实际已与HMS完成了管理周期的H(e)NB。在管理完成后，SeGW查找并将该票据数据与HMS所返回的T_PVM进行比较。如果找到正确的T_PVM，则可接受该使用TLS票据的重新确认尝试，从而例如防止受到使用TLS票据为重放而发起的DoS攻击。TLS票据可被接受用于重新确认，否则会认为其超期，这是因为与HMS所进行的修正过程会花很长时间。完成该操作不会对安全造成较大损失，因为SeGW具有带时间戳的T_PVM可用于比较。

现在描述进行自主确认（AuV）的PVM的示例。AuV方法不向SeGW传送任何确认数据，因此不需要为设备的初始网络连接而对现有协议进行任何改变。因此，在设备安全启动期间，PVM系统获知关于验证结果的任何事。唯一所传输的设备专用信息是Dev_ID。

AuV限制了根据平台确认结果来管理设备的可能性。特别是，没有直接的方法来区分出初始向网络进行认证的设备，和在更新后为重新确认而执行AuV的设备。如果设备管理是基于AuV的，则需要在网络中有数据库，用于存储设备状态历史。现在描述的示例方法能够有效地根据AuV至少执行基本设备管理。

现在描述用于仅能进行AuV的设备的H(e)NB修正的示例。仅能进行AuV的设备执行安全启动，该安全启动当且仅当设备完整性验证成功时，才允许设备执行设备认证过程。如果任何组件的完整性检查失败，则可认为该设备的完整性检查失败。但是，通过使用FBC图像，该设备可联系指定的HMS，以进行设备修正。

一旦与修正HMS的连接建立，则可替换H(e)NB的正常代码图像和/或可信参考值。当修正过程完成时，H(e)NB应重启，并再次重新开始完整性检查过程。

如果一组预定条件满足，则PVM可使用FBC。一个示例条件是FBC被安全的存储在设备中。另一条件是可在安全失败的情况下加载和启动FBC。而另一个条件是指定H(e)MS的地址安全地存储在FBC图像中。而另一个条件是FBC可向指定H(e)MS发送呼救信号。该信号可包括设备ID，且该消息可受到密钥的完整性保护，该密钥作为FBC的一部分安全地存储。进一步的示例条件是当接收到该信号时，H(e)MS可确定设备的完整性检查失败，需要进行维护。而另一个条件可以是FBC可包含的功能可实现由网络触发的完全代码重建。另一个条件可以是FBC可包含的功能可实现由网络发起的TRV替换。

图11A和11B表示的示例方法用于在完整性验证失败后，由FBC所实现的设备修正。RoT1100检查呼救标记（1）。如果该标记为空，则RoT1100检查TrE1105的完整性（2）。如果设置了该标记，则RoT1100加载FBC（3）。如果完整性检查成功，则RoT1100加载TrE1105（4）。如果完整性检查失败，则RoT1100设置呼救标记，并重启（5）。一旦加载了正常代码，则TrE1105对正常代码的完整性进行检查（6）。如果完整性检查成功，则TrE1105加载正常代码图像（7）。如果完整性检查失败，则TrE1105设置呼救标记并重启（8）。如果RoT已经加载了FBC，则由FBC启动，向HMS发送用于修正的呼救信号（9）。

现在描述使用AuV进行修正和配置改变的基本方法的示例。在AuV期间，唯一发送给SeGW，且可能在平台管理中使用的单独信息是设备标识。因此，一个实施方式中可向设备分配多个标识，以在AuV中使用该标识来对（有限数量的）状态（例如组件完整性验证失败）进行通知。在另一个实施方式中，可使用组ID来通知验证结果，该组ID不是专用于任何一个设备的。可根据安全启动进程的步骤来将管理标识分组。例如，DevM_ID3b用于通知阶段3b失败，DevM_ID3a用于通知阶段3a失败，和DevM_ID2用于通知阶段2失败。阶段1失败不能通知，因此此时设备缺乏通信能力。

在另一AuV使用情况的例子中，设备可在失败和执行回退代码后尝试连接HMS，作为下一步操作。

在阶段2中某一个或多个组件的失败并不能表明该设备不能进行通信。应将该阶段理解为属于特定类型的组件分类。只要在阶段2中加载了最关键的组件，设备就能够将其状态和失败组件发送给PVM系统。这种情况是如果设备上有策略管理器，该策略管理器由HMS维护，并提供标准框架，在该标准框架下都能进行连接。

为了安全性，必须将DevM_IDn和相关认证数据（例如私人密钥）保护好，否则攻击者会进行欺诈攻击，从而破坏管理过程。这是十分危险的威胁，因为管理ID对大量设备都是相同的。一种解决办法是仅使用该信息来设计平台管理过程。通过将第一确认绑定到重新确认，能够为唯一设备通知管理进程的成功，该第一确认通知某些未知标识的设备的失败。确定有多种方法可执行该操作。在一个示例中，在设备已经认证了管理标识中的一个之后，SeGW运行补充协议，设备必须在该补充协议中对原始Dev_ID进行认证。在另一种方法中，通过交换特定秘密，设备和PVM系统以及特别是SeGW建立了管理会话，该管理会话覆盖第一确认过程和第二重新确认过程。

现在描述补充认证协议的示例。设备和SeGW已经完成了对设备的第一认证协议，设备在该第一认证协议中对其管理标识DevM_IDn中的一个进行认证。其中，假设它们已建立了加密的和经认证的通信会话。之后，设备可只发送Dev_ID和用于该Dev_ID的认证数据。例如，可通过该建立的安全信道来发送签名消息和公共密钥证书。这就确保了没有其他方知道该请求管理的设备的标识，也不会使用该信息来破坏管理过程，即，不会在重新确认前使设备无效，或假冒该设备。

SeGW将DevM_ID和Dev_ID发送给PVE，PVE将其插入需要管理的设备列表。之后，PVE将所需的设备管理操作通知给DMS，例如“安装阶段2回退代码”。DMS通过之前由SeGW所建立的安全信道，将相应代码下载至设备。在正常PVM中，之后系统启动设备的重新确认。

当管理成功时，之后设备在AuV中对其原始Dev_ID进行认证。SeGW将其通知给PVE，PVE在重新确认列表中找出该Dev_ID，并将其删除。否则，设备可再次对管理ID进行确认，也将该管理ID找出，并根据策略进行进一步操作。

现在描述建立管理会话的示例。该实施方式与其他实施方式的不同之处在于PVM对唯一的单独设备进行管理。可在设备与SeGW之间的通信协议中建立该管理会话。这种方法的作用是实际通过建立假名，使设备标识对PVM系统保持未知。

在正常的协议执行中，可能会限制协议建立这种永久秘密的能力。例如，公共密钥建立协议，例如Diffie-Hellman（D-H），满足一种称为联合密钥控制的属性，使得所建立的密钥依赖于双方。也就是说，双方向协议中插入（伪）随机信息，以在每次执行中产生不同密钥。覆盖了多方的会话执行不能使用这种协议来建立。

因此，SeGW和设备必须在特殊的协议中建立秘密，例如通过使用发问（challenge）-响应。可由设备或SeGW引起发问，该响应必须满足，在第二个执行（即重新确认）中的第二个回复与第一轮中的回复相同。在简单的实施方式中，设备只需在重新确认中示出从SeGW所获的现时，而SeGW在表中查找该现时。因此该现时为假名。可使用更复杂的加密协议。

之后，可按上述来进行重新确认。但是，其区别在于，在此方法中，SeGW由于操作原因而对重新确认的设备的信息进行维护，因为该信息会在SeGW与设备间的重新确认所用的协议执行中被使用。

现在描述用于H(e)NB的基于OMA设备管理（DM）的结构的示例。OMA DM是由开放移动联盟（OMA）设备管理（DM）工作组和数据同步（DS）工作组所联合规定的设备管理协议。OMD DM是为小型移动设备而形成的，例如电话或PDA。其不支持设备与DM服务器之间的宽带有线连接，而仅支持短距离有线连接，例如USB或RS232C，或无线连接，例如GSM、CDMA或WLAN。但是，其可用作H(e)NB（尤其在将自身作为与之连接的CSG和非CSG WTRU的基站的同时，还将其自身作为核心网的WTRU的H(e)NB）的设备规定和管理协议。

OMA DM所用于支持的使用情况，例如提供，包括首次设备配置和实现或禁止特征、设备配置更新、软件升级和诊断报告和查询。虽然设备可以可选地执行这些特征中的一些或全部，但OMA DM服务器端可支持所有这些功能。

可将OMA规范优化为对连接受限的小型设备支持上述特征。其还可使用认证支持集成的安全性（例如通过使用类似EAP-AKA这样的协议）。

OMA DM使用XML（或更准确地，SyncML的子集）来进行数据交换。这可用于提供一种标准化同时灵活的方式，来为了确认的目的，而为软件模块或H(e)NB的功能定义和传输属性。

在DM服务器与客户端之间进行设备管理，该DM服务器例如是设备的管理实体，该客户端例如是被管理的设备。该OMA DM支持传输层，例如WAP、HTTP或OBEX或类似传输。DM通信由DM服务器通过使用通知或报警消息，采用任何可用方法（例如WAP推入或SMS）来异步启动。一旦在服务器和客户端之间建立了通信，则可交换消息序列，以完成指定的DM任务。

该OMA DM通信基于请求-响应协议，其中，通常由DM服务器发出请求，而客户以回复消息作为响应。服务器和客户都是记录状态的，即在内建的认证过程之后，可出现由于特定顺序而进行交换的任何数据。

由于DM通信可由DM服务器来启动，因此通过DM执行PVM可能需要基于服务器查询的方法来进行确认。例如，可以采用使用了IKEv2的设备认证过程，该过程可由设备启动。可考虑将多种不同消息类型作为确认数据的承载。例如，可在失败软件模块或设备功能列表中发送。在另一示例中，可从设备向服务器发送管理报警消息。可替换地，还可考虑通用报警消息（在来自设备或服务器的至少一个管理报警消息传输之后，该通用报警消息只能从设备发送至DM服务器）的使用者。这些消息（包括报警消息）可使用SyncML格式，该格式在指定内容和用于该内容的元数据方面具有灵活性。这可用于确认信息传输。DM还可支持分段数据传输，这可用于软件更新，其中更新的大小可能很大。

虽然最早的DM通信必须由DM服务器来启动，但是之后的通信可由DM客户使用继续会话来启动。DM客户（例如H(e)NB或M2ME）的这种能够启动会话中的通信的能力可用于由设备启动的任务，例如由设备启动的重新确认或由设备启动的确认消息传送。

现在描述在认证证书中绑定确认的示例。在认证证书中绑定确认能够实现确认和认证的结合，从而自动将设备的认证ID与确认绑定。之后，将确认消息放在认证证书的附加字段中。例如，通过使用IKE协议，可以选择地将这种验证数据放在通知负载字段中。

如果验证数据存储在认证证书内，则每次设备配置改变时，都必须发布新的合并的认证/确认证书。必须由SeGW来控制生成该证书，因为SeGW是负责为PVM目的进行Dev_ID认证的实体。这可至少以两种方式来执行。第一，SeGW或从属实体可在从DMS接收到更新的Clist之后，生成该新证书。第二，设备可自己生成该证书，并将其发送至SeGW和PVE，由SeGW对其签名，并将其发送回设备。

SeGW可在成功进行某种重新确认之后，结束该过程（或者生成并发送新证书，或对由设备所生成的新证书进行应答）。这是为了向PVM系统确保新配置实际到达了设备。

由于当设备配置变化时可能会需要新证书，因此该周期涉及CN中的全部三个实体及设备。DMS触发配置变化（例如对软件和/或参数的更新），并将新的所需状态保存在策略数据库C_DB中。在将该变化应用至设备后，需要进行重新确认。

在示例情况中，设备应用该更新并执行重新确认。设备可使用新软件，但不能使用新证书，直到完成了重新确认（特别是对成功的更新进程的）。此时，设备使用旧的证书来运行新的软件配置，该旧证书与设备的实际配置不相匹配。响应于此，向设备提供新证书用于设备认证；当且仅当已经应用了更新时提供；且需要确保在没有应用更新时，不能使用该证书。

现在描述撤回设备认证证书的示例。如果在设备认证期间，SeGW判断需要撤回该设备所发出的用于进行设备认证的设备证书，则SeGW可向设备指示由于证书撤回而导致设备认证失败，并之后将该设备从网络维护的白名单中删除，或反之，加入到网络维护的黑名单。设备在接收到该指示时，就可知其证书已被撤回，且其标识已从白名单中移除，或反之，加至黑名单中。之后设备可执行操作，将其自身重新建立为网络中的有效实体。

如果设备ID失效，设备证书过期或发出H(e)NB设备的由可信第三方运营商授权的实体及其相关证书请求网络撤回证书，则SeGW可将设备证书撤回。

现在描述基于证书的确认基本方法的示例。绑定证书是签名数据组。其由发出者、SHO、或其SeGW或负责管理证书的等同实体进行签名。证书中的签名数据至少包括Dev_ID、用于认证和确认的设备公共密钥和Clist。

该证书可在确认和认证的合并消息中发送给SeGW。后者是（部分）由设备使用其私人密钥进行签名以用于认证和确认的消息。该消息可包含其他数据，例如时间戳和/或现时，用于防止重放。SeGW检查证书和消息的签名，并按正常过程进行确认。

现在描述证书交换的示例方法。通常可以采用两种方式。将其称为证书前交换和证书后交换。其区别在于重新确认使用旧的还是新的证书。这两种方式都确保自动执行所有所需步骤，即，要么全部执行，要么全都不执行。起始状态是设备使用旧证书运行旧配置，结束状态是新设备配置和新设备证书。可能需要由独立TTP或制造商来创建、管理和控制认证证书和RIM证书，从而设备可在多个网络中使用，而不是将其固定在一个运营商上。可替换地，新设备证书可由例如开放移动联盟（OMA）进行处理，以用于设备管理（DM），可将其扩展为包含证书。

在证书前交换方法中，更新包括新证书，因此，在更新完成前证书进入设备。当应用更新后，设备使用新证书进行重新确认。在CN中使用合适的存储器和数据结构将该设备标记为“正在进行更新”。例如，在认证数据库中设置标记。另一种方法是使用确认令牌T_PVM。

现在描述证书前交换流的一个示例。如标准PVM中一样，DMS将更新和/或改变的组件发送至设备。之后DMS向SeGW发送新的Clist。DMS向SeGW传递T_PVM。这时，SeGW（从而PVM系统）进入状态，其中其等待设备对新配置进行重新确认。SeGW收集需要的信息（Clist、Dev_Id、设备公共密钥等），并生成新设备证书。之后，SeGW将该新证书发送至设备，之后结束与设备的通信会话。

现在，SeGW具有从DMS所获得的T_PVM，并从而知道应等待设备的重新确认。其在内部重新确认列表中存储所有用于这样的设备的T_PVM。假设设备正确安装了更新和新证书，则进行以下进程。设备启动重新确认，在确认消息中发送新证书。SeGW通过验证签名数据和设备证书来对设备进行认证。SeGW在重新确认列表中查找T_PVM。进行重新确认，其中使用来自之前的确认的T_PVM（且不再生成新的）来维护PVM系统状态。在SeGW处而不是PVE处进行该步骤和之前步骤，否则SeGW会自动生成新令牌。因此为SeGW进行重新确认列表维护。

如在标准PVM中一样，在多轮重新确认中连续使用T_PVM有助于检测重复出现的更新失败和其他形式的性能异常。

在进一步实施方式中，TrE具有可信更新服务，该服务允许HMS向设备发送更新，之后在安全可信的进程中应用该更新。可以依赖安全启动来确保TrE中的更新服务的完整性。当HMS使用新更新时，其可向SeGW发送令牌，该令牌包含新更新的设备配置。之后，SeGW可为设备创建新认证证书，并将其附加在令牌上，将该令牌发回HMS。HMS包含新证书，以及用于设备更新服务的更新数据。该数据包可为TrE加密，并由HMS签名。可信更新服务接收该更新数据包，验证签名，解密数据，应用更新，并在安全存储器中存储新证书。之后，TrE向HMS通知更新成功。由于可信更新服务由安全启动所保护，因此更新过程可信，从而不需要重新确认。根据更新的类型，可能需要重启。在这种情况下，设备可使用新证书在SeGW进行认证。因此，HMS必须确保通知了SeGW关于所要进行的重新确认。

在另一实施方式中，如果在设备上不存在可用的可信更新服务，则可将新证书与新软件更新一起提供，这样证书由密钥加密，该密钥与成功安装更新相绑定。这种方法及其所涉及的问题还需要更多考虑。

在证书后交换方法中，更新可以不包括包含新设备配置的新证书。设备使用旧证书进行重新确认。在重新确认成功后，CN激活新证书，并将新证书发送至设备。由于可能没有新配置来进行安全启动，因此将新配置发送至设备，尽管此时设备还没有新证书。

现在描述运营商RIM屏蔽的示例。可以使用无线局域网（WAN）管理协议来用于设备的远程管理。图12表示签名消息格式1200的示例图，该消息格式允许从发布者向设备下载软件数据包。该格式允许在一个签名数据包中发送一个或多个文件，例如固件更新或配置数据包。接收设备能够对源进行认证，并包含安装该内容的所有指令。

报头1205可包含格式版本和命令列表及负载组件的长度。命令列表1210包含可被执行用于安装数据包中所含文件的指令序列。签名字段1215可包含数字签名，由报头和命令列表组成该数字签名所签发的消息数据。虽然所签发的消息数据仅包含数据包报头和命令列表，但是由于所有涉及负载文件1220的命令都包含文件内容的哈什值，因此该签名可确保整个数据包的完整性。

在运营商RIM屏蔽的情况下，DMS对命令列表签名，并将软件更新数据包及其各自RIM放在消息的负载中。之后，设备的TrE使用公共密钥对DMS的签名进行验证。可在制造或配置时，或由运营商信任的CA，使该公共密钥为TrE可用。可将所有对公共密钥进行验证所需的根证书安全地存储在TrE中。命令列表则包含安装软件的命令和用于使设备获得RIM的命令。这向运营商提供了有效的方式对设备上的软件和RIM安装进程具有完全的控制。在这种实施方式中，不会出现向设备显式地传输RIMc。

现在描述使用第二代码库进行修正的示例。安全启动失败，例如在通用PVM设备模型中阶段2失败，会在比TrE更大的范围上产生问题，该问题是TrE用于向加载至正常操作空间的修正组件扩展信任时不可信。因此，为了启动修正，需要调用FBC，但是需要在TrE内部运行，以至少用于最重要的功能性加密和修正协议栈。

在特定情况下，可以从外部安全源，此处称为FBC载体（carrier），获得FBC。这可由以下进程完成，该进程一部分在带外，且可以要求人工参与，例如向H(e)NB设备插入智能卡。该过程可通过将第二安全组件（智能卡）用作FBC载体（该FBC载体安全存储并保护FBC代码）或通过在修正初始化过程中明确要求人工参与，来提供增强的安全性，以减轻简单自动的DoS攻击，并可按照约定定期的从HP中获得。该外部载体FBC可以是保证设备简单便宜、TrE简单的措施。该外部载体FBC可承载FBC的可执行二进制代码，包括修正所需的所有秘密，当需要时，还可额外为FBC提供安全的操作环境。在设备位于远程或难以接近的位置的情况中，不再适用使用单独的FBC载体。此处所述的在三个实体之间建立信任的进程与之前所述的各种“可传递的信任”过程相类似。

以下过程可用于外部FBC载体，例如UICC、智能卡或具有其自己的处理单元的安全存储卡。TrE是依赖方，其要求加载经授权和认证的FBC代码。另一方面，只要用于修正的凭证一直受到保护，向未授权方显示FBC代码风险就较小。因为要执行带外过程，TrE向FBC载体的认证不是太大问题，在该带外过程中，TrE和设备实际并不完全可信。这也是载体不应向设备显示用于HMS接入的凭证的原因。可能需要显示FCB，但风险较小。

因此，可使用以下授权或通信顺序。该带外或人工参与的步骤只是为了表示特殊使用的情况，在其他方法中可使其自动化或集成，例如将FBC载体嵌入H(e)NB中。在这种基于回退代码的过程中，通信可能会非常简单，因此可将认证和授权结合在单个协议步骤中。

首先，阶段1的启动成功，阶段2的启动失败。TrE停止，进入“等待FBC”状态，并闪烁LED，或提供其他类似的失败指示。用户/HP插入FBC载体。在本实施方式中，FBC载体，例如诸如主机方模块（HPM）的智能卡，通过使用特定物理接口来通知FBC载体的授权秘密的存在和/或提交，例如OTP或签名现时，来将其自身向TrE授权。在TrE和FBC之间，建立安全关联（SA），即加密和受完整性保护的通信会话。之后，将FBC加载至安全环境中，该安全环境可由TrE或FBC载体或这两种环境性能的任何结合来提供。之后，如果需要的话，可对FBC进行整体性检查，之后对其加载并启动。

在安全启动后，FBC使用秘密向载体表示加载成功，并在TrE（FBC）与载体之间创建新的SA。用于修正的凭证留在载体中，但FBC包含用于HMS发现的数据。FBC联系HMS。通过使用受智能卡保护的凭证，在智能卡和HMS之间建立端对端SA，该凭证依然完全对TrE（FBC）不可用。现在，HMS得知有效TrE（FBC）请求修正。智能卡将通信会话交给TrE（FBC），TrE（FBC）向HMS展示其ID。HMS启动修正过程。该授权秘密需要保护好，因为这类连接可用于多个设备，因此其破坏是灾难性的。一种用于执行授权的方法将受TPM保护的授权秘密（例如160位HW保护的值）用作获得所有关系过程中所创建的。根据该实施，可直接从FBC载体启动FBC，之后FBC载体必须提供安全可靠的操作环境。在这种情况下，甚至还可取代受攻击的TrE。一个例子可以是当FBC载体包含安全组件时，由微处理单元和存储器独立操作FBC。可通过公共接口（例如USB、JTAG）将FBC载体连接至设备，并直接向设备内的组件认证，之后取代受攻击的组件和可能的TrE组件。在另一种方式中，如果使用了签名代码图像，则FBC载体设备可取代包含签名的图像。

由于在一些情况中，由于TrE不是完全可信的被用于正确加载和操作FBC，且在多数情况下，其不能对加载至FBC载体中的FBC进行确认，因此需要进行一些安全增强，从而FBC载体必须在远程代码库执行中建立信任。例如，FBC载体可生成一次性秘密，并使用混淆方法将其嵌入FBC中。可替换地，载体可与FBC一起，或紧随FBC之后，发送另一授权秘密，该秘密只能由成功启动的FBC识别和使用。该秘密由成功启动的FBC用于从TrE中受保护的空间获得紧接着下一步通信中所用的通信秘密。

现在描述为回退代码使用内部并行码库的示例。内部并行码库可包括触发机制和实现修正所需的回退代码库。例如，H(e)NB可包含两个代码图像，一个是正常模式，一个是回退代码图像（FBC）。可在各个阶段中对AuV和SAV都执行正常模式调用。在阶段1中，ROM中的RoT对TrE进行验证。如果TrE有效，则可检验下一阶段的组件。如果之后任何组件的完整性检查失败，则将代码卸载回到TrE代码的开端。此时，TrE可开始检查回退（例如修正）代码。如果回退代码通过了完整性检查，则将其加载并启动。该回退代码可包含设备管理（DM）码的一些最小集合，用于与HMS建立连接。一旦与HMS建立了连接，则可标识出失败的模块，并将更新发送至HNB。在修正进程完成时，H(e)NB可重启，并重新开始确认进程。可保持回退代码尺寸较小，以促进与HMS进行通信。由于代码可“回退”至TrE中，且使用回退代码进行加载，因此可不需要触发机制或寄存器。

现在描述另外一种形式的“混合（内部/外部）码库”。可在例如上述并行码库的情况中将FBC存储在设备内，但是，FBC在设备上是加密的，并受到完整性保护。不能使用TrE自身来对FBC解密，否则，受攻击的TrE会导致FBC本身受到攻击。该混合方案将用于FBC的解密和验证密钥存储在外部安全组件（例如智能卡或UICC）上。在启动失败的情况下，TrE通知该失败，并要求用户/HP向设备中插入认证令牌，即智能卡。根据设备属性，两种选择可用。在第一种选择中，认证令牌只存储密钥内容，并与TrE进行相互认证，在该相互认证之中或之后，TrE接收所需密钥内容。TrE对FBC执行完整性检查和解密，之后加载并启动FBC。在另一种选择中，对认证令牌进行改进，使其能自动对存储在设备上的FBC进行验证和解密，之后或者通过仅使用设备资源（例如，使用部分TrE来提供安全的执行环境），或者通过在该认证令牌自身内部所提供安全的、可执行FBC的执行环境来执行该FBC。这种方式能够允许使用设备较大的存储空间进行FBC存储，还合并入了附加外部安全元素的安全性。

现在描述用于使用内部顺序码库的实施方式。设备管理协议可在远程设备上定义用于安装和改变软件配置的协议和命令，并可包括“重启”命令。其可以不包括获知发送“需要修正”消息的设备。但是，通过将例如SAV的确认结果与设备管理协议相结合，HMS可使用设备管理协议来对软件组件启动重新安装或重新设置，并之后发布用于重新确认的重启命令。

可替换的，FBC能够删除或卸载部分正常代码，只留下剩余的正常代码，并启动重启，重启之后进行重新确认。可对FBC预先规定需要删除或卸载的正常代码的列表。可替换地，FBC可从外部安全组件（例如智能卡（例如HPM））获得该列表。可替换地，FBC可从基于网络的实体（例如H(e)MS）获得该列表。

为了使该机制安全操作，设备上可能需要有可信应用程序，该可信应用程序可包含以下属性：完整性受保护；在设备中安全地存储；能在安全启动失败的情况下启动；向HMS建立（安全）连接；能够对来自HMS的软件和命令上的签名进行验证；能够对设备上的软件进行安装/卸载；以及能够对设备需要修正进行报告。

可以使用可能冗余的第二码库来负责该应用程序。从上述描述和根据上述要求，该第二码库向设备中引入一些额外的冗余码。在设备中正常、成功的安全启动的情况下，可能会需要该码库所提供的所有特征。第二码库的所有特征都可在第一码库中存在。

另一种方式是用顺序设计代替并行设计。这会涉及以下顺序。一旦成功，RoT验证并启动TrE。之后，一旦成功，TrE对修正代码进行验证。一旦成功，TrE对剩余的软件组件进行验证。如果不成功，TrE存储失败模块，并设置标记，表示设备需要修正。之后，TrE触发设备重启。一旦重启，对修正代码进行验证后，TrE传送对修正代码的控制，并释放失败模块列表。之后修正代码可为设备修正进程使用该列表，并联系HMS。

现在描述使用安全性策略属性的SAV的示例。向PVE通知哪些模块的内部完整性检查失败可包括为H(e)NB的所有结构和模块建立所有SW模块的标准化列表。也可生成安全性策略属性（SPA）的标准化列表。该SPA可以是策略，该策略通知PVE如果特定SW模块的完整性检查失败，应当采取怎样的操作。PVE不需要知道其他有关该失败模块的信息。

可对SPA码进行标准化，其可包括以下代码。“00”模块失败可表示网络接入被拒绝。所有这种类型的模块都会是在阶段2中，但在阶段3的模块中也包含该码可实现灵活性。“01”模块失败可表示允许暂时网络接入。如在修正部分所描述的，设备可使用该暂时网络接入来进行修正，例如通过使用修正中心来修正失败的SW模块，且如果修正不成功，则可停止网络接入。“02”模块失败可表示允许网络接入。这可以是指允许对失败SW模块进行修正的修正中心，并可在修正不成功时，保持网络接入。“03”模块失败可表示允许网络接入。其可删除/禁止/隔离失败的SW模块，并且如果操作不成功，可停止该网络接入。“04”模块失败可指示允许网络接入。其可删除/禁止/隔离失败的SW模块，并且如果操作不成功，可保持网络接入。“05”模块失败可表示允许网络接入，并可忽略SW完整性失败。“06”可指示其他失败。

可将单个SPA与H(e)NB中的每个阶段3的SW模块相关联。则SW模块的实际标识符可由H(e)NB的每个构造和模型所有。在SAV中，H(e)NB已向SeGW发送了H(e)NB_ID，网络可使用该H(e)NB_ID来标识H(e)NB的构造、模型和序列号。对于每个阶段3完整性检查失败，H(e)NB在通知负载中放入其所拥有的SW模块ID和相应的SPA。如我们现有的每个SAV机制一样，该负载被转发至PVE。

PVE检查SPA，如果存在任何SPA=00，则SeGW不被授权对H(e)NB准许接入。如果SPA=01或02，则触发修正进程。PVE发送H(e)NB_ID和SW模块ID。修正中心可使用H(e)NB_ID来对其所拥有的SW模块ID进行交叉参考，这样其可向H(e)NB下载正确的更新。

如果有任何SPA=03或04，则PVE可向SeGW发送适当的指令。如果有任何SPA=05，则H(e)MS或其他网络组件可存储用于管理目的的数据。

可选地，非00的SPA可能会涉及一些重启/重新确认和ACK消息。SPA=00与AuV的最终结果一样，除非网络现在具有一些关于不良H(e)NB的信息，且可采取管理操作。可选地，可不通知PVE关于通过了完整性检查的模块。

如果FBC支持基本通信，则可将PVM扩展为包括阶段2模块的失败。SPA可以是包含SW模块ID的对象的一部分。需要将其存储在TrE中。不能将其作为SW模块的一部分进行存储，且在SW模块的完整性检查失败的情况下，其不可信。

根据风险评价进程，分配给每个SW模块的SPA与每个H(e)NB提供者一致，其作为SW栈的类型确定进程的一部分。一旦提供者与运营商建立了联系，则向新SW模块分配SPA就变得简单。根据之前成功的类型确定，信任由所建立的提供者来分配适当的SPA。

为了减少对H(e)NB结构的SW结构进行标准化的需求，H(e)NB的SW结构可按码块的方式来定义，其中根据完整性检查或可修正的内容，来将该块定义为最小原子块或量。不可定义各个块功能。例如，从完整性检查的角度来看，所有的阶段3SW可作为一个单独的块。可替换地，可将块1：1地映射至实际的SW应用程序，或应用程序内的敏感对象。可将SPA应用至SW块。当由于01或02的SPA而调用修正中心时，其下载所需块。块ID可涉及卖方，其结构可以不是标准化的。

如果在设备确认中使用了SPA，则可将SPA安全地存储在TrE中，并与SW标识符绑定。这可例如保证，不会为另一具有00-SPA的组件重放05-SPA。因此，PVE能够验证所接收的SPA实际属于H(e)NB中所加载的组件。

可使用由设备最早的初始网络连接所启动的登记进程来将SPA从设备安全地传输至C_DB，并存储用于以后使用。之后，设备可以报告失败组件的SW_ID，且PVE能够从本地数据库中取回相应的SPA策略操作。这可用于低带宽连接的设备。

现在描述用于对SPA进行分组的实施方式。如果将SPA本地存储在TrE中，则TrE可检查所有失败代码及其SPA，对其进行处理，并发送更加概括的阶段完整性检查。失败模块及其SPA可包括表1中所示的情况。

失败模块ID	SPA
		00	01
01	01
		02	03
03	03
		04	03
05	04

表1

TrE可对表2中所示的数据进行处理。

SPA值	模块
		01	00,01
03	02,03,04
		04	05

表2

可发送由SPA所指示的具有不同失败级别的模块列表，而不是所有SPA值。

因此，当在通知消息中定义了一些比特块时，可具有如表3所示的映射关系。

SPA	模块值
		00	空
01	00,01
		02	空
03	02,03,04
		04	04
05	空

表3

数据的紧密度依赖于预期失败模块的数量。例如，如果对于大部分SPA，都有平均多于1个模块失败，则数据会更紧密（compact）。

图13表示通过远程证明进行确认的方法的示例图。确认实体1300接收SML和签名的PCR值。该SML包含扩展到各个PCR中的所有文件的有序列表。确认实体1300对SML中的每个项执行以下步骤。确认实体1300查询指定文件名是否存在于已知良好哈什值的本地数据库1310中（1）。该数据库1310包含所有认为可信的文件名和二进制RIM（例如哈什）。如果在数据库中找不到文件名，则认为其不可信（2）。确认实体1300可将RIM与SML所报告的测量值进行比较（3）。如果不匹配，则平台的二进制值已被（用户、不良软件或其他实体）改变。在这种情况下，平台不可信（4）。确认实体1300可对虚拟PCR执行扩展操作（5）。实质上，确认实体所执行的操作与平台在执行和测量期间的完全相同。在该进程结束时，将虚拟PCR值与平台所报告的值进行比较（6）。如果不匹配，则SML已受到篡改（例如，如果从SML删了一行，但向PCR提供了哈什值，则虚拟PCR与所报告的PCR不匹配）。则认为该平台不可信（7）。

作为一种用于报告Clist中的所加载的组件列表，或用于报告在F-SAV情况下失败的组件列表，或用于报告测量的方式，可在模块间采用分级关系来减少所要报告的组件数量，并用于时间延迟要求。在图14中表示了示例安排。这种安排向模块自动引入了自然顺序。因为由于OS、协议栈、管理模块和其他模块的原因而使可能模块的数量很大，因此模块数量可以很大。

在成功的安全启动之后，PVE或SeGW必须向设备发布证书，该证书指示成功启动。这种证书包含的信息元素例如是TrE_ID、（软件、硬件的）版本号或软件的哈什值和安全时间戳、设备位置、模块哈什值、模块Clist和其他相关信息。

这种证书可用于失败的启动。在这种情况下，可将信息发回PVE，PVE可认证性地验证所报告的版本号是否正确。由于PVE是证书的颁发者，因此，其可采取适当的步骤。所不同在于，PVE不像设备指示启动成功状态的情况一样，由于信任而对设备依赖。但是，只有在PVE至少相信其从设备所接收的任何信息都涉及其启动失败状况时，这才有效。因此，在这种情况下，可将设备设计为使其能够检测启动失败，并将向PVE报告其状态，其未受破坏且未受攻击。

还可将证书用于启动成功。在这种情况下，在之后的安全启动进程中，设备可以发送测量的哈什值或测量，以及由PVE所发布的最后一个安全启动证书，或指向该证书的指针。通过这种操作，PVE可以验证是否存在任何恶意变化。

证书还可用于设备在一个地理区域内或运营商领域内启动并移动至另一运营商领域中的情况。这种情况出现在地理跟踪设备中。为了验证跟踪数据，需要知道设备是否成功启动，以及所生成的数据是否真实。可向这种成功启动证书提供由设备所生成的数据。在证书内，可以包含当成功实现启动时设备所处的位置。之后，当这种证书的第三方接收方试图验证证书真实性时，可（优选地，使用不依赖于设备内部对位置信息进行处理的方法，例如基于GPS的方法）来检验设备的目前位置，并查看所获得的目前位置是否与证书中的位置相匹配。如果不匹配，则证书接收方可向设备或管理设备重新确认的网络实体请求对设备进行新的安全启动和之后对完整性的重新确认。当终点网络需要知道关于上一次成功启动的环境和配置（包括位置）时，这种包含关于上一次执行成功启动地点的位置信息的证书还可用于中途失败的情况。

如此所述，PVM可使用任何形式的确认。通常，三种主要方法是AuV、SAV和远程确认（RV）。每种方法都处理测量、报告和强制的步骤，这些步骤与设备完整性确认产生不同的关联。AuV在设备本地执行所有三个步骤。RV在本地执行测量，之后将测量报告给外部实体。由外部实体来进行强制。SAV本地执行安全启动，向外部实体报告测量，并允许重新确认。

特别是，使用SAV的设备可执行信任状态测量的直接评价，并建立初始网络连接。可向外部实体，例如安全网关（SeGW）报告评价结果，以及相关参考度量。可选地，可以报告测量和参考度量的子集。

确认报告可基于H(e)NB特征实现对H(e)NB信任状态的评价，该特征例如是其平台结构、安全性结构、安全性策略和设备证明。确认报告可包括关于H(e)NB的信息、TrE能力、测量和验证规则、TrE的安全策略管理器能力、测量结果、平台级别证明信息、上一次启动时间、或启动计数器。

设备信息可包括例如制造商、结构、模型号、版本号、硬件构建或版本号或软件构件或版本号。TrE性能可包括例如测量、验证、报告和强制性能。

该测量和内部验证规则信息可包括在安全启动期间执行信任状态测量和内部验证的方法。例如，可以包括覆盖范围，例如组件加载的名称、类型和顺序。可以包括组件验证的方法，例如验证中信任链的数量和范围。可以包括用于测量和验证的算法，例如安全哈什算法1（SHA-1）扩展。还可以包括寄存器范围，例如在启动验证中所涉及的平台配置寄存器（PCR）。

TrE的安全性策略管理器能力可以包括涉及实现和强制安全性策略的信息。测量结果可以包括内部报告和验证的实际测量值，例如签名PCR值。平台级别证明信息可以包括通常关于H(e)NB的信息，或特别地关于TrE的信息。上一次启动时间可以包括关于何时执行上一次安全启动的安全时间戳。

启动计数器可以包括计数器值，该计数器在出现功率循环时，和进行安全启动操作时增加。该计数器可以是受保护的计数器，其不能被重置或反向，只能向前计数。当设备首次初始化时，可将该计数器值初始化为零。

可通过将信息绑定至认证协议（例如互联网密钥交换协议版本2（IKEv2）），来经由认证和确认的结合过程，将确认报告绑定至H(e)NB。确认报告可包括证书。可选地，证书中可包括所述信息中的一些。

可替换地，确认报告可包括对提供信任状态信息的可信第三方（TTP）的指针或参考，外部实体可从该TTP获得信任状态信息。例如，确认报告可包括对单独的设备信任证书的参考，该证书包含信任状态信息。

响应于在评价期间所遇到的异常，外部实体可以拒绝网络接入。外部实体还可以评价测量和参考度量，并可以检测H(e)NB未检测出或未报告的错误。可替换地，可向H(e)NB许可进行受限的网络接入（隔离）。否则，可向H(e)NB许可进行网络接入。H(e)NB可响应于外部设备的请求，而执行、评价和报告信任状态测量。该请求可由运营商发出。重新确认可确认在启动期间未确认的组件。如果检测到非核心确认错误，则外部实体可以向H(e)NB发送请求，以执行修正措施。例如，响应于修正请求，H(e)NB可返回至预定状态。

SAV允许通过指示符来检测损害，即使在安全启动中没有检测到攻击。根据安全属性，可对受损害的设备执行修正步骤。只要发给网络的指示符显示核心安全启动没有受到损害，且安全性属性被传送，则这便是有可能的。如果核心受到损害，设备将由于本地执行而不能连接至网络。受损害的设备可由重启或请求重新确认而被检测出。因此，有更高的检测可能性。可经过OTA提供软件更新，且不需要业务技术员来替换设备。SAV实现了对CN良好精度的接入控制，并由于使用了指示符和本地强制而提供了低于RV的带宽占用率。

SAV结合了AuV和RV的优点，产生了更好的粒度和对设备安全属性和确认测量更好的可视性。其提供了更低的带宽占用率、与自主确认相当的本地设备资源、对受攻击设备更快更方便的检测，并实现了对受损害的设备使用隔离网络。

图15是无线通信网1500的示例框图，该无线通信网1500包括WTRU1510、H(e)NB1520和H(e)MS1530。如图15所示，将WTRU1510、H(e)NB1520和H(e)MS1530配置为执行平台确认和管理。

除了在典型WTRU中可见的组件以外，WTRU1510包括带有可选链接存储器1522的处理器1516、至少一个收发信机1514、可选的电池1520和天线1518。将处理器1516配置为，对于通过基站（例如H(e)NB1520）传递到处理器的PVM功能执行补充平台确认和管理功能。收发信机1514与处理器1516和天线1518进行通信，以促进无线通信的发射和接收。在WTRU1510使用电池1520的情况中，该电池1520对收发信机1514和处理器1516供电。

除了在典型H(e)NB中可见的组件以外，H(e)NB1520包括带有可选链接存储器1515的处理器1517、收发信机1519和天线1521。将处理器1517配置为执行平台确认和管理功能，以实现PVM方法。收发信机1519与处理器1517和天线1521进行通信，以促进无线通信的发射和接收。H(e)NB1520与H(e)MS1530相连接，H(e)MS1530包括带有可选链接存储器1534的处理器1533。

虽然未在图15中示出，但除了典型SeGW和PVE中可见的组件以外，SeGW和PVM可包括具有可选链接存储器的处理器、收发信机、天线和通信端口。将处理器配置为执行平台确认和管理功能，以实现PVM方法。收发信机和通信端口根据需要与处理器和天线进行通信，以促进通信的发射和接收。

选择性地将网络组件配置为执行此处结合各个示例所详细描述的所期望PVM功能。此外，可将WTRU配置为例如对验证、确认和其他可信因素具有补充PVM功能，以促进其对能进行PVM的网络和资源的接入和利用。

作为例子，将各个组件都配置为在处于活动状态的实体间使用PVM最大类型的任务分隔。如此处所述，这可通过在各个实体间使用PVM令牌传递特定信息来实现。

实施例

1、一种用于平台确认和管理（PVM）的方法，包括响应于来自设备的确认消息来接收PVM令牌，该PVM令牌至少包括来自所述设备的验证信息。

2、根据实施例1的方法，进一步包括使用来自所述PVM令牌的预定信息来执行确认。

3、根据前述任一实施例的方法，进一步包括响应于失败组件，向设备管理系统（DMS）发送失败报告，以启动修正和重新确认。

4、根据前述任一实施例的方法，进一步包括发送具有确认结果的修改的PVM令牌。

5、根据前述任一实施例的方法，其中执行确认包括确定至少一个失败状况的适用性。

6、根据前述任一实施例的方法，其中使用远程确认（RV）、自主确认（AuV）、半自主确认（SAV）、完全SAV（F-SAV）、最小确认或参量确认中的至少一者来进行确认。

7、根据前述任一实施例的方法，其中验证信息包括设备标识、设备信息、可信环境（TrE）信息、验证数据、验证绑定和组件指示符-组件的有序组件列表中的至少一个。

8、根据前述任一实施例的方法，其中执行确认包括确定TrE不可信、确定完整性测量/验证数据不匹配、确定组件的丢失参考完整性度量（RIM）、确定加载组件列表策略失败和确定设备超期或RIM证书超期中的至少一种。

9、根据前述任一实施例的方法，其中将PVM令牌被绑定到确认TrE的标识和确认过程。

10、根据前述任一实施例的方法，其中通过对PVM令牌添加时间戳，并由每个传递所述PVM令牌的实体将所述时间戳添加到按时间排序的列表来控制确认的时新性。

11、根据前述任一实施例的方法，进一步包括通过在RIM证书中使用设备标识来建立个体化。

12、根据前述任一实施例的方法，进一步包括向DMS发送PVM令牌，以确定隔离、白名单、黑名单和灰名单的适用性。

13、根据前述任一实施例的方法，其中灰名单包括新加入网络的设备、还未连接达到延长的时间段的设备、具有可疑性能的设备和对其存在安全警告的设备中的至少一种。

14、根据前述任一实施例的方法，其中运营商RIM屏蔽将来自各种外部源的用于设备组件的预定RIM证书替换为运营商RIM证书。

15、根据前述任一实施例的方法，其中，其中向确认数据库发送查询，以检查在PVM令牌中所接收的信息。

16、根据前述任一实施例的方法，其中向配置数据库发送查询，以基于预定标识符来取回配置策略。

17、根据前述任一实施例的方法，其中对所取回的配置策略进行评价。

18、根据前述任一实施例的方法，其中响应于失败状况，将消息发送至确认数据库管理器。

19、一种对连接到平台确认和管理（PVM）的设备进行确认的方法，包括对所述设备的至少一个预先指定的组件执行完整性检查，并存储完整性检查结果。

20、根据实施例19的方法，进一步包括对设备执行安全启动检查，并存储安全启动检查结果。

21、根据实施例19-20中任一实施例的方法，进一步包括根据完整性检查结果和安全启动检查结果来生成确认消息。

22、根据实施例19-21中任一实施例的方法，进一步包括将确认消息转发至PVM。

23、根据实施例19-22中任一实施例的方法，进一步包括分阶段地执行安全启动，以确保在可信环境（TrE）组件的本地确认成功的条件下，每个TrE组件都被加载。

24、根据实施例19-23中任一实施例的方法，进一步包括在第一阶段中，经由依赖于信任根（RoT）的安全启动来加载所述TrE的组件。

25、根据实施例19-24中任一实施例的方法，进一步包括在第二阶段中，加载TrE外部的组件，以实现与所述PVM的通信。

26、根据实施例19-25中任一实施例的方法，进一步包括加载所述设备的剩余组件。

27、根据实施例19-26中任一实施例的方法，其中执行完整性检查是基于至少一个可信参考值和所述TrE进行的。

28、根据实施例19-27中任一实施例的方法，其中确认消息包括本地通过/失败指示符，以作为在第一阶段和第二阶段中所建立的完整性的测量。

29、根据实施例19-28中任一实施例的方法，进一步包括回退代码库。

30、根据实施例19-29中任一实施例的方法，其中启动回退代码库包括触发对包括RIM的主代码库的软件更新。

31、根据实施例19-30中任一实施例的方法，进一步包括在加载了回退代码的条件下，发送呼救信号。

32、根据实施例19-31中任一实施例的方法，其中回退代码（FBC）图像促进设备修正，并存储在安全存储器中。

33、根据实施例19-32中任一实施例的方法，其中所述完整性检查确定只有登记的组件被激活。

34、根据实施例19-33中任一实施例的方法，其中通过加载至存储器中来激活登记的组件。

35、根据实施例19-34中任一实施例的方法，其中通过开始进入完整性证实状态来激活登记的组件。

36、根据实施例19-35中任一实施例的方法，进一步包括执行第二完整性检查。

37、根据实施例19-36中任一实施例的方法，进一步包括在设备已经完成了成功的网络连接的条件下，执行第二完整性检查。

38、根据实施例19-37中任一实施例的方法，其中使用通过所述设备或响应于消息中的一种方式来启动第二完整性检查。

39、根据实施例19-38中任一实施例的方法，其中在受保护的存储位置存储完整性检查结果。

40、根据实施例19-39中任一实施例的方法，其中确认消息包括加密签名的声明。

41、根据实施例19-40中任一实施例的方法，其中确认消息包括完整性检查与之后的认证过程之间的绑定的证据。

42、根据实施例19-41中任一实施例的方法，其中确认消息包括安全启动检查与之后的认证过程之间的绑定的证据。

43、根据实施例19-42中任一实施例的方法，其中确认消息包括时间戳。

44、根据实施例19-43中任一实施例的方法，其中确认消息包括第一时间戳和第二时间戳，该第一时间戳在完整性检查和启动检查之前获得，该第二时间戳在完整性检查和启动检查之后获得。

45、根据实施例19-44中任一实施例的方法，其中确认消息包括对设备配置的指示。

46、根据实施例19-45中任一实施例的方法，其中确认消息包括对设备组件的安全性属性的指示。

47、根据实施例19-46中任一实施例的方法，进一步包括从PVM接收响应于确认消息的决定消息。

48、根据实施例19-47中任一实施例的方法，其中所述决定消息包括对与设备相关联的网络权限的指示。

49、根据实施例19-48中任一实施例的方法，进一步包括可信资源（TR）执行完整性检查。

50、根据实施例19-49中任一实施例的方法，进一步包括可信资源（TR）执行安全启动检查。

51、根据实施例19-50中任一实施例的方法，进一步包括可信资源（TR）生成确认消息。

52、根据实施例19-51中任一实施例的方法，进一步包括可信资源（TR）从PVM接收决定消息。

53、根据实施例19-52中任一实施例的方法，其中FBC删除或卸载一部分正常代码，并重启设备以进行重新确认。

54、一种用于促进平台确认和管理（PVM）的平台确认实体（PVE），包括所述PVE被配置为响应于来自设备的确认消息来接收PVM令牌，该PVM令牌至少包括来自设备的验证信息。

55、根据实施例54的方法，进一步包括所述PVE被配置为使用来自所述PVM令牌的预定信息来执行确认。

56、根据实施例54-55中任一实施例的方法，进一步包括所述PVE被配置为响应于失败组件而向设备管理系统（DMS）发送失败报告，以启动修正和重新确认。

57、根据实施例54-56中任一实施例的方法，进一步包括所述PVE被配置为发送具有确认结果的修改后的PVM令牌。

58、根据实施例54-57中任一实施例的方法，其中验证消息至少包括安全性策略属性。

59、一种用于经由平台确认和管理（PVM）来执行确认的设备，该设备包括处理器，该处理器被配置为对所述设备的至少一个预先指定的组件执行完整性检查，并将完整性检查结果存储在存储器中。

60、根据实施例59中任一实施例的方法，进一步包括所述处理器被配置为对所述设备执行安全启动检查，并在所述存储器中存储安全启动检查结果。

61、根据实施例59-60中任一实施例的方法，进一步包括所述处理器被配置为基于完整性检查结果和安全启动检查结果生成确认消息。

62、根据实施例59-61中任一实施例的方法，进一步包括发射器，用于向PVM发送确认消息。

63、一种用于促进平台确认和管理（PVM）的设备管理系统（DMS），包括该DMS被配置为响应于来自设备的确认消息来从平台确认实体（PVE）接收失败报告和PVM令牌中的至少一者，以便响应于失败组件而启动修正和重新确认，所述PVM令牌至少包括来自所述设备的验证信息。

64、根据实施例63中任一实施例的方法，进一步包括所述DMS被配置为至少为所述失败组件确定更新的可用性。

65、根据实施例63-64中任一实施例的方法，进一步包括所述DMS被配置为准备无线更新以作为可用更新。

66、根据实施例63-65中任一实施例的方法，进一步包括所述DMS被配置为确保在确认数据库中存在用于可用更新的可信参考值。

67、根据实施例63-66中任一实施例的方法，进一步包括所述DMS被配置为向安全性网关（SeGW）发送修改后的PVM令牌和重新确认指示。

68、根据实施例63-66中任一实施例的方法，进一步包括所述DMS被配置为向所述设备发送重新确认触发。

69、一种在无线通信中使用的方法，该方法包括执行平台确认和管理（PVM）。

70、根据实施例69中任一实施例的方法，其中执行PVM包括执行半自主确认（SAV）。

71、根据实施例69-70中任一实施例的方法，其中执行PVM包括在平台确认实体（PVE）中所执行的无线设备确认。

72、根据实施例69-71中任一实施例的方法，其中执行PVM包括：

73、根据实施例69-72中任一实施例的方法，进一步包括按阶段执行安全启动，以确保在所需加载的组件的本地确认成功的条件下，加载了每个可信环境组件。

74、根据实施例69-73中任一实施例的方法，进一步包括在第一阶段中，通过依赖于信任根（RoT）的安全启动加载可信环境组件。

75、根据实施例69-74中任一实施例的方法，进一步包括在第二阶段中，加载可信环境外部的组件，需要该组件来执行与安全性网关（SeGW）的基本通信。

76、根据实施例69-75中任一实施例的方法，进一步包括加载设备的剩余组件。

77、根据实施例69-76中任一实施例的方法，进一步包括收集数据并将其发送至SeGW，该数据包括以下至少一者：设备标识、属于增强型家庭节点B（H(e)NB）的信息、属于可信环境（TrE）的信息、验证数据；验证绑定；、组件指示符-组件的有序组件列表。

78、根据实施例69-77中任一实施例的方法，进一步包括响应于对经过认证的H(e)NB失去连接而对设备进行重新确认。

79、根据实施例69-78中任一实施例的方法，进一步包括在PVE执行确认期间，确定失败状况，该失败状况包括以下至少一者：根据所传递的TrE信息确定TrE不可信；确定完整性测量/验证数据不匹配；确定组件的参考完整性度量（RIM）丢失；确定加载组件列表（Clist）策略失败；确定设备或RIM证书超期；和SeGW拒绝网络接入和设备认证，并阻止之后的认证尝试。

80、根据实施例69-79中任一实施例的方法，进一步包括生成PVM令牌，该PVM令牌与有效TrE的标识和确认进程绑定。

81、根据实施例69-80中任一实施例的方法，其中通过对PVM令牌添加时间戳，该时间戳最初由SeGW所生成，并由每个实体在传递PVM令牌时添加到按时间排序的列表来控制确认的时新性。

82、根据实施例69-81中任一实施例的方法，其中通过完成第一和第二阶段与SeGW和PVE进行通信，和在将第三阶段的结果发送至SeGW前，使用SeGW/PVE所提供的现时来绑定阶段3检查的进一步确认来控制确认的时新性。

83、根据实施例69-82中任一实施例的方法，进一步包括由设备希望与之建立回程链路的运营商来生成RIM证书。

84、根据实施例69-83中任一实施例的方法，其中RIM管理器对用于平台确认的PVE和DMS进行配置，将DMS配置为对设备上将要安装RIM证书的组件执行证书更新操作，并进一步包括对设备强制执行状态重新确认。

85、根据实施例69-84中任一实施例的方法，进一步包括运营商通过执行以下中的至少一个来控制设备操作：使用对称密钥来对将被锁定的组件的一部分加密；在受保护和受控的空间中向TrE发送解密密钥，该空间只能具有运营商授权才能访问；和当PVE接收到用于该组件的指示符时，向TrE释放授权数据。

86、根据实施例69-85中任一实施例的方法，进一步包括通过使用RIM证书中的设备标识来根据PVM建立个体化。

87、根据实施例69-86中任一实施例的方法，进一步包括根据向设备标识和组件指示符对提供运营商签名来建立个体化。

88、根据实施例69-87中任一实施例的方法，进一步包括为设备建立黑名单，并根据黑名单禁止网络接入，其中黑名单至少包含设备标识。

89、根据实施例69-88中任一实施例的方法，进一步包括为设备建立隔离网络，其中SeGW用作核心网的强制承载。

90、根据实施例69-89中任一实施例的方法，进一步包括建立被隔离设备的灰名单，该灰名单包括新加入网络的设备、连接还未达到预定时间的设备、具有可疑性能的设备和对其存在安全警告的设备中的至少一种。

91、根据实施例69-90中任一实施例的方法，进一步包括执行诊断确认，包括加载未知组件、拒绝加载未知组件和禁止组件中的至少一个。

92、根据实施例69-91中任一实施例的方法，进一步包括执行最小确认，包括发送本地验证过程中所用的指示符或参考值。

93、根据实施例69-92中任一实施例的方法，进一步包括在认证证书中绑定确认。

94、根据实施例69-93中任一实施例的方法，其中证书是由发布者、其SeGW、或负责管理这些证书的从属实体所签名的签名数据组，证书中的该签名数据至少包含设备标识、用于认证和确认的设备公共密钥、和组件列表。

95、根据实施例69-94中任一实施例的方法，进一步包括执行自主确认和对管理标识进行分组，该自主确认根据安全启动进程的各阶段，不向SeGW发送任何确认数据。

96、根据实施例69-95中任一实施例的方法，进一步包括在设备和SeGW已经完成了对设备的第一认证协议的条件下，通过所建立的安全信道发送设备标识和认证数据，在该第一认证协议中，设备对其管理标识之一进行认证。

97、根据实施例69-96中任一实施例的方法，进一步包括确保向安全存储卡发送组件代码的安全。

98、根据实施例69-97中任一实施例的方法，进一步包括使用加密来替换摘要值。

99、根据实施例69-98中任一实施例的方法，进一步包括将设备位置信息包括在确认消息中。

100、根据实施例69-99中任一实施例的方法，其中将通过设备标识符（Dev_ID）来标识所述设备。

101、根据实施例69-100中任一实施例的方法，其中Dev_ID是正式域名（FQDN）、统一资源位置符（URL）、统一资源名称、统一资源标识、媒介接入控制（MAC）地址、互联网协议（IP）地址、IP主机标识、子网地址、国际移动设备识别码、国际移动站设备识别码和软件版本号、电子序列号、移动设备标识、IP多媒体核心网子系统用户ID或移动站集成业务数据网ID。

102、根据实施例69-101中任一实施例的方法，其中Dev_ID是字母数字或机器可读的形式，其实现对设备唯一可靠和明确的标识。

103、根据实施例69-102中任一实施例的方法，进一步包括根据一个或多个可信参考值和TrE，在启动时执行设备完整性检查。

104、根据实施例69-103中任一实施例的方法，其中TrE是包含PVM所需最小功能的实体。

105、根据实施例69-104中任一实施例的方法，进一步包括对SeGW执行网络认证，并发送包含设备标识的数据。

106、根据实施例69-105中任一实施例的方法，进一步包括准备测量消息，该消息包含在第一和第二步骤中用作所建立的完整性测量的本地通过/失败指示符。

107、根据实施例69-106中任一实施例的方法，其中执行PVM包括基本SAV。

108、根据实施例69-107中任一实施例的方法，其中执行PVM包括完全SAV。

109、根据实施例69-108中任一实施例的方法，其中执行PVM包括平台确认。

110、根据实施例69-109中任一实施例的方法，其中平台确认允许对核心网（CN）保护，以防恶意设备。

111、根据实施例69-110中任一实施例的方法，其中执行PVM包括在设备和CN之间使用间接通信。

112、根据实施例69-103中任一实施例的方法，其中平台确认确保在证实的安全状态中的设备能够与CN中的实体进行通信。

113、根据实施例69-112中任一实施例的方法，其中执行PVM包括报告确认数据。

114、根据实施例69-113中任一实施例的方法，其中报告确认数据包括收集确认数据，并将其报告给SeGW。

115、根据实施例69-114中任一实施例的方法，其中执行PVM包括使用PVE进行确认。

116、根据实施例69-115中任一实施例的方法，其中PVE确定设备的有效性。

117、根据实施例69-116中任一实施例的方法，其中PVE是策略决定点（PDP）。

118、根据实施例69-117中任一实施例的方法，其中PVE报告失败状况。

119、根据实施例69-118中任一实施例的方法，其中失败情况是TrE失效、验证数据失败、Clist策略失败或确认前设备认证失败。

120、根据实施例69-119中任一实施例的方法，其中执行PVM包括重新确认。

121、根据实施例69-120中任一实施例的方法，其中重新确认包括周期性地重新确认。

122、根据实施例69-121中任一实施例的方法，其中周期性地重新确认包括确认设备正在执行恶意代码的风险较小的预定状态中进行操作。

123、根据实施例69-122中任一实施例的方法，其中重新确认包括启动认证过程。

124、根据实施例69-123中任一实施例的方法，其中执行PVM包括由设备启动的重新确认。

125、根据实施例69-124中任一实施例的方法，其中周期性地执行由设备启动的重新确认。

126、根据实施例69-125中任一实施例的方法，其中执行PVM包括由网络启动的重新确认。

127、根据实施例69-126中任一实施例的方法，其中周期性地执行由网络启动的重新确认。

128、根据实施例69-127中任一实施例的方法，其中可出于安全需要而执行由网络启动的重新确认。

129、根据实施例69-128中任一实施例的方法，其中执行PVM包括平台管理。

130、根据实施例69-129中任一实施例的方法，其中平台管理包括DMS执行设备管理。

131、根据实施例69-130中任一实施例的方法，其中平台管理基于所接收和所存储的设备信息。

132、根据实施例69-131中任一实施例的方法，其中设备是H(e)NB。

133、根据实施例69-132中任一实施例的方法，其中执行PVM包括令牌传递。

134、根据实施例69-133中任一实施例的方法，其中PVM是进程。

135、根据实施例69-134中任一实施例的方法，其中SeGW负责生成和管理与确认进程唯一相关的令牌。

136、根据实施例69-135中任一实施例的方法，其中执行PVM包括通过公共互联网进行确认。

137、根据实施例69-136中任一实施例的方法，其中通过互联网进行确认包括满足确保初始确认安全的特殊要求。

138、根据实施例69-137中任一实施例的方法，其中执行PVM包括运营商RIM屏蔽。

139、根据实施例69-138中任一实施例的方法，其中运营商RIM屏蔽使用由设备希望与之建立回程链路的运营商所生成的RIM证书替换来自各个外部源的用于设备组件的大量RIM证书。

140、根据实施例69-139中任一实施例的方法，其中执行PVM包括运营商组件锁定。

141、根据实施例69-140中任一实施例的方法，其中运营商组件锁定包括运营商控制设备或其组件在外部网络中的操作。

142、根据实施例69-141中任一实施例的方法，其中执行PVM包括个体化。

143、根据实施例69-142中任一实施例的方法，其中个体化包括证明由谁管理设备配置和可信度。

144、根据实施例69-143中任一实施例的方法，其中个体化包括向设备提供数据，该数据签发了对设备的寻址。

145、根据实施例69-144中任一实施例的方法，其中执行PVM包括将设备列入黑名单。

146、根据实施例69-145中任一实施例的方法，其中将设备列入黑名单包括为设备建立黑名单，并根据黑名单禁止网络接入。

147、根据实施例69-146中任一实施例的方法，其中黑名单是设备专用黑名单。

148、根据实施例69-147中任一实施例的方法，其中黑名单是网络范围的黑名单。

149、根据实施例69-148中任一实施例的方法，其中执行PVM包括将设备列入白名单。

150、根据实施例69-149中任一实施例的方法，其中将设备列入白名单包括为设备建立白名单，并根据白名单允许网络接入。

151、根据实施例69-150中任一实施例的方法，其中白名单是设备专用白名单。

152、根据实施例69-151中任一实施例的方法，其中白名单是网络范围的白名单。

153、根据实施例69-152中任一实施例的方法，其中执行PVM包括隔离网络。

154、根据实施例69-153中任一实施例的方法，其中由SeGW决定将哪些设备进行隔离。

155、根据实施例69-154中任一实施例的方法，其中被隔离的设备没有对CN的直接接入，并提供受限的服务。

156、根据实施例69-155中任一实施例的方法，其中执行PVM包括参量确认。

157、根据实施例69-156中任一实施例的方法，其中参量确认包括在确认期间不受阻碍地发送参数。

158、根据实施例69-157中任一实施例的方法，其中执行PVM包括诊断确认。

159、根据实施例69-158中任一实施例的方法，其中执行PVM包括加载未知组件。

160、根据实施例69-159中任一实施例的方法，其中加载未知组件允许在设备中没有RIM的情况下加载组件。

161、根据实施例69-160中任一实施例的方法，其中执行PVM包括对失败状况进行PVM诊断。

162、根据实施例69-161中任一实施例的方法，其中将DMS配置为省略替换设备上的失败组件。

163、根据实施例69-162中任一实施例的方法，其中将DMS配置为使用正确组件替换Clist中的所有组件。

164、根据实施例69-163中任一实施例的方法，其中执行PVM包括拒绝加载未知组件。

165、根据实施例69-164中任一实施例的方法，其中诊断确认包括报告不能加载组件，并向CN发送该组件的测量值。

166、根据实施例69-165中任一实施例的方法，其中执行PVM包括禁止组件。

167、根据实施例69-166中任一实施例的方法，其中禁止组件包括在不拒绝对设备的连接的情况下，为不能进行确认也不能在PVM中被替换或更新的组件发送禁止CInd和重新确认消息。

168、根据实施例69-167中任一实施例的方法，其中执行PVM包括最小确认策略。

169、根据实施例69-168中任一实施例的方法，其中最小确认策略包括只在特定情况下执行设备确认。

170、根据实施例69-169中任一实施例的方法，其中执行PVM包括在认证证书中绑定确认。

171、根据实施例69-170中任一实施例的方法，其中在认证证书中绑定确认包括自动将设备的认证ID与确认绑定。

172、根据实施例69-171中任一实施例的方法，其中执行PVM包括撤回设备认证证书。

173、根据实施例69-172中任一实施例的方法，其中撤回设备认证证书包括确定是否从设备撤回用于设备认证的设备证书。

174、根据实施例69-173中任一实施例的方法，其中撤回设备认证证书包括向设备指示由于撤回证书而设备认证失败；并将设备从白名单删除或将设备加入黑名单。

175、根据实施例69-174中任一实施例的方法，进一步包括PVM执行自主确认（AuV）。

176、根据实施例69-175中任一实施例的方法，其中AuV包括省略向SeGW发送确认数据。

177、根据实施例69-176中任一实施例的方法，其中AuV包括仅发送Dev_ID。

178、根据实施例69-177中任一实施例的方法，其中执行PVM包括修正。

179、根据实施例69-178中任一实施例的方法，其中修正包括更新软件。

180、根据实施例69-179中任一实施例的方法，其中修正是对设备继续服务所必需的操作。

181、根据实施例69-180中任一实施例的方法，其中执行PVM包括由设备启动的修正。

182、根据实施例69-181中任一实施例的方法，其中在检测到错误时，执行由设备启动的修正，而不是将设备隔离。

183、根据实施例69-182中任一实施例的方法，其中执行PVM包括由网络启动的修正。

184、根据实施例69-183中任一实施例的方法，其中执行PVM包括启动回退代码库。

185、根据实施例69-184中任一实施例的方法，其中启动回退代码库包括触发对包含RIM的主码库的软件更新。

186、根据实施例69-185中任一实施例的方法，其中执行PVM包括发送呼救信号。

187、根据实施例69-186中任一实施例的方法，其中回退代码（FBC）图像促进了设备修正，并被存储在安全存储器中。

188、根据实施例69-187中任一实施例的方法，其中执行PVM包括不使用RIM进行确认。

189、根据实施例69-188中任一实施例的方法，其中执行PVM包括包含基于位置的信息。

190、根据实施例69-189中任一实施例的方法，其中将位置信息用于防盗、货物追踪、车队监控或监视。

191、根据实施例69-190中任一实施例的方法，其中设备包括GPS模块。

192、根据实施例69-191中任一实施例的方法，其中安全启动包括确认GPS模块和组件。

193、根据实施例69-192中任一实施例的方法，其中执行PVM包括使用IKEv2协议的确认连接。

194、根据实施例69-193中任一实施例的方法，其中执行PVM包括使用传输协议。

195、根据实施例69-194中任一实施例的方法，其中传输协议是IKE或ISAKMP。

196、根据实施例69-195中任一实施例的方法，其中传输协议定义了多个可用的证书简档。

197、根据实施例69-196中任一实施例的方法，其中执行PVM包括传输层安全性（TLS）握手。

198、根据实施例69-197中任一实施例的方法，其中执行PVM包括使用TLS会话票据扩展。

199、根据实施例69-198中任一实施例的方法，其中TLS会话票据扩展允许服务器向客户端发布会话票据，可将该票据用于恢复会话和保存每个客户端的会话状态。

200、根据实施例69-199中任一实施例的方法，其中执行PVM包括补充认证协议。

201、根据实施例69-200中任一实施例的方法，其中补充认证协议包括通过所建立的安全信道发送Dev_ID和用于Dev_ID的认证数据。

202、根据实施例69-201中任一实施例的方法，其中执行PVM包括管理会话建立。

203、根据实施例69-202中任一实施例的方法，其中管理会话建立包括在设备与SeGW之间使用通信协议。

204、根据实施例69-203中任一实施例的方法，其中执行PVM包括基于证书的确认。

205、根据实施例69-204中任一实施例的方法，其中执行PVM包括针对基于设备管理（DM）的结构使用开放移动联盟（OMA）。

206、根据实施例69-205中任一实施例的方法，其中执行PVM包括使用证书交换方法。

207、根据实施例69-206中任一实施例的方法，其中证书交换方法包括将确认与认证合并，并自动将设备的认证ID与确认绑定。

208、根据实施例69-207中任一实施例的方法，其中绑定证书是签名数据组。

209、根据实施例69-208中任一实施例的方法，其中绑定证书由发布者进行签名的。

210、根据实施例69-209中任一实施例的方法，其中执行PVM包括证书前交换。

211、根据实施例69-210中任一实施例的方法，其中执行PVM包括证书后交换。

212、根据实施例69-211中任一实施例的方法，其中执行PVM包括使用签名消息格式用于从发布者向设备下载软件数据包。

213、根据实施例69-212中任一实施例的方法，其中签名消息格式允许在单个签名数据包中发送文件。

214、根据实施例69-213中任一实施例的方法，其中签名消息格式允许接收方设备能够对源进行认证，且该数据格式包含用于安装内容的指令。

215、根据实施例69-214中任一实施例的方法，其中签名消息格式包括报头，该报头包含格式版本、以及命令列表和负载组件的长度。

216、根据实施例69-215中任一实施例的方法，其中执行PVM包括使用第二码库用于修正。

217、根据实施例69-216中任一实施例的方法，其中执行PVM包括使用外部FBC。

218、根据实施例69-217中任一实施例的方法，其中将外部FBC用于启动修正，并在TrE内运行。

219、根据实施例69-218中任一实施例的方法，其中执行PVM包括使用内部并行码库。

220、根据实施例69-219中任一实施例的方法，其中执行PVM包括使用触发机制和所需回退代码库，用于促进修正。

221、根据实施例69-220中任一实施例的方法，其中执行PVM包括使用内部顺序码库。

222、根据实施例69-221中任一实施例的方法，其中内部顺序码库定义了用于在远程设备上安装或改变软件配置的协议和命令。

223、根据实施例69-222中任一实施例的方法，其中使用内部顺序码库包括将执行PVM和协议的结果合并。

224、根据实施例69-223中任一实施例的方法，其中执行PVM包括使用安全策略属性。

225、根据实施例69-201中任一实施例的方法，其中使用安全策略属性包括生成安全性策略属性（SPA）标准化列表。

226、根据实施例69-201中任一实施例的方法，其中SPA是策略，该策略能够通知PVE如果特定模块的整体性检查失败时，应该采取怎样的操作。

尽管上述在特定结合中描述了PVM的特征和组件，但是，各个特征或组件都可单独使用不需其他特征和组件，或以各种方式与其他特征和组件结合或不结合。可以在结合至计算机可读存储介质中，可由通用目的计算机或处理器执行的计算机程序、软件或固件中实现此处所提供的方法或流程。计算机可读存储介质的例子包括只读存储器（ROM）、随机存储存储器（RAM）、寄存器、缓存、半导体存储设备、磁介质例如内部硬盘和可移动硬盘、光磁介质和光学介质例如CD-ROM光盘和数字化视频盘（DVD）。

适当的存储器包括例如通用目的存储器、专门目的存储器、传统处理器、数字信号处理器（SDP）、多个微处理器、与DSP核相连的一个或多个微处理器、控制器、微控制器、特定用途集成电路（ASIC）、现场可编程门阵列（FPGA）电路、任何其他类型的集成电路（IC）和/或状态机。

可将与软件相连的处理器用于实现无线设备中所用的射频收发信机、无线发射接收单元（WTRU）、用户设备（UE）、终端、基站、无线网络控制器（RNC）或任何主机计算机。WTRU可与以硬件和/或软件实现的模块连接使用，例如照相机、视频摄像模块、视频电话、免提电话、振动设备、扬声器、麦克风、电视收发信机、便携式耳机、键盘、蓝牙

模块、调频（FM）无线单元、液晶显示（LCD）显示单元、有机发光二极管（OLED）显示单元、数字音乐播放器、媒体播放器、视频游戏播放器模块、互联网浏览器和/或任何无线局域网（WLAN）或超宽带（UWB）模块。

Claims (20)

1.一种执行耦合到平台确认实体（PVE）的无线发射/接收单元（WTRU）的确认的方法，该方法包括：

测量所述WTRU的至少一个预先指定组件的完整性测量；

获取所述WTRU的所述至少一个预先指定组件的可信参考值；

使用位于无线发射/接收单元（WTRU）中的可信环境（TrE）执行所述WTRU的所述至少一个预先指定组件的完整性检查，并存储完整性检查结果；所述完整性检查包括所述TrE比较所测量的所述至少一个预先指定组件的完整性测量与所述WTRU的所述至少一个预先指定组件的所述可信参考值；

使用所述TrE在所述WTRU上执行安全启动检查，并存储安全启动检查结果；所述启动检查确定所述至少一个预先指定组件是否达到安全启动的状态，所述启动检查结果包括当所述至少一个预先指定组件没有达到安全启动的状态时的指示；

使用所述TrE基于所述完整性检查结果和所述安全启动检查结果形成确认消息；以及

使用所述TrE将所述确认消息从所述WTRU转发到所述PVE，所述PVE在所述WTRU外部。

2.根据权利要求1所述的方法，该方法还包括：

使用所述TrE分阶段地执行安全启动，以确保在每个TrE组件的本地确认成功的情况下加载第一TrE组件和第二TrE组件；

在第一阶段，经由依赖于信任根（RoT）的安全启动加载所述TrE组件；以及

在第二阶段，加载所述TrE外部的第二组件，以允许与所述PVE的通信。

3.根据权利要求2所述的方法，其中所述确认消息包括本地通过/失败指示符，以作为在所述第一阶段和第二阶段期间所建立的完整性的测量。

4.根据权利要求1所述的方法，该方法还包括启动回退代码库。

5.根据权利要求4所述的方法，其中启动所述回退代码库包括触发对包括主代码库的软件更新。

6.根据权利要求1所述的方法，其中所述完整性检查确定只有登记的组件被激活。

7.根据权利要求6所述的方法，其中通过加载至存储器中来激活所述登记的组件。

8.根据权利要求6所述的方法，其中通过开始进入完整性证实状态来激活所述登记的组件。

9.根据权利要求1所述的方法，该方法还包括在所述设备已经完成了成功的网络连接的条件下，执行第二完整性检查。

10.根据权利要求1所述的方法，其中存储完整性检查结果包括在受保护的存储位置存储完整性检查结果。

11.根据权利要求1所述的方法，其中所述确认消息包括加密签名的声明。

12.根据权利要求1所述的方法，其中所述确认消息包括所述完整性检查与之后的认证过程之间的绑定的证据。

13.根据权利要求1所述的方法，其中所述确认消息包括所述安全启动检查与之后的认证过程之间的绑定的证据。

14.根据权利要求1所述的方法，其中所述确认消息包括时间戳。

15.根据权利要求1所述的方法，其中所述确认消息包括第一时间戳和第二时间戳，所述第一时间戳在所述完整性检查和所述启动检查之前取得，所述第二时间戳在所述完整性检查和所述启动检查之后取得。

16.根据权利要求1所述的方法，其中所述确认消息包括设备配置的指示。

17.根据权利要求1所述的方法，其中所述确认消息包括设备组件的安全性属性的指示。

18.根据权利要求1所述的方法，该方法还包括从所述PVE接收响应于所述确认消息的决定消息。

19.根据权利要求18所述的方法，其中所述决定消息包括与所述设备相关联的网络权限的指示。

20.一种用于经由耦合到无线发射/接收单元（WTRU）的平台确认实体（PVE）执行所述WTRU的确认的设备，该设备包括：

处理器，位于所述WTRU中且用于执行计算机可读指令；以及

存储器，位于所述WTRU中且通信耦合到所述处理器，所述存储器已经在其上存储了当由所述处理器执行时使得所述处理器执行操作的计算机可读指令，所述操作包括：

测量所述WTRU的至少一个预先指定组件的完整性测量；

获取所述WTRU的所述至少一个预先指定组件的可信参考值；

使用位于无线发射/接收单元（WTRU）中的可信环境（TrE）执行所述WTRU的所述至少一个预先指定组件的完整性检查，并将完整性检查结果存储在所述存储器中；所述完整性检查包括所述TrE比较所测量的所述至少一个预先指定组件的完整性测量与所述WTRU的所述至少一个预先指定组件的所述可信参考值；

使用所述TrE在所述WTRU上执行安全启动检查，并将安全启动检查结果存储在所述存储器中；所述启动检查确定所述至少一个预先指定组件是否达到安全启动的状态，所述启动检查结果包括当所述至少一个预先指定组件没有达到安全启动的状态时的指示；

使用所述TrE基于所述完整性检查结果和所述安全启动检查结果形成确认消息；以及

使用所述TrE和位于所述WTRU中的发射机将所述确认消息从所述WTRU转发到所述PVE，所述PVE在所述WTRU外部。

Images