1. 概述
Android手机的可信引导过程，主要分为三部分，lk的可信，boot的可信，和system的可信；系统上电到lk的启动过程验证,因为和硬件联系紧密，基本都由各自硬件厂商完成.
lk就是bootloader，它由Pre-loader 启动，该模块在android手机中只可由fastboot工具刷入设备，它的大小一般在1M以下，那么lk的可信就由Pre-loader定义，但是Pre-loader的可信有谁定义呢？为了让android手机有一个公认的可信根，综合考虑可移植性、开发难度、成本等因素，决定定制fastboot工具，android手机如果需要刷入bootloader、Pre-loader等模块，必须使用特制的fastboot工具，用户一旦使用该工具刷入lk模块，fastboot工具就对其进行摘要运算，并且将摘要值传递给远程服务器，服务器通过比较得出lk是否可信的结论，回传给fastboot工具，fastboot工具根据结论是否刷入lk；通过这个办法基本解决lk的可信。
Boot分区包括了kernel、init、healthd等操作系统必须的文件，它由bootloader启动，该模块在android手机中可由fastboot、ota方式刷入设备，它的大小一般在30M以下，那么kernel的可信就由bootloader定义，由于bootloader是可信的，因此在bootloader中增加校验boot.img的功能，就能解决boot分区的可信。
System分区包括了vold、surfaceflinger、servicemanager、camera等系统核心进程，里面的核心进程基本都由init进程启动，该模块在android手机中可由fastboot、ota方式刷入，该分区里面的单个文件可由adb工具上传和下载，它的大小一般在1G上下,system.img校验的任务就交给了操作系统，由于system分区的容量，不太适合使用校验boot.img的办法，通常的办法有两个：dm-verity和ima；dm-verity采用的是块校验技术，android原生采用的是该办法；ima采用的是运行时实时校验技术，ima是linux内置的可用模块。
2. 安全引导流程图
3. 摘要算法与签名算法
在安全引导过程中经常要使用摘要算法和签名算法，在此介绍几种常用的算法，供参考：
摘要算法：把任意长度的输入柔和成固定长度的伪随机输出，其具有无论输入消息长度、消息摘要是’随机’的、无陷门单向函数等特点，一般应用于提取数据’指纹’信息和数据完整性校验场景，常用的摘要算法有hmac、sha1、sha256.
SHA1:以分组为单位处理数据输入，生成一个长度为160比特的消息摘要，应用比较广泛，SHA256是其变种版本.
HMAC:以一个密钥和一个消息为输入，生成一个长度为128~512比特的消息摘要，它是一个典型的’挑战/响应’身份认证算法.
签名算法：可以看作是带有密钥的消息摘要算法，并且这个密钥包括公私钥，它是非对称加密算法和消息摘要算法的结合体，具有抗否认的功能，广泛应用于公钥基础设施(PKI)，以及许多网络安全机制中，典型的签名算法有RSA、DSA、ECDSA
RSA:加密是对明文的E次方后除以N后求余的过程，验证的过程与加密的过程一致，不过加密使用私钥，验证使用公钥，目前为止地球上还没有破解方法.
4. 硬件平台安全引导机制概述
硬件平台安全引导是指系统上电到lk的引导过程，由于该过程与硬件联系紧密，基本都由手机所使用的硬件平台完成，其核心原理同样是验证签名摘要，典型案例有高通平台的secure boot方案，需要了解可去其官网.
5. 安全引导机制实现细节
一. BOOTLOADER安全引导实现细节
1、PC端 USB连接android
2、PC端Fastboot刷入lk
3、PC端Fastboot利用hmac算法对lk做信息摘要
4、PC端将摘要发送给远程服务器
5、远程服务器校验摘要信息，返回lk是否被篡改的结果
6、PC端Fastboot根据远程服务器的结果决定是否刷入lk
7、Lk可信引导完成
注：LK的可信认证是在‘体外’完成的，主要开发任务在于定制fastboot刷机工具，不影响手机功能实现。
二. KERNEL 安全引导实现细节
Boot.img的可信认证由两部分组成：编译阶段签名和运行时阶段校验
HOST编译阶段：
1、正常将boot.img编译出来
2、利用openssl dgst 提取boot.img的摘要信息
3、利用openssl工具对摘要信息做签名
4、将boot.img和签名摘要信息重新打包成新的boot.img
Bootloader运行时阶段：
1、正常流程运行于启动boot_linux之前
2、利用openssl dgst提取缓存于emmc中的kernel镜像文件的摘要信息
3、利用openssl模块解密附加于boot.img中的签名摘要信息
4、将2、3步骤中的结果对比，相同则证明boot.img可信
三. SYSTEM 分区安全引导实现细节
System.img的认证目前有两种办法：ima(运行时细粒度校验)和dm-verity(挂载时粗粒度校验+运行时细粒度)
Ima：将文件的内容和文件的属性/扩展属性，通过加密哈希生成对应的ima/evm串，以扩展属性的方式保存在文件系统节点中；系统运行时在文件被访问之前，内核 IMA/EVM模块通过校验文件的ima/evm串，来判断文件是否被离线篡改过；该流程分为两部分：编译阶段签名和运行时阶段校验
HOST编译阶段：
1、利用openssl dgst 提取文件的摘要信息
2、将摘要信息串保存于文件的扩展属性security.ima中
3、利用openssl dgst 提取文件所有扩展属性的摘要信息
4、利用openssl工具对扩展属性的摘要信息做签名
5、将签名摘要信息串保存于文件的扩展属性security.evm中
运行时阶段：
1、运行于文件被打开前
2、校验文件的security.evm属性
3、校验文件的security.ima属性
4、2、3过程都通过则证明文件没有被离线篡改过
注：系统启动阶段需要导入签名公钥、文件校验策略，便于内核IMA模块校验文件，此外该方法是细粒度的分区校验，它会在系统运行时对系统产生影响.
Dm-verity: 分区映射校验是一种针对分区进行完整性检查的安全机制。它利用哈希树结构去构建整个分区目录的签名信息。系统在启动挂载分区时，内核对挂载的分区进行 签名验证，验证成功则进行挂载操作;同时这种机制允许system分区在读写的时候分块校验，而不是一次性校验整个分区;该过程同样分为两部分: 编译阶段签名和运行时阶段校验，过程与ima类似，但与ima不同的是，dm-verity校验过程在系统启动阶段还拦截了mount操作，且是粗粒度的校验过程， 采用该办法后系统无法使用普通的差分包进行升级，且对系统的启动有一定影响.
