专利名称：设备检验、遇险指示和补救的制作方法
设备检验、遇险指示和补救相关申请的交叉引用本申请要求于2010年11月5日提交的美国临时专利申请61/410，781的权益，其中该申请的内容在这里全部引入作为参考。
背景技术：
无线通信系统可以使用多余的资源来执行完整性检查和/或修复该系统内部无线通信设备上的完整性故障。当前的完整性检查可以在大型单体码块上执行，以便确定无线通信设备的完整性是否受损。例如，通过完整性检查，可以在无线通信设备上检测到未经授权的修改、篡改和/或受损软件。一旦检测到很大的单体码块的完整性故障，则网络可以采用大型单个码块的形式来将更新下载至无线通信设备，以便修复故障。这样做有可能需要不必要的带宽，并且在系统上增加了不需要的计算负担。此外，多种类型和/或模型的无线通信设备可以用于与网络通信或是在网络上通信，并且其中每一个设备都具有不同的软件和硬件形式。由于硬件和软件开发实践有可能会随着公司而不同，因此，这些不同的设备可能会导致难以使无线通信设备上发生故障的组件的报告处理标准化。
发明内容
本概述是为了以简化形式引入在以下的详细描述中被更进一步描述的不同概念而被提供的。在这里描述的是用于对无线通信设备的一个或多个组件执行完整性检查的系统、方法和设备实施例。这里描述的第一完整性检查可以在与无线通信设备相关联的组件上执行。该组件可被确定未能通过第一完整性检查。这时可以向网络实体发送一个关于与所述发生故障的组件相对应的功能的指示。从该网络实体可以接收一个在发生故障的组件上执行第二完整性检查以便确定发生故障的组件中导致该组件未通过第一完整性检查的部分的请求。所述第二完整性检查可以在发生故障的组件上执行，以便隔离所述发生故障的组件的部分，以通过网络实体来补救。根据一个例示实施例，加载器可以被配置成在与无线通信设备相关联的组件上执行第一完整性检查。该加载器还可以被配置成确定组件未通过第一完整性检查，并且在发生故障的组件上执行第二完整性检查，以便隔离发生故障的组件的部分，以通过网络实体来补救。根据一个例示实施例，平台完整性策略引擎(PIPE)可以被配置成接收来自加载器的关于发生故障的组件的指示，以及接收与发生故障的组件相对应的网络功能。该PIPE还可以被配置成向网络实体报告一个关于与发生故障的组件相对应的功能的指示，并且从网络实体接收在发生故障的组件上执行第二完整性检查以便确定发生故障的组件中导致该组件未通过第一完整性检查的部分的请求。根据一个例示实施例，设备补救服务器可以如这里所述。该设备补救服务器可以驻留在无线通信网络上，并且被配置成补救无线通信设备上未能通过完整性检查的组件的部分。例如，设备补救服务器可以被配置成从无线通信设备接收一个关于与无线通信设备上未能通过完整性检查的组件相关联的网络功能的指示。所述发生故障的组件可以是基于接收到的关于网络功能的指示而被确定的。设备补救服务器还可以被配置成执行向无线通信设备的询问，以便通过隔离发生故障的组件的部分来进行补救。该设备补救服务器还可以被配置成基于一个或多个标准(criteria)来确定发送给无线通信设备的关于发生故障的组件的修复或替换。一旦基于该标准确定了修复或替换，则设备补救服务器可以将用于发生故障的组件的部分的修复或替换发送到无线通信设备。多种不同的标准可以用于确定发生故障的组件的修复或替换。例如，所述标准可以基于发生故障的组件的大小或其他某个因素。在一个例示实施例中，补救服务器可以基于OS软件版本来替换特定组件。其他例示标准可以包括但不局限于:版本号；每一个设备/组件/代码部分的最近更新或成功补救的日期/时间；代码或组件的所有权；代码许可的状况(例如数字权利管理)；发生故障的组件、比特或字节的数量；发生故障的代码部分的大小；以及所指定或计算的代码部分或组件的风险或损害影响值。本概述是为了以简化形式引入精选概念而被提供的，并且在以下的详细描述中将会进一步描述这些概念。本概述既不是为了确定所保护主题的关键特征或必要特征，也不是为了限定所保护的主题的范围。此外，所要保护的主题并不局限于解决在本公开的任何部分中指出的任何或所有缺陷的范围。
更详细的理解可以从以下结合附图举例给出的描述中得到，其中:图1A示出的是可以实施所公开的一个或多个实施例的例示通信系统；图1B示出的是可以实施所公开的一个或多个实施例的例示无线发射/接收单元;图1C示出的是可以实施所公开的一个或多个实施例的例示系统无线电接入网络；图2是示出了无线通信设备上的引导序列的例示实施例的图示；图3是示出了对象文件与可执行映像之间的联系的图示；图4是示出了对象文件与可执行映像之间的联系的另一个图示；图5示出的是文件的组件TRV区段的一个示例。图6是示出了组件-网络功能映射的图示；图7示出的是文件的组件-功能映射区段的示例；图8是示出了在引导序列中使用的平台能力策略初启(bring-up)的图示；图9是示出了这里描述的在完整性检查和/或报告期间使用表格或映射的图示；图10是示出了这里描述的报告和补救处理的例示综述的图示；图11示出的是通过在设备上收集信息来确定可以执行的操作的例示呼叫流程图；图12示出的是用于在设备与网络实体之间执行询问的例示呼叫流程图；图13示出的是在无线通信设备的组件上执行的询问的示例；
图14示出的是在无线通信设备组件上执行的询问的另一个示例；图15示出的是与遇险警报以及单体代码替换相关的例示呼叫流程图；图16示出的是与远程软件遇险/补救相关联的例示呼叫流程图；图17示出的是与实施SeGW验证尝试的远程软件遇险/补救相关联的例示呼叫流程图；图18A示出的是与远程软件遇险/补救相关联的例示呼叫流程图，其中网络可以禁止经由SeGW的验证；图18B示出的是与实施即时限制访问和精确访问控制的远程软件遇险/补救相关联的例示呼叫流程图；图19示出的是将无线通信设备软件组件补救与SeGW访问相关联的例示呼叫流程图；图20示出的是与中继节点的能力自举(bootstrap)相关联的例示呼叫流程图；图21示出的是与具有经过验证的管理能力的中继节点补救相关联的例示呼叫流程图；图22示出的是具有功能组件和代码/数据存储组件的例示系统；图23示出的是引导序列的阶段以及在每一个阶段实施的不同实体间的交互的例示流程图；图24A示出的是被线性组合以创建TRV的量度序列的图示；以及图24B示出的是使用Merkle散列树来创建TRV的值的组合的图示。
具体实施例方式图1A-24B涉及的是可以实施所公开的系统、方法和手段的例示实施例。这里描述的实施例是例示性而不是限制性的。虽然在这里示出并描述了协议流程，但是这些流程的顺序是可以改变的，和/或附加流程是可以添加的。图1A、1B和IC示出的是可以在这里描述的实施例中使用的例示通信系统和设备。图1A是可以实施所公开的一个或多个实施例的例示通信系统100的图示。通信系统100可以是为多个无线用户提供语音、数据、视频、消息传递、广播等内容的多址接入系统。该通信系统100通过共享包括无线带宽在内的系统资源来允许多个无线用户访问此类内容，举例来说，通信系统100可以使用一种或多种信道接入方法，如码分多址(CDMA)、时分多址(TDMA)、频分多址(FDMA)、正交 FDMA (OFDMA)、单载波 FDMA (SC-FDMA)等等。如图1A所示，通信系统100可以包括无线发射/接收单元(WTRU) 102a、102b、102c、102d，无线电接入网络(RAN) 104，核心网络106，公共交换电话网络(PSTN) 108，因特网110以及其他网络112，但是应该了解，所公开的实施例设想了任意数量的WTRU、基站、网络和/或网络部件。WTRU102a、102b、102c、102d中的每一者可以是被配置成在无线环境中工作和/或通信的任何类型的设备。例如，WTRU102a、102b、102c、102d可以被配置成发射和/或接收无线信号，并且可以包括用户设备(UE)、移动站、固定或移动订户单元、寻呼机、蜂窝电话、个人数字助理(PDA)、智能电话、膝上型计算机、上网本、个人计算机、无线传感器、消费类电子设备等等。通彳目系统100还可以包括基站114a和基站114b。基站114a、114b中的每一者可以是被配置成通过与WTRU102a、102b、102c、102d中的至少一个无线对接来促成对一个或多个通信网络的访问，例如核心网络106、因特网110和/或网络112。例如，基站114a、114b可以是基地收发信台(BTS)、节点B、e节点B、家用节点B、家用e节点B、站点控制器、接入点(AP)、无线路由器等等。虽然每一个基站114a、114b都被描述成是单个部件，但是应该了解，基站114a、114b可以包括任何数量的互连基站和/或网络部件。基站114a可以是RAN104的一部分，并且所述RAN还可以包括其他基站和/或网络部件(未显示)，例如基站控制器(BSC)、无线电网络控制器(RNC)、中继节点等等。基站114a和/或基站114b可以被配置成在被称之为为小区(未显示)的特定地理区域内部发射和/或接收无线信号。小区可以进一步分成小区扇区。例如，与基站114a相关联的小区可以分成三个扇区。因此，在一个实施例中，基站114a可以包括三个收发信机，也就是说，每一个收发信机对应于小区的一个扇区。在另一个实施例中，基站114a可以使用多输入多输出(MIMO)技术，由此可以为小区中的每个扇区使用多个收发信机。基站114a、114b可以经由空中接口 116来与一个或多个WTRU102a、102b、102c、102d进行通信，其中该空中接口可以是任何适当的无线通信链路(例如射频(RF)、微波、红外线(IR)、紫外线(UV)、可见光等等)。空中接口 216可以采用任何适当的无线电接入技术(RAT)来建立。更具体地说，如上所述，通信系统100可以是一个多址接入系统，并且可以使用一种或多种信道接入方案，如CDMA、TDMA, FDMA, OFDMA, SC-FDMA等等。举例来说，RAN104中的基站114a和WTRU102a、102b、102c可以实施诸如通用移动电信系统(UMTS)陆地无线电接入(UTRA)之类的无线电技术，其中该技术可以使用宽带CDMA (WCDMA)来建立空中接口116。WCDMA可以包括下列通信协议，如高速分组接入(HSPA)和/或演进型HSPA (HSPA+)。HSPA可以包括高速下行链路分组接入(HSDPA)和/或高速上行链路分组接入(HSUPA)。在另一个实施例中，基站114a和WTRU102a、102b、102c可以实施诸如演进型UMTS陆地无线电接入(E-UTRA)之类的无线电技术，该技术可以使用长期演进(LTE)和/或高级LTE (LTE-A)来建立空中接口 116。在其他实施例中，基站114a与WTRU102a、102b、102c可以实施IEEE802.16 (全球微波接入互操作性(WiMAX))、CDMA2000、CDMA20001X、CDMA2000EV-D0、临时标准 2000(IS-2000)、临时标准95 (IS-95)、临时标准856 (IS-856)、全球移动通信系统(GSM)、用于GSM演进的增强数据速率(EDGE)、GSM EDGE (GERAN)等无线电接入技术。图1A中的基站114b可以是例如无线路由器、家用节点B、家用e节点B或接入点，并且可以使用任何适当的RAT来促成局部区域中的无线连接，例如营业场所、住宅、交通工具、校园等等。在一个实施例中，基站114b和WTRU102c、102d可以通过实施诸如IEEE802.11之类的无线电技术来建立无线局域网(WLAN)。在另一个实施例中，基站114b和WTRU102C、102d可以通过实施诸如IEEE802.15之类的无线电技术来建立无线个人局域网(WPAN)。在再一个实施例中，基站114b和WTRU102c、102d可以通过使用基于蜂窝的RAT (例如WCDMA、CDMA2000、GSM、LTE、LTE-A等等)来建立微微小区或毫微微小区。如图1A所示，基站114b可以直接连接到因特网110。由此，基站114b未必需要经由核心网络106来接入因特网110。RAN104可以与核心网络106通信，所述核心网络可以是被配置成向一个或多个WTRU102a、102b、102c、102d提供语音、数据、应用和/或借助网际协议的语音(VoIP)服务的任何类型的网络。例如，核心网络106可以提供呼叫控制、记账服务、基于移动位置的服务、预付费呼叫、因特网连接、视频分发等等，和/或执行高级安全功能，例如用户验证。虽然在图1A中没有显示，但是应该了解，RAN104和/或核心网络106可以直接或间接地和其他那些与RAN104使用相同RAT或不同RAT的RAN进行通信。例如，除了与可以使用E-UTRA无线电技术的RAN104相连之外，核心网络106还可以与另一个使用GSM无线电技术的RAN (未显示)通信。核心网络106还可以充当WTRU102a、102b、102c、102d接入PSTN108、因特网110和/或其他网络112的网关。PSTN108可以包括提供简易老式电话服务(POTS)的电路交换电话网络。因特网110可以包括使用公共通信协议的全球性互联计算机网络设备系统，所述协议可以是TCP/IP互连网协议族中的传输控制协议(TCP)、用户数据报协议(UDP)和网际协议(IP)。网络112可以包括由其他服务供应商拥有和/或运营的有线或无线通信网络。例如，网络112可以包括与一个或多个RAN相连的另一个核心网络，其中所述一个或多个RAN可以与RAN104使用相同RAT或不同的RAT。通信系统100中一些或所有町冊102&、10213、102(3、102(1可以包括多模能力，换言之，WTRU102a、102b、102c、102d可以包括在不同无线链路上与不同无线网络通信的多个收发信机。例如，图1A所示的WTRU102C可以被配置成与使用基于蜂窝的无线电技术的基站114a通信，以及与可以使用IEEE802无线电技术的基站114b通信。图1B是例示WTRU102的系统图示。如图1B所示，WTRU102可以包括处理器118、收发信机120、发射/接收部件122、扬声器/麦克风124、键盘126、显示器/触摸板128、不可拆卸存储器130、可拆卸存储器132、电源134、全球定位系统(GPS)芯片组136以及其他外围设备138。应该了解的是，在保持符合实施例的同时，WTRU102可以包括前述部件的任何子组合。处理器118可以是通用处理器、专用处理器、常规处理器、数字信号处理器(DSP)、多个微处理器、与DSP核心关联的一个或多个微处理器、控制器、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)电路、其他任何类型的集成电路(1C)、状态机等等。处理器118可以执行信号编码、数据处理、功率控制、输入/输出处理和/或其他任何能使WTRU102在无线环境中工作的功能。处理器118可以耦合至收发信机120，收发信机120可以耦合至发射/接收部件122。虽然图1B将处理器118和收发信机120描述成是独立组件，但是应该了解，处理器118和收发信机120可以一起集成在一个电子封装或芯片中。发射/接收部件122可以被配置成经由空中接口 116来发射或接收去往或来自基站(例如基站114a)的信号。例如，在一个实施例中，发射/接收部件122可以是被配置成发射和/或接收RF信号的天线。在另一个实施例中，举例来说，发射/接收部件122可以是被配置成发射和/或接收IR、UV或可见光信号的发射器/检测器。在再一个实施例中，发射/接收部件122可以被配置成发射和接收RF和光信号。应该了解的是，发射/接收部件122可以被配置成发射和/或接收无线信号的任何组合。此外，虽然在图1B中将发射/接收部件122描述成是单个部件，但是WTRU102可以包括任何数量的发射/接收部件122。更具体地说，WTRU102可以使用MMO技术。因此，在一个实施例中，WTRU102可以包括两个或更多个经由空中接口 116来发射和接收无线电信号的发射/接收部件122 (例如多个天线)。
收发信机120可以被配置成对发射/接收部件122将要发射的信号进行调制，以及对发射/接收部件122接收的信号进行解调。如上所述，WTRU102可以具有多模能力。因此，收发信机120可以包括允许WTRU102借助UTRA和IEEE802.11之类的多种RAT来进行通信的多个收发信机。WTRU102的处理器118可以耦合至扬声器/麦克风124、键盘126和/或显示器/触摸板128 (例如液晶显示器(IXD)显示单元或有机发光二极管(OLED)显示单元)，并且可以接收来自这些部件的用户输入数据。处理器118还可以向扬声器/麦克风124、键盘126和/或显示器/触摸板128输出用户数据。此外，处理器118可以从任何适当的存储器(例如不可拆卸存储器130和/或可拆卸存储器132)中访问信息，以及将信息存入这些存储器。所述不可拆卸存储器130可以包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘或是其他任何类型的记忆存储设备。可拆卸存储器132可以包括订户身份模块(SM)卡、记忆棒、安全数字(SD)记忆卡等等。在其他实施例中，处理器118可以从那些并非实际位于WTRU102的存储器访问信息，以及将数据存入这些存储器，其中举例来说，所述存储器可以位于服务器或家用计算机(未显示)。处理器118可以接收来自电源134的电力，并且可以被配置分发和/或控制用于WTRU102中的其他组件的电力。电源134可以是为WTRU102供电的任何适当的设备。举例来说，电源134可以包括一个或多个干电池组(如镍镉(NiCd)、镍锌(NiZn)、镍氢(NiMH)、锂离子(L1-1on)等等)、太阳能电池、燃料电池等等。处理器118还可以与GPS芯片组136耦合，该芯片组可以被配置成提供与WTRU102的当前位置相关的位置信息(例如经度和纬度)。作为来自GPS芯片组136的信息的补充或替换，WTRU102可以经由空中接口 116接收来自基站(例如基站114a、114b)的位置信息，和/或根据从两个或更多个附近基站接收的信号的定时来确定其位置。应该了解的是，在保持符合实施例的同时，WTRU102可以借助任何适当的定位方法来获取位置信息。处理器118还可以耦合到其他外围设备138，这其中可以包括提供附加特征、功能和/或有线或无线连接的一个或多个软件和/或硬件模块。例如，外围设备138可以包括加速度计、电子指南针、卫星收发信机、数码相机(用于照片或视频)、通用串行总线(USB)端口、振动设备、电视收发信机、免提耳机、蓝牙 糢块、调频(FM)无线电单元、数字音乐播放器、媒体播放器、视频游戏播放器模块、因特网浏览器等等。图1C是根据一个实施例的RAN104和核心网络106的系统图示。如上所述，RAN104可以使用E-UTRA无线电技术以经由空中接口 116来与WTRU102a、102b、102c进行通信。并且该RAN104还可以与核心网络106通信。RAN104可以包括e节点B140a、140b、140c，但是应该理解，在保持与实施例相符的同时，RAN104可以包括任意数量的e节点B。节点B140a、140b、140c中的每一者都可以包括一个或多个收发信机，以便经由空中接口 116来与WTRU102a、102b、102c进行通信。在一个实施例中，e节点B140a、140b、140c可以实施MMO技术。因此，举例来说，e节点B140a可以使用多个天线来向WTRU102a发射无线信号以及接收来自WTRU102a的无线信号。e节点B140a、140b、140c中的每一者都可以与特定的小区(未显示)相关联，并且可以被配置成处理无线电资源管理决策、切换决策、上行链路和/或下行链路中的用户调度等等。如图1C所示，e节点B140a、140b、140c彼此可以经由X2接口来进行通信。
图1C所示的核心网络106可以包括移动性管理网关(MME) 142、服务网关144以及分组数据网络(PDN)网关146。虽然在前的每一个部件都被描述成是核心网络106的一部分，但是应该了解，这其中的任一部件都可以被核心网络运营商以外的实体拥有和/或运营。MME142可以经由SI接口来与RAN104中的每一个e节点B140a、140b、140c相连，并且可以充当控制节点。例如，MME142可以负责验证WTRU102a、102b、102c的用户，激活/去激活承载，在WTRU102a、102b、102c的初始附着过程中选择特定服务网关等等。MME142还可以提供控制平面功能，以便在RAN104与使用了诸如GSM或WCDMA之类的其他无线电技术的其他RAN (未显示)之间进行切换。服务网关144可以经由SI接口而与RAN104中的每一个e节点B140a、140b、140c相连。该服务网关144通常可以路由和转发去往/来自WTRU102a、102b、102c的用户数据分组。该服务网关144还可以执行其他功能，例如在e节点B间的切换过程中锚定用户面，在下行链路数据可供WTRU102a、102b、102c使用时触发寻呼，管理和存储WTRU102a、102b、102c的上下文等等。服务网关144还可以连接到PDN网关146，该PDN网关可以为WTRU102a、102b、102c提供针对因特网之类的分组交换网络的接入，以便促成WTRU102a、102b、102c与启用IP的设备之间的通信。核心网络106可以促成与其他网络的通信。例如，核心网络106可以为WTRU102a、102以102(3提供针对？5了附08之类的电路交换网络的接入，以便促成WTRU102a、102b、102c与传统的陆线通信设备之间的通信。例如，核心网络106可以包括IP网关(例如IP多媒体子系统(MS)服务器)或与之通信，其中该IP网关充当的是核心网络106与PSTN108之间的接口。此外，核心网络106可以为WTRU102a、102b、102c提供针对网络112的接入，该网络可以包括其他服务供应商拥有和/或运营的其他有线或无线网络。这里描述的通信系统和设备可以用于管理通信设备的软件，管理通信设备的配置，和/或提供软件和/或配置信息补救，以便将设备恢复到原始状态。此外，在这里还描述了使用软件开发和代码发布工具的实施方式，其中所述软件开发和代码发布工具可以使用软件工具、网络协议、设备策略以及软件管理和/或远程调试技术来自动生成和管理可信代码库(code base)的软件方面的基准，从而在设备中嵌入用于可证实报告和补救的机制和基准。更进一步，在这里描述的是可以确保设备实施的完整性检查的故障指示的技术，其中包括对表明可以信任报告故障的设备的指示所进行的描述。这里描述的无线通信设备可以被配置成在具有多个阶段的安全引导处理的每个阶段执行完整性检查。在多个阶段的安全引导处理过程中，每一个阶段可以核实后续阶段，由此创建一个信任链。在具有多个阶段的安全引导处理的每个阶段中可以确定是否可以信任与该阶段相关联的组件。与组件相关联的完整性量度可被确定。该组件可以具有相关联的可信基准值。组件的可信赖度可以通过将完整性量度与可信基准值相比较来确定(例如测试)。如果完整性量度与可信基准值相匹配，则可以认为该组件是可信赖的。如果完整性量度未能与可信基准值相匹配，则认为该组件未必是可信赖的。虽然在这里描述的是通过将完整性量度与可信基准值相比较来执行完整性检查，但是应该了解，完整性检查是可以采用其他那些用于确定组件可信赖度的方式执行的。
由于外部实体未必会辨认出组件，因此，举例来说，在多个网络和/或设备上可以定义和/或标准化功能，从而与标准规范和/或取决于实施的方式的相一致。组件可以与功能相关联。组件与功能之间的关系可以在组件-功能映射中给出。功能故障可以通过将发生故障的组件与组件-功能映射相比较来识别。设备可以向外部实体发送与功能故障相关联的警报。外部实体可以确定与功能相关联且可以用于修复或替换发生故障的组件的替换代码。换言之，替换代码可以是一个替换组件。设备可以接收该替换组件，并且使用该替换组件来替换发生故障的组件。安全引导处理可以提供检验过程的基础。由不可变硬件可信根(RoT)发起的信任链可以核实所加载的初始代码的有效性。如图2所示，举例来说，该引导处理可以在每一个阶段通过信任链核实后续阶段的时候继续进行。在通电以及硬件初始化过程之后，设备可以启动一个例如图2所示的安全引导处理。初始的RoT可以用驻留于ROM中的安全存储器的引导加载器202表示。在一开始，ROM引导加载器202可以执行一些初始化功能。该ROM引导加载器202可访问安全凭证(例如融合键控信息)，并且可以使用该信息来核实第二阶段的引导加载器204 (例如驻留在外部存储器中)的完整性。第二阶段的加载器204可以由硬件或软件密码加密装置进行检查，以确保其完整性。计算得到的第二阶段的加载器204的散列(hash)量度可以与一个用安全凭证签名并保存在外部存储器中的可信基准值(TRV)量度相比较。如果计算得到的量度与带签名的TRV相匹配，则第二阶段的加载器204可被核实并加载到内部存储器(例如RAM)中。该引导ROM可以跳转到第二阶段的加载器204的开端，并且信任链可以继续。所述核实处理中的初始阶段的故障可以表明后续核实有可能受损(例如，初始阶段的故障可以表明信任链发生了重大故障)。如果存在在核实处理的初始阶段指示出的故障，则可以将设备关闭。第二阶段的引导加载器204可以包括可信执行环境(TrE)代码以及可以检查附加代码并且将其加载到内部存储器的代码。TrE可以建立一个能够计算和存储附加的完整性基准值的可信环境和安全存储区域。该TrE完整性可以检查、加载和/或启动操作系统以及通信代码。随着每个阶段被检查和加载(例如，图2所示的方框202、204、206和208中的每一者都可以表示一个阶段)，所述信任链可以延续。例如，第二阶段的加载器204可以核实OS/通信(Comm) 206和/或设备软件208的完整性。作为替换或补充，OS/通信206可以核实设备软件208的完整性。所述OS/通信206可以包括一个OS加载器。根据一个实施例，图2所示的实体可以按照执行顺序而被核实和/或相互核实，以便保持信任链。信任链可以由一个能够安全核实后续处理的执行过程来保持。该核实过程可以使用密码加密计算和/或可信基准值。驻留在非安全存储器中的代码可能易受攻击，并且可以在加载之前对其进行检查。在没有细粒度检验的情况下，第二阶段的引导加载器204可以检验剩余代码，以此作为体积(bulk)量度。如果测量得到的值不与单体块的TRV匹配，那么可以确定所述代码未必可信以及不可以加载该代码。设备未必能够通信，并且一个结果有可能包括借助高成本的上门服务或是运回设备进行修复来补救整个代码库。这里描述的方法、系统和手段可以使得设备能够检验已存储代码的较小组件，以及提供关于哪些组件出现故障以及哪些组件可以或者不可以被远程补救的详细描述。这种细粒度信息可被提供给补救管理器。
在这里可以建立策略来确定哪些发生故障的组件是可以远程补救的。举个例子，如果设备检查并加载了 TrE以及最小的通信代码集合，那么该设备可以保持充当用于补救管理器的代理的功能，以便识别以及向补救管理器报告发生故障的特定组件的信息。如果补救能力存在且属于设备的代理功能的一部分，则可以发起后续的远程补救过程，这样做可以减少使用高成本的现场人员更新。根据一个实施例，可执行映像可被分区和检验，以便能够实施细粒度的报告处理。可执行映像的生成可以在几个阶段中进行。组件可以是指一个包含了子程序和/或参数/数据的文件。开发人员可以编写一个在组件源和头文件中捕获的程序。从这些组件源文件中，编译器和汇编器可以产生同时包含了机器二进制码和程序数据的目标文件(例如*.ο )。链接器可以将这些目标文件作为输入，并且产生一个能够用于与其他目标文件附加链接的可执行映像或目标文件。链接器命令文件可以指示链接器如何组合对象文件，以及将二进制码和数据放置在目标嵌入式系统中的什么位置。链接器的功能可以是将多个对象文件合并成较大的可重新定位的对象文件、共享的对象文件或是最终的可执行映像。全局变量和非静态函数可被称为全局符号。在最终的可执行二进制映像中，符号可以是指存储器中的地址位置。该存储器位置的内容可以是用于变量的数据或是用于函数的可执行代码。编译器可以创建一个具有符号名称-地址映射的符号表，以此作为其产生的对象文件的一部分。在创建可重新定位的输出的时候，编译器可以产生地址，其中对于每一个符号来说，所述地址与所编译的文件是关联的。链接器执行的链接处理可以包括符号解析和/或符号重新定位。符号解析可以是链接器检查每一个目标文件并且为目标文件确定在哪个(哪些)(其他)目标文件中定义外部符号。符号重新定位可以是链接器将符号引用映射到其定义的处理。该链接器可以修改所链接的对象文件的机器码，由此，对符号的代码引用反映了指定给这些符号的实际地址。对象和可执行文件可以采用若干种格式，例如ELF (可执行和链接格式)以及COFF(公共对象-文件格式)。对象文件可被划分成区域或区段。这些区段可以保持下列各项中的一项或多项:例如可执行代码、数据、动态链接信息、调试数据、符号表、重新定位信息、注释、字串表或注解。这些区段可以用于向二进制文件提供信息，以及允许检查。函数区段可以包括下列各项中的一项或多项:可以存储系统函数地址的全局偏移表(GOT)、可以存储至GOT的间接链接的过程链接表(PLT)、可以用于内部初始化的.1nit/fin1、以及可以用于构造器和析构器的.shutdown或.ctors/.dtors。数据区段可以包括下列各项中的一项或多项:用于只读数据的.rodata，用于已初始化数据的.data，或是用于未初始化数据的.bss。ELF区段可以包括下列各项中的一项或多项:用于启动的.1nit、用于字串的.text、用于停机的.fin1、用于只读数据的.rodata、用于已初始化数据的.data、用于已初始化的线程数据的.tdata、用于未初始化线程数据的.tbss、用于构造器的.ctors、用于析构器的.dtors、用于全局偏移表的.got、或用于未初始化数据的.bss。一些区段可被加载到进程映像中。一些区段可以提供在构建进程映像的过程中使用的信息。一些区段可被限制成在链接对象文件的过程中使用。一些对象文件可以包括对位于其他对象文件中的符号的引用。该链接器可以创建一个符号表，所述符号表可以包括符号名称的列表及其在用于每一个对象文件的文本和数据分段中的相应偏移。在将对象文件链接在一起之后，链接器可以使用重新定位记录来找出可能未被填充的未解析符号地址。在编译了多个源文件(例如C/C++和汇编文件)并将其汇编成ELF对象文件之后，链接器可以组合这些对象文件，并且将来自不同对象文件的区段并入如图3所示的程序分段。如图3所示，对象文件302、304和306的文本区段308、316和324分别可以并入可执行映像338的文本分段332。作为补充或替换，启动区段310、318和326可以并入可执行映像338的文本分段332。同样，对象文件302、304和306的数据区段312、320和328分别可以并入可执行映像338的数据分段334。最后，对象文件302、304和306的未初始化数据区段314、322和330分别可以并入可执行映像338的未初始化数据分段336。虽然图3示出了可以并入可执行映像338的区段的对象文件302、304和306的多个区段，但是应该理解，任意数量和/或组合的区段都可以并入可执行映像的区段。如图3所示，区段可以提供一种将相关区段归组的方式。每一个分段都可以包括具有相同或不同类型(例如文本、数据或动态区段)的一个或多个区段。操作系统在逻辑上可以依照在程序头表中提供的信息来拷贝文件分段。所述可执行和只读数据区段可以组合成单个文本区段。数据和未初始化的数据区段可以组合成数据分段或组合成其自己的单独的分段。由于这些分段可以在创建进程的时候加载到存储器中，因此，这些分段可被称为加载分段。诸如符号信息和调试区段之类的其他区段可以并入到其他的非加载分段。文本区段可以包括源代码以及已初始化的静态变量。编译器定义的多个区段可被加载到链接器定义的单个组合分段中。最终的可执行映像可以是用那些控制链接器如何组合区段和/或将区段分配到目标系统存储器映射的链接器命令(它可以是被叫链接器指令)产生的。链接器指令可以保持在链接器命令文件中。嵌入式开发人员可以使用该链接器命令文件来将可执行映像映射到目标系统。对发生故障的组件执行检验和细粒度报告的能力可以使用可执行映像中提供的附加信息，此外，开发和代码发布工具链是可以修改的。在可执行映像内部，每一个组件的基准量度以及识别所述量度所关联的组件的信息元素都是可以识别的。对发生故障的组件所进行的补救可以取决于设备报告标准的功能故障的能力。功能以及基于故障所采取的操作可以由网络运营商定义。软件开发者可以确定如何能将运营商定义的功能映射到其系统中的软件组件。在可执行映像中，功能映射是可见的，并且可以使用工具链增强。通过修改开发阶段使用的软件工具链，可以适应下列各项中的一项或多项:组件区段生成、安全的TRV生成和嵌入、组件-功能定义的插入、或策略及策略配置文件的插入。通过修改加载器的功能，可以适应检验和/或补救。加载器可被修改成执行下列各项中的一项或多项:在加载组件时对组件执行完整性检查、隔离或卸载发生故障的组件、管理策略、或在存储器中保存发生故障的组件ID以供策略管理器报告故障。在这里描述了可被应用于这里描述的软件开发和代码发布工具链来例证预期功能的例示实施例。然而，这里的实施例并不局限于这里提供的示例。链接器的作用可以是获取输入对象，以及将不同的区段组合成分段。由于可以在链接过程期间组合对象代码，因此，在符号表信息中可以保持识别对象文件中的函数或变量的能力。最终的合并代码区段可不提供可以用于触发这里描述的检验过程的检验方案。
为了便于识别单个组件，加载器可以具有一种识别代码起源的方式，其中可以包括定义组件或是生成可被加载器识别的单个组件的TRV。例如，通过增强用于生成可执行映像的工具链，能够识别出与加载器检验功能的特定对象文件组件相关联的代码，从而识别特定的组件以及执行完整性检查。代码映像的重新排列可以改变输入对象的TRV(例如，如果修改一个输入对象，那么有可能导致改变其他输入对象的TRV)。此外还可以阻止工具链使用优化方法，以便阻止TRV的变化。对于需要完整性检查的组件来说，在这里可以为其生成特定区段名称。例如，区段名称可以出现在最终的ELF可执行文件包含的区段头表中。通过归组用户定义的区段，力口载器可以识别组件以及执行完整性检查。所述加载器可以向策略管理器报告组件的通过与否的状态。通过隔离那些通过/未能通过完整性检查的特定功能，可以允许策略管理器以精细的粒度或详细的等级来报告那些可能受到发生故障的组件影响的功能。图4示出了两个可以链接在一起形成单个可执行映像406的对象文件402和404。对象文件402具有两个不同的代码分段，即组件文件区段408和文本区段410。对象文件404具有可以包括代码和/或恒定数据的单个代码分段，即组件文件区段416。对用户定义的代码区段、即组件文件区段408和组件文件区段416来说，这些区段可以连同与其映射的分段类型相关的大小和/或存储位置一起出现的区段报头中。在图4中用箭头描述了关于这种映射关系的一个示例。例如，对象文件402的组件文件区段408、文本区段410、数据区段412以及bss区段414分别可被映射到可执行映像406的组件文件区段420、文本区段424、数据区段426以及bss区段428。同样，对象文件404的组件文件区段416和bss区段418分别可以被映射到可执行映像406的组件文件区段422以及bss区段428。通过链接可执行映像406，可以在可执行映像406开端的预定位置包含用户定义的区段，由此可以按顺序对其进行检查。借助于检验的完整性检查可以仅限于代码库的一个子集。剩余那些被归组成较大文本分段的代码可以不被执行完整性检查，和/或是可以加载的。用户定义的区段的添加可以是可识别的，例如通过在组件代码中插A#_PRAGMA。仍旧参考图4的示例，在源文件的顶部可以插入指令#_PRAGMA区段(例如组件文件区段408)。通过增强编译器，可以借助编译器标记来包含用户定义的区段。如果设置了特定的标记，那么可以通过增强编译器来自动插入PRAGMA。此外，用户定义的区段的概念可以扩展，以便将用户定义的区段局限于那些可能被完整性检查的组件内部的功能。可用于设备的可信执行的功能可被分区或隔离成在启动过程中首先或者早期会被完整性检查的组件。区段可以借助链接器命令文件而被映射到存储器的特定分段。ELF对象可以依照源和目的地址来查看。在区段头表中标识的区段可以向加载器告知在哪儿发现所要移动的代码和/或数据的开端。在分段报头中标识的分段可以向加载器告知将组件拷贝至何处。在下文中示出了区段和程序报头的格式。区段报头程序报头
typedef struct {tvpedef struct }
Elf32_Word sh—name;E!f32_Word p—type:
Elf32—Word sh—type;Ei132 0ff p offset:;
Elf32_Word sh flags;Elf32_Addr p vaddr;
Elf32_Addr sh addr:Eif32—Addr p paddr:
E{132_Off sh—offset;ElB2_Word p—filesz:
Elf32_Word sh size;E!f32_Word p—menisz;
Elf32—Word sh—link:Eii32_Word p—flags;
区段报头程序报头
Elf32_Word sh info;E1132_Word p—align;
Elf32_Word sh addraiign ;} Eif32_Phdr;
EI i3 2 Word sh_e ntsize;j Elf32_Shdr;—sh_addr是程序区段可以在目标存储器中驻留的地址。p_addr可以是程序分段在目标存储器中驻留的地址。sh_addi^Pp_paddr字段可以是指加载地址。加载器可以使用来自区段报头的加载地址作为将映像从非易失存储器传送到RAM的起始地址。组件区段标识的概念可被扩展至文件内部包含的一个以上的特定组件。该扩展可以通过识别将被执行完整性检查的特定子例程而不是整个文件来允许策略管理器所实施的访问控制的进一步的粒度。TRV可以是特定组件或对象文件的预期量度(例如采用安全方式计算的组件的散列)。出于完整性核实的目的，举例来说，检验处理可以依靠将被检查的存在于可执行映像中的或是分别以安全方式加载的每一个组件的TRV。该处理可以采用多种方式来实现。作为例证，通过修改构建可执行映像的工具链，可以安全地计算组件或对象文件的散列值，并且安全地将计算得到的TRV插入同一对象文件的恰当区段。该计算可以作为链接过程的一部分来执行。计算TRV散列的顺序可以与加载和量度组件的顺序匹配，否则有可能无法正确匹配量度值。该散列值可以被加载器得到或是包含在可执行映像内部。为了保持信任链，在这里可以安全地生成和/或存储TRV。举例来说，通过使用与诸如软件/固件制造商的公钥之类的公钥相对应的私钥来对TRV值进行签名，可以保护TRV。组件对象文件可以包括单独的用户定义区段，以此作为如图5所示的与之关联的TRV的占位符。举个例子，如图5所示，组件目标文件408的TRV可被计算并保存在组件TRV区段502中。区段报头可以识别该区段的起始地址和/或尺寸，其中所述区段包括这里描述的用户定义区段。在对象文件402上，链接器可以在符号解析阶段结束时计算组件对象文件408的散列值，以及定位相应的组件TRV区段502。该组件TRV可被插入到处于存储器中的指定位置的可执行映像(例如组件TRV区段)。区段报头可以允许加载器在检验处理过程中定位特定区段的TRV。这里描述的设备检验可以关注于组件的完整性状态。由于软件的开发实践有可能会随着公司的不同而不同，因此有可能很难使关于发生故障的软件的报告处理标准化。
在这里公开了用于将对照软件执行的功能来归组组件的方式标准化的系统、方法和手段。通过将功能标准化，可以使其与标准规范相一致和/或采用与实施方式无关的方式。在这里可以为可被标准化的设备功能预先定义一个功能列表。通过使用功能与组件之间的关联，可以允许将完整性检查期间发现的故障映射到特定功能以进行报告，并且在图6中描述了它的一个不例。如图6所示，信任域602可以包括相互映射的组件和功能。例如，可信任域602可以包括高级功能604、中间功能606和/或可信环境(TrE)核心功能608。高级功能604可以包括功能610和功能612。中间功能606可以包括功能614和功能616。TrE核心功能608可以包括功能618，例如RoT。功能612可以映射到组件620和/或622，其中举例来说，该组件可以是软件组件。功能616可以映射到组件624，并且举例来说，该组件同样可以是软件组件。功能618可以映射到组件626，其中举例来说，该组件可以是固件组件。在对可信任域602执行完整性检查期间，在组件624上可能会确定一个故障。由于组件624映射到了功能616，因此可以确定网络功能616同样存在故障。由此，设备可以向网络发送关于发生故障的功能616的指示，以便进行补救。图6的功能与组件之间的映射是作为执行层映射而被示出的。作为图6示出的实施例的替换或补充，组件与功能之间的映射可以具有一个以上的层。可以使用具有两个以上的层的数据结构(例如，其中一个层用于组件，另一个层用于功能)。在该结构中，组件可被映射到一组子功能，并且子功能可以被映射到一组更高级的子功能。中间映射可以持续进行，直至处于最终子功能层的子功能被映射至处于最终层的最终功能。树或类似于树的数据结构可以是能够获取这种多层组件-功能映射关系的结构的一个示例。开发者可以确定组件如何映射至标准化功能。根据一个实施例，可执行映像可以包括组件-功能映射。举例来说，这种映射可以在编译时通过一个图形工具来实现，其中该图形工具对编译代码或源代码进行解析，显示了单个文件布局、文件中的函数相互依存性中的一项或多项，以及允许将组件映射到功能。功能可以是文本字段和/或缩写ID号码，其中所述字段和/或号码可以由用户输入和/或手动映射到组件/文件。开发工具可以创建一个引用了组件-功能映射表的区段。组件名称、功能名称以及ID连同交叉引用的互连一起可以作为所述表的元素而被包含。图7示出的是包含组件-功能映射的区段的一个示例。如图7所示，功能-组件映射区段702可以作为对象文件402之类的对象文件的区段而被包含。此外，如这里所述，功能-组件映射区段702还可以链接到可执行映像中的相应分段。加载器的功能可以是将代码从外部存储器引入内部存储器。信任链可以依靠正由从RoT和引导加载器开始的先前阶段核实的每一个已加载阶段的代码。第二阶段的加载器可以核实下一个阶段，所述下一个阶段则可以包括可信环境核心以及OS加载器。一旦OS被初始化且正在运行，则剩余的完整性检查可以如这里所述由标准的OS加载器执行。可执行映像可以在没有缓存的情况下被加载到RAM。这里公开的这些概念可以扩展成包含更多具有附加修改且可执行映像大于可用ROM的受限实施方式，例如使用缓冲存储器以及直接从ROM执行代码。将代码从外部引入内部存储器的加载器可以包括执行密码加密的完整性检查的能力。所述完整性检查回过来可以引用安全地保持在可信环境中的密码加密功能。在正常的操作中，加载器可以将文本区段410之类的组合文本区段以及数据区段412之类的数据区段中的代码和数据拷贝至链接器命令脚本和分段报头信息定义的内部存储器。与批量加载文本区段410和数据区段412不同，加载器可以识别用户定义的代码和/或数据区段。这其中的一些补充区段信息可用于完整性检查。加载器可以计算组件的完整性量度，然后将组件的TRV定位在与之关联的区段。区段报头可以提供区段的起始地址和大小。量度值可以与同一个组件的已存储TRV相比较。如果值是匹配的，则可以将代码加载到内部存储器。如果完整性量度不匹配，则不能加载代码，并且可以为组件记录故障和/或将故障报告给策略管理器。每一个组件的加载器核实结果可以保存在表明该组件已被检查的比特字段以及通过与否的比特指示中。在将全部代码移至内部存储器时，策略管理器可以基于已完成的完整性检查结果来确定授予设备怎样的访问。一种实现该处理的方式是规定加载器可以访问安全的存储器位置来追踪完整性结果。过程链接表(PLT)可以用附加信息元素增强，以便追踪是否检查并核实了组件完整性，并且在每次将经过检查的组件加载到RAM的时候可以更新完整性检查结果以及所述信息。在具有有限存储器的嵌入式系统中，可以使用代码调换。代码调换可以包括将那些可能用于执行的功能加载到RAM中。如果使用了子组件，那么可以在RAM中未提供所述子组件的情况下使用PLT和GOT表来定位其地址。子组件可以是具有相关联的TRV的较大组件中的很小的部分。在加载子组件时对其进行动态检查的系统中，在每次加载子组件的时候都可以使用关于整个组件的完整性检查。这种需求有可能在系统上添加不必要的计算负担。组件可以分成子组件，并且可以计算一个中间TRV，所述中间TRV可以用于检查每一个子组件的完整性。此外，通过实施最小块尺寸，可以计算出中间散列。这个生成子组件的TRV散列的过程可被称为TRV分解(digestion)。例如，很小的子组件散列可以是基于存储页面块大小计算的。举例来说，这种将组件拆分成子组件的处理可以在对子组件执行作为安装或启动过程的一部分的完整性检查的时候进行。此外，通过增强G0T，可以包含每一个子组件的中间TRV。平台完整性策略引擎(PIPE)可以是整个平台的信任系统架构的一部分。例如，PIPE可以防止下列各项中的一项或多项:网络受到攻击、误用设备、在平台上以未经授权的方式传递或操纵敏感数据。PIPE可以依靠诸如引导加载器、策略管理器和虚拟化组件之类的不同操作系统功能来控制和创建安全可信赖的平台。所述PIPE可以控制不同的功能，这其中包括安全引导处理流程、关于软件组件的完整性检查量度的处理、依照策略的后续强制操作、和/或后续的软件负载控制流程。这些策略可以由外部的利益相关者定义，例如制造商或运营商，并且是可以在设备上供应的。此外，这些策略可以通过远程更新过程而在字段中被更新。PIPE可以通过下列各项中的一项或多项来减小加载受损软件功能的风险:受控软件数据检查和加载操作、渐进式地安装更多的功能能力、或者在运行时保持组件的动态加载。依照加载操作的进度阶段，所述操作可以包括下列各项中的一项或多项:将平台断电；阻止加载一个或多个受损组件或是隔离一个或多个组件；触发针对网络中的安全网关或补救管理器之类的外部实体的警报，以便通告低级故障或是受损功能；禁止访问平台上的安全信息，例如验证密钥等等；禁止访问平台上的安全功能，例如验证算法等等；执行批量代码或数据重载/更新过程；替换受损的软件组件和/或配置数据；或者进行更详细的调查，包括以更高的细节粒度来对疑似受损的组件执行完整性检查，以便隔离组件中的故障位置。在一些情况中，故障有可能非常严重，以至于可信任环境由于核心TrE功能受损而不能保证平台的信任度。低级故障有可能触发诸如产生用可信根签名的默认警报消息之类的基本操作，其中可以包括完整性和回放保护以及机密性保护。换言之，一旦发生了严重的低级安全故障，则可以通过一个或多个可用通信信道来向网络发布遇险消息。由于所加载的功能已被构建并且变得日益复杂，设备有可能执行更复杂的操作，例如充当代表网络实体的安全可信赖代理，这样做可以促成用于诊断、报告和/或替换受损软件或配置数据的询问过程。依照成功核实的功能等级，可以提供针对平台上的资源的不同访问(例如由PIPE)。如果组件的完整性检查失败，那么它可能不是可信的。检测到的这种故障可以被安全标记并指示给网络(显性或隐性)，并且引导流程有可能因为这个发生故障的状况而出现分支。这种完整性检查故障可被称为执行流故障，由此，经过检查的组件可能不是可信赖的，并且启动该组件有可能会导致执行恶意的、受损的、有故障的或是错误配置的代码，而这有可能导致设备以非指定和/或非预期的方式执行网络功能。由此，新组件和可用功能的加载可能受到先前加载的组件的完整性的影响。结果，执行环境有可能根据控制执行过程和/或每一个引导阶段以及每一个运行时处的访问权限而改变。例如，在引导过程中的每一个阶段可以基于在该时间产生的完整性量度来做出决定。后续的阶段和策略可以使用通过任何超越了执行阶段的可用安全信息运送或存储手段而从先前阶段传递的信息(状态、变量、参数、寄存器、文件等等)来确定自己的操作。例如，上层应用验证功能可以使用关于先前加载的组件的完整性的信息来确定自己的操作，其中包括选通释放那些用于与例如外部实体进行成功验证的密钥。例示的PIPE功能流程可以采用这里描述的方式执行。例如，在这里可以对RoT执行完整性检查，和/或其完整性可被核实。RoT可以对基线TrE执行完整性检查，和/或所述基线TrE的完整性可被核实。如果在对基线TrE进行完整性检查和/或核实中发生故障，那么PIPE可以阻止用于附着于网络的密钥的发布，触发针对网络的警报，和/或将设备断电。如果PIPE触发针对网络的警报，则可以加载能向网络发送警报的回退代码。该警报可以触发远程批量更新过程，以便替换TrE。如果在对基线TrE的完整性检查和/或核实中没有发生故障，那么可以加载基本的通信连接代码。这其中可以包括执行完整性检查以及加载基线操作系统模块、执行完整性检查以及加载基线管理客户端、和/或执行完整性检查以及加载通信模块。如果在检查操作系统模块、基线管理客户端和/或通信模块的完整性的同时识别出故障，那么PIPE可以阻止用于附着到网络的密钥的发布，触发针对网络的警报，通过执行远程批量过程来替换组件，执行远程组件更新过程，和/或将设备断电。如果PIPE触发远程批量更新过程，那么可以加载一个能够向网络发送警报的回退代码。该警报可以触发远程批量更新过程，以便替换基本代码。如果在对基本通信连接代码的完整性检查和/或核实中没有出现故障，那么可以对剩余的操作系统及管理客户端组件执行完整性检查和/或加载这些组件。这其中可以包括执行完整性检查和/或加载可重新定位和/或重新加载的功能模块。如果在完整性检查期间识别出故障，那么PIPE可以阻止释放用于附着到网络的密钥，向网络发送依照协议的故障报告，触发警报和/或请求远程更新组件过程，和/或将设备断电。所述故障报告可以指示发生故障的组件，该组件例如可以由网络远程更新。PIPE的操作可以根据成功核实的引导链而改变。在引导过程的每一个阶段都可以基于为在该时间(或是到该时间)被执行了完整性检查的部分或全部底层平台评定的完整性以及所应用的策略来做出决定。这些策略可以根据所实现的信任等级而适配或被其他策略替换。执行环境可以根据每一个引导阶段的控制策略而改变。后续的阶段和/或策略可以使用通过超越了执行阶段的可用安全信息运送或存储手段而从先前阶段传递的信息(例如状态、变量、参数、寄存器、文件等等)。举例来说，如这里所述，PIPE可以在平台上规定策略，其中所述策略可以根据如图8所示的所实现的平台初启和信任状态的等级而进行适配或改变。如图8所示，依照相应的策略812，可以对TrE802执行完整性检查、以及加载和/或执行所述TrE802。在将TrE802确定成是可信实体并且执行所述TrE802之后，设备可以移动到引导序列的下一个阶段。例如，在这里可以依照策略814来对能力804执行完整性检查、以及加载和/或执行所述能力804。关于能力804的完整性检查、加载或执行可以基于与TrE802的完整性检查、加载和/或执行相关联的信息(例如信任状态)。在引导序列先前阶段中实施的策略812可以向在关于能力904的完整性检查、加载和/或执行期间实施的策略814发出通知。在将能力804确定成是可信实体并且执行了所述能力804之后，该设备可以移动到引导序列的下一个阶段。该引导序列可以通过依照相应的策略816、818和820分别检查、加载和/或执行能力806、808和810而继续进行。如这里所述，引导序列的每一个阶段可以由引导序列中的一个或多个先前阶段通知。这里描述的策略可以由运营商之类的可信外部实体规定。所实现平台信任状态的结果可被传递到外部实体，其中举例来说，所述外部实体有合法的兴趣/权利来了解平台的信任状态，诸如敏感应用或服务的运营商或提供者。应该指出的是，对于可以在启动或平台工作循环中的不同阶段评定的有关平台可能的不同状态的信息来说，这些信息可被传递到一个以上的外部实体。多层完整性检查以及将这种完整性检查绑定到平台信任状态的处理可以采用这里描述的方式执行。例如，这种完整性检查和绑定可以使用多层完整性检查，以便通过策略和强制执行来确保设备上的密钥验证设备实现的能力(例如针对网络上的服务器之类的外部核实器且执行补救任务的设备补救功能)。如果某个用于实现预期能力的预先已知的软件和/或配置文件集合通过了完整性检查，那么使用这种密钥来进行验证的安全敏感功能对于设备而言将会是可用的。举例来说，这种软件和/或配置文件可以包括低级OS功能、驱动、配置文件和/或通信堆栈代码的某个子集。多层完整性检查以及完整性检查绑定还可以包括用于保护验证密钥的策略，由此可以将密钥限制成只供已授权功能或过程使用。如果密钥未受保护，那么软件有可能受损害以访问该密钥。通过提供可信功能，设备可以:对密钥进行保护，以使其仅限于供有限集合的能力、功能或单个功能使用；保护对密钥执行操作的功能/程序；和/或限制可以调用这其中的某个特许功能的对象(例如用户、系统、脚本等等)。这里描述的关于多层完整性检查和绑定的实施例可以包括一组预先已知的软件，这些软件可以用于允许可能受损的设备向外部实体验证其部分能力(例如其报告故障以及与补救服务器或是用于此类服务器的AAA实体一起执行补救操作的能力)。外部实体(例如补救服务器)可以是一个逻辑实体，并且可以由设备管理服务器托管，其中对于H(e)NB来说，所述外部实体是H(e)MS。为了提供用于规定与特定平台上的实际实施方式无关的策略的机制，在这里可以通过规定特定平台能力所需要的功能来定义这些策略。由此，与特定能力相对应的策略也可以采用与这里公开的组件-功能映射相似的方式映射到功能。外部利益相关者可以将关于特定能力的策略规定给单个功能或若干个功能。而PIPE则可以在将能力映射到特定策略以及映射到平台初启阶段的过程中负责解释策略需求。如果某个能力使用了某组功能，那么可以为指定给该能力的相应策略规定这些功能。举个例子，如果希望将执行补救的能力映射到某个策略，那么可以将用于执行补救的功能映射到相应的策略，例如，修补能力可以被功能1、2和3覆盖，从而规定将相应的策略映射到功能1、2和3。对于一些实施方式来说，在分层的平台初启与能力和功能之间存在着合理的相关等级。这些能力可以是随着功能一层一层地渐进式初启的。例如，在平台初启的较早阶段即可初启补救功能和能力。多层完整性检查可不按顺序确定不同功能的已检查-未检查状态。这些功能可以是依照顺序方式检查的。然而，由于不同的功能可被映射到不同的组件(随后可以在不同的阶段加载这些组件)，因此，依照功能的完整性确定处理有可能会以非顺序方式执行，或者以一种可不与依照组件的完整性检查的原子处理序列同步(在时间长度或时间顺序方面)的顺序方式执行。序列化可被用于策略实施。策略实施可以为给定的平台能力确定相应的功能是否通过了完整性检查和/或是否应该应用策略。多范围验证可以允许平台基于所实现的平台信任等级来向一个或多个外部实体进行验证。该验证机制(例如验证询问响应机制)可被用作一种将最终得到的设备完整性范围传达给外部实体的手段。所述外部实体可以验证并且同时获取关于设备完整性范畴/范围的指示。在经历多层完整性检查的同时，设备的TrE可以生成用于验证询问响应的不同参数或参数值，以便用于不同的目的。根据成功的完整性检查的范围，这种生成参数的处理可以基于或使用与外部验证实体共享的相同的秘密证书。所使用的可以是常见的询问-响应计算算法。然而，根据完整性检查的范围和/或验证目的，至这种算法的输入可能是不同的。举个例子，如果TrE成功检查了整个代码库，那么可以使用诸如“已成功检查整个代码库(entire code basis successfully checked)”之类的文本串作为验证询问响应计算算法的输入。如果TrE成功检查了用于实现遇险补救功能的组件，但是未必检查了整个代码库，那么可以使用诸如“已成功检查用于遇险补救的代码库(code base for distressremediation successfully checked)”之类的另一个字串。一旦向设备发送了其验证询问请求，则外部验证器还可以计算两个版本的“预期”询问响应。由于其可能不知道在计算设备上计算询问响应的过程中使用的输入，因此，它有可能需要同时计算所有这两个版本的响应。通过将接收自设备的响应与预期响应集合相比较，外部验证器可以隐性地成功测试出设备完整性“范围”。通过归纳，实体可以验证和/或核实在设备端成功检查了设备完整性的某个“范围”。在以上的示例中可以使用相同或相似的实施方式来验证设备的另一个特定(例如部分)能力，这一点取决于对功能进而是用于实现该功能的组件所进行的完整性检查。举个例子，可被核实信任度的外部指示可以是在安全引导处理期间将代码的完整性量度绑定到特定的引导循环执行和配置签名的受保护的签名证书版本。在这里可以包括安全的时间戳、受保护的依照引导循环递增的单调计数器、或引导循环秘密(例如现时(nonce)之类的在每个引导循环中生成或引入一次的隐藏随机值)。当满足前提条件时，验证密钥将会变得可用，并且当前的可信赖处理将会设置逐次引导的受保护一次性可编程“通过”标记，其中该标记可被限制成在下一次复位之前恢复至发生故障的状况(例如检测到初始量度之后的故障的时候)。在发布给外部实体之前，诸如TrE之类的永久性可信任环境(例如进入运行时而不仅仅是引导时)可以使用验证协议现时来对状态信息进行签名。所述报告的区段可以由通过永久性核实的可信赖处理使用临时引导密钥来签名，由此，以后的处理可以将该状态呈现给外部实体，以便进行检验。在这里可以使用在验证协议中交换的一个或多个经过修改的随机现时，并且这种经过修改的现时可被用作询问响应以及所预期的询问响应计算的输入。换言之，在设备本身，设备的TrE可以尝试以常规方式使用在响应计算输入(例如在通过了完整性检查的情况下)中从验证服务器接收的一个或多个随机现时来计算其验证响应。如果关于整个设备的完整性检查失败，但是设备部分功能的完整性检查成功，例如“遇险/补救功能”的完整性检查成功，那么TrE可以计算该响应的另一个值，此时使用的将会是所接收的现时的修改版本。验证服务器可以知道在哪里/如何执行这种修改。关于这种修改的示例可以包括:改变初始现时中的已知位置的一个或多个比特。这样一来，除了计算初始的“设备验证”响应之外，设备和验证服务器都可以使用经过修改的现时输入来计算响应。在接收机上(例如验证服务器)，服务器可以检查它从设备接收的响应是否与“设备验证”响应相匹配。如果它们不匹配，则与声明验证彻底失败不同，验证服务器可以将接收到的响应与使用经过修改的现时计算的另一个响应值相比较。如果它们匹配，那么验证服务器可以确定虽然设备整体可能没有通过验证，但是某些功能是可以通过验证的，例如本示例中的“遇险/补救功能”。在安全引导处理期间，通过对照相应的TRV来比较每一个软件组件，设备可以获悉组件的完整性故障，这样做有助于确保组件的比特精度以及源的真实性。检测到的组件检查故障可以在完整性检查状态信息元素中获取。出于安全性目的以及出于对报告和诊断效率的考虑，该状态数据的结构可以采用多种形式。该信息可以被支持策略管理过程的当前和后续引导阶段以及运行时进程读取。组件-功能映射可以用于确定组件与网络功能以及设备的其他功能的依存关系。功能可以是网络运营商之类的连接实体或是移动支付之类的设备支持的增值应用所依靠的功能。运营商和/或应用服务提供者可以定义哪些功能可被用于针对特定任务的可信设备操作，例如承载业务量、补救、管理操作或增值应用特征，并且可以在设备上设置用于表明哪些功能可用于特定网络操作的策略。一组网络功能可以来自网络运营商和/或应用服务供应商所预期的标准能力集合。这些功能可以包括无线电技术、协议堆栈中的层、网络协议、管理能力、安全和信任机制、增值应用特征等等。设备的策略管理器可以使用显示了依照设备组件的网络功能依存关系的嵌入式组件-功能表或映射(如这里所述)。在图9中显示了在完整性检查和/或报告期间使用这种组件-功能表或映射的处理。如图9所示，在910，设备可以通过使用相应的TRV904检查组件902的完整性量度来执行完整性检查。在执行了完整性检查之后，在916，设备策略管理实体908可以接收到一个或多个已经经过了完整性检查的组件的组件标识符(例如组件地址)，并且会在918接收到关于每一个组件是否通过完整性检查的指示。该策略管理实体908可以确定与组件相关联的相应功能，以便发送至网络实体。举例来说，发生故障且需要补救的功能可被发送，或者可以发送关于已被检验的功能的指示。例如，策略管理实体908可以使用处于920的组件地址来检索处于922且与所给出的组件相对应的组件标识符。如图9所示，组件标识符可以是从表906中检索的，其中所述表包含了组件地址到组件标识符的映射。策略管理实体908可以使用处于924的组件标识符来检索处于926且与所给出的组件相对应的组件功能。这些组件功能可以是从表912中检索的，其中所述表包含了组件标识符-组件功能的映射。在932，策略管理实体908可以使用所确定的功能(例如通过或未能通过完整性检查)来与网络实体进行交互。例如，策略管理实体可以执行完整性报告，接收设备策略，或者接收与所确定的一个或多个功能相对应的操作和/或限制。每一功能可与一个或多个策略930相关联。所收集的一个或多个功能可以一起启用设备内部的特定功能。这些能力可以是分层次的。例如，基础层能力可以是下一个能力层的子集，该下一个能力层则是接下来的能力层的子集等等。将能力分层的处理可以反映典型的以层或信任链为基础的安全引导序列。层可以是能够实现特定能力的功能的任意组合，或者它也可以是分层的层次与特定功能组合的混合组合。策略管理实体908可以使用处于928的组件映射功能来检索处于930且与给定能力相对应的一个或多个策略。这些策略可以是从表914中检索的，其中所述表包括能力与不同策略的映射。如932所示，这些策略可以是从网络实体接收的。发生故障的组件可能导致出现一个或多个发生故障的功能。软件开发和构建工具嵌入的组件-功能映射信息可以在确定功能的完整性检查故障量度的过程中为策略管理器提供支持，并且由此支持以标准化的方式报告可能与设备和制造商方面的实施方式无关的故障，例如验证功能或基带无线电协议堆栈故障。在设备上，该信息可以可被保护免于修改，这一点是由不可变的可信根(RoT)保证的。策略管理进程可以在引导和运行时环境中使用该信息。通过使用完整性检查处理的结果，设备上的策略管理进程可以确定哪一个网络功能发生故障。在加载器检查代码的时候，组件可以用一个在引导时间期间可用的引用(例如符号表或存储地址)来识别。在核实了完整性和源的真实性之前，被检查的代码可被隔离，以免在可执行存储器中使用。同样，从加载、检查被检查的代码时起以及在执行过程中，所述被检查的代码可以受到保护(例如通过以受保护的方式执行和存储，硬件保护，密码加密保护，虚拟化等等)。通过修改存储器映射、访问权限等等，可以阻止执行过程。作为在图9的表906和912中示出的示例，处于地址位置X的代码可以对应于组件A，所述组件可以映射到网络功能F1、F5和F14。举例来说，这个代码可以是一个原始的散列函数，并且有若干个通信协议是依赖于该函数的。完整性报告和补救有可能依赖于发生故障的基元。因此，在网络标准化列表中可以包含这些完整性报告和补救功能，以此作为底层的支持功能。功能故障的标准化列表可以向网络提供关于设备能力的细粒度信息。对于远端设备来说，可靠地理解设备所能实现的功能有助于应用资源来补救问题。在遇险情况下，如果有能力以安全和有保证的方式指示故障，从而使得网络可以检验遇险指示本身(例如源、时间和精度)的完整性，那么可以防止在虚假警报的情况下不必要地使用昂贵的网络资源。图10提供的是包含了例示系统组件的报告和补救系统的例示综述。如图10所示，在1002，在设备1004的组件上检测到故障。该故障可被指示给网络。例如，在1008，所述故障可以包含在报告给网络的设备报告1006中。举例来说，该故障可被指示成是与发生故障的组件相关联的发生故障的网络功能。在向网络报告故障时，网络可以做出关于访问控制的细粒度决定。例如，网络平台检验实体1010可以基于所报告的功能检查报告1006来允许禁止访问、局部访问或是完全访问。在1016，设备1004可以接收访问决定。如果在设备报告1006中指示了故障，那么网络平台检验实体可以将功能报告传送给设备管理服务器1012，所述服务器可以从功能-组件映射信息1014中确定一个或多个发生故障的组件。该信息可以用于补救设备1004，以及重新加载设备1004中发生故障的软件组件。例如，设备管理服务器1012可以在1018询问设备1004，以便窄化与发生故障的组件相关联的发生故障的功能的范围。在将完整性故障隔离到设备1004的某个区段以便实施有效补救之后，设备管理服务器1012可以在1020请求软件更新(例如替换组件)，例如从代码构建发布实体1022请求。设备管理服务器1012可以在1024向设备1004提供软件更新，以便补救发生故障的组件。这种制造商设备上的特定故障代码的抽象形式将会减小运营商紧密了解设备(与之相连)的负担，但是与此同时还可以允许基于发生故障的功能的粒状访问控制及补救决定。执行流程故障有可能是在处理链中调用的组件的故障。组件的执行可以保持很高的确信等级，同时扩展设备的能力。在当前已被核实的处理检查下一个处理的代码(并且有可能检查设备配置)的完整性并且发现其出现故障的时候，这时有可能检测到执行流程故障。后续引导代码中的故障有可能意味着当前可信处理可以执行下列各项中的一项或多项:将当前状态锁定成最后一个已知的良好状态；指示故障；将对于处理的控制保持在等待模式中；将控制权传递到遇险处理；和/或将控制权传递到不可信赖的处理。用于发生故障的阶段的验证和身份密钥可被锁定来避免进一步处理，以使不可信赖的处理无法通过报告(例如带签名的状态)或是验证技术(例如自主检验)来向网络指示有效状态。出于对效率的考虑，从设备发送到网络的故障报告可以包括用于提示来自运营商网络检验功能的操作以执行细粒度网关访问控制以及向网络设备管理实体指示设备故障的最低限度的信息量。管理实体可以通过查看制造商专用信息来确定故障的根本原因，以及确定哪些代码可被补救。该管理实体可以向网络检验功能反向提供进一步的信息，以便允许实体做出关于访问控制和/或补救的进一步策略决定。在下表I中描述了可以包含在故障报告中的发生故障的功能的例示集合。
权利要求
1.一种方法，该方法包括: 对关联于无线通信设备的组件执行第一完整性检查； 确定该组件未能通过所述第一完整性检查； 向网络实体发送对与发生故障的所述组件相对应的功能的指示； 从所述网络实体接收对所述发生故障的组件执行第二完整性检查以便确定所述发生故障的组件中导致该组件未能通过所述第一完整性检查的部分的请求；以及 对所述发生故障的组件执行所述第二完整性检查，以便隔离所述发生故障的组件的所述部分，从而由所述网络实体进行补救。
2.根据权利要求1所述的方法，该方法还包括: 向所述网络实体发送对与所述发生故障的组件中导致该组件未能通过所述第一完整性检查的部分相对应的功能的指示； 从所述网络实体接收对所述发生故障的组件的所述部分执行一次或多次所述第二完整性检查迭代的请求；以及 对所述发生故障的组件的所述部分执行一次或多次所述第二完整性检查迭代，以便进一步隔离所述发生故障的组件的所述部分，以便由所述网络实体进行补救。
3.根据权利要求1所述的方法，其中所述指示包括警报，该警报被配置成触发与所述网络实体进行的远程更新过程，以便替换所述发生故障的组件的所述部分。
4.根据权利要求1所述的方法，该方法还包括:基于保存在所述无线通信设备处的组件-功能映射来确定与所述发生故障的组件相对应的功能。
5.根据权利要求1所述的方法，其中所述指示被安全地发送至所述网络实体。
6.根据权利要求1所述的方法，其中确定所述组件未能通过所述第一次完整性检查还包括: 确定与所述组件相关联的完整性量度； 将该完整性量度与关联于所述组件的可信基准值相比较；以及 确定所述完整性量度与所述可信基准值不匹配。
7.根据权利要求1所述的方法，该方法还包括: 接收与所述发生故障的组件的所述部分相关联的替换组件；以及 用所述替换组件来替换所述发生故障的组件的所述部分。
8.根据权利要求7所述的方法，其中所述发生故障的组件的所述部分是用使用了其他通过了所述第一完整性检查的与所述网络设备相关联的组件的替换组件来替换的。
9.根据权利要求1所述的方法，该方法还包括:在所述确定所述组件未能通过所述第一完整性检查时，阻止释放用于附着于所述网络实体的密钥。
10.根据权利要求1所述的方法，其中所述发生故障的组件是在多阶段的安全引导处理期间确定的。
11.根据权利要求1所述的方法，其中所述网络实体包括设备补救服务器，并且其中所述指示被直接地或者经由网络发送到所述设备补救服务器。
12.根据权利要求1所述的方法，其中所述第一完整性检查和所述第二完整性检查是在可信任环境中执行的。
13.根据权利要求1所述的方法，其中所述功能与将基于所述第一完整性检查的结果来应用的网络策略相关联。
14.根据权利要求1所述的方法，其中所述功能通过与至少一个其他无线通信设备上的至少一个其他组件相关联而在多个无线通信设备上被标准化。
15.—种系统,该系统包括: 加载器，被配置成:对与无线通信设备相关联的组件执行第一完整性检查；确定该组件未能通过所述第一完整性检查；以及对发生故障的所述组件的部分执行第二完整性检查，以便隔离所述发生故障的组件的部分，从而由网络实体进行补救；以及 平台完整性策略引擎(PIPE)，被配置成:接收来自所述加载器的对所述发生故障的组件的指示；接收与所述发生故障的组件相对应的网络功能；向网络实体报告对与所述发生故障的组件相对应的功能的指示；以及从所述网络实体接收对所述发生故障的组件执行第二完整性检查以便确定所述发生故障的组件中导致该组件未能通过所述第一完整性检查的部分的请求。
16.根据权利要求15所述的系统，其中所述加载器还被配置成执行以下处理来确定所述组件未能通过所述第一完整性检查: 确定与所述组件相关联的完整性量度； 将所述完整性量度与关联于所述组件的可信基准值相比较；以及 确定所述完整性量度与所述可信基准值不匹配。
17.根据权利要求15所述的系统，其中所述PIPE还被配置成在从所述加载器接收到对所述发生故障的组件的指示时执行下列各项中的一项或多项:将所述系统断电、阻止加载所述发生故障的组件、阻止访问用以向所`述网络实体验证所述无线通信设备的验证密钥、或者阻止访问安全功能。
18.根据权利要求15所述的系统，其中所述PIPE还被配置成核实设备管理功能，该设备管理功能被配置成:接收来自所述网络实体的替换组件；以及使用所述替换组件来替换所述发生故障的组件的所述部分。
19.根据权利要求15所述的系统，其中所述PIPE还被配置成接收来自外部实体的策略，并且将所述网络功能映射到所述策略中的一者或多者，其中所述策略被配置成基于所述第一完整性检查的结果来应用。
20.一种驻留在无线通信网络上的设备补救服务器，被配置成补救无线通信设备上的未能通过完整性检查的组件的部分，其中所述设备补救服务器被配置成: 从所述无线通信设备接收对与该无线通信设备上的未能通过所述完整性检查的组件相关联的网络功能的指不; 基于接收到的对所述网络功能的指示来确定发生故障的所述组件； 执行向所述无线通信设备的询问，以便隔离所述发生故障的组件的部分来进行补救； 基于一个或多个标准来确定用于所述发生故障的组件的所述部分的修复或替换；以及 将对所述发生故障的组件的所述部分的修复或替换发送到所述无线通信设备。
21.根据权利要求20所述的设备补救服务器，其中对所述发生故障的组件的所述部分的修复或替换包括软件代码。
22.根据权利要求20所述的设备补救服务器，其中该设备补救服务器还被配置成接收表明与所述完整性检查相关联的信息可靠的指示。
全文摘要
一种无线通信设备，其可以被配置成执行完整性检查和向网络实体的询问，来隔离无线通信设备上的发生故障的组件的部分来进行补救。一旦确定了设备的组件上的完整性故障，则设备可以识别与该组件相关联的功能，并且向网络实体指示该发生故障的功能。无线网络设备和网络实体都可以使用组件-功能映射来识别发生故障的功能和/或发生故障的组件。在接收到设备处的完整性故障的指示之后，网络实体可以确定在设备处执行一个或多个附加的完整性检查迭代，以便窄化发生故障的组件上的完整性故障的范围。一旦隔离了完整性故障，则网络实体可以修复无线通信设备上的发生故障的组件的部分。
文档编号G06F21/10GK103202045SQ201180053416
公开日2013年7月10日 申请日期2011年11月4日 优先权日2010年11月5日
发明者Y·C·沙阿, L·凯斯, D·F·豪利, I·查, A·莱切尔, A·施米特 申请人:交互数字专利控股公司