Android Safety 系列专题【篇三：Secure Boot机制】

前文讲解的Keystore和应用签名都是google原有的安全机制，属于Android系统的强制要求，Google的XTS测试也会对其进行检测和验证。这里讲解的Secure Boot确实芯片厂商自己设计定义的功能，因此不属于Android系统强制要求，XTS也不会针对这些进行测试，然而基本所有的厂商在生产的时候都会做Secure Boot。这里根据安全模块的同事对secure boot文档简单总结一下。

1、什么是Secure Boot?

Secure Boot从字面上面来讲，是安全启动，就是为了保证设备里刷入的镜像是安全的，这里

安全的意思是，这些刷入的镜像是由厂商编译生成的，而不是刷入的别的厂商或者恶意破坏后

的镜像。

1.1 Secure Boot有什么用?

上面已经提到了，secure boot 特性是，保证安全启动，保证刷入设备的镜像，是厂商自己生成

的。避免设备遭受攻击。这里列举几个可能遭受攻击的场景：

• 由其他厂商生成镜像来获取一些信息：高通的代码会给到不同的厂商，如果没有 secure boot，A 、B 厂商都有相同的代码，假如A 厂商要攻击 B 厂商的设备，A 厂商可以自己编译镜像，刷入到 B 厂商的设备，从而绕过 B 厂商自己代码中的一些限制。
• 由其他厂商生成镜像来获取敏感信息：我们知道，有些支付信息什么的，都是在安全世界运行，如果没有 secure boot，可以在TEE 或者 TA 中添加恶意代码，编译镜像，刷入设备，就可以很轻松的获取到一些用户的敏感信息。
• 获取其他信息：secure boot 不仅能够保证安全启动，还可以关闭一些调试通道，如：自动给 fastboot 上锁、关闭 JTAG 调试等，万一厂商在出厂的时候，因为某些疏忽，有些信息没有去掉，黑客在拿到设备的时候，可以通过这些漏洞获取一些敏感数据，如果开启了 secure boot，那么就可以关闭这些信息。（如：TEE log，dump 信息等）

从上面看，开启 secure boot 是每个出厂设备的必须要做的，还有就是要保护好自己的私钥。

1.2 Secure Boot如何运作？

高通芯片内部有一段固化的程序，我们称为 PBL（Primary Boot Loader），同时内部有一个

硬件模块，我们称为 eFuse。eFuse 在熔断的时候，会存储一些验证信息，如：root key 证书的

hash 值。在启动的时候，PBL 会根据 eFuse 的状态（熔断？还是非熔断？）来对后面的要加

载的镜像进行校验。只有校验通过的镜像才会加载。这样只有正确签名的镜像才会被加载运行

，从而实现了安全启动。

注意：这里 PBL 的代码，我们是看不到的，上面的回答，只是根据经验而得，比如：efuse 里面烧录了什么信息？这部分我暂无法知道怎么去查看。

root key 证书的hash 值安全，就可以判断root key 证书是否可信。（root key 证书的hash 值在熔断的时候，就写死在efuse 中，是必然安全）

root key 证书可信，就可以判断ca key 证书是否可信。 ca key 证书可信，就可以判断镜像是否可信。

1.3 Secure Boot概念总结

• Secure boot主要是保证BP 侧镜像，在加载kernel 之前的镜像的安全，防止刷入设备的镜像，不是由厂商自己编译生成，使设备遭受到恶意攻击。
• Secure boot是高通这样的厂商的一个特性，在芯片内部是有一个硬件单元的，只能一次烧录，是不可逆的，烧录的东西和root key密切相关，efuse被熔断了，那么root key就不能改变，同时这块芯片只能运行和root key相关的key签名的镜像。
• Secure boot这个模块的工作，我们只需要生成相关的key，然后生成熔断的文件（包含了root key 的hash信息），签名镜像，知道如何debug 就行，其他里面的运行机理高通已经实现，对我们来说也是黑盒子，不必深究。
• EFUS是高通/MTK等CPU芯片内部的一小段存储器件，这段器件只允许写入一次，即写入了之后就不允许在写入其他数据，哪怕是拆掉芯片也不行。因为此特性，我们可以考虑用它来保存永久不会改变的东西，例如Secure Boot的秘钥信息。
• 熔断

2、Secure Boot使用流程

上面说了那么多secure boot的好处，那么我们如何在设备上使能secure boot呢？其实，高通都实现了这个功能，默认使用的高通的秘钥，我们要做的就是替换成我们自己的秘钥信息而已。做之前，我们可以在高通/MTK的网站上搜索：Secure Boot Enablement，找到适合我们产品的平台，其实里面的步骤会指导我们如何去使能secure boot。

2.1 生成产商自己的KEY

