CN104918252A - 用于对wtru执行完整性验证的方法及wtru - Google Patents

Abstract

本发明公开了用于对WTRU执行完整性验证的方法及WTRU。该方法包括在该无线发射/接收单元处执行的以下步骤：在所述WTRU测量该WTRU的至少一组件的完整性度量；在所述WTRU从在所述WTRU上的本地存储器中获取所述至少一个组件的可信的参考值(TRV)；在所述WTRU将测量的完整性度量与所述TRV进行比较，以确定所述至少一个组件的完整性验证校验的结果；以及一旦所述至少一个组件的完整性验证校验失败，基于本地提供的策略确定行动路线。

Description

用于对WTRU执行完整性验证的方法及WTRU

本申请是申请号为201080010524.9、申请日为2010年03月05日、发明名称为“用于H(e)NB完整性验证和确认的方法和装置”的中国发明专利申请的分案申请。

相关申请的交叉引用

本申请要求2009年3月5日提交的美国临时申请No.61/157,833、2009年6月30日提交的美国临时申请No.61/222,067、2009年8月21日提交的美国临时申请No.61/235,793以及2009年9月3日提交的美国临时申请No.61/239,698的权益。本申请与同时提交的题为“Platform Validation andManagement of Wireless Devices”的美国专利申请No.12/718,480相关，其全部内容以引用的方式结合于此如同在这里全部提出。

技术领域

本申请涉及通信。

背景技术

家庭演进型节点B(H(e)NB)，也被称为毫微微蜂窝(femtocell)基站，是一种小的、便携式的3G网络接入点，它们通常被布置在房屋上或者称为主机方(HP)的相关者的室内。H(e)NB成为了在小的、特定的地理区域内提供移动通信和服务的折中方案。H(e)NB可用于在目前的盲区(由于不好的无线电条件)例如室内或者工厂环境内提供移动服务。H(e)NB也可以成为私人家庭以及家庭办公(SOHO)区域的选择，这是因为H(e)NB可用作宽带互联网和移动网络的统一的接入点。

本申请会提出特别的安全要求。例如，这些装置i)不再是像移动手持设备传统地被认为的那样，被当成是用于存储和处理敏感数据的封闭的、不变的环境了；以及ii)这些特殊的装置典型地不是由移动网络处理器(MNO)直接进行物理控制的，MNO作为H(e)NB的主要相关器件处理H(e)NB以为移动通信终端用户提供服务；以及iii)这些设备通常通过不安全的链路及断断续续的而不是连续的方式而连接到核心网络。

现有的或标准的移动通信网络技术可能不为网络提供完全认为它所处理的H(e)NB是值得信任的方法，即使H(e)NB通过了传统的鉴权(authentication)步骤。所需要的就是一种方法来帮助MNO鉴权及确认这种可信性、即设备的完整性，以及管理和提供这样的设备。

发明内容

公开了一种使用自动确认和半自动确认来为家庭演进型节点B(H(e)NB)提供完整性确认的装置和方法。

附图说明

从以下描述中可以更详细地理解本发明，下面的描述是以实例的形式给出的，并且可以结合附图被理解，其中：

图1示出了模块、功能性和组件的示例性结构；

图2示出了组件和功能性的示例性结构；

图3示出了用于软件下载提供的示例性TR069架构；

图4示出了基本的完整性测量和报告的实例；

图5示出了完整性报告和参考材料的实例；

图6示出了将确认报告与参考清单进行比较的实例；

图7示出了参考清单中的组件信息的实例；

图8示出了认证管理架构的实例；

图9示出了重新配置家庭演进型节点B(H(e)NB)(H(e)MS)的实例；

图10示出了自动确认(AuV)补救的实例；

图11示出了文件包格式的实例；

图12示出了半自动确认(SAV)的网络架构的实例；

图13A和图13B示出了SAV过程的示例性流程图；

图14示出了示例性SAV补救流程图；

图15示出了示例性完整性校验结果；

图16示出了示例性失败的功能性的列表；

图17A是表示示例性实体集合和它们之间的关系以及平台确认和管理(PVM)的接口的结构图；

图17B是表示另一示例性实体集合和它们之间的关系以及PVM接口的结构图；

图18A、图18B和图18C是使用平台确认实体的示例性确认方法的信号图；

图19示出了长期演进(LTE)无线通信系统/接入网络；以及

图20是LTE无线通信系统典型的结构图。

具体实施方式

当在下文中提及时，术语“无线发射/接收单元(WTRU)”包括但不局限于用户设备(UE)、移动站、固定或移动用户单元、传呼机、蜂窝电话、个人数字助理(PDA)、计算机、或能在无线环境中运行的任何其它类型的设备。当在下文中提及时，术语“基站”包括但不局限于节点-B、站点控制器、接入点(AP)、网关、用户预定设备(CPE)、或能在无线环境中运行的任何其它类型的接口设备。当在下文中提及时，术语“HMS”包括但不局限于家庭节点B管理系统(HMS)、家庭增强型节点B管理系统(HeMS)(这两者可总称为H(e)MS)、设备管理系统(DMS)、配置服务器(CS)、自动配置服务器(ACS)、或者其他任何类型的管理“基站”的配置或功能性的系统。术语“WTRU”和术语“基站”互不冲突。例如，WTRU可以是增强型家庭节点B(H(e)NB)。当在下文中提及时，术语“信息理论安全”包括但不局限于完全安全、无条件安全以及近似信息理论安全。当在下文中提及时，术语“信任”、“可信的”以及“值得信任的”以及其他变化的说法表示一种可计量的以及可观察的方法，该方法用于评定一个部件是否会以特定方法工作。

本文描述的是一种使用自动确认(AuV)和半自动确认(SAV)来为家庭演进型节点B(H(e)NB)提供完整性验证和确认的装置和方法。描述是先详细描述AuV和SAV的共同部分，然后再分别描述AuV和SAV的实施详情。

本文描述了在确认方法中确定可信的参考值(TRV)的方法。设备完整性校验是确认方法的一种常用过程。对于设备完整性校验，需要一组TRV以使由组件组成的测量可用于它们的完整性校验。这种组件的完整性校验应在组件装载之前进行是可取的。这样的TRV在使用之前需要进行鉴权及自我确保完整性也是可取的。

为了进行完整性校验及提供和生成TRV，可以使用不同的完整性校验方法。例如，可以考虑根据编码生成TRV的方法、包括数字签名方法、基于哈希(hash)的消息鉴权码或者基于加密的消息鉴权码。

这里描述的是数字签名方法。数字签名可以使用公钥加密技术。H(e)NB可以对模块的哈希(或者通常说的校验字)进行数字签名，通过使用它的私有密钥对校验字进行加密。加密的校验字然后可以被发送到平台确认实体(PVE)，在那里它会被用H(e)NB的公用密钥进行解密并与TRV进行比较。对于本地完整性校验，参考完整性校验可以由制造商签名并在H(e)NB内进行本地验证。作为没有限制性的实例，表1列出了一些数字签名方法。

表1

这里描述的是哈希算法和基于哈希的消息鉴权码。哈希是一种单向或者近似单向的函数，它产生其输入的唯一的(或近似唯一的)并且不可逆的(或近似不可逆的)总结。许多情况中，数字签名仅仅就是加密的哈希。而数字签名方法可以使用公共/私有密钥对，消息鉴权码(MAC)可以使用共享的秘密密钥。校验字可以在带有嵌入的秘密密钥(连接的模块和密钥)的模块上生成。作为没有限制性的示例，表2列出了一些哈希算法及基于哈希的消息鉴权码的方法。

表2

这里描述的是基于加密的消息鉴权码。校验字可以由哈希算法生成然后使用秘密密钥进行加密。作为没有限制性的实例，表3列出了一些基于加密的消息鉴权码方法。

表3

完整性度量是由在软件组件上执行完整性方法产生的摘要(例如，加密的哈希值)。这里认为组件是完整性校验的最小的可能单元。单独的二进制可执行或预可执行文件是组件的实例。另外，模块在这里被认为是指软件包的制造商认证、发布的最小单元。对于本描述的剩余部分，总体上考虑及如图1所示，1)组件也可能由一个或多个模块组成，以及2)任何一个模块只在一个组件中出现一次(也就是说一个模块不能出现在两个组件中)。为支持用AuV和SAV进行设备完整性校验和确认，可能需要提供软件模块及其关联的属性的列表，这些关联的属性例如与模块相关的参考完整性度量(RIM)、严重性以及其他信息。参考完整性度量(RIM)作为各个模块的完整性的参考值。在使用AuV时，所述列表可以由制造商生成并安全地存储在设备中，当使用SAV时，所述列表可由制造商生成并提供给平台确认实体(PVE)(所有模块)并且也提供给H(e)NB(在多步骤系统中作为步骤1和步骤2模块启动实施)。由于软件模块怎样进行组织、架构或存储，以及设备可能存在什么种类的模块可能依赖于H(e)NB的实施，因此可以使用公共的规范语言来说明模块及其属性。

例如，基于可扩展标记语言(XML)和抽象语法定义一(ASN.1)的方法可被用作实施公共的规范语言。设备配置数据表包含软件模块和与模块相关联的各种属性的列表。它也可以表明模块的分类是组件还是功能性。

这里描述的是基于XML的软件模块属性的规范，它可以提供公共的、可移植的语言来详细说明(H(e)NB)的组件和/或模块，以及相关联的属性。为了用可移植的方法和与H(e)NB结构无关的方式提供信息，需要演变出一种具体说明模块的语言。这种语言可以与包含了XML概要和XML文件的XML语言类似。模块的格式和各种属性可以进行标准化，并且每个制造商用前面描述的格式提供描述软件模块的设备配置数据表。格式可以与XML概要类似，并且设备配置数据表可以与XML文件类似。XML签名支持增加数字签名来提供完整性、消息鉴权和/或签名者鉴权。二进制XML是一种更紧凑的描述，并且它也可以作为减少语法开销以及减少在实体之间传递配置数据的带宽需求的基础。表4中给出了一个XML概要的实例，可以是制造商用来详细描述他们模块的标准格式。

表4

制造商可以提供设备配置数据表并用数字签名进行签名。设备配置数据表可以在H(e)NB上维护以用于AuV。在校验失败的情况下，如果设备配置表的数字签名本身验证通过，可以采取适当的措施，因为这表明软件的属性、包括对失败模块的影响的信息，是完整无损的，尽管软件模块本身(即二进制镜像(image))可能已经改变或者完整性校验失败。在使用SAV的情况下，设备配置表需要在设备和PVE上进行维护。为了支持SAV，需要增加本文描述的额外的行动。

这里描述的是基于ASN.1的软件模块属性的规范，它可以提供公共的、可移植的语言来详细描述H(e)NB的组件及相关联的属性。在电信和计算机网络中，ASN.1是一种标准的、灵活的定义，它描述了用于表示、编码、传输和译码数据的数据结构。它可以提供一组独立于机器特定编码技术之外的、用于描述对象结构的正式规则，并且它是一种消除了歧义的准确的、正式的定义。通常用于定义通信协议消息、ASN.1及其相关联的编码规则，是一种二进制编码方式。其他通信协议、例如互联网协议HTTP和SMTP，定义了使用文本标记和值的消息，有时是基于扩展巴克斯-诺尔范式(ABNF)定义。这个定义也用文本的形式定义了编码。

ASN.1方法被认为更有效，以及与分组编码规则一起，当然就提供了一种更紧凑的编码方式。这种文本方法宣称更容易应用(通过创建和解析文本字符串)和更容易调试，因为可以简单地读懂编码的消息。在媒体网关协议中，定义了两种基于ASN.1和ABNF的编码。

ASN.1XML编码规则(XER)提供了一种定义了使用ASN.1定义的数据结构的文本编码。通用字符串编码规则也是为了给/从用户显示和输入数据的唯一目的而定义的。表5给出了一个用于传递设备完整性度量的ASN.1的实例。

表5

如果对于设备的每一个软件模块，它的相关联的模块属性网络都知道，则在SAV过程中，H(e)NB可以只向PVE发送所有在本地完整性校验过程中完整性校验失败的模块的标识(ID)列表。网络通过PVE可以知道特定软件模块的相关属性和它们失败的影响。这个信息可用于评估网络采取的下一个步骤，如本文描述的一样。

这里描述的是软件模块属性，它们可以被认为是传送至H(e)NB的并且可以作为来自可信的第三方(TTP)、如H(e)NB管理系统(H(e)MS)的数字证书或签名消息来提供。例如，编码镜像的总体信息元素可以包括但不局限于H(e)NB的制造商以及可用于生成模块编码镜像的摘要或RIM的完整性方法。

这里描述的是描述组件特定信息的方法。一个或多个组件组成了软件模块。组件是完整性校验的基本单元。每一个组件关联有一个可信的参考值(TRV)。组件特定的信息元素可以包括组件ID，组件ID是与组件描述有关的唯一可识别的ID。这是用一个TRV进行校验的编码单元的ID。它还可进一步包括TRV，TRV被H(e)NB的完整性校验机制用来比较组件的测量结果以验证组件的完整性。

模块特定的信息元素可以包括但不局限于在H(e)NB中描述特定模块功能的模块描述以及为制造商唯一地标识模块的模块ID。它也可以包括指明了该模块映射到H(e)NB的哪一个特定功能性的功能描述以及功能ID，该功能ID可以是全球可识别的ID，由卖方制定标准并与该功能描述一致。它还可以进一步包括标识了该模块映射到哪一个组件的组件ID以及指示了模块的版本号的发布版本。在组件和模块是一对一映射的情况下，模块特定的信息实际上和组件特定的信息是相同的。

模块特定的信息元素还可以包括严重性分级(classification)，该分级指明了当前软件完整性校验失败对系统功能性的影响。例如，可以有多层次的严重性分级系统。例如，严重性1可以是导致对H(e)NB功能性有高影响并有必要终止系统操作的模块/功能的失败。模块/功能的失败会导致基于回退编码镜像(FBC)的蹒跚(limp along)系统。在这种情况下，与基于网络的设备管理系统(如果设备是H(e)NB,该系统会是H(e)MS)通信是可能的。FBC能给指定的H(e)MS发送遇险信号。更进一步地，FBC还能支持网络发起的固件/软件更新。例如，H(e)NB的可信的环境(TrE)的任何模块或组件会具有严重性1。严重性2可以是导致H(e)NB功能性受限的模块/功能失败，可以部分地起作用或者支持全部H(e)NB功能性的子集。这种情况下，与安全网关(SeGW)通信是可能的。严重性3可以是不会影响系统的核心功能性、但在失败的情况下仍会被认为足够重要而需要提早补救的模块/功能的失败。失败的模块/功能可以通过用立即的固件/软件更新过程来替换并通过随后的重新启动生效。严重性4可以是不影响系统的核心功能性的模块的失败。失败的模块可以通过常规的固件/软件更新调度进行替换。

