CN110263545B - 一种基于Android***的启动过程完整性度量检测方法 - Google Patents

Abstract

本发明公开了一种基于Android***的启动过程完整性度量检测方法，从加电开始，可信度量根CRTM引导Bootloader并验证其完整性，采用安全散列算法SHA‑1对Bootloader运算，将得到的实际度量值与RIM证书中的RIM值进行比对，如果对比结果一致，将结果存入平台配置寄存器存储可信根中；然后CRTM将控制权移交给Bootloader；在Bootloader度量内核过程中，利用信任度量模型得出对于内核的综合度量值TValue，最终达到整个Android***的可信。本发明解决了现有技术中存在的可信计算中完整性度量架构过于复杂、难以扩展以及没有体现行为可信的问题。

Description

一种基于Android***的启动过程完整性度量检测方法

技术领域

本发明属于移动智能终端技术领域，具体涉及一种基于Android***的启动过程完整性度量检测方法。

背景技术

Android***是目前应用最广泛的移动操作***。Android***最大的特点是具有较强的开放性，各个厂家都可以根据自己需求来定制***；第三方应用的安装比较便捷，没有太多限制，这一点也是促使安卓***持续发展的核心因素。而Android移动智能终端在为用户提供便利的同时，也造成了严重的安全隐患，比如：终端存储的个人信息、密码等已经成为攻击者的主要目标，短信内容、联系人列表、通话记录等信息容易被窃取。Android应用程序是以消息驱动起来的，驱动起来的应用程序离不开触摸机制的配合，由此可见触摸机制在Android***中占有举足轻重的地位。从2010年发现首个Android木马程序以来，Android下的恶意软件数量急速增长，给用户的数据安全带来难以预测的风险。伴随着Android***恶意代码的增多，触摸机制就成为攻击者选择的对象。触摸机制是操作所有客户端应用程序的前提，因此，检测触摸机制核心代码的完整性，可以有效的防止触摸机制植入恶意代码，保证用户数据的安全性。Android***中的恶意代码往往不会让用户轻易发现，通常将恶意代码植入***层，比运行在应用层的恶意软件更具有隐蔽性。更有严重的会对手机的硬件设备进行调用，进行偷拍、录音录像等等。因此，对于提高Android***的安全性、防止隐私信息泄露给用户带来重要的意义。

可信计算(Trusted Computing)是在计算和通信***中广泛使用基于硬件安全模块支持下的可信计算平台,以提高***整体的安全性。可信计算的概念最早出现在美国的彩虹系列信息***安全的相关文件中，世界领先的IT巨头企业IBM、惠普、英特尔以及微软联合发起并建立了可信计算平台联盟(Trusted Computing Platform Alliance,简称为TCPA),可信计算平台联盟的成立也标志着可信计算技术的基础研究和产业化进入一个全新的发展阶段。在2003年,可信计算平台联盟改名并重组成为可信计算组织(TrustedComputing Group,简称为TCG),可信计算组织的出现同时也推动了可信计算技术研究和应用想着更高层次发展。可信计算平台联盟和可信计算组织自成立以来已经研究并确定了多种关于可信计算平台、可信存储以及可信网络连接等关于可信计算技术规范。

可信计算技术属于一种全新的信息***安全技术，在Android移动智能终端中应用的原理是把安全芯片架构引入到移动终端的硬件平台上，从而提高安卓终端的安全性和可靠性，这一点正好弥补了Android***开放特性带来的缺陷。大量应用实例表明，可信移动平台的研发是可信计算技术发展的里程碑，Intel和IBM公司在2004年就提出了可信移动平台的研发，并设立相应协议，大大提高了移动智能终端的安全性。就其结构特性而言，可信移动平台是一种具有密码运算能力和存储功能的***，通过加密、认证、密钥等体系进一步保证移动智能终端的安全性，可有效解决Android移动智能终端一直面临的安全问题。

发明内容