这里不详细说明KEY的生成，通常只有安全模块的同事才会需要到，详情请参阅官方文档，

这一步的最后产物就是：生成了root key和证书、生产了CA key和证书、还要root key的hash值。

2.2 对镜像进行签名

通过第一步已经完成了我们的签名文件、key和证书、secimage.xml 文件，接下来就是把他们作为高通或者MTK的签名工具的输入，就可以得到我们需要的签名文件。

这个过程的实现，在版本编译构建的后面阶段，即就是我们通常所说的镜像签名。编译脚本在生成了各个img之后，通过调用高通或者MTK的签名脚本来对需要签名的img或者其他文件进行签名。因此这里说的镜像签名都属于各个平台自己的机制，和google没有任何关联。

2.2.1 高通镜像签名脚本

2.2.2 MTK镜像签名脚本

2.2.3 镜像签名前后差异

2.3 对设备进行熔断

对设备的熔断的概念就是第一章讲解的把签名key相关信息写入到efus存储里面，因为被写入后就不能在修改，因此它是不可逆的，通常成为硬件的熔断，所以需要慎重。

2.3.1 高通设备的熔断

高通设备只要将制作的sec.dat 文件刷入到sec分区，就实现了secure boot硬件上的熔断。这里只介绍一下sec.dat文件是怎么生成的。其实也是通过高通签名脚本，命令如下：

python sectools.py fuseblower -p <chipset_name> -g -d

-d is for debug information which generates file with fuse information in the <sectools>\fuseblower_output\v1\debug\secdat_repr.txt file.

-p is platform or chipset. The configuration files for platform are at <sectools>\config\

-g generates the SEC.DAT file

最后在工具的输出目录生产文件<sectools>\fuseblower_output\v2\sec.dat，这个文件就是我们配置后，编译的生成物，使用命令：hexdump -C sec.dat可看到内容如下：

可以从大概我圈起来的地方，看到root key的hash值。高通默认的sec.dat 是如下这样的：

sec.dat只是高通的工具生成的一个文件而已，要解析它，只要知道它的结构就行，我感觉没必要解析其结构，我们通过secdat_repr.txt 就可以知道，里面的详细配置。

但是网上确实有人分析了sectools这个工具，有兴趣的可以查看这个链接：独角兽暑期训练营系列 | 高通芯片安全相关熔丝设定及检测方法研究-安全KER - 安全资讯平台

最后的熔断，就是将sec.dat文件写到设备中：

Fastboot flash sec <sectools>\fuseblower_output\v2\sec.dat

During reboot, eFuses will be blown and RoT is configured to the device. The device will reboot again. After the reboot, secure boot is enabled to the device and will only run with signed and trusted software.

2.3.2 MTK设备的熔断

2.3.3 设备是否熔断？

上面我们已经将设备熔断了，那么我们如何查看呢？

方法一：xbl的日志查看

Format: Log Type - Time(microsec) - Message - Optional Info

Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic

S - QC_IMAGE_VERSION_STRING=BOOT.BF.3.3.2-00078

S - IMAGE_VARIANT_STRING=PAASANAZA

S - OEM_IMAGE_VERSION_STRING=SHC0273

S - Secure Boot: On

S - JTAG ID @ 0x000a4120 = 0x90400106

S - Serial Number @ 0x000a4128 = 0xe8c134c3

S - Feature Config Row 0 @ 0x000a4160 = 0x3d018400d8800000

S - Feature Config Row 1 @ 0x000a4168 = 0x02c2f80004000005

S - Boot Config, 0x000000e1

这是sbl1 的日志，我们从日志上看到Secure Boot: On 代表设备已经熔断了，同时还能看到JTAG ID、Serial Number等信息。

方法二：fastboot模式查看sercure boot

3、 相关案例

案例一：熔断后刷入签名的镜像设备进入了fastboot模式

问题分析：如下过程

• 获取串口日志，发现是avb 中，vbmeta.img 镜像校验不通过。
• avb这边，我们没有配置，只是打开了开关，所有的设置都是默认的配置，同时avb和secure boot没有关系。
• 结合代码，分析日志，vbmeta.img 校验不过会进入到fastboot模式，属于正常现象。
• 综上，可能是我们刷入的vbmeta.img 确实可能被破坏了，我们需要重新编译。

解决方案：经过全部整体编译，然后进行签名，发现设备启动正常

案例二：非熔断的设备刷入sec.dat之后IMEI号丢失

• IMEI 这个部分是和modem有关，也是和QCN相关，大概率在modem部分。
• 非熔断的设备，刷入sec.dat后，就使能了secure boot，efs文件系统加密产生变化，所以会导致参数异常，熔断后需要重新校准
• 生产时先全擦再刷入mini版本，将设备熔断；然后进行写号操作等；然后通过upgrade的方式升级到出货版本（user版本）