这里描述的是确认方法的报告过程或方法。对于AuV，设备完整性校验的所有过程都可在本地进行。如果完整性校验失败，则需要向H(e)MS发送遇险信号以指示该失败。随后的操作可以从派遣人员到解决该问题或检测该设备。可以进行补救，这种情况下失败模块的列表需要报告给补救服务器/H(e)MS。对于SAV，完整性校验失败的功能性的列表要报告给PVE。

模块依赖于制造商的应用。一组编译过的软件模块可能会形成对象镜像。完整性校验可以针对对象镜像块(chunk)进行。因此，引入了组件，组件将进行完整性校验的一组模块结合起来。一个模块在一个组件中只出现一次并且只出现在一个组件中(即一个模块不能出现在两个组件中)。这样，当进行完整性校验时，一个模块只被校验一次。H(e)NB的制造商(可能与任一软件模块的制造商相同或不同)根据架构来决定如何将模块分割成组件以进行设备完整性校验。

功能性可以基于H(e)NB的需求和功能架构，而且可以是标准化的标识符。例如，Iu接口和移动性管理就是功能。两个功能可以共享一个模块。因此，在一个组件(完整性校验单元)的完整性校验失败时，就知道了受影响的模块。由于每个模块有与其关联的功能性，因此会得出失败的功能性的列表。SAV中，这个失败的功能性的列表被发送到PVE。

这里描述的是功能性ID。该架构的使用管理着软件模块的数量和类型。为了通过多个制造商和/或利益相关者(如移动网络运营商)协调报告结构和方法，报告可以基于功能性而不是实际的模块。软件模块可以根据其功能性来进行分组。功能性ID提供了根据功能性描述将模块进行分类的方法。表6列出了一些根据目前已知的推导出的功能性。该列表可以被扩展和标准化。表6中，低位数字1-9是为将来使用或扩展预留的。

表6

这里描述的是组件ID。为了协调设备完整性校验，这些模块可以根据生成的镜像进行分类。一组对象文件集可一并存档到一个镜像文件中。这样一组模块包含同一组件ID并共同进行完整性校验，因此，一个组件有一个可信的参考值(TRV)。由于每个软件模块都有自己的参考完整性度量(RIM)，因此组件的可信的参考值(TRV)可以作为一个或多个软件模块的一系列的摘要(例如，哈希)而获得，每个模块都有与之相关联的RIM。请注意，在一个组件ID中出现的模块可能被映射到不同的功能性ID而不是相同模块出现在另一个组件ID中。该过程给制造商根据他们的架构和编译器提供了灵活性，例如，使基于对象镜像或者SAV完整性校验的步骤进行模块分组变成可能。

模块ID用于跟踪软件不同的模块，并且可能不需要进行标准化，尽管不是不可能标准化。如果模块ID没有被标准化，会留给制造商来决定存在哪些和存在多少模块。模块ID可用来提供、跟踪和构造固件/软件更新包。

这里描述的是组织和陈述各种标识符例如模块、组件和功能性之间关系的方法和结构。图1示出了一个示例性方法和结构。软件架构定义了模块的数量和类型。这些模块根据其功能性和完整性校验单元进行分类。由多个模块组成的组件有它自己的TRV。如果任何组件使用它的TRV进行的完整性校验失败了，那么要么组件本身被更改了，或者其摘要已不再与TRV相同了，或者与组件一致的TRV被更改了。任何情况下，一旦完整性校验失败，模块和完整性校验失败的组件之间的映射以及模块和功能性之间的映射会被用来确定失败的(至少是“受影响的”)功能性的列表。受影响的功能性的标识符的列表被传递到H(e)MS或者PVE。

图2示出了组件和功能性的示例性结构。如图所示，当这些组件是进行完整性校验的单元时，组件可能由制造商决定。每一个组件都要与一个功能性列表相关联。这些组件是基于这些功能性的。因此，当一个组件的完整性校验失败，失败的功能性的列表会被创建。这些组件可以按其加载顺序或者可替换地按照其执行的顺序进行组织。因此，如果组件1校验失败，则使用了来自组件1的功能的组件2的功能性不管是加载还是执行也会失败。

另一种替换的根据失败的完整性校验提取失败的功能性的列表的应用可以在成块的镜像对象文件上进行完整性校验。如果某个由对象镜像中的起始地址和结束地址指定的镜像块没有通过完整性校验，则与该失败的分段对应的软件功能的名称会被提取出来。根据应用的功能，失败的H(e)NB功能性的列表会被推导出来。可以这样做是因为软件功能属于应用了某些H(e)NB功能性的模块。例如，在UNIX环境下‘nm’提供了提取对象文件中的功能的名称的功能性。这个信息是提取自该对象的符号表的。

这里描述的是用于确认方法的软件和TRV的下载或提供。可用的三种协议是基于TR069的架构、基于开放移动联盟(OMA)设备管理(DM)的架构和基于可信的计算组(TCG)基础结构工作组(IWG)的架构。另外这些协议也可以通过利用提供的支持来配置H(e)NB。除了这三种之外，也可以考虑其他的协议。

图3中基于TR069的架构描述了客户端设备(CPE)广域网(WAN)管理协议，它是用于CPE和自动配置服务器(ACS)之间的通信的。CPE映射到H(e)NB，并且ACS映射到H(e)MS/补救服务器/操作、管理和维护(OAM)。该CPE WAN管理协议可以提供工具来管理CPE软件/固件镜像文件的下载。该协议可以提供版本识别机制、文件下载启动(ACS发起的下载和可选的CPE发起的下载)、以及文件下载成功或失败的ACS的通知。

CPE WAN管理协议也可定义数字签名的文件格式，它可选择地被用于下载个别文件或一包文件，与供CPE执行的显式的安装指南一起。签名的包格式确保了下载文件和相关安装指南的完整性，允许文件源的鉴权可能是除了ACS操作员之外的一方。下载的文件的完整性校验可以建立在将从包含在下载的文件中的各个模块计算得到的完整性摘要(如哈希)与它们对应的RIM值比较的基础上。

CPE WAN管理协议可能对H(e)NB的设备完整性校验需要的TRV的下载是有用的。这些内容可以用网络运营商的签名密钥进行数字签名。一旦接收到签名的数据包，H(e)NB然后可以解密签名并且验证收到的TRV的可靠性和完整性。当组件是由按顺序的几个模块级联而成时，TRV可以按照与这些模块对应的RIM的顺序级联而创建。

TRV也可以在数字签名前为了安全性而进行加密。它们也可能被添加到同一数字签名包中TRV创建的软件模块二进制镜像的全部或(第一或最后)部分中。

这里描述的是处理H(e)NB设备的额外的过程。这些额外的需求和过程可以使用接口标识，就像下文描述的H(e)NB-H(e)MS接口一样。H(e)NB的确认可能需要额外的协议组件需求。H(e)NB-H(e)MS应当支持安全插口层/传输层安全性(SSL/TLS)并使用基于证书的H(e)NB和H(e)MS之间的鉴权。这个证书可以与用于SeGW鉴权的证书是相同的。如果H(e)NB-H(e)MS接口使用的是基于TR069的架构，则需要采用CPE鉴权的基本或摘要鉴权来支持基于证书的鉴权。

这里描述的是基于TR069架构的H(e)MS发现可能需要的过程或结构。H(e)NB应以ManagementServer.URL(管理服务器.URL)参数中一个缺省H(e)MS统一资源定位符(URL)进行配置。这个初始化配置可以由运营商在布置H(e)NB的时候完成或者由制造商完成。H(e)NB可支持局域网(LAN)侧的通过鉴权的管理员进行的ManagementServer.URL配置。H(e)MS URL可以是超文本传输协议安全(HTTPS)URL。主机侧基于动态主机配置协议(DHCP)的H(e)MS URL更新过程可以不需要支持。如果该值在本地更新，则H(e)NB可以联系新的H(e)MS来揭开(bootstrap)配置文件并建立关系。该URL可以是名称或者互联网协议(IP)地址，它可能需要域名系统(DNS)解析。名称的DNS解析可能会返回多个IP地址，这种情况下它或者需要确保不会返回多个IP或者如果返回多个IP则H(e)NB从中任意选择一个。

这里描述的是基于TR069架构的SeGW发现。类似于H(e)MS URL，SeGW URL可以作为参数(SecureGateway.URL(安全网关.URL))来增加。该URL可以由运营商根据H(e)NB的位置来配置。通过DHCP更新这个参数可以不被支持。经授权的管理员可以进行本地更新。

为了AuV和SAV，为适应设备管理协议的其他机制、诸如TR069、OMADM、或TCG IWG在下文中描述。

这里描述的是基于OMA DM的架构，用于下载和提供软件和用于确认方法的TRV。OMA DM是由OMA DM工作组和数据同步(DS)工作组联合指定的设备管理协议。虽然OMD DM是为像电话、PDA和其他类似设备的小型移动设备而开发的，它不支持设备和DM服务器之间的宽带有线连接，只支持短距离有线连接(例如，通用串行总线(USB)或RS232C)或无线连接(全球移动通信系统(GSM)、码分多址接入(CDMA)、无线局域网络(WLAN)和其他无线通信系统)，它可以用于作为为H(e)NB提供和管理协议的设备。当H(e)NB相对于核心网络把自己当成无线发射接收单元(WTRU)而相对于通用串行网关(CSG)把自己当成基站并且没有CSG WTRU与它相连时，这可能成为现实。

OMA DM可以支持使用诸如提供(包括首次设备配置和使能/禁用特征)、设备配置更新、软件升级以及诊断报告和查询的情况。OMA DM服务器端可支持所有这些功能，尽管该设备可以选择性地应用这些特征的全部或子集。

OMA规范可以进行优化以支持上述所列的有连接限制的小型设备的特征。它也可支持完整性安全、使用鉴权(通过使用例如可扩展鉴权协议-鉴权和密钥协商(EAP-AKA))协议作为规范的一部分。

OMA DM可使用XML(或者更确切地说，来自SyncML的子集)进行数据交换。为了确认的目的，这可能对为H(e)NB的软件模块或功能性提供一种可标准化的且灵活的方式来定义和传递属性是有用的。

设备管理发生在DM服务器(设备的管理实体)和客户端(被管理的设备)之间。OMA DM支持传输层、如无线应用协议(WAP)、HTTP或对象交换(OBEX)或类似的传输。

DM通信是由DM服务器使用任何可用的方法例如WAP、Push(推送)或短消息服务(SMS)、使用通知或警告信息异步发起的。一旦通信在服务器和客户端之间建立起来，就会通过交换一系列消息来完成给定的DM任务。

OMA DM通信可以基于请求-响应协议，其中请求只能由DM服务器发出，且客户端可以用应答消息进行响应。服务器和客户端都是有状态的，这意味着任何由于特定的顺序的数据交换只能发生在内置的鉴权过程之后。

由于DM通信只能由DM服务器发起，在DM上应用SAV可能需要基于服务器请求的方法来确认，可能(立即)继设备鉴权过程之后使用互联网密钥交换(IKE)v2(这是由设备启动的)。几种不同类型的消息可以考虑作为传递确认数据(例如，失败的软件模块或设备功能性的列表)。例如，管理警告消息可从设备发送到服务器。可替换地，自设备或者服务器至少传输了一个管理警告信息之后，可以由设备发给DM服务器的通用警告消息的用户也是可以考虑的。由于所有消息、包括这些警告消息使用了同步标记语言(SyncML)格式，该格式在详细描述内容和内容的元数据时提供了灵活性，因此它可用于确认信息传输。

DM可以支持分段数据的传输，这可用于更新的大小比较大时的软件更新。当从H(e)NB传输到PVE的失败的功能性的列表信息的大小足够大以至于需要分成多个消息时，分段数据传输也可用于传输这样的列表。

这里描述的是基于TCG IWG的架构，它用于下载和提供软件以及用于确认方法的TRV。可信的计算组(TCG)、基础结构工作组(IWG)已详细描述了用于平台完整性管理的详细格式和协议。在完整性测量和报告的基本模型中，网络和服务接入可以取决于平台的验证状态。

TCG IWG标准提供了一个H(e)NB SAV或AuV需要的结构的超集。没有IWG规范可以现成使用的。此外，将IWG规范用于设备确认的特定用途的情况需要对XML概要进行修改(如略去需要的元素)，这意味着偏离了IWG标准。

图4示出了请求的平台和网络侧验证者之间的基本交互。验证者需要对请求者的平台的每一个组件寻找鉴权信息(在第五步)。也就是说，为了由度量提供者变成可用的平台确认，需要参考测量。度量提供者的实例有硬件制造商、软件供应商或代表制造商和供应商的可信的供应者。一旦验证者能够识别每个请求者的平台的组件，并将报告的测量值与预期的(基准)参考测量值(该组件的)进行比较，验证者就能衡量请求者的平台的信任级别。在这个阶段，验证者能根据请求者在可信赖方对接入资源/服务的愿望做出决定。这在第六步中示出。

需要注意的是IWG完整性验证架构在很大程度上是独立于验证过的平台上的硬件可信的平台模块(TPM)的存在的。尤其是在标准中的数据格式有能力表达通用组件和平台安全相关的属性。

为了支持给定组件内的技术上的信任，组件制造商可能会以其组件来源相关的信息支持他的产品。也就是说，制造商或可信的第三方必须提供一些该组件的静态参考值。组件的这些静态参考/度量值被称为参考测量，并用TCG参考清单(RM)结构的形式表示。组件的清单包含诸如其身份(identity)、制造商、型号、版本号等等的信息。就本申请而言，H(e)NB组件的可信的参考值(TRV)可以由TCG IWG参考清单(RM)结构详细描述。

当平台需要得到确认，它必须向确认者(如平台验证实体-PVE)提供完整性报告，该完整性报告是从如图5中所示的覆盖了平台组件的一组快照编译而成的。所述快照表示关于平台的每一个相关组件(可能是这些组件的子组件)的测量和断言(assertion)。参考(ID参考)被用来指向属于如图6中所示的完整性报告中报告的组件的信息。

基于RM的用于确认的核心组件是在TCG标准中描述的。为了灵活性，XML命名空间(namespace)可用于IWG格式的平台特定的文档(profile)，例如移动或PC客户端。

可共用的完整性日志结构通过定义“硬件架构”类型值来指示平台特定的编码方式可以解决一些平台特定的限制。类型值可以通过使用可共用的命名空间机制例如XML命名空间和XRI，用TCG命名空间的形式来定义。

从核心概要扩展继承而来的RM概要，定义了结构以保持参考。该RM概要可大体理解为由如图7所示的两组信息组成。第一个属于关于各个组件的信息，并涵盖了诸如组件模型、名称、版本、序列号等属性。该信息是在ComponentIDtype(组件ID类型)结构中捕获的。围绕着该组件特定的信息的是属于捕获(收获)组件信息的元数据。这由概要中IntegrityManifestType(完整性清单类型)结构表示。捕获的元数据包括使用的收集者(收获者)方法、RM签名(以及相关签名者/发行者信息)、组件(软件的)的概要值、信任等级、断言进行以及其他。

