android安全启动验证链

Kael.dong

已于 2023-02-21 13:59:13 修改

阅读量2.4k

点赞数 1

分类专栏： android系统安全安全 android 文章标签： android 系统安全安全 Powered by 金山文档

于 2023-01-30 21:49:16 首次发布

本文链接：https://blog.csdn.net/dongyi1988/article/details/128801614

版权

android系统安全同时被 3 个专栏收录

12 篇文章 5 订阅 ¥99.90 ¥299.90

订阅专栏

超级会员免费看

android

25 篇文章 11 订阅

订阅专栏

安全

7 篇文章 1 订阅

订阅专栏

前言android 系统安全内容总结

1、签名验签

启动验证链核心技术就是签名验签，这里复习下，流程如上图：

android基础算法使用的是RSA

红色部分是编译时对需要验签的镜像与文件进行签名操作；需要用到私钥，这个私钥一般放在编译代码或者签名服务器。

黄色部分是开机启动时对启动镜像与文件的验签；需要用到公钥，这个公钥集成到镜像中，一般对开发与使用者都是可见的。

2、安全启动验证链

极简的开机启动流程如下

红色部分是secure boot部分，黄色部分是AVB部分（AVB包括verify-boot与dm-verity）。

https://blog.csdn.net/dongyi1988/article/details/103995737

以MTK为例：

Secure Boot验证阶段，Boot Rom程序段上电直接运行，这段程序不能修改或者跳过，它将获取芯片内部非易失只读性存储中的公钥or公钥HASH；用于验证引导加载程序（preloader）镜像末尾的root公钥，验证成功后启动preloader；然后preloader代码段的公钥头文件（oemkey.h）验证ATF、TEE、lk；在启动到lk后，利用TEE提供的加密库使用公钥头文件（oemkey.h）验证md1、scp、logo等。

AVB（android verify boot）校验阶段，启动到lk会用公钥头文件(avbkey.h)验证vbmeta分区，再用验证通过的vbmeta分区里面存的公钥对一般较小的分区（例如boot、dtbo）进行hash校验；验证完毕后进入kernel，kernel使用dm-verity对动态分区（一般较大的分区，例如system，vendor）进行hash tree的校验，所有分区校验成功后正常挂载，设备继续进入android启动流程。

2.1、secure boot

发现有价值文章：浅析安全启动（Secure Boot）

现在网上内容很多，不再赘述，解答标红的三个问题

QCOM启动流程图参考

https://www.cnblogs.com/schips/p/how_qualcomm_soc_boot.html

MTK启动流程图参考

https://blog.csdn.net/forever_2015/article/details/53000643

https://blog.csdn.net/forever_2015/article/details/53047993

MTK的secure boot配置参考:

https://blog.csdn.net/qq_43805880/article/details/108062898

QCOM的secure boot 配置参考：

https://blog.csdn.net/tq501501/article/details/94719382

1、只是刷入efuse.img镜像设备就熔丝了？

fastboot flash efuse只是刷写emmc/ufs上的分区数据，熔丝并不是fastboot做的事。如果还在调试，efuse熔丝公钥与preloader签名不匹配那不就完蛋了吗？

我们看不到Boot Rom代码，在secure boot安全验证上，以及芯片手册上能猜测其流程。其实从QCOM网站看到，文档名记不住了，大概意思如下流程图。

熔丝真正操作在TEE，efuse公钥hash判断有效后，重启才真正生效，从此每次开机进行secure boot校验。

硬件关闭公钥存储写入能力，也就是熔断操作，会耗电；如同读写标志位强制拉低，从此此段存储再也无法篡改。

熔丝寄存器位也置为有效，再也无法关闭。

这就创建了一个值得信任的根。

2、为什么secure boot有多级验证？

MTK对其使用的镜像md1、scp、logo等等进行二次签名，那么开机需要进行二次验证增加启动耗时，安全性只是倍增，而不是指数级增加，有必要吗？

先了解多级认证的作用https://www.wenmi.com/article/q04bcq008upf.html

我理解这是供应商自己玩的隔离，即md1、scp、logo部分使用MTK自己签名授权的一级签名，二级签名交给ODM。这样MTK就控制了md1、scp等部分的芯片功能。（貌似还是跟QCOM学的。）

3、如何联网签名？

软件架构方案已经有了，但开发人员随意签名漏洞版本、可恶意窃取数据版本怎么办？如何降低开发人员的攻击呢？

ODM只需要管理好发布版本，管理好私钥即可，这就是非对称密钥的好处。将私钥存储到服务器，开发人员编译镜像需要授予签名权限，控制版本输出。MTK与QCOM的secboot签名都做好了接口，修改非常方便，有钱也可直接请人搭建👌。

MTK的secure boot最终签名接口调用hsm.py，路径应该在vendor/mediatek/proprietary/scripts/secure_chip_tools，如注释部分描述，替换lib.cert.sig_gen的实现即可。

hsm_rsa_sign(data, key, padding, sig)函数中，data是镜像hash、key私钥名、padding加密方式，sig返回签名后内容。

def hsm_rsa_sign(data, key, padding, sig):  
    """ 
    sign data with HSM 
    """  
    # note that key is pubk actually, use it as index for  
    # HSM parameters such as key selection  
    hsm_param_obj = HsmParam()  
    key_table = create_key_table()  
    hsm_param_obj.m_prvk = query_key_table(key_table, key)  
     if hsm_param_obj.m_prvk is None:  
         print 'not valid HSM parameter'  
         return -1  
   
     print "========================"  
     print "HSM parameter:"  
     print "    m_prvk  = " + hsm_param_obj.m_prvk  
     print "========================"  
   
     # place hsm request here -- start  
     # we re-direct it to signing with private key to mimic HSM  
     # data is not hashed here, you can hash data here to reduce  
     # network usage  
     lib.cert.sig_gen(data, hsm_param_obj.m_prvk, padding, sig)  
     # place hsm request here -- end  
     return 0

联网签名步骤参考：