本发明的目的是提供一种基于Android***的启动过程完整性度量检测方法，解决了现有技术中存在的可信计算中完整性度量架构过于复杂、难以扩展以及没有体现行为可信的问题。

本发明所采用的技术方案是，一种基于Android***的启动过程完整性度量检测方法，包括以下步骤：

从加电开始，可信度量根CRTM引导Bootloader并验证其完整性，Bootloader是***启动前的引导程序；

采用安全散列算法SHA-1对Bootloader运算得到实际度量值，将得到的实际度量值与RIM证书中的RIM值进行比对，如果对比结果一致，将结果存入平台配置寄存器存储可信根中；

然后CRTM将控制权移交给Bootloader；若比对结果不同，则开机失败，并将检验报告发送给用户。

在Bootloader度量内核的过程中，利用信任度量模型得出对于内核的综合度量值TValue，根据可信度阙值Tm，做出相应的信任决策，可信度阙值Tm用来作为信任决策的评判标准，如果***内核是可信的，则TValue>Tm，则将结果存入平台配置寄存器存储可信根中，随后将控制权交给***内核，否则***无法继续启动，并将检验报告发送给用户，按照上述同样的方法，再对Android操作***以及第三方应用程序进行度量，最终达到整个Android***的可信。

本发明的特点还在于，

移动可信模块MTM规范了若干可信根，包括度量可信根RTM、存储可信根RTS、报告可信根RTR，其中RTM作为一个软件模块存入只读ROM中，在***加电后第一个被执行且不可以被修改，用于MTM作为可信度量和验证的起点，存储可信根RTS和报告可信根RTR作为硬件模块包含于MTM之中，用于完整性存储和报告，MTM中还定义了参考完整性度量值RIM和RIM证书，RIM的值是要对实体的度量摘要，是提前写入信任根的安全存储区，是该实体符合期望的基准值，为每次***完整性验证提供了参考依据，RIM证书是一个经过数字签名的完整性保护结构，里面包含着RIM的值，数字签名以及相关的一些附加信息。

存储可信根RTS由可信平台度量配置寄存器PCR构成，PCR为160比特的存储位置，寄存器个数最少为16个，都存储在移动可信模块之中，它允许存储无限数量的度量值，还保持着度量的顺序，PCR保存着所有当前已经产生的度量值SHA-1的累积哈希值，160位的累积HASH值表示所有被度量过的组件完整性的状态。

信任度量模型表示为{V,E}，其中V表示节点集合，E表示边集合，节点集合V为有限集合{rt,T}，rt表示根目标，即rt表示为{TValue,TCount}，TValue表示对各子目标度量完成后得到的综合度量值，TCount表示子目标的个数，TCount取值为{0…m}，当TCount＝0，即为需要度量的最小目标，不可再分，目标集合T＝{t1,t2,…tn},t＝{Name,Type,TValue,TCount}，Name表示目标的名称，Type表示目标类型，边集合E为组合关系，边集合E代表权重值，权值的取值范围[0，1]，且满足归一条件。

步骤1中度量具体如下：

在Bootloader运行的过程中，Bootloader将***内核映像ZImage和根文件***映像Ramdisk.img从flash读到ARM中，当前控制权在Bootloader，对内核进行度量：将需要度量的***内核设置为根目标rt，Android源码编译完成后产生ZImage、System.img、Ramdisk.img、Userdata.img、Recovery.img镜像，上述镜像包含Android启动与运行所需的文件与相关库，因而，对***内核进行度量，即是对产生的所有镜像进行度量，在度量***内核的过程中，将System.img、Ramdisk.img、ZImage、Recovery.img、Userdata.img镜像作为根目标的子目标；

不同镜像的重要程度以及受到入侵的可能性各不相同，因而对不同镜像应赋予不同的权值，ZImage是内核映像，System.img为***镜像，用于存储Android***的重要文件，包括包和库文件，内存磁盘文件Ramdisk.img存储Linux内核启动时所要装载的文件，Recovery.img镜像只用于刷机，Bootloader根据用户选择进入相应模式，不同模式均包含ZImage和Ramdisk.img文件，Userdata.img是用户数据镜像，存储和用户相关的数据，确定Android设备内存的大小；