这里描述的是AuV特定的项。AuV中，完整性校验可在本地进行。因此，任何本文描述的数字签名或消息鉴权码都可以使用。这些可以由制造商使用制造商的私有密钥/共享的秘密来签名，并且可以使用制造商共享的秘密或公开的密钥来为他们的可靠性进行本地验证，以及可用于本地编码的完整性确认。

然而，在AuV中，设备的验证可在设备中本地执行，并且信息不被发送到任何网络实体。因此，可能会留给制造商来决定确切的用于确认的的方法。不过，最低限度的安全需求可以进行标准化，如‘完整性算法必须提供等于或优于SHA–1的安全性’。

这里描述的是AuV怎样应用TRV证书管理。由于系统的组件依赖于实际的应用，有必要统一设备完整性使用的机制。这可以通过标准化用于生成被称为TRV的可信的参考完整性度量的方法的最低要求来实现。这些TRV可由生产商生成或由对该值进行数字签名的TTP生成。因此，回顾一下组织信息、生成TRV、发布并使用它们的机制。

这里描述的是首次TRV认证初始化(initialization)。在完成H(e)NB开发之后，制造商执行本地完整性数据初始化。在这个过程中，所有的软件模块的名称被收集在设备配置数据表中。如果存在任何与配置文件有关的工厂设置，它们也被包含在设备配置数据表中。这些模块是可执行的，而不是源代码。也进行配置数据提供的发起。设备配置数据表概要紧跟标准概要。本文描述的XML或者ASN.1概要可以作为基准使用。所有关于严重性、兼容性、步骤和其他的属性都是根据设备的结构填充(populate)的。

图8示出了证书管理架构800。在制造商的认证服务器805中，所有模块实体810是用参考完整性度量填充的。完整性方法属性和TRV属性被填充。设备配置数据表然后由制造商使用私有密钥820进行签名。它也可以用由TTP发布给制造商的根证书进行认证。由此，参考完整性度量(RIM)变成了TRV 830。

在一个替换架构中，TRV可以由TTP生成。制造商提供可执行的及部分完成的设备配置表，该表列出了所有的模块和一些可在制造商方填入(fill)的填充的属性。是概要度量的TRV由TTP填充。然后TTP对设备配置证书进行数字签名。

设备配置数据表可在设备中进行维护，因为AuV是在设备中本地进行的。该设备配置数据表必须保存在只能由鉴权的一方访问的安全存储器中。可替换地，设备配置数据表必须被加密，它在H(e)NB中进行读取和使用时可以被解密。在这两种情况下，只有H(e)NB的可信的环境(TrE)有权发布用于由应用读取访问的设备配置数据表或修改它。

在安全启动过程中，当设备执行组件的本地测量时，生成的摘要会与设备配置数据表中指定的值进行比较。如果发生不匹配则被解释为设备完整性确认失败。设备配置数据表的完整性必须在它被访问之前得到确认。设备配置数据表的完整性也可以在数据表中描述的任何一个或多个组件的一个或多个完整性校验失败之后进行确认。

这里描述的是随后的TRV证书更新过程。对于部署好的H(e)NB系统，如果制造商发布了一个新的软件版本，那么制造商会在提供软件模块给H(e)MS/OAM服务器/补救服务器的同时提供该设备配置数据表。这可以由制造商通过执行‘PUSH(推送)’操作异步完成。这样的PUSH可以根据运营商和制造商之间达成一致的预定的更新/升级进行调度，这些更新/升级是基于运营商和制造商之间签订的服务协议的。

这样的PUSH之后，用于更新固件或软件模块的OAM过程或TR069过程可能会被调用(invoke)，这指示设备在预定的时间重新启动以从H(e)MS/OAM/补救服务器执行‘PULL’操作软件/固件。加密、签名以及随机数可以分别提供诸如保密性、完整性和重放保护的安全方式。

可替换地，当设备配置数据表由于根据软件发布时间表的预定期满而期满时，H(e)NB会启动固件/软件更新过程，并从OAM/补救服务器针对软件/固件开始PULL操作。可替换地，H(e)MS可以根据已知的时刻表(例如从制造商处获取的)执行软件更新的预定的PUSH操作。

这里描述的基于TR069或OMA DM架构的过程支持软件/固件下载到设备。在AuV的情况下，TR069协议可以提供对客户端设备的远程管理支持。它也可以提供对设备软件/固件更新的支持。TR069可用于提供固件/软件更新到H(e)NB设备。

这里描述的是为随后的更新而在H(e)NB 905和H(e)MS 910之间进行的AuV过程实例，这些随后的更新如图9所示，可以在H(e)NB 905上由经过授权的管理员或者通过利用URL更新过程来执行。H(e)NB 905被用如前文描述的关于H(e)MS发现的ManagementServer.URL参数(0)中的缺省H(e)MS统一资源定位符(URL)进行初始化配置。这可能由制造商提供。H(e)MS 910打开传输控制协议(TCP)连接(1)。在H(e)NB 905和H(e)MS 910之间建立起安全插口层(SSL)连接以允许安全通信(2)。H(e)MS 910发起远程过程调用(RPC)方法设置参数值(SetParameterValue)并更新ManagementServer.URL(3)。在成功更新后，H(e)NB 905以指示成功或失败的状态字段发送设置参数值响应(SetParameterValuesResponse)(4)。H(e)NB 905更新H(e)MS URL(5)。

这里描述的是为支持文件传输使用H(e)NB-H(e)MS接口的TR069的AuV过程。TR069支持通过单播和多播传输协议进行文件传输。单播协议包括HTTP/HTTPS、文件传输协议(FTP)、安全文件传输协议(SFTP)和普通文件传输协议(TFTP)。多播协议包括通过单向传输的文件传递(FLUTE)和数字存储媒体命令和控制(DSM-CC)。对HTTP/HTTPS的支持是必选的。为了使TR069适应H(e)NB-H(e)MS接口中的固件/软件下载，除了HTTP/HTTPS，FTP安全(FTPS)也可以使用并需要加到TR069中。FTPS(也称为FTP安全和FTP-SSL)是FTP的扩展，它增加了对传输层安全性(TLS)和SSL加密协议的支持。由于H(e)NB-H(e)MS接口使用了TLS-SSL接口，FTPS可应用于传输文件。

TR069也提供了对为下载文件重利用相同的TLS连接、为下载文件产生一个新的连接的支持，后一种情况可能存在于平行或发布第一个会话时。下载完成之后，信令的TLS连接被建立。如果HTTP/HTTPS被用于下载文件，则可以使用标准的TR069过程。

这里描述的是支持补救的AuV过程实例。如果AuV中设备完整性校验失败了，则本地遇险标志被设置并且该系统重新启动后备代码(FBC)。FBC可以安全地存储在设备中，如果安全启动过程(或设备的任何其他被认为是对确保设备的基本完整性‘必不可少’的过程)失败，FBC会被加载和执行。FBC有与核心网络进行基本通信的能力和有向预先指定的H(e)MS发送遇险信号的能力。H(e)MS可以已经由H(e)MS发现过程进行了更新。遇险信号的内容可以安全地存储在设备上的FBC内，或者由MNO提供并作为设备配置数据表的一部分进行安全存储。遇险信号可以包含指示设备完整性校验失败的具体信息的错误代码信息元素。一旦接收到遇险信号，网络会决定更新完整的镜像和包含了可信的参考值的设备配置文件。FTP服务器存储了包含完整镜像的包文件、设备配置文件和安装指南。该FTP服务器可以与H(e)MS进行合并。

该过程可以通过FBC支持TR069协议取得，图10示出了H(e)NB 1005、H(e)MS 1010和FTP服务器1015之间的流程图的实例。如果设备完整性校验失败且信任根(RoT)已经在H(e)NB 1005上启动了FBC(0)，则H(e)NB 1005与预先指定的H(e)MS服务器1010建立TCP连接(1)。执行SSL初始化和/或建立传输层安全性(TLS)(2)。H(e)NB 1005然后调用RPC方法INFORM、例如遇险信号给H(e)MS 1010。遇险信号可以包含任何信息元素、例如设备ID(Device ID)、事件(Event)、最大包络(MaxEnvelopes)和当前时间(CurrentTime)的组合。

设备ID(Device ID)是一个结构，该结构可以包含制造商名称；设备制造商的组织唯一标识符(OUI)；产品分类(ProductClass)，可用于指示使用序列号的产品的分类或者用于为了让序列号(SerialNumber)属性被用于指示TrE ID或H(e)NB ID而指示设备的序列号；以及序列号，可用于发送特定设备的序列号或者发送TrE ID或H(e)NB ID。

事件(Event)字段可以包含引起执行的RPC方法通知的事件代码。可能需要定义一个新的事件代码(X_HeNB_FBC调用)来指示设备完整性校验已经失败以及FBC已经被调用以发送该遇险信号。用以向ACS(例如H(e)MS)指示可能被包含在单个HTTP响应中的叫做“SOAP包络”的参数的最大发生次数的最大包络值，可以被设为1。参数最大包络(MaxEnvelope)的值可以是1或者更大。由于遇险指示倾向于只发送一次，将该值设为1是合适的。当前时间(CurrentTime)字段是H(e)NB1005知道的当前日期和时间的值。因此，该通知(Inform)RPC方法向H(e)MS 1010指示了设备完整性校验已经失败并且正在为初始化固件/软件更新进行连接。

余下的过程1000是可选的。H(e)MS 1010可以调用RPC方法下载并且提供固件或者软件位置的URL和设备配置数据表(4)。下面的参数值需要设置。CommandKey(命令密钥)参数是一个可能会被H(e)NB 1005用来指示特定下载的字符串。这可以是用于使下载和响应相关联的任何字符串。FileType(文件类型)参数可以针对固件/软件镜像被设置为“1FirmwareUpgrade Image(固件升级镜像)”以及针对设备配置数据表被设置为“X_<OUI>_data_sheet(X_<OUI>_数据_表)”。URL参数是下载文件的URL。HTTP和HTTPS必须被支持。针对下载也推荐支持FTPS。用户名(Username)参数可以被H(e)NB 1005用来鉴权文件服务器。密码(Password)参数可以被H(e)NB 1005用来鉴权文件服务器。FileSize(文件大小)参数是要下载的文件的大小。还可以设置其他参数。

H(e)NB 1005连接到FTP服务器1015并且下载固件镜像(或软件镜像)和设备配置数据表(5)。FTP服务器1015上的信息可以表示成补救信息。一旦成功完成下载，就发送一个具有值设为0(表示成功)的状态参数的下载响应(DownloadResponse)，或者一个下载请求的错误响应(表示失败)(6)。也可以接着用替换过程来指示成功或者失败的下载。在成功的下载响应之后，H(e)MS 1010则调用H(e)NB 1005中的重新启动过程(7)。H(e)NB 1005中的RPC处理器重置本地遇险标志并正常启动以执行本地完整性校验过程(8)。签名的包格式可能包括重新启动命令，它可用来指示H(e)NB 1005在固件或者软件更新之后进行重新启动。传输完成(TransferComplete)RPC方法可以从H(e)NB 1005被调用以指示H(e)MS 1010固件/软件更新过程已经成功完成(9)。可替换地，SeGW可以向H(e)MS 1010发送消息以指示设备已经成功启动，这在H(e)MS 1010中会被解释为成功的固件/软件更新完成消息。

这里描述的是一个可用于H(e)NB固件/软件更新的文件格式1100的实例，在图11中示出。报头1105可以是一个固定长度的结构，包括前同步码、格式版本和命令列表和负载(payload)组件的长度。命令列表1110包含可被执行以提取和安装包含在包中的文件的指令序列。每一个命令都可以是类型-长度-值(TLV)的形式。签名字段1115可以包含公共密钥加密标准(PKCS)#7数字签名块，该数字签名块可能包含了一组0或者更多数字签名。负载文件1120可能包括要按照命令列表1110中的指令进行安装的一个或多个文件。除了固件/软件更新文件外，设备配置数据表也用签名包格式进行打包。

为了支持存储分类器的需求，可以增加下列新的H(e)NB特定的命令：1)存储到安全非易失性存储器中(针对诸如TRV或者配置数据表之类的数据)；以及2)存储到非易失性储存器中；或者3)可以存储到易失性储存器中。

图12示出了SAV的网络架构1200的实例。H(e)NB 1205作为用户设备1210通过通信链路1215与核心网络1220通信的网关。H(e)NB 1205与SeGW 1225通过不安全的通信链路1215相互配合。SeGW 1225可以允许通过鉴权的H(e)NB接入到核心网络1220。H(e)MS 1230作为H(e)NB管理服务器并提供对补救的支持。H(e)MS 1230可以支持标准的协议来管理H(e)NB 1205。平台确认实体(PVE)1235存储了当H(e)NB 1205中的某一组功能性失败时需要采取的行动的策略。失败的功能性由H(e)NB 1205在SAV进程中报告。OAM 1240是操作、行政和管理服务器。尽管H(e)MS 1230和PVE 1235是作为分开的实体显示的，但它们可以合并成一个单独的网络实体。这样一个合并的实体可以是每个网络运营商的一个节点或者可以是每个运营商多个节点。

这里描述的是关于SAV的过程。总的来说，在执行设备鉴权过程之前，H(e)NB的TrE首先进行某些预先指定的组件的完整性校验，这些组件例如但不局限于启动代码、后备代码(FBC)、SeGW的基本通信代码以及执行使H(e)NB接入到H(e)MS的过程的代码。在这一步中，组件完整性的验证可以通过将来自完整性测量的概要输出与设备配置数据表中指定的值进行比较而本地进行。如果组件通过了完整性验证，则他们被装载和执行。

进一步的校验可以通过TrE本身或者通过外在于TrE的H(e)NB中的测量组件进行，但由TrE保证完整性。在这些后面的步骤校验中，其他组件、配置或者重置H(e)NB的参数在被加载或者启动时、或者在其他预定义实时时间事件、不管在哪里只要这些对测量组件是可用的，都会被校验完整性。在这一步中，完整性校验的验证可以在本地进行。

H(e)NB然后会尝试与SeGW建立互联网密钥交换(IKEv2)安全联盟。在该进程中，H(e)NB将自己向SeGW进行鉴权并且验证SeGW的可靠性(authenticity)。这可以通过证书交换和证书鉴权来进行。如果鉴权成功，则TrE通过汇编受组件失败影响的失败的功能性的列表将本地完整性验证的结果传达给PVE。TrE然后对消息(使用受TrE保护的签名密钥，以保护消息的完整性)签名，该消息断言了进行完整性测量和验证的H(e)NB的核心部分以及(向PVE)报告的(向PVE)失败的功能性的列表已经通过了它上面进行的(例如通过信任根(RoT))完整性校验并且因此已经能使用签名密钥并执行签名操作，或者通过使用秘密签名密钥进行其他的本身可信的操作。

图13A和13B示出了一个用H(e)NB 1305、SeGW 1310和PVE 1315进行的SAV过程1300的实例。在组件1和组件2模块的本地完整性验证之后，这些模块被加载和执行。组件3模块的设备完整性校验的结果和验证结果由H(e)NB 1305发送给SeGW 1310以转发给PVE 1315(0)。

H(e)NB 1305可以发送IKE_INIT消息以启动建立包含了加密算法的安全参数索引、版本号、IKEv2标志、Diffie-Hellman值以及初始值随机数的IKEv2安全联盟(1)。SeGW 1310可以发送IKE_INIT响应给IKE_INIT请求消息(2)。SeGW 1310可以从H(e)NB 1305选择加密套件并完成Diffie-Hellman交换。H(e)NB 1305可以为相互鉴权而以IKE_AUTH_REQ发送其证书(3)。它也可以包括形式为失败的功能性的列表的完整性验证结果。如果本地完整性验证成功，则不包括这个失败的功能性的列表。这种情况下就发送空列表。这里描述了组件、模块和功能性之间的关系。

SeGW 1310可以评估H(e)NB 1305的鉴权凭证并提取将要发送给PVE1315的功能性ID的列表，如果该列表存在的话(4)。如果鉴权评估成功，则SeGW 1310将其指示给H(e)NB 1305(5s)。它也可以将它自己的证书在响应中发送给H(e)NB。如果鉴权失败，则就传递给H(e)NB 1305(5f)。

如果鉴权成功，并且失败的功能性的列表被包含在IKE_AUTH消息中，则SeGW 1310将该失败的功能性的列表与H(e)NB ID一起转发给PVE 1315(6)。如果该列表不存在，就向PVE 1315发送一个空的列表。根据该失败的功能性的列表，PVE 1315可以决定将采取的行动、例如隔离设备、提供完全接入、提供部分接入或者可选择地请求H(e)MS干涉以进行设备补救(7)。如果PVE 1315决定受影响的功能性不重要并且因此H(e)NB 1305可以工作，则将该决定指示给SeGW 1310以允许设备接入网络(8s)。SeGW1310指示由PVE 1315进行的设备完整性评估的结果。如果失败的模块不重要，则PVE 1315就允许H(e)NB 1305完全接入到网络中(9s)。完全地或者部分地根据接收到的空的失败的功能性的列表，如果PVE 1315决定H(e)NB应该能足够被信任用于鉴权，则会获得H(e)NB的‘确认’的状态。在这种意义上，确认被解释为由PVE 1315从网络的角度作出的指示H(e)NB 1305值得足够信任来进一步与之交互的决定。

如果支持补救，则PVE 1315通过消息发送指示给H(e)MS 1320以启动由H(e)NB ID识别的设备的的补救(8f_1)。它还可以包括失败的模块的列表。根据失败的功能性的列表和设备特定的配置数据表，H(e)MS 1320决定需要的固件或者软件更新。如果支持补救，则PVE 1315可以发送指示给H(e)NB 1305来为H(e)MS 1320发起的补救做准备(8f_2)。根据PVE 1315的响应，SeGW 1310会限制接入并将该结果通知给H(e)NB 1305(9f)。系统以FBC模式重新启动以启动设备发起的补救(10)。该步骤是可选的，因为重新启动可以由H(e)MS 1320使用针对补救的TR069协议来处理。

这里描述的是SAV的H(e)MS和PVE发现过程。H(e)NB可以被采用工厂的默认设置、包括PVE的IP地址、H(e)MS和OAM来进行配置。他们也可以由H(e)MS使用TR069协议通过如图9所示的TR069协议支持的设置参数(SetParameter)和获取参数(GetParameter)RPC方法来配置。注意，该过程也可以被用来改变PVE的地址。也可以定义与ManagementServer.URL参数类似的其他参数(PlatformValidationServer.URL(平台确认服务器.URL))以在H(e)NB上保持PVE URL。类似地，PlatformValidationServer.URL的工厂设置可以在制造的时候预先配置并之后被TR069更新。

这里描述的是SAV的完整性方法和过程。在SAV中，设备完整性校验可在本地进行。完整性校验的结果可以通过失败的功能性的列表的形式传给PVE。因此例如本文段落[0038]-[0040]中描述的任何完整性校验方法都可以使用。完整性校验不是由网络实体进行。因此，可以留给制造商去决定合适的用于确认的完整性方法。然而，最低的安全需求可以被标准化，例如‘完整性方法必须提供等于或优于SHA-1的安全性’。

这里描述的是SAV中可用于TRV证书管理的机制。首先描述支持SAV的接口和消息。PVE-SeGW接口可以使用点对点协议(PPP)。PPP可以提供对鉴权、加密和压缩的支持。可替换地，传输层安全性/安全插口层(TLS/SSL)也可以使用。

有多个消息可在PVE-SeGW接口上发送。例如，H(e)NB_Integrity_Information(H(e)NB_完整性_信息)消息可以包含失败的功能性的列表，该列表是由H(e)NB通过IKEv2NOTIFY(IKEv2通知)消息发送给SeGW并由SeGW提取的。表7给出了一个该消息的内容的实例。

表7

H(e)NB_Integrity_Information消息的响应是表8所示的H(e)NB_Validation_Result(H(e)NB_确认_结果)消息。

表8

PVE-H(e)MS接口也可以是基于PPP的，因为他们都是网络实体。可替换地，也可以使用TLS/SSL。在一个实例中，PVE和H(e)MS可以是一个实体。表9示出了一个该接口上的消息的实例。

表9

可替换地，PVE可以只发送失败的功能性的列表(或者可选地，也发送所有通过完整性校验的功能性的列表或者所有没有通过完整性校验的功能性的列表)，并且H(e)MS自己决定采取哪个行动。如表10所示。H(e)MS可以采取下述行动：立即补救、调度补救以及需要管理员干涉。

表10

这里描述了关于SAV的H(e)NB架构和功能性。H(e)NB架构可以包括外部的TrE完整性校验者。H(e)NB的TrE可以将组件的完整性验证任务委托给可以是被应用的硬件和/或软件的外部实体，该组件的完整性验证的任务是TrE的责任。这种情况在TrE不够快或者没有足够的资源来进行设备完整性校验之时可以使用。这种情况下，TrE验证将会执行设备完整性确认任务的硬件和/或软件实体的完整性和可靠性。成功确认之后，TrE允许外部完整性校验者来执行该任务并将结果和测量数据报告给TrE。

H(e)NB实体可以有一个本地时间服务器来为各种事件、报告和与网络的通信提供时间标记。这样一个时间服务器可以使用网络时间协议(NTP)来同步时间。该时间服务器码和NTP码也应在它们被TrE或者外部TrE完整性校验者执行之前进行完整性确认。

H(e)NB架构也可以将确认和鉴权结合起来。除了在AuV情况下用于确认和鉴权的结合的机制之外，确认和鉴权之间的结合可以由IKEv2会话提供，即，只在完整性校验通过之后才发布敏感密钥和鉴权功能性。鉴权证书和SAV中本地确认的结果可以用IKEv2IKE_AUTH_REQ消息进行发送。SeGW滤出失败模块的列表并将其转发给PVE。如果该消息中不包括这样的列表，它则将该信息中转给PVE。PVE决定将来的行动，并将该结果指示给SeGW，在某些情况下指示给H(w)MS。

在另一个替换结合方法中，H(e)NB预先装备了密钥对，密钥对中私有部分安全地存储在H(e)NB的TrE内，而公共(public)部分对H(e)NB可用。H(e)NB的制造商可以生成该密钥对并相应地提供私有和公共密钥。为了通过加密方法创建确认和鉴权的结合，H(e)NB用来自证书的公共密钥来加密其接收自AAA服务器的(其中，AAA服务器请求H(e)NB计算基于秘密的计算的鉴权材料并将它发回AAA服务器)消息(例如IKE_AUTH响应消息)，并将加密的数据转发给TrE。TrE然后解密该数据并计算该基于秘密的鉴权材料(例如，在使用了对称鉴权的情况下的EAP-AKARES参数，或者在使用了基于证书的鉴权的情况下的基于私有密钥的使用的AUTH参数)，需要这些材料向AAA确认H(e)NB的标识的可靠性。

在一个替换结合方法中，密钥和其他TrE的敏感计算能力对这些应用是不可访问的，除非H(e)NB的TrE知道了本地完整性校验成功的结果，该敏感计算能力由基于IKEv2的H(e)NB的设备鉴权应用使用。

这里描述了存储在H(e)NB和PVE中的策略规范。H(e)NB设备配置文件描述了存储在H(e)NB中的策略，它描述了诸如功能性ID、组件ID和模块ID等属性，这些将在本文详细描述。设备配置表在出厂时被初始化。该信息的初始化过程和随后的AuV更新在这里描述并可应用于SAV的情况。

PVE策略配置文件可以包括失败的功能性与SeGW行动、H(e)NB行动以及H(e)MS行动之间的映射。根据失败的功能性的列表，PVE可以决定H(e)NB、SeGW和H(e)MS将会采取的行动。表11定义了这些行动。

表11

这里描述的是SAV中支持补救的方法。为了支持补救，H(e)NB与H(e)MS相互配合。该连接可以通过SeGW或者使用TLS/SSL直接通过网络。如果在安全启动进程中，设备完整性校验针对步骤1或步骤2编码而失败，则执行FBC并尝试补救，其中步骤1或步骤2编码是由制造商预先设计好的并包含了鉴权和与SeGW通信的必须的编码以及TrE的编码。

图14示出了包含了H(e)NB 1405、H(e)MS 1410和FTP服务器1415的SAV补救的示例性流程图1400。如果设备完整性校验失败并在RoT使用FBC启动之后(0)，H(e)NB 1405与预先设计的H(e)MS服务器1410建立连接(例如，通过使用TCP连接)(1)。然后执行SSL初始化和/或之后建立TLS(2)。H(e)NB 1405然后与H(e)MS 1410一起调用RPC方法通知(例如，遇险信号)(3)。该遇险信号可以包括设备ID(Device ID)、事件(Event)、最大包络(MaxEnvelopes)以及当前时间(CurrentTime)。

设备ID(Device ID)是一个结构，该结构可以包含制造商名称；设备制造商的组织唯一标识符(OUI)；产品分类(ProductClass)，可用于指示使用序列号的产品的分类，或可用于为了让序列号(SerialNumber)属性被用于指示TrE ID或H(e)NB ID而指示设备的序列号；以及序列号字段，可用于发送特定设备的序列号或者用于发送TrE ID或H(e)NB ID。

事件(Event)字段可以包含用于引起执行RPC方法通知的事件代码。为了使TR069适应SAV补救，可能需要定义新的事件代码(X_HeNB_FBC调用)来指示设备完整性校验已经失败以及FBC已经被调用以发送该遇险信号。最大包络(MaxEnvelopes)值设为1。该值可以被忽略但仍设为1。当前时间(CurrentTime)字段被设为H(e)NB 1405知道的当前日期和时间。

通知RPC方法向H(e)MS指示了设备完整性校验已经失败并且正在为发起固件更新进行连接。然后H(e)MS调用RPC方法上传(Upload)来指示H(e)NB上传失败的功能性的列表和制造商特定的错误码列表(4)。这些错误码可能涉及与完整性校验已经失败的组件一致的软件模块或者可能包含特定于调试的错误码。提供了文件必须被上传到的FTP服务器1415的URL。注意，FTP服务器1415可以由制造商维护。FTP服务器1415可以是由制造商提供的补救服务器。

H(e)MS 1410通过发送消息Prepare_For_Upload(准备_上传)来指示FTP服务器1415准备上传失败的功能性的列表(5)。H(e)NB 1405然后调用HTTP/HTTPS/FTPS过程来上传包含了失败的功能性的列表的文件(6)。接收到该文件之后，当H(e)MS收集上传的文件时，FTP服务器1415或H(e)MS 1410评估需要的补丁或者固件/软件更新来解决问题(6a)。如果该包含了失败的功能性的列表的文件被上传到FTP服务器1415，在评估完所需的补丁之后，FTP服务器1415发送Download_Package_Ready(下载_包_就绪)消息给H(e)MS(7)。如果H(e)MS已经收集了上传的文件，则不需要该消息。可替换地，如果H(e)MS 1410的功能性和FTP服务器1415合并起来，则也不需要该消息。

可替换地，该信息可以直接从PVE处接收，并且不需要步骤1至5。

H(e)MS 1415然后调用RPC方法下载(Download)并提供固件或者软件位置的URL和设备配置数据表(8)。下述参数值可以被设置。CommandKey(公共密钥)参数是可能会被H(e)NB 1405用来指示特定下载的字符串，并且可以是任何字符串。它被用来使下载和响应发生关联。FileType参数可以针对固件镜像而被设置为“1Firmware Upgrade Image”以及针对设备配置数据表被设置为“X_<OUI>_data_sheet”。URL参数是下载文件的URL。HTTP和HTTPS必须被支持。针对下载也推荐支持FTPS。Username参数可以被H(e)NB 1405用来鉴权FTP服务器1415。Password参数可以被H(e)NB 1405用来鉴权FTP服务器1415。FileSize参数是要下载的文件的大小。还可以根据TR069协议需求设置其他参数。

H(e)NB 1405连接到FTP服务器1415并下载固件或者软件镜像和设备配置数据表(9)。一旦成功完整下载，可以发送一个具有值为0(指示成功)的状态参数的DownloadResponse或者一个下载请求的错误响应(指示失败)(10)。本文描述的替换过程也可接着用于指示成功或者失败的下载。

在成功的DownloadResponse之后，H(e)MS 1415则调用H(e)NB 1405中的重新启动过程(11)。H(e)NB 1405中的RPC处理者重置本地遇险标志并正常启动以执行上面指示的本地完整性校验过程(11a)。签名的包格式可以包含重新启动命令，该命令用于指示H(e)NB 1405在固件或软件更新之后重新启动。

可选择地，可以从H(e)NB调用一个传输完成(TransferComplete)RPC方法来指示H(e)MS固件/软件更新过程已经成功完成(12)。注意，可替换地，SeGW可以发送消息给H(e)MS以指示设备已经成功启动，这会被H(e)MS解释为固件或软件成功更新完成的消息。

图15示出了通过PVE进行SAV补救的实施例的流程图1500。该过程包括H(e)NB 1505、SeGW 1510、PVE 1515、H(e)MS 1520和FTP服务器1525。在安全启动进程中，如果步骤1和步骤2编码通过了完整性校验并且被加载并成功进行了鉴权，则H(e)NB 1505可以与SeGW 1510进行通信，通过IKEv2消息发送本地完整性校验的结果(1)。H(e)NB 1505通过如图16所示的IKEv2NOTIFY消息1600发送失败的功能性的列表和制造商特定的错误码列表给SeGW 1510。

SeGW 1510然后可以通过H(e)NB_Integrity_Information消息来发送本地完整性校验的结果，该消息可以包含失败的功能性的列表和/或制造商特定的错误码列表(2)。根据接收到的信息，PVE 1515可以用H(e)NB_Validation_Result消息来回应SeGW 1510，该消息可以包含SeGW行动和H(e)NB行动(3)。SeGW 1510可以将H(e)NB行动转发给H(e)NB1505(5)。H(e)NB可以相应地做准备并为本地补救做准备或者不采取行动。