根据上述各镜像重要程度以及面临风险的程度，设ZImage分配的权值为w1，设System.img分配的权值为w2，设Ramdisk.img分配的权值为w3，设Recovery.img分配的权值为w4，设Userdata.img分配的权值为w5，则对应权值的关系应为：

w1+w2+w3+w4+w5＝1；

w1>w2>w3>w4>w5；

所述内核镜像ZImage包含的子文件均为***核心文件，因而在度量时将ZImage镜像整体度量；

所述System.img镜像包含如下子目录文件：app、bin、etc、fonts、framework、lib、media、priv-app、tts、usr以及vendor，度量时对这些目录的权重分配进行分析：

各目录的权值分配顺序为：

framework>priv-app>app>xbin＝bin＝lib>etc>fonts＝tts＝media＝user＝vendor

Ramdisk.img中包含一些很重要的配置文件和内核启动完后加载的第一个进程init，init会分别解析init.rc和init.goldfish.rc配置文件初始化并装载***库、程序直到开机完成，init进程还负责创建***中包括Zygote进程在内的几个子进程，Zygote进程是所有JAVA进程的父进程，init动作执行分为四个时间段：early-init、init、early-boot、boot，根据配置文件在开机启动过程中被解析的顺序分配其权重值大小，分配的顺序为：

init.rc>init.goldfish.rc>ueventd.rc>init.environ.rc>init.usb.rc>init.trace.rc

因为Recovery.img由ZImage和Ramdisk.img构成，ZImage部分和正常启动的内核镜像是相同的，因此只需度量其自身的Ramdisk.img镜像即可，度量权重分配和上述一致，对于Userdata.img，只需度量与用户应用程序无关的nativebenchmark文件作为Userdata.img的度量值；

分配各个镜像对应的子目录的权重后，对一级子目录进行分别度量，度量结果用e_i表示，其中i表示一级子目录的个数，若子目录度量结果与参考性完整度量值相同，则对应子目录的度量结果为1，否则结果为0，将子目录对应的权重表示为a_i，其中i表示一级子目录的个数，则综合度量值TValue：

TValue＝∑e_i*a_i

对于二级目录的情况，采用类似上述描述的办法进行度量。

本发明的有益效果是，一种基于Android***的启动过程完整性度量检测方法，将可信度量机制与Android平台相结合，在分析完整性度量机制的基础上，对可信的概念进行扩展，引入信任度量机制，在***中增加安全芯片作为可信根，采用逐级度量方式构建信任链，进而把这种信任拓展到整个Android终端，确保信息***安全。在逐级度量的过程中，根据模型计算出度量目标的综合信任度，并将综合信任度与可信度阙值进行比对，若高于可信度阙值，则将控制权交给度量目标，否则***启动失败，并将检测报告结果告知用户，与TCG的完整性度量模型的二进制度量结果相比，其有着更好的可扩展性与可适用性。

附图说明

图1是本发明一种基于Android***的启动过程完整性度量检测方法中Android启动过程流程图；

图2是本发明一种基于Android***的启动过程完整性度量检测方法中基于可信移动模块的信任链传递过程；

图3是本发明一种基于Android***的启动过程完整性度量检测方法中提出的改进度量模型。

具体实施方式

下面结合具体实施方式对本发明进行详细说明。

本发明一种基于Android***的启动过程完整性度量检测方法，将可信度量机制与Android平台相结合，能有效的判断Android代码的完整性和安全性，接下来将做出详细的说明：

目前Android智能终端安全系数比较低，为了采用可信计算技术进行安全加固，还需要在Android智能终端增设MTM(Mobile Trusted Module)可信模块，由于Android***普遍具有体积小，能耗低等特点，因此在增设MTM可信服务体系可以通过TF卡进行扩展存储处理，可以采用基于TF接口的MTM对Android智能移动终端体系进行可信计算改造，满足安全加固的需求。

大量实例表明，基于MTM信任链传递技术(如图2所示)是可信计算技术保证Android***的完整和安全性的主要技术，合理地利用信任链技术，可以将可信计算平台的信任关系从可信度量根扩展到整个Android终端***之中。移动端信任链是以MTM移动可信模块为核心，起点为核心信任根模块CRTM(core root of trust moudle)，CRTM是***加电之后运行的第一道程序，是一段简单可控的代码模块，认为其完全可信。

本发明一种基于Android***的启动过程完整性度量检测方法，包括以下步骤：

如图1所示，从加电开始，可信度量根CRTM引导Bootloader并验证其完整性，Bootloader是***启动前的引导程序；

采用安全散列算法SHA-1对Bootloader运算得到实际度量值，将得到的实际度量值与RIM证书中的RIM值进行比对，如果对比结果一致，将结果存入平台配置寄存器存储可信根中；

然后CRTM将控制权移交给Bootloader；若比对结果不同，则开机失败，并将检验报告发送给用户。

在Bootloader度量内核的过程中，利用信任度量模型得出对于内核的综合度量值TValue，根据可信度阙值Tm，做出相应的信任决策，可信度阙值Tm用来作为信任决策的评判标准，如果***内核是可信的，则TValue>Tm，则将结果存入平台配置寄存器存储可信根中，随后将控制权交给***内核，否则***无法继续启动，并将检验报告发送给用户，按照上述同样的方法，再对Android操作***以及第三方应用程序进行度量，最终达到整个Android***的可信。

其中，移动可信模块MTM规范了若干可信根，包括度量可信根RTM、存储可信根RTS、报告可信根RTR，其中RTM作为一个软件模块存入只读ROM中，在***加电后第一个被执行且不可以被修改，用于MTM作为可信度量和验证的起点，存储可信根RTS和报告可信根RTR作为硬件模块包含于MTM之中，用于完整性存储和报告，MTM中还定义了参考完整性度量值RIM和RIM证书，RIM的值是要对实体的度量摘要，是提前写入信任根的安全存储区，是该实体符合期望的基准值，为每次***完整性验证提供了参考依据，RIM证书是一个经过数字签名的完整性保护结构，里面包含着RIM的值，数字签名以及相关的一些附加信息。

存储可信根RTS由可信平台度量配置寄存器PCR构成，PCR为160比特的存储位置，寄存器个数最少为16个，都存储在移动可信模块之中，它允许存储无限数量的度量值，还保持着度量的顺序，PCR保存着所有当前已经产生的度量值SHA-1的累积哈希值，160位的累积HASH值表示所有被度量过的组件完整性的状态。

然而由于Android***文件众多，对于Android的硬件抽象层(HAL)，其目的在于将硬件抽象化，为了保护硬件厂商知识产权，隐藏了特定平台的硬件接口细节。由此可见，不同的硬件厂商对于硬件抽象层的相关文件代码各不相同，对于不同硬件厂商的Android移动终端需要的参考性完整度量值各不相同，因而使得原有的可信度量机制的可扩展性弱。同样的，源码/system/core/init下的logo.c以及framworks/base/cmds下的bootanimation的作用是设置开机动画，不同的移动终端设备对应的开机动画也是各不相同，对于厂商的这些改动，我们依然认为该移动终端是可信的。

如图3所示，信任度量模型表示为{V,E}，其中V表示节点集合，E表示边集合，节点集合V为有限集合{rt,T}，rt表示根目标，即rt表示为{TValue,TCount}，TValue表示对各子目标度量完成后得到的综合度量值，TCount表示子目标的个数，TCount取值为{0…m}，当TCount＝0，即为需要度量的最小目标，不可再分，目标集合T＝{t1,t2,…tn},t＝{Name,Type,TValue,TCount}，Name表示目标的名称，Type表示目标类型，边集合E为组合关系，边集合E代表权重值，权值的取值范围[0，1]，且满足归一条件。

步骤1中度量具体如下：