根据接收到的信息，PVE也可以发送H(e)NB_Validation_Result给H(e)MS 1520，该消息可以包含失败的功能性的列表、制造商特定的错误码列表、H(e)MS行动和H(e)NB ID(4)。根据由PVE 1515发送给H(e)MS 1520的行动，H(e)MS 1520可以调度补救更新或者立即更新。在这两种情况中，H(e)MS 1520将该列表发送给制造商特定的补救FTP服务器。

H(e)MS 1520可以将H(e)NB_Validation_Result消息转发给FTP服务器1525，该消息可以包含失败的功能性列表、H(e)NB ID及制造商特定的错误码列表(4a)。FTP服务器1525可以评估固件/软件下载文件并准备下载包(4b)。FTP服务器1525向H(e)MS 1520发送Download_Package_Ready消息。如果H(e)MS 1520收集上传的文件，则由此可以不需要该消息。可替换地，如果H(e)MS 1520和FTP服务器1525合并起来，则该消息也不需要发送。

H(e)MS 1520然后调用RPC方法下载并提供固件/软件位置的URL和设备配置数据表(7)。下述参数值可以被设置。CommandKey参数是可能会被H(e)NB 1505用来指示特定下载的字符串，也可以是任何使下载和响应发生关联的字符串。FileType参数可以针对固件镜像被设置为“1Firmware Upgrade Image”以及针对设备配置数据表被设置为“X_<OUI>_data_sheet”。URL是下载文件的URL。HTTP和HTTPS必须得到支持。针对下载也推荐支持FTPS。Username参数可以被H(e)NB 1505用来鉴权文件服务器。Password参数可以被H(e)NB 1505用来鉴权文件服务器。FileSize参数是要下载的文件的大小。还可以根据TR069协议需求设置其他参数。

H(e)NB 1505连接到FTP服务器1515并下载固件/软件镜像和设备配置数据表(8)。一旦成功完整下载，一个具有值为0(指示成功)的状态参数(argument)的DownloadResponse或者一个下载请求的错误响应(指示失败)被发送给H(e)MS 1520(9)。TR069中描述的替换过程也可接着用于指示成功或者失败的下载。

在成功的DownloadResponse之后，H(e)MS 1515则调用H(e)NB 1505中的重新启动过程(10)。H(e)NB 1505中的RPC处理者重置本地遇险标志并正常启动以执行上面指示的本地完整性校验过程(10a)。可替换地，签名的包格式可以包含重新启动命令，该命令用于指示H(e)NB 1505在固件或软件更新之后重新启动。在固件/软件更新成功完成之后，可以向SeGW1510发送传输完成消息(11)。可替换地，传输完成(TransferComplete)RPC方法可以由H(e)NB 1505调用以向H(e)MS 1520指示固件/软件更新已经成功完成。在另一个实例中，SeGW 1510可以发送消息给H(e)MS 1520以指示设备已经成功启动，这会被H(e)MS 1520解释成一个成功的固件/软件更新完成消息。

这里描述的是在平台确认和管理(PVM)架构中使用SAV的架构和方法。PVM提供了一种系统方法来确认和管理设备，当他们首先尝试附着到通信网络上以及随后的监视设备的完整性、通过来自可信的计算的安全技术信赖部分。PVM提供：1)在允许网络连接之前确认设备；2)通过无线电(OtA)管理设备配置；3)通过在组件加载/开始上校验RIM的安全启动；以及4)配置改变时在设备上安装新的RIM–RIM摄取。

PVM可以使用下述术语。术语“验证(verification)”可用于安全建立期间设备组件的内部验证，而术语“确认(validation)”用于由外部实体进行的整个校验过程。这样，就可以避免介绍“内部”相对“外部”确认了。其中确认用于通常意义上的加密校验或者数据匹配，这是明确需要注意的，这样才不会引起混淆。

PVM使用SeGW、PVE和DMS中的至少一个。由于设备中的TrE执行设备内部的确认关键任务，因此通常TrE与其他实体进行通信。而该通信需要的设备的其他组件例如网络接口，不是TrE组成部分中必须的，可以由TrE来评估这些组件的完整性以确保端到端的安全。

职责的严格划分需要每一个实体限制于它的核心任务。例如，SeGW在(不)可信的设备与MNO的CN之间建立安全接口。它作为关卡和网络接入控制以及MNO的CN的强制实例。它也进行所有安全相关的(作为这样一个关卡必须的)功能，包括鉴权、对与设备的通信进行加密/解密、安全联盟和对话建立。SeGW可被用于作为在MNO的CN与外界之间建立边界的网络实体的一个实例，所述外界例如外部设备。使用PVM方法进行设备确认也可能不需要SeGW。这样做可能包括使用安全连接例如传输层安全性(TLS)直接将设备连接到DMS。

至于PVE，它作为CN中的确认实体并执行完整性确认。它接收完整性确认数据并检验报告的值是否已知并是好的。它向CN中其他实体发布有关设备完整性的报告。

至于DMS，它作为设备组件管理的中心实体，这些组件包括软件更新、配置改变、OTA管理和失败模式补救。DMS在根据平台确认执行该功能方面，与H(e)MS的增强版本类似。

除了上述实体外，PVM还包括RIM管理器(RIMman)。RIMman执行下述任务，包括管理和提供用于确认中的比较的参考值。它也管理证书，尤其，摄取外来的RIM证书、验证RIM证书、生成(运营商特定的)RIM证书以及通过例如撤回、时间限制和信任关系来校验证书的有效性。也就是说，RIM管理器是唯一的实体，它被授权以管理确认数据库(V_DB)。该V_DB和RIMman是受保护的CN组件。对V_DB的写访问权限仅限于RIMman，因此PVE不能向V_DB写入。RIMman在安全方面具有特殊的重要性，因为它管理着PVM必须的(SHO-CN)外部信任关系。

PVM还包括进行管理和提供设备配置的配置策略管理器(CPman)。它也管理策略，尤其是，从例如可信的第三方(TTP)摄取外部配置和策略，并生成(运营商特定的)目标设备配置和策略。也就是说，CPman是被授权来管理配置策略数据库C_DB的唯一的实体。CPman在安全方面具有特殊的重要性，因为它管理PVM必须的(SHO-CN)外部信任关系。

图17A和17B示出了PVM的实体的最小组、它们的关系和接口的实例。也示出了其他实体，例如鉴权、鉴权&计费(AAA)服务器和无线发射/接收单元(WTRU)和他们的接口。

图17A中的PVM架构或者系统1700包括具有TrE 1710的设备1705。WTRU 1712(或者用户实体(UE))可以通过I-ue接口1714与设备1705进行通信。设备1705通过I-h接口1715与SeGW 1720进行通信。总的来说，设备1705和SeGW 1720之间的接口I-h 1715可能不受保护，并且可以使用特殊的测量来确保该信道的可靠性、完整性和可选的保密性。I-h 1715可以被用于建立设备1705与SeGW 1720以及CN之间的链路。例如，SeGW 1720可以通过接口I-aaa 1775与AAA服务器通信。运营商可以建立适当的测量来确保该接口的安全。

I-pve接口1722可以被SeGW 1720用来在确认过程中与PVE 1724联系。PVE 1724可以使用I-pve接口1722将确认的结果用信号通知给SeGW 1720。I-dms接口1730可以用于设备配置相关的DMS 1735与SeGW 1720之间的通信。该I-pd接口1732可以被PVE 1724用来与DMS 1735进行通信，反之亦然。接口I-pd 1732可用于设备管理过程中，例如用于设备软件更新和配置改变。

接口I-v 1726和I-d 1738可以分别被PVE 1720用于从V_DB 1740读取RIM以及被DMS 1735用来从C_DB 1750读取允许的配置。接口I-r 1728和I-c 1734可以被PVE 1720用来与RIMman 1760进行通信，例如在V_DB 1740中缺少RIM的情况下，并被DMS 1735用来与CPman 1770进行通信。RIMman 1760和CPman 1770可以分别使用接口I-rdb 1762和I-cdb 1772来读、写和管理数据库V_DB 1740和配置策略数据库C_DB 1750。

图17B示出了PVM 1782，其中设备1705可以直接与DMS 1735连接。当该设备是H(e)NB时，DMS 1735应该是如之前描述的H(e)MS。例如，对于其中设备1705不能与SeGW进行安全协议的回退模式。在这种情况下，DMS 1735可以作为通过接口I-dms_d 1784第一次联系设备1705的点，并通过接口I-pve 1786和I-pd 1788与PVE 1724通信来执行确认，或者至少得知哪些组件在安全建立过程中已经失败了。DMS 1735可以根据该信息为补救而行动。

如本文所述，PVM可以使用任何版本的确认。这里描述的是与PVM一起工作的半自动确认(SAV)的一个实施例。我们将焦点放在半自动确认(SAV)的演进型确认方法上。SAV的这个解决方法的优点是进一步地使CN完全免受流氓(rogue)设备的影响。在SAV过程中，由SeGW有效地建立起一个隔离。设备对PVE和DMS没有直接的威胁，因为它们只能接收限于它们的任务的数据并且只能通过与SeGW的安全连接，或者由SeGW建立。SAV中的确认进程不需要设备与CN中的任何实体之间的直接通信。只有在使用SAV成功确认之后，才允许连接到CN。这确保了只有被证明处于安全状态的设备才能与CN中的实体进行通信。

图18A、18B和18C示出了一个使用PVM基础结构的SAV确认方法实例的示意图。该PVM基础结构包括本文描述的实体，包括TrE 1805、SeGW1807、PVE 1809、DMS 1811、V_DB 1813以及C_DB 1815。在相互鉴权(1820)之后，TrE 1805可以收集下列数据的部分或全部：设备信息例如Dev_ID、制造商、设备能力(包括但不限于通信能力例如支持的数据速率、传输功率等级、信令特性和其他能力)、TrE能力和性质包括RoT；TrE_信息包括ID、认证信息、制造商、创建版本和可选的模型、样式、串号；确认数据包括1)设备的失败的功能性的列表，和/或2)平台配置寄存器(PCR)值；确认结合例如通过PCR值的签名或者失败的设备功能性的列表；组件Clist的组件指示符(CInd)的有序列表以及可以包括组件的参数；以及时间标记(可信的或不可信的)(1822)。从TrE 1805到SeGW 1807的确认消息/数据可以包含上述数据(1824)。

SeGW 1807应该将接收到的时间标记与本地时间进行校验/比较来检测变化(1826)。如果报告的时间标记与本地时间不匹配，则SeGW根据报告的时间标记的属性而行动。如果设备的时间标记是可信的时间标记并且显示了变化，则SeGW 1807应该触发TrE的重新确认以及它的可信的时间源。在不可信的时间标记的情况下，SeGW 1807将它自己可信的时间标记加到该消息上。如果该设备不能提供可信的时间标记，则SeGW 1807可以加入一个可信的时间标记作为防止重放(replay)攻击之用。

一旦接收到该消息，则SeGW 1807可以校验是否出现来自TrE的签名形式的确认结合(1828)。这确保了确认数据的可靠性。SeGW 1807然后创建PVM令牌(T_PVM)(1830)并在发送之前在该T-PVM上应用时间标记以确保时新性并阻止异步消息流(1832)。

SeGW 1807将该T_PVM转发给PVE 1809(1834)，它们轮流查询使用TrE-信息的V_DB 1813(1836)。如果向PVE 1809返回了一个不值得信任的确定(1838)，PVE则对T_PVM应用时间标记(1840)并将它转发给SeGW1807(1842)。SeGW 1807发送设备鉴权的否定到TrE 1805(1844)。

如果向PVE 1809返回了一个值得信任的确定(1846)，则该PVE查询使用Dev_ID的C_DB(1848)，它们轮流向PVE 1809返回配置策略(1850)。该PVE 1809评估该配置策略(1852)。

如果该PVE 1809确定该配置是不值得信任的(1854)，则PVE 1809修改T_PVM并应用时间标记(1856)。该PVE 1809然后将该T_PVM转发给SeGW 1807(1858)，它们轮流发送设备鉴权的否定到TrE 1805(1860)。

如果该PVE 1809确定该配置是值得信任的并允许该配置(1862)，则PVE 1809通过Clist或者来自V_DB 1813的C_List(C_列表)为所有实体恢复RIM(1864)。该PVE 1809重新计算来自RIM的正确的确认数据(1866)并将计算出的确认数据与报告的确认数据进行比较(1868)。在SAV的情况下，来自RIM的计算出的确认数据可以为失败的功能性的‘空的列表’的形式。PVE 1809然后修改T_PVM并应用时间标记(1870)。PVE 1809然后将T_PVM转发给SeGW 1807(1872)。SeGW 1807针对PVE确认结果检查T_PVM(或者从T_PVM进行提取)(1874)。SeGW 1807向TrE 1805发送设备鉴权的否认或允许(1876)。如果PVE确认结果是否定的，则TrE 1805执行重新启动并进行重新确认(1890)。

可选地，在PVE 1809将计算出的确认数据与报告的确认数据进行比较之后(1868)，PVE 1809可以发送一个失败的组件的列表给DMS 1811(1878)。如果该失败的组件的列表不为空，则DMS 1811可以确定可以应用软件或固件的更新(1880)，并且如果是这样的话，准备好OTA更新(1882)。DMS 1811也确保用于更新的RIM在V_DB 1813中存在(1884)。该DMS 1811通过用于重新确认的指示向SeGW 1807发送T_PVM(1886)以及向TrE 1805发送重新确认触发(1888)。TrE 1805执行重新启动并进行重新确认(1890)。