在Bootloader运行的过程中，Bootloader将***内核映像ZImage和根文件***映像Ramdisk.img从flash读到ARM中，当前控制权在Bootloader，对内核进行度量：将需要度量的***内核设置为根目标rt，Android源码编译完成后产生ZImage、System.img、Ramdisk.img、Userdata.img、Recovery.img镜像，上述镜像包含Android启动与运行所需的文件与相关库，因而，对***内核进行度量，即是对产生的所有镜像进行度量，在度量***内核的过程中，将System.img、Ramdisk.img、ZImage、Recovery.img、Userdata.img镜像作为根目标的子目标；

不同镜像的重要程度以及受到入侵的可能性各不相同，因而对不同镜像应赋予不同的权值，ZImage是内核映像，System.img为***镜像，用于存储Android***的重要文件，包括包和库文件，内存磁盘文件Ramdisk.img存储Linux内核启动时所要装载的文件，Recovery.img镜像只用于刷机，Bootloader根据用户选择进入相应模式，不同模式均包含ZImage和Ramdisk.img文件，Userdata.img是用户数据镜像，存储和用户相关的数据，确定Android设备内存的大小；

根据上述各镜像重要程度以及面临风险的程度，设ZImage分配的权值为w1，设System.img分配的权值为w2，设Ramdisk.img分配的权值为w3，设Recovery.img分配的权值为w4，设Userdata.img分配的权值为w5，则对应权值的关系应为：

w1+w2+w3+w4+w5＝1；

w1>w2>w3>w4>w5；

每个镜像中又包含了各个文件目录，不同的目录对应于Android中不同的功能，在确定权重值时，应考虑以下两个因素：

一是对判断***可信的重要程度，重要性越高，具有的权值也就越大.

二是判断其独立性，独立性越大，且其他文件对它有依赖关系，则具有较大权值。

所述内核镜像ZImage包含的子文件均为***核心文件，因而在度量时将ZImage镜像整体度量；

System.img镜像包含如下子目录文件：app、bin、etc、fonts、framework、lib、media、priv-app、tts、usr以及vendor，度量时对这些目录的权重分配进行分析：

大量的底层攻击发生在Android的Framework层，例如触摸事件的隐私获取，通过修改Framework层源码，达到隐私窃取的目的。而这些改变将会引起System.img镜像Framework目录下framework.jar文件的改变，因而对于System.img文件下的Framework目录我们应分配高权值。priv-app和app分别存放着***核心的apk文件和应用程序，恶意软件会安装在这两个文件目录下成为***级应用程序。此外，Root病毒将会注入elf文件至手机xbin，bin，lib目录，造成手机私自扣费，恶意弹窗的现象发生，因而这些目录是我们需要重点度量的目录。相反的，Vendor目录存放的是第三方厂商的配置文件，因此我们可以赋予其相对较低的权值。由此，各目录的权值分配顺序为：

framework>priv-app>app>xbin＝bin＝lib>etc>fonts＝tts＝media＝user＝vendor

Ramdisk.img中包含一些很重要的配置文件和内核启动完后加载的第一个进程init，init会分别解析init.rc和init.goldfish.rc配置文件初始化并装载***库、程序直到开机完成，init进程还负责创建***中包括Zygote进程在内的几个子进程，Zygote进程是所有JAVA进程的父进程，init动作执行分为四个时间段：early-init、init、early-boot、boot，根据配置文件在开机启动过程中被解析的顺序分配其权重值大小，分配的顺序为：

init.rc>init.goldfish.rc>ueventd.rc>init.environ.rc>init.usb.rc>init.trace.rc

因为Recovery.img由ZImage和Ramdisk.img构成，ZImage部分和正常启动的内核镜像是相同的，因此只需度量其自身的Ramdisk.img镜像即可，度量权重分配和上述一致，对于Userdata.img，只需度量与用户应用程序无关的nativebenchmark文件作为Userdata.img的度量值；

分配各个镜像对应的子目录的权重后，对一级子目录进行分别度量，度量结果用e_i表示，其中i表示一级子目录的个数，若子目录度量结果与参考性完整度量值相同，则对应子目录的度量结果为1，否则结果为0，将子目录对应的权重表示为a_i，其中i表示一级子目录的个数，则综合度量值TValue：

TValue＝∑e_i*a_i

对于二级目录的情况，采用类似上述描述的办法进行度量。

改进的度量模型将叶子节点的度量结果按照不同的权值汇聚到各个子目标，然后汇聚到总目标得到最终的可信度。TCG完整性度量模型得到的是二进制的结果，经过改进的度量模型得到的是综合信任度，且改进的度量模型相比于原来的模型，其可扩展性与适用性变得更高。

Claims (1)

1.一种基于Android***的启动过程完整性度量检测方法，其特征在于，包括以下步骤：

从加电开始，可信度量根CRTM引导Bootloader并验证其完整性，Bootloader是***启动前的引导程序；

采用安全散列算法SHA-1对Bootloader运算得到实际度量值，将得到的实际度量值与RIM证书中的RIM值进行比对，如果对比结果一致，将结果存入平台配置寄存器存储可信根中；

然后CRTM将控制权移交给Bootloader；若比对结果不同，则开机失败，并将检验报告发送给用户；

在Bootloader度量内核的过程中，利用信任度量模型得出对于内核的综合度量值TValue，根据可信度阙值Tm，做出相应的信任决策，可信度阙值Tm用来作为信任决策的评判标准，如果***内核是可信的，则TValue>Tm，则将结果存入平台配置寄存器存储可信根中，随后将控制权交给***内核，否则***无法继续启动，并将检验报告发送给用户；

对Android操作***度量过程中，利用信任度量模型得出对于Android操作***的综合度量值TValue，根据可信度阙值Tm，做出相应的信任决策，可信度阙值Tm用来作为信任决策的评判标准，如果Android操作***是可信的，则TValue>Tm，并将结果存入平台配置寄存器存储可信根中，随后将控制权交给Android操作***，否则***无法继续启动，并将检验报告发送给用户；

对Android操作***第三方应用程序的度量过程中，利用信任度量模型得出对于第三方应用程序的综合度量值TValue，根据可信度阙值Tm，做出相应的信任决策，可信度阙值Tm用来作为信任决策的评判标准，如果第三方应用程序是可信的，则TValue>Tm，并将结果存入平台配置寄存器存储可信根中，随后将控制权交给该第三方应用程序，否则该第三方应用程序无法启动，并将检验报告发送给用户；最终达到整个Android***的可信；

移动可信模块MTM规范了若干可信根，包括度量可信根RTM、存储可信根RTS、报告可信根RTR，其中RTM作为一个软件模块存入只读ROM中，在***加电后第一个被执行且不可以被修改，用于MTM作为可信度量和验证的起点，存储可信根RTS和报告可信根RTR作为硬件模块包含于MTM之中，用于完整性存储和报告，MTM中还定义了参考完整性度量值RIM和RIM证书，RIM的值是要对实体的度量摘要，是提前写入信任根的安全存储区，是该实体符合期望的基准值，为每次***完整性验证提供了参考依据，RIM证书是一个经过数字签名的完整性保护结构，里面包含着RIM的值，数字签名以及相关的一些附加信息；

存储可信根RTS由可信平台度量配置寄存器PCR构成，PCR为160比特的存储位置，寄存器个数最少为16个，都存储在移动可信模块之中，它允许存储无限数量的度量值，还保持着度量的顺序，PCR保存着所有当前已经产生的度量值SHA-1的累积哈希值，160位的累积HASH值表示所有被度量过的组件完整性的状态；

信任度量模型表示为{V,E}，其中V表示节点集合，E表示边集合，节点集合V为有限集合{rt,T}，rt表示根目标，即rt表示为{TValue,TCount}，TValue表示对各子目标度量完成后得到的综合度量值，TCount表示子目标的个数，TCount取值为{0…m}，当TCount＝0，即为需要度量的最小目标，不可再分，目标集合T＝{t1,t2,…tn},t＝{Name,Type,TValue,TCount}，Name表示目标的名称，Type表示目标类型，边集合E为组合关系，边集合E代表权重值，权值的取值范围[0，1]，且满足归一条件；