这里描述了关于图18A、18B和18C中的进程的具体情况。为了执行平台确认，TrE收集如下数据并将其传达给SeGW：设备信息例如Dev_ID、制造商、TrE能力和性质包括RoT；TrE_信息包括ID、认证信息、制造商、创建版本和可选的模型、样式、串号；完整性确认数据(IVD，一个IVD的实例可以是签名的平台配置寄存器(PCR)值，另一个实例可以是简单的组件或功能性的列表，这些组件或者功能性的完整性被设备本地完整性校验进程校验过，并且进一步地被评估为没有通过这样的设备本地完整性检验；确认结合例如PCR值上的签名；Clist-它是组件Clist的组件指示符(CInd)的有序列表并且可以包含组件的参数；该组件的列表将会服务于识别确认的RIM，例如，通过指向RIM证书，RIMcs。该组件的指示符的有序列表和它们的参数可以包含如下数据字段的项：索引、组件_指示符CInd、组件_参数。CInd给出了组件的参考并且可以为URN格式(例如URN://vendor.path.to/component/certificate))。可选地：时间标记(这可以是可信的时间标记，或者通常意义上不需要是可信的常规时间标记)。

在该设备的情况下，确认消息还可以额外包括设备信息，例如ID、认证信息、制造商、模块、版本、样式、串号。TrE能力和性质包括RoT、设备的安全策略、在完整性校验以及校验之后组件加载的多步骤进程中的不同步骤通过完整性校验的模块、HW建立版本号以及可选的SW建立版本号和完整性测量数据。

将RIM用于确认是一种用于SAV的优选但可选的方法。它在这里作为基本情况使用，其他选项背移了它。例如，存在没有重新计算来自RIM的确认数据的确认，甚至还有可能完全没有RIM而执行PVM。

如果确认消息必定是通过其他而不是那些包括设备完整性的方法，例如通过安全信道的存在和使用，验证结合可以是可选的。

SeGW可以将接收到的时间标记与本地时间进行校验/比较以检测变化。如果报告的时间标记与本地时间不匹配，则SeGW根据报告的时间标记的性质采取行动。如果该设备的时间标记是可信的时间标记并且显示出变化，SeGW会触发TrE的重新确认及它的可信的时间源。在不可信的时间标记的情况下，SeGW将它自己的时间标记加到消息中。

TrE_info(TrE_信息)可以是可选的。Dev_ID可以给出TrE_info的参考。由于不是所有的MNO都会知道所有的TrE，因此所有的TrE_info数据，可以由数据库提供这样一个映射，该数据库可以由MNO查询来获得任何给定Dev_ID的TrE_info。TrE_info可以在TrE_certificate(TrE_证书)中。该TrE_certificate应被TrE的供应商或者TTP签名，例如同族(german)BSI。

使用URN作为组件的指示符(CInd)是有利的，因为它同时允许组件的这个唯一标识和可以取得RIM或RIM证书的位置。

SeGW创建PVM令牌(T_PVM),该T_PVM可用于作为轮询令牌并且在通信中在实体之间传递。每一个实体在发送之前将一个时间标记放到该令牌上来确保时新性以及阻止异步消息流。该令牌上的时间标记可以被用于提供一种跟踪令牌状态的方法。该令牌在CN中的实体之间传递，甚至几个来回，因此可以被实体跟踪到。可选地，实体ID可以加入到该时间标记的数据链中。

T_PVM可以包含Dev_ID。如果该原始时间标记不存在或不可信，该T_PVM也可以包含由SeGW发布的新的时间标记。否则该T_PVM可以包含来自确认消息的原始时间标记。

时间标记可被用于避免重放攻击。它们可以与随机数或者单调(monotonically)递增的计数器合并或者甚至被他们替代。时间标记也可被用于评估确认数据的时新性。两种目的的结合是有利的且可以由时间标记提供。

在第一种变型中，对于通过DMS、T_PVM的后来的设备管理可以包含在DMS与TrE之间建立安全通道的通信秘密，例如TLS证书。

SeGW维护包含所有激活的T_PVM的令牌数据库T_DB。

SeGW从确认消息中提取如下数据：确认数据、TrE_info和Clist。在将该数据与令牌T_PVM一起发送之前，SeGW在T_PVM上放置时间标记并将它转发给PVE。SeGW可以校验该确认消息及其部件的格式以减轻来自错误形成的数据攻击。否则，攻击者会尝试修改妥协的TrE的确认消息中的数据，由此在PVE上的对该数据的纯粹的检查会导致系统错误或失败。

PVE是决定设备有效性的实体。也就是，用策略系统的语言来说，它是一个策略决策点(PDP)。在严格的责任分离方法下，它是PVM系统中唯一的PDP。它依赖SeGW和DMS来实施策略，例如作为策略实施点(PEP)。用它通常的描述，PVM保持着对策略是如何生成的和它们在哪里存储/管理的问题的不可知，例如PVE从哪里得到该策略。在下面描述的一些更具体的变型和次要的方法中(尤其参数的确认和最小的确认)，给出了策略条件和行动的一些实例。通常，确认策略的决定可以不仅根据单个组件的有效性也要根据Clist中包含的其他数据。尤其是，可以评估允许的参数(范围)和加载顺序(Clist是有序的)。

失败条件有一些基本的等级，可以发生在由PVE执行的确认进程中。例如，失败条件F1指示一种“TrE无效”场景。通过它的经过鉴权的Dev_ID和传递的TrE_info，PVE识别设备和/或它的TrE哪一个不值得信任。注意：能被用于确定TrE是否无效的信息可以在SAV确认消息上进行携带，或可以从其他消息或其他方法中推出。在它基本的形式中，SAV确认消息的存在可以隐式地指示TrE本身必须是有效的。怎样检测F1的具体描述在同时提交的申请号为No.______，题为“无线设备的平台确认和管理”的美国专利申请中，它作为参考加入本文，就如同本文具体描述一样。

另一个实例是失败条件F2，它指示“IVD验证失败”的三种场景。场景F2a指示完整性测量/验证数据不匹配。它指示设备的安全启动进程的失败，和/或错误的存在和/或过期的RIM和/或设备的RIM证书，然后启动无效的组件。场景F2b指示RIM遗失，也就是，组件的RIM遗失并且需要从其他地方取回。场景F2c指示过期的RIM证书。

失败条件F3指示“Clist策略失败”的两种场景。对场景F3a，单个组件是有效的，但该配置使一个策略失败，例如在加载顺序上或者非期望的组件或参数。场景F3b指示配置未知，这样Clist的‘已知的好值’不可用。

这里描述的是检测和处理失败条件等级F2的一种方法。对于失败条件F2，PVE针对来自接收到的Clist的所有组件从V_DB取回RIM。确认数据库V_DB只存储认证过的RIM。相关的RIM证书必须安全地存放在V_DB中。

如果IVD是“与本地完整性校验失败的设备的组件相应的设备组件”的一个简单列表的形式，就如本文描述的狭义的SAV过程，则IVD_ref会简单的是一个空的列表的形式。也就是，在这种情况下，IVD_ref应仅仅是预期的失败的功能性的列表，如果每一个组件都预期通过了设备本地完整性校验，则该列表应该是一个空表。

如果IVD_ref与接收到的IVD不匹配，则设备上的安全启动进程已经被妥协或者错误的RIM被存储到该设备中，以及无效的组件因此在该安全启动进程中被加载。

根据该F2a策略，一旦检测到F2a失败，可以应用一些选项。在一个选项中，拒绝。PVE用信号通知SeGW确认的结果。SeGW然后可以拒绝网络接入或者将该设备放入隔离的网络中。另一个选项被更新。在接收到指示验证数据失败的确认结果(T_PVM)之后，DMS开始一个管理进程来替代确认失败的组件。这样一个补救进程的具体描述在同时提交的申请号为No._____，题为“无线设备的平台确认和管理”的美国专利申请中，它作为参考加入本文，就如本文详细描述一样。

如果没有策略失败条件得到满足，则该设备是有效的。PVE将其用信号通知给SeGW，然后它允许连接到CN。

对失败条件F2b，其中RIM遗失了，这个发生可能是因为RIM可以在V_DB中遗失，或者它可以在该设备中遗失(因此，在这种情况下，该设备不能进行设备本地完整性校验过程)。怎样检测F2的具体描述在同时提交的申请号为No._____，题为“无线设备的平台确认和管理”的美国专利申请中，它作为参考加入本文，就如本文详细描述一样。

这里描述的是检测和处理失败条件等级F3的方法。如果单个组件是有效的但组件的配置使一个策略失败(例如加载顺序不匹配)，或者如果该配置未知，即Clist的‘已知的好值’不可用，该F3失败条件发生。这样一个失败条件怎样发生和这样一个失败条件能怎样被处理的详细描述在同时提交的申请号为No._____，题为“无线设备的平台确认和管理”的美国专利申请中讨论，它作为参考加入本文，就如本文详细描述一样。

图19示出了一个长期演进(LTE)无线通信系统/接入网络1900，包括演进型全球陆地无线电接入网络(E-UTRAN)1905，它可以与H(e)NB一起使用。E-UTRAN 1905包括一个WTRU 1910和若干演进型节点B(eNB1920)。WTRU 1910与eNB 1920进行通信。eNB 1920使用X2接口相互连接。每一个eNB 1920通过S1接口与移动性管理实体(MME)/服务网关(S-GW)1930相连。尽管图19中只示出了一个WTRU 1910和三个eNB1920，但应该很明显，任何无线和有线设备的组合都可以包含在该无线通信系统接入网络100中。

图20是包括WTRU 1910、eNB 1920和MME/S-GW 1930的LTE无线通信系统2000的示例结构图。如图20所示，WTRU 1910、eNB 1920和MME/S-GW 1930被配置来执行使用自动和半自动确认的H(e)NB完整性验证和确认的方法。

除了可以在典型WTRU中找到的组件外，WTRU 1910还包括具有可选链接的存储器2022的处理器2016、至少一个收发信机2014、可选的电池2020和天线2018。该处理器2016被配置来执行使用自动和半自动确认的H(e)NB完整性验证和确认的方法。该收发信机2014与处理器2016和天线2018进行通信以方便无线通信的传送和接收。如果WTRU 1910中使用了电池2020，该电池2020给收发信机2014和处理器2016提供电能。

除了可以在典型eNB(包括H(e)NB)中找到的组件外，eNB 1920还包括具有可选链接的存储器2015的处理器2017、收发信机2019、天线2021。该处理器2017被配置来执行使用自动和半自动确认的H(e)NB完整性验证和确认的方法。该收发信机2019与处理器2017和天线2021进行通信以方便无线通信的传送和接收。该eNB 1920连接到移动性管理实体/服务网关(MME/S-GW)1930，MME/S-GW包括具有可选链接的存储器2034的处理器2033。

SeGW和PVE，尽管在图19和20中没有示出，除了在典型的SeGW和PVE中可以找到的组件外，还包括具有可选链接的存储器的处理器、收发信机、天线和通信端口。该处理器被配置来执行平台确认和管理函数以完成PVM方法。该收发信机和通信端口与处理器和天线根据需要进行通信，以方便通信的传送和接收。

实施例

1.一种用于对家庭演进型节点B(H(e)NB)执行完整性验证的方法，该方法包括在组件加载之前测量组件的完整性度量。

2.根据实施例1所述的方法，该方法还包括鉴权可信的参考值(TRV)。

3.根据前述任一实施例所述的方法，该方法还包括将测量的完整性度量与TRV进行比较。

4.根据前述任一实施例所述的方法，该方法还包括根据完整性验证结果而采用常规码或者回退码中的一者来启动H(e)NB。

5.根据前述任一实施例所述的方法，该方法还包括提供软件模块和关联属性的列表，该列表包括至少一个参考完整性度量以及H(e)NB和平台确认实体(PVE)中的至少一者的严重性。

6.根据前述任一实施例所述的方法，其中设备配置数据表包含所述软件模块和关联属性的列表，并且该设备配置数据表被提供给所述H(e)NB和平台确认实体(PVE)中的至少一者。

7.根据前述任一实施例所述的方法，其中所述关联属性提供了提供了组件相关的软件模块与功能性之间的映射。

8.根据前述任一实施例所述的方法，其中所述设备配置数据表及所述软件模块和关联属性的列表中的至少一者被存储在所述H(e)NB和平台确认实体(PVE)中的至少一者内。

9.根据前述任一实施例所述的方法，该方法还包括基于所述PVE能确定哪个行动而发送至少包含模块标识符的完整性校验失败消息。

10.根据前述任一实施例所述的方法，该方法还包括根据完整性验证失败的严重性等级来执行预先确定的行动。

11.根据前述任一实施例所述的方法，其中所述预先确定的行动包括下列中的至少一者：发送遇险消息、发起码更新、发起补救、以及报告失败的功能性的列表。

12.根据前述任一实施例所述的方法，其中所述软件模块和关联属性的列表包括下列中的至少一者：组件特定的信息元素、模块特定的信息元素和功能元素。

13.根据前述任一实施例所述的方法，其中所述组件特定的信息元素包括下列中的至少一者：组件描述、组件标识(ID)和可信的参考值(TRV)。

14.根据前述任一实施例所述的方法，其中所述模块特定的信息元素包括下列中的至少一者：模块描述、模块标识(ID)、功能描述、功能ID、组件ID、发布版本和严重性。

15.根据前述任一实施例所述的方法，其中所述模块在完整性验证期间至少被校验一次。

16.根据前述任一实施例所述的方法，其中所述模块只在一个组件中出现。

17.根据前述任一实施例所述的方法，其中所述模块在两个功能之间被共享。

18.根据前述任一实施例所述的方法，其中每一个模块都有关联的功能性。

19.根据前述任一实施例所述的方法，其中一组模块与同一组件关联、共享同一组件标识符(ID)并且与所述同一组件共同地进行完整性验证。

20.根据前述任一实施例所述的方法，其中具有一个组件标识符(ID)的模块被以不同的功能性标识符(ID)进行分类。

21.根据前述任一实施例所述的方法，其中模块是基于功能性和完整性校验单元进行分类的。

22.根据前述任一实施例所述的方法，其中具有同一组件标识符的模块具有一个可信的参考值(TRV)，并且在该可信的参考值失败的条件下，具有失败的组件标识符的所有模块都被用来确定失败的功能性的列表。

23.一种用于对家庭演进型节点B(H(e)NB)执行确认的方法，该方法包括由于设备完整性校验失败而以回退码来启动所述H(e)NB。

24.根据实施例23所述的方法，该方法还包括发送遇险消息。

25.根据实施例23-24中任一实施例所述的方法，该方法还包括接收用于取回补救信息的下行链路消息。

26.根据实施例23-25中任一实施例所述的方法，该方法还包括响应于所述下行链路消息而下载所述补救信息。

27.根据实施例23-26中任一实施例所述的方法，该方法还包括基于安装的补救信息而重新启动所述H(e)NB。

28.根据实施例23-27中任一实施例所述的方法，该方法还包括上传失败信息以允许准备所述补救信息。

29.根据实施例23-28中任一实施例所述的方法，其中所述遇险消息包括下列中的至少一者：制造商标识、可信的环境标识、H(e)NB标识和失败码。

30.根据实施例23-29中任一实施例所述的方法，其中严重性测量指明了设备完整性校验失败的影响。

31.根据实施例23-30中任一实施例所述的方法，其中设备完整性校验在本地执行。

32.根据实施例23-31中任一实施例所述的方法，其中所述失败信息被发送给H(e)NB管理系统(H(e)MS)或者平台确认实体(PVE)中的一者。

33.根据实施例23-32中任一实施例所述的方法，其中所述H(e)NB使用安全插口层/传输层安全性(SSL/TLS)来发送所述遇险消息。

34.根据实施例23-33中任一实施例所述的方法，其中所述H(e)NB是以缺省H(e)MS统一资源定位符(URL)来配置的。

35.根据实施例23-34中任一实施例所述的方法，其中设备配置数据表在设备的安全存储器中被维护并被授权方访问。

36.根据实施例23-35中任一实施例所述的方法，其中一旦设备配置数据表期满，所述H(e)NB就发起更新进程以从补救服务器上拉取数据。

37.根据实施例23-36中任一实施例所述的方法，其中所述H(e)NB执行预先指定的组件的设备完整性校验。

38.根据实施例23-37中任一实施例所述的方法，该方法还包括从所述PVE接收H(e)NB行动。

39.一种用于对家庭演进型节点B(H(e)NB)执行确认的方法，该方法包括建立互联网密钥交换(IKE)安全联盟。

40.根据实施例39所述的方法，该方法还包括以IKE_AUTH请求来发送证书以对设备完整性校验结果进行相互鉴权和指示。

41.根据实施例39-40中任一实施例所述的方法，该方法还包括接收对鉴权和设备完整性确认结果的指示。

42.根据实施例39-41中任一实施例所述的方法，该方法还包括基于对设备完整性校验结果的评估而接收行动。

43.根据实施例39-42中任一实施例所述的方法，其中所述设备完整性校验结果包括失败的功能性的列表。

44.根据实施例39-43中任一实施例所述的方法，其中接收到的行动调用补救。

45.根据实施例39-44中任一实施例所述的方法，其中所述H(e)NB中的完整性校验结果被隔离，被完全访问、被部分访问或者为补救而被人为干预。

46.根据实施例39-45中任一实施例所述的方法，该方法还包括响应于指示补救的行动而发送遇险消息。

47.根据实施例39-46中任一实施例所述的方法，该方法还包括接收用于取回补救信息的下行链路消息。

48.根据实施例39-47中任一实施例所述的方法，该方法还包括响应于所述下行链路消息而下载所述补救信息。

49.根据实施例39-48中任一实施例所述的方法，该方法还包括基于安装的补救信息而重新启动所述H(e)NB。

50.根据实施例39-49中任一实施例所述的方法，该方法还包括上传失败信息以允许准备所述补救信息。

51.根据实施例39-50中任一实施例所述的方法，其中失败信息包括失败的功能性的列表。

52.根据实施例39-51中任一实施例所述的方法，其中所述失败信息被发送到H(e)NB管理系统(H(e)MS)或平台确认实体(PVE)中的一者。

53.根据实施例39-52中任一实施例所述的方法，其中所述失败信息包括校验后的功能性的列表。

54.根据实施例39-53中任一实施例所述的方法，其中所述失败信息包括未校验的功能性的列表。

55.根据实施例39-54中任一实施例所述的方法，其中确认和鉴权的结合由IKE会话提供。

56.根据实施例39-51中任一实施例所述的方法，其中确认和鉴权的结合由在设备完整性校验成功的基础上进行的鉴权过程提供。

57.一种用于结合设备确认的方法，该方法包括将可信的环境(TrE)结合到鉴权过程中。

58.根据实施例57所述的方法，其中所述鉴权过程是用于UMTS鉴权和密钥协商的可扩展的鉴权协议方法(EAP-AKA)过程。

59.根据实施例57-58中任一实施例所述的方法，其中所述过程确认AKA凭证。

60.根据实施例57-59中任一实施例所述的方法，其中所述AKA凭证包含在TrE中。

61.根据实施例57-60中任一实施例所述的方法，该方法还包括将确认的设备和基于EAP-AKA的鉴权进行结合。

62.根据实施例57-61中任一实施例所述的方法，其中所述EAP-AKA鉴权包括将所述TrE拥有所述AKA凭证与基于EAP-AKA的鉴权过程进行结合。

63.根据实施例57-62中任一实施例所述的方法，该方法还包括将TrE拥有AKA凭证与增强型家庭节点B(HeNB)进行逻辑结合。

64.根据实施例57-63中任一实施例所述的方法，其中所述设备平台的完整性被确认。

65.根据实施例57-64中任一实施例所述的方法，该方法还包括将TrE拥有AKA凭证与HeNB进行物理结合。

66.根据实施例57-65中任一实施例所述的方法，其中硬件和软件的实际的完整性确认是由安全内嵌在HeNB内的硬件安全组件执行的。

67.根据实施例57-66中任一实施例所述的方法，其中EAP-AKA鉴权适当的凭证和存储在物理上密切关联的TrE内的相关应用被配置成确认可移除的硬件组件与主机设备的结合。

68.根据实施例57-67中任一实施例所述的方法，其中所述TrE拥有AKA凭证和HeNB进一步密切相关。

69.根据实施例57-68中任一实施例所述的方法，该方法还包括所述HeNB加密计算用于设备鉴权的AKA凭证需要的数据，由此只有TrE能解密所述数据。

70.根据实施例57-69中任一实施例所述的方法，该方法还包括所述TrE安全地存储解密所述HeNB加密数据所需要的密钥。

71.根据实施例57-70中任一实施例所述的方法，该方法还包括将在公共安全协议的同一会话中设备确认和设备鉴权有关的信息结合起来以获得进一步的结合。

72.根据实施例57-71中任一实施例所述的方法，其中所述公共安全协议是互联网密钥交换版本2(IKEv2)。

73.根据实施例57-72中任一实施例所述的方法，其中所述设备确认包括HeNB与网络实体之间的交互和消息交换。

74.根据实施例57-73中任一实施例所述的方法，其中所述HeNB包括TrE。

75.根据实施例57-74中任一实施例所述的方法，该方法还包括网络实体执行HeNB的确认。

76.根据实施例57-75中任一实施例所述的方法，该方法还包括安全网关在所述HeNB与执行确认的网络实体之间传达信令。

77.根据实施例57-76中任一实施例所述的方法，该方法还包括将设备确认与基于证书的鉴权进行结合。

78.根据实施例57-77中任一实施例所述的方法，其中所述结合包括将HeNB的TrE与基于证书的设备鉴权过程进行物理结合。

79.根据实施例57-78中任一实施例所述的方法，其中所述结合包括将HeNB的TrE与基于证书的设备鉴权过程进行逻辑结合。

80.根据实施例57-79中任一实施例所述的方法，其中所述TrE拥有证书凭证并且HeNB进一步密切相关。

81.根据实施例57-80中任一实施例所述的方法，该方法还包括HeNB使用加密密钥来加密计算用于设备鉴权的证书凭证所需要的数据；并且所述TrE使用TrE安全保存的密钥来解密所述TrE内的加密数据。

82.根据实施例57-81中任一实施例所述的方法，该方法还包括将基于证书的鉴权会话与所述用于HeNB确认的过程通过使两个过程使用相同的或连续的公共协议会话的会话来进行结合。

83.根据实施例57-82中任一实施例所述的方法，其中所述设备确认包括通过公共协议会话在HeNB与使网络能进行HeNB的设备完整性确认的网络实体之间的交互。

84.根据实施例57-83中任一实施例所述的方法，该方法还包括将HeNB绑定的设备确认与基于EAP-AKA的客户鉴权进行结合。

85.根据实施例57-84中任一实施例所述的方法，该方法还包括使用加密密钥和用于TrE与HeNB其余的之间消息交换的凭证将TrE和HeNB进行结合。

86.根据实施例57-85中任一实施例所述的方法，其中所述在TrE与HeNB其余的之间的消息交换包括与设备鉴权相关的消息交换。

87.根据实施例57-86中任一实施例所述的方法，其中所述密钥和凭证在TrE内受保护。

88.根据实施例57-87中任一实施例所述的方法，该方法还包括在公共安全协议相同的或者连续的会话中，HeNB和TrE执行设备的预先指定的部分确认以及基于EAP-AKA的客户鉴权。

89.根据实施例57-88中任一实施例所述的方法，该方法还包括将HeNB的设备确认与基于证书的客户鉴权结合起来。

90.根据实施例57-89中任一实施例所述的方法，其中所述TrE包括密钥对。

91.根据实施例57-90中任一实施例所述的方法，其中所述密钥对包括私有部分和公共部分。

92.根据实施例57-91中任一实施例所述的方法，其中所述私有部分安全存储在TrE内。

93.根据实施例57-92中任一实施例所述的方法，其中所述公共部分对HeNB可用。

94.根据实施例57-93中任一实施例所述的方法，该方法还包括HeNB的制造商生成所述密钥对；以及提供使公共密钥对HeNB可用所需要的证书。

95.根据实施例57-94中任一实施例所述的方法，该方法还包括通过使用基于EAP-AKA的鉴权的加密方法来创建确认和鉴权的结合。

96.根据实施例57-95中任一实施例所述的方法，该方法还包括HeNB用来自所述证书的公共密钥来加密响应；并将该加密数据转发给所述TrE。

97.根据实施例57-96中任一实施例所述的方法，其中所述响应是IKE_AUTH响应。

98.根据实施例57-97中任一实施例所述的方法，该方法还包括所述TrE然后加密所述数据；以及计算将所述HeNB向鉴权、授权和收费(AAA)服务器进行鉴权所需要的EAP-AKA响应(RES)参数。

99.根据实施例57-98中任一实施例所述的方法，该方法还包括所述HeNB使用所述公共密钥来加密计算TrE中的AUTH参数所需要的数据。

100.根据实施例57-99中任一实施例所述的方法，该方法还包括所述TrE加密所述数据；以及计算将所述HeNB向所述SeGW鉴权所需要的AUTH参数。

101.根据实施例57-100中任一实施例所述的方法，该方法还包括将设备完整性和设备ID加密地进行结合。

102.根据实施例57-101中任一实施例所述的方法，其中所述设备完整和设备ID的加密结合由所述TrE和HeNB执行。

103.根据实施例57-102中任一实施例所述的方法，其中所述TrE和所述HeNB分别装备了公共密钥对。

104.根据实施例57-103中任一实施例所述的方法，其中所述TrE和所述HeNB分别装备了对称共享的密钥。

105.根据实施例57-104中任一实施例所述的方法，其中所述TrE和所述HeNB使用密钥来保护通信和相互鉴权。

106.根据实施例57-105中任一实施例所述的方法，其中用于设备鉴权的IKEv2协议被用于结合所述TrE和HeNB。

107.根据实施例57-106中任一实施例所述的方法，其中所述设备完整性通过将设备完整性确认过程和设备鉴权连接在一起来与设备ID密切关联。

108.根据实施例57-107中任一实施例所述的方法，其中所述设备完整性确认和设备鉴权在受保护的TrE中进行。

109.根据实施例57-108中任一实施例所述的方法，其中所述TrE是受保护的、可信的实体。

110.根据实施例57-109中任一实施例所述的方法，其中所述TrE执行设备完整性确认和设备鉴权过程。

111.根据实施例57-110中任一实施例所述的方法，其中所述IKEv2协议的会话，或者紧随其后的会话被用于设备完整性确认和设备鉴权。

112.根据实施例57-111中任一实施例所述的方法，该方法还包括将设备确认过程结合到新的消息交换中。

113.根据实施例57-112中任一实施例所述的方法，其中所述新的请求和响应交换发生在另一个类似的为设备鉴权而进行交换之前。

114.根据实施例57-113中任一实施例所述的方法，其中被设备鉴权使用的请求和响应交换被用于设备确认过程。

115.根据实施例57-114中任一实施例所述的方法，其中设备完整性确认需要的额外数据内嵌在选定的消息字段内。

116.根据实施例57-115中任一实施例所述的方法，其中设备完整性需要的数据包括关于本地自动完整性校验或半自动确认的结果的签名的状态。

117.根据实施例57-116中任一实施例所述的方法，其中所述消息字段包括受保护的通知字段。

118.根据实施例57-117中任一实施例所述的方法，该方法还包括将设备确认过程结合到存在的消息交换中。

119.根据实施例57-118中任一实施例所述的方法，该方法还包括将所述设备确认过程结合到新的请求和响应交换中。

120.根据前述任一实施例所述的方法，该方法还包括执行完整性校验及使用完整性校验中产生的信息来影响网络决定。

121.根据前述任一实施例所述的方法，其中信息元素包括制造商和完整性算法。

122.根据前述任一实施例所述的方法，其中组件特定的信息元素包括组件描述、组件标识(ID)和可信的参考值(TRV)。

123.根据前述任一实施例所述的方法，其中模块特定的信息元素包括模块描述、模块标识(ID)、功能描述、功能ID、组件ID、发布版本和严重性。

124.根据前述任一实施例所述的方法，其中所述严重性指示了完整性校验失败的影响。

125.根据前述任一实施例所述的方法，其中所述严重性分级为范围1到4。

126.根据前述任一实施例所述的方法，其中严重性1表明对H(e)NB功能性的高影响和可能保证停止操作和回退码镜像(FBC)能发送遇险信号给预先指定的H(e)MS。

127.根据前述任一实施例所述的方法，其中严重性2表明受限制的H(e)NB功能性。

128.根据前述任一实施例所述的方法，其中严重性3可能不会影响核心功能性，并且模块/功能的失败被固件更新过程替换并通过重新启动被确认。

129.根据前述任一实施例所述的方法，其中严重性4可能不会影响核心功能性，并且失败的模块能通过常规的固件更新被替换。

130.根据前述任一实施例所述的方法，其中在自动确认过程中，所述设备完整性校验在本地进行。

131.根据前述任一实施例所述的方法，其中如果完整性校验失败，则向室内移动站(H(e)MS)发送遇险信号。

132.根据前述任一实施例所述的方法，其中在半自动确认过程中，完整性校验失败的功能性的列表被报告给个人视频编码器(PVE)。

133.根据前述任一实施例所述的方法，其中在完整性校验过程中，一个模块只被校验一次。

134.根据前述任一实施例所述的方法，其中一个模块只在一个组件中出现。

135.根据前述任一实施例所述的方法，其中一个模块可以在两个功能之间共享。

136.根据前述任一实施例所述的方法，其中每一模块有一个相关联的功能性，并且失败的功能性的列表能被推导出来并被用半自动确认(SAV)发送到个人视频编码器(PVE)。

137.根据前述任一实施例所述的方法，其中功能性标识符(ID)提供了模块的类别。

138.根据前述任一实施例所述的方法，其中模块根据生成的镜像进行分类。

139.根据前述任一实施例所述的方法，其中一组模块包含同一组件标识符(ID)并且共同进行完整性校验。

140.根据前述任一实施例所述的方法，其中具有一个组件标识符(ID)的模块以不同的功能性标识符(ID)进行分类。

141.根据前述任一实施例所述的方法，其中模块标识符(ID)被用于追踪变化的软件模块并且未被标准化。

142.根据前述任一实施例所述的方法，其中模块根据功能性和完整性校验单元进行分类。

143.根据前述任一实施例所述的方法，其中具有同一组件标识符(ID)的所有模块有一个可信的参考值，并且如果该可信的参考值失败，则该失败的组件的所有模块用于确定失败的功能性的列表并被传递给室内移动站(H(e)MS)或者个人视频编码器(PVE)。

144.根据前述任一实施例所述的方法，其中功能性的列表与组件相关联。

145.根据前述任一实施例所述的方法，其中组件被按照他们加载的顺序进行组织。

146.根据前述任一实施例所述的方法，其中所述完整性校验针对部分镜像对象文件进行，并且如果所述镜像对象文件没有通过完整性校验，则抽取出失败的分段名。

147.根据前述任一实施例所述的方法，其中客户端设备(CPE)被用于下载可信的参考到所述H(e)NB上，并且该可信的参考被网络运营商的签名密钥进行了数字签名。

148.根据前述任一实施例所述的方法，其中一旦接收到包含可信的参考值的签名包，所述H(e)NB就解密所述签名并确认接收到的可信的参考值的可靠性和完整性。

149.根据前述任一实施例所述的方法，其中可信的参考值在数字签名之前为保密性而进行了加密。

150.根据前述任一实施例所述的方法，其中可信的参考值被添加到软件模块二进制镜像的一部分。

151.根据前述任一实施例所述的方法，其中所述H(e)NB和室内移动站H(e)MS支持安全插口层/传输层安全性(SSL/TLS)并使用基于证书的鉴权。

152.根据前述任一实施例所述的方法，其中基于TR069的架构支持基于证书的鉴权。

153.根据前述任一实施例所述的方法，其中所述H(e)NB被用ManagmentServer.URL参数中的缺省室内移动站(H(e)MS)统一资源定位符(URL)来进行配置。

154.根据前述任一实施例所述的方法，其中所述H(e)NB支持局域网(LAN)侧ManagmentServer.UR配置。

155.根据前述任一实施例所述的方法，其中安全网关SeGW统一资源定位符(URL)是一个参数。

156.根据前述任一实施例所述的方法，其中在自动确认过程中，数字签名或消息被用私有密钥进行签名。

157.根据前述任一实施例所述的方法，其中在自动确认过程中，信息不被发送到网络实体。

158.根据前述任一实施例所述的方法，其中针对用于生成可信的参考完整性度量或可信的参考值的算法，最低需求被标准化。

159.根据前述任一实施例所述的方法，其中可信的参考值由可信的第三方生成并被数字签名。

160.根据前述任一实施例所述的方法，其中本地完整性数据初始化被执行。

161.根据前述任一实施例所述的方法，其中初始的配置数据的提供被执行。

162.根据前述任一实施例所述的方法，其中参考完整性度量变为可信的参考值。

163.根据前述任一实施例所述的方法，其中设备配置数据表在设备的安全存储器中被维护并被授权过的一方访问。

164.根据前述任一实施例所述的方法，其中设备配置数据被H(e)NB加密和解密。

165.根据前述任一实施例所述的方法，其中在安全启动进程中，生成的摘要被与设备配置数据表中的指定的值进行比较。

166.根据前述任一实施例所述的方法，其中如果设备配置数据表期满，则所述H(e)NB开始固件更新进程以从补救服务器上拉取数据。

167.根据前述任一实施例所述的方法，其中室内移动站(H(e)MS)发起远程过程调用(RPC)并更新ManagmentServer.URL。

168.根据前述任一实施例所述的方法，其中文件传输协议安全(FTPS)被用于传输文件。

169.根据前述任一实施例所述的方法，其中所述设备完整性校验在自动确认中失败并且本地遇险标志被设置并且回退码(FBC)被存储在设备中。

170.根据前述任一实施例所述的方法，其中遇险信号包含了设备完整性校验失败的详细信息。

171.根据前述任一实施例所述的方法，其中文件传输协议(FTP)服务器被与室内移动站(H(e)MS)合并。

172.根据前述任一实施例所述的方法，其中在半自动确认(SAV)过程中，所述H(e)NB与安全网关(SeGW)通过不安全的链路进行交互。

173.根据前述任一实施例所述的方法，其中安全网关(SeGW)只允许鉴权过的H(e)NB接入到网络；

根据前述任一实施例所述的方法，其中室内移动站(H(e)MS)作为所述H(e)NB管理服务器并提供对补救的支持。

174.根据前述任一实施例所述的方法，其中在SAV中所述H(e)NB进行预先指定的组件的完整性校验。

175.根据前述任一实施例所述的方法，其中在SAV中组件的确认通过比较来自完整性算法的摘要输出和设备配置表中指定的值而在本地进行。

176.根据前述任一实施例所述的方法，其中所述H(e)NB的传输元素(TrE)进行预先定义的组件的完整性校验。

177.根据前述任一实施例所述的方法，其中所述H(e)NB通过证书交换用安全网关(SeGW)建立互联网密钥交换(IKE)安全联盟。

178.根据前述任一实施例所述的方法，其中在组件的本地完整性确认之后，所述组件被所述设备加载并执行。

179.根据前述任一实施例所述的方法，其中互联网密钥交换元素(IKE)被发送以建立安全联盟，该安全联盟包含了用于加密算法的安全参数索引。

180.根据前述任一实施例所述的方法，其中安全网关(SeGW)发送响应给互联网密钥交换(IKE)。

181.根据前述任一实施例所述的方法，其中所述H(e)NB用IKE_AUTH_REQ来发送证书以用于相互鉴权。

182.根据前述任一实施例所述的方法，其中安全网关(SeGW)评估所述H(e)NB的鉴权凭证并提取功能性标识符的列表。

183.根据前述任一实施例所述的方法，其中如果鉴权确认成功，则安全网关(SeGW)发送指示给所述H(e)NB。

184.根据前述任一实施例所述的方法，其中如果鉴权确认失败，则安全网关(SeGW)发送指示给所述H(e)NB。

185.根据前述任一实施例所述的方法，其中所述SeGW发送失败的功能性的列表给个人视频编码器(PVE)。

186.根据前述任一实施例所述的方法，其中所述PVE确定行动，该行动包括隔离所述设备、提供完全接入、提供部分接入或者请求室内移动站(H(e)MS)为补救而干涉。

187.根据前述任一实施例所述的方法，其中所述PVE将决定通知给所述SeGW。

188.根据前述任一实施例所述的方法，其中个人视频编码器(PVE)发送通知给室内移动站(H(e)MS)以启动补救和失败的模块的列表。

189.根据前述任一实施例所述的方法，其中个人视频编码器(PVE)发送关于补救的通知给所述H(e)NB。

190.根据前述任一实施例所述的方法，其中安全网关(SeGW)指示设备完整性评估的结果给所述H(e)NB。

191.根据前述任一实施例所述的方法，其中传输元素(TrE)将完整性验证委托给外部实体。

192.根据前述任一实施例所述的方法，其中所述H(e)NB包括本地时间服务器，该本地时间服务器使用网络时间协议(NTP)来同步时间。

193.根据前述任一实施例所述的方法，其中鉴权证书和SAV中的本地确认的结果以IKE_AUTH_REQ消息进行发送。

194.根据前述任一实施例所述的方法，其中安全网关(SeGW)在将该表传递给个人视频编码器(PVE)之前过滤一系列失败的模块。

195.根据前述任一实施例所述的方法，其中所述H(e)NB与室内移动站(H(e)MS)通过安全网关或者通过互联网连接而进行交互以支持补救。

196.根据前述任一实施例所述的方法，其中室内移动站(H(e)MS)调用远程过程调用(RPC)来指示所述H(e)NB上传失败的功能性的列表和错误码的列表。

197.根据前述任一实施例所述的方法，其中室内移动站(H(e)MS)指示文件服务器准备上传失败的功能性的列表。

198.根据前述任一实施例所述的方法，其中所述H(e)NB调用过程来上传包含了失败的功能性列表的文件。

199.根据前述任一实施例所述的方法，其中文件服务器在评估上传的文件之后，发送Download_Package_Ready消息给室内移动站(H(e)MS)。

200.根据前述任一实施例所述的方法，其中室内移动站(H(e)MS)调用远程过程调用(RPC)并提供设备配置表的统一资源定位符(URL)。

201.根据前述任一实施例所述的方法，其中所述H(e)NB与文件传输协议(FTP)文件服务器相连并下载固件镜像和设备配置表。

202.根据前述任一实施例所述的方法，其中室内移动站(H(e)MS)一旦接收到成功下载的响应，就调用重新启动过程。

203.根据前述任一实施例所述的方法，其中所述H(e)NB一旦接收到成功下载的响应，就重置本地遇险标志。

204.根据前述任一实施例所述的方法，其中室内移动站(H(e)MS)从安全网关(SeGW)接收指示所述设备成功启动的消息。

205.根据前述任一实施例所述的方法，其中如果在安全启动进程中，完整性校验被加载、执行并且鉴权成功进行，则所述H(e)NB与安全网关进行通信。

206.根据前述任一实施例所述的方法，该方法还包括传送本地完整性校验的结果。

207.根据前述任一实施例所述的方法，该方法还包括将所述本地完整性校验的结果转发给个人视频编码器(PVE)。

208.根据前述任一实施例所述的方法，其中H(e)NB用IKEv2NOTIFY消息发送失败的功能性的列表和制造商特定的错误码的列表给所述SeGW。

209.根据前述任一实施例所述的方法，其中SeGW将所述失败的功能性的列表转发给个人视频编码器(PVE)。

210.根据前述任一实施例所述的方法，其中PVE决定SeGW行动、H(e)NB行动，并将所述行动的列表转发给所述SeGW。

举例来说，恰当的处理器包括：通用处理器、专用处理器、传统处理器、数字信号处理器(DSP)、多个微处理器、与DSP内核相关的一个或多个微处理器、控制器、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)电路、任何一种集成电路(IC)和/或状态机。

与软件相关的处理器可以用于实现一个射频收发机，以便在无线发射接收单元(WTRU)、用户设备(UE)、终端、基站、无线电网络控制器(RNC)或者任何主机计算机中加以。WTRU可以与采用硬件和/或软件形式实施的模块结合使用，例如照相机、摄像机模块、可视电话、扬声器电话、振动设备、扬声器、麦克风、电视收发器、免提耳机、键盘、模块、调频(FM)无线单元、液晶显示器(LCD)显示单元、有机发光二极管(OLED)显示单元、数字音乐播放器、媒体播放器、视频游戏机模块、互联网浏览器和/或任何无线局域网(WLAN)模块或者超宽带(UWB)模块。

虽然本发明的特征和元素在优选的实施方式中以特定的结合进行了描述，但每个特征或元素可以在没有所述优选实施方式的其他特征和元素的情况下单独使用，或在与或不与本发明的其他特征和元素结合的各种情况下使用。本发明提供的方法或流程图可以在由通用计算机或处理器执行的计算机程序、软件或固件中实施，其中所述计算机程序、软件或固件是以有形的方式包含在计算机可读存储介质中的。计算机可读存储介质的例子包括只读存储器(ROM)、随机存取存储器(RAM)、寄存器、缓存存储器、半导体存储设备、诸如内部硬盘和可移动磁盘这样的磁性介质、磁光介质和如CD-ROM光盘和数字通用光盘(DVD)这样的光介质。

Claims (24)

1.一种用于对无线发射/接收单元(WTRU)执行完整性验证的方法，该方法包括在该无线发射/接收单元处执行的以下步骤：

在所述WTRU测量该WTRU的至少一组件的完整性度量；

在所述WTRU从在所述WTRU上的本地存储器中获取所述至少一个组件的可信的参考值(TRV)；

在所述WTRU将测量的完整性度量与所述TRV进行比较，以确定所述至少一个组件的完整性验证校验的结果；以及

一旦所述至少一个组件的完整性验证校验失败，基于本地提供的策略确定行动路线。

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

将完整性验证校验失败的所述至少一个组件映射到功能性以在所述WTRU产生受所述至少一个组件的完整性验证校验失败影响的功能性的设备独立分类；以及

向平台确认实体(PVE)报告所述至少一个组件的完整性验证校验结果，并向所述PVE发送受所述至少一个组件的完整性验证校验失败影响的功能性的设备独立分类。

3.根据权利要求2所述的方法，其中所述PVE和所述WTRU是在网络上的单独实体。

4.根据权利要求2所述的方法，其中向所述PVE报告所述完整性验证校验结果包括发送所述WTRU的设备标识符。

5.根据权利要求1所述的方法，该方法还包括确定与失败的完整性验证校验相关联的严重性分级，并且基于所确定的严重性分级执行预先确定的行动。

6.根据权利要求5所述的方法，其中第一严重性分级的确定导致使用回退编码镜像(FBC)重新启动所述WTRU。

7.根据权利要求6所述的方法，其中不同的第二严重性分级的确定可能导致所述WTRU的功能性的受限子集的性能。

8.根据权利要求7所述的方法，其中一旦确定另一个严重性分级，经由立即更新过程执行失败组件的替换。

9.根据权利要求7所述的方法，其中一旦确定另一个严重性分级，作为常规更新调度的一部分执行进行失败组件的替换。

10.根据权利要求6所述的方法，其中所述FBC有与核心网络进行基本通信的能力和有向所述核心网络发送遇险信号的能力，所述遇险信号包含指示完整性验证校验失败的具体信息的错误代码信息元素。

11.根据权利要求10所述的方法，其中所述遇险信号包括含有以下一者或多者的信息元素的组合：

所述WTRU的设备标识符、包含关于完整性验证校验失败的信息的事件字段、以及包含指示WTRU知道的当前日期和时间的时间字段。

12.根据权利要求2所述的方法，其中所述功能性的设备独立分类包括版本信息、设备模型信息以及序列号中的至少一者。

13.一种无线发射/接收单元(WTRU)，适用于：

测量所述WTRU的至少一组件的完整性度量；

从在所述WTRU上的本地存储器中获取所述至少一个组件的可信的参考值(TRV)；

将测量的完整性度量与所述TRV进行比较，以确定所述至少一个组件的完整性验证校验的结果；以及

一旦所述至少一个组件的完整性验证校验失败，基于本地提供的策略确定行动路线。

14.根据权利要求13所述的WTRU，该WTRU还适用于：

将完整性验证校验失败的所述至少一个组件映射到功能性以产生受所述WTRU上所述至少一个组件的完整性验证校验失败影响的功能性的设备独立分类；以及

向平台确认实体(PVE)报告所述至少一个组件的完整性验证校验结果，并向所述PVE发送受所述至少一个组件的完整性验证校验失败影响的功能性的设备独立分类。

15.根据权利要求14所述的WTRU，其中所述PVE和所述WTRU是在网络上的单独实体。

16.根据权利要求14所述的WTRU，其中向所述PVE报告所述完整性验证校验结果包括发送所述WTRU的设备标识符。

17.根据权利要求13所述的WTRU，该WTRU还适用于确定与失败的完整性验证校验相关联的严重性分级，并且基于所确定的严重性分级执行预先确定的行动。

18.根据权利要求17所述的WTRU，其中第一严重性分级的确定导致使用回退编码镜像(FBC)重新启动所述WTRU。

19.根据权利要求18所述的WTRU，其中不同的第二严重性分级的确定可能导致所述WTRU的功能性的受限子集的性能。

20.根据权利要求19所述的WTRU，其中一旦确定另一个严重性分级，经由立即更新过程执行失败组件的替换。

21.根据权利要求19所述的WTRU，其中一旦确定另一个严重性分级，作为常规更新调度的一部分执行进行失败组件的替换。

22.根据权利要求18所述的WTRU，其中所述FBC有与核心网络进行基本通信的能力和有向所述核心网络发送遇险信号的能力，所述遇险信号包含指示完整性验证校验失败的具体信息的错误代码信息元素。

23.根据权利要求22所述的WTRU，其中所述遇险信号包括含有以下一者或多者的信息元素的组合：

所述WTRU的设备标识符、包含关于完整性验证校验失败的信息的事件字段、以及包含指示WTRU知道的当前日期和时间的时间字段。

24.根据权利要求14所述的WTRU，其中所述功能性的设备独立分类包括版本信息、设备模型信息以及序列号中的至少一者。