具体按照以下步骤实施如下：

在Bootloader运行的过程中，Bootloader将***内核镜像ZImage和根文件***镜像Ramdisk.img从flash读到ARM中，当前控制权在Bootloader，对内核进行度量：将需要度量的***内核设置为根目标rt，Android源码编译完成后产生ZImage、System.img、Ramdisk.img、Userdata.img、Recovery.img镜像，上述镜像包含Android启动与运行所需的文件与相关库，因而，对***内核进行度量，即是对产生的所有镜像进行度量，在度量***内核的过程中，将System.img、Ramdisk.img、ZImage、Recovery.img、Userdata.img镜像作为根目标的子目标；

不同镜像的重要程度以及受到入侵的可能性各不相同，因而对不同镜像应赋予不同的权值，ZImage是内核镜像，System.img为***镜像，用于存储Android***的重要文件，包括包和库文件，内存磁盘文件Ramdisk.img存储Linux内核启动时所要装载的文件，Recovery.img镜像只用于刷机，Bootloader根据用户选择进入相应模式，不同模式均包含ZImage和Ramdisk.img文件，Userdata.img是用户数据镜像，存储和用户相关的数据，确定Android设备内存的大小；

根据上述各镜像重要程度以及面临风险的程度，设ZImage分配的权值为w1，设System.img分配的权值为w2，设Ramdisk.img分配的权值为w3，设Recovery.img分配的权值为w4，设Userdata.img分配的权值为w5，则对应权值的关系应为：

w1+w2+w3+w4+w5＝1；

w1>w2>w3>w4>w5；

所述内核镜像ZImage包含的子文件均为***核心文件，因而在度量时将ZImage镜像整体度量；

所述***镜像System.img包含如下子目录文件：app、bin、etc、fonts、framework、lib、media、priv-app、tts、usr以及vendor，度量时对这些目录的权重分配进行分析：

各目录的权值分配顺序为：

framework>priv-app>app>xbin＝bin＝lib>etc>fonts＝tts＝media＝user＝vendor

Ramdisk.img中包含一些很重要的配置文件和内核启动完后加载的第一个进程init，init会分别解析init.rc和init.goldfish.rc配置文件初始化并装载***库、程序直到开机完成，init进程还负责创建***中包括Zygote进程在内的几个子进程，Zygote进程是所有JAVA进程的父进程，init动作执行分为四个时间段：early-init、init、early-boot、boot，根据配置文件在开机启动过程中被解析的顺序分配其权重值大小，分配的顺序为：

init.rc>init.goldfish.rc>ueventd.rc>init.environ.rc>init.usb.rc>init.trace.rc

因为Recovery.img由ZImage和Ramdisk.img构成，ZImage部分和正常启动的内核镜像是相同的，因此只需度量其自身的Ramdisk.img镜像即可，度量权重分配和上述一致，对于Userdata.img，只需度量与用户应用程序无关的nativebenchmark文件作为Userdata.img的度量值；

分配各个镜像对应的子目录的权重后，对一级子目录进行分别度量，度量结果用e_i表示，其中i表示一级子目录的个数，若子目录度量结果与参考性完整度量值相同，则对应子目录的度量结果为1，否则结果为0，将子目录对应的权重表示为a_i，其中i表示一级子目录的个数，则综合度量值TValue：

TValue＝∑e_i*a_i

对于二级目录的情况，分配二级子目录的权重后，对二级子目录进行分别度量，度量结果用e_k表示，其中k表示二级子目录的个数，若二级子目录度量结果与参考性完整度量值相同，则对应二级子目录的度量结果为1，否则结果为0，将二级子目录对应的权重表示为a_k，则综合度量值TValue：

TValue＝∑e_k*a_k。

Images