[加密]展讯secureboot方案

Secure Boot方案介绍及实施流程

转自网络

1. Secure boot概述

本文档主要是secure boot方案的介绍和说明，其内容会涵盖以下方面：secure boot的目的和介绍、技术方案的描述、PC端签名工具和Image download&update工具的使用以及产线实施所需要做的准备工作和注意事项等。

1.1. 需求与目的

目前，非授权更改甚至替换手机原版操作系统中固有软件或者操作系统的软件技术手段层出不穷，secure boot方案对系统软件采用签名认证的方式，在手机出厂前对手机操作系统的Image文件进行签名认证，并将公钥的Hash值写入芯片的一次性可编程模块。由于不同文件计算得到的Hash值不同，采用secure boot方案的手机每次启动时都会先校验系统的Hash值，即和芯片内的Hash值进行比较，然后对签名images的一级一级校验，实现从手机芯片到系统软件的链式校验过程，很好地避免手机出厂后没有得到客户签名认证的非授权操作，保护手机中原有的操作系统和软件版本。

1.2. 缩写定义

Name	Description
CA	Certificate authority
PUK	Public key
RSA	One public-key cryptosystems
SHA	Secure hash algorithm

2. 技术方案介绍

Secure boot技术方案主要分为三个部分：

1)        Images signature

2)        Secure Boot Process

3)        Image download/update

2.1. 文件签名

2.1.1. 签名的原理

数字签名是通过一些密码算法对数据进行签名，以保护源数据的做法。典型的数字签名方案包括以下三个算法：

1)      密钥生成算法，用来输出公钥和私钥。

2)      签名算法，用私钥对给定数据进行加密来生成签名。

3)      签名验证算法，用公钥对加密过的消息进行解密验证。

Fig.1 数字签名和验证过程.

Fig.1是数据的数字签名和验证过程。Secure boot方案中的数字签名由SHA和RSA算法组成，并直接采用PUK替代CA。我们在PC端实现对Images的签名，并在手机端实现Images的验证，images文件的变化会导致解密过程的失败，从而很好地避免非授权操作。

2.1.2. 签名工具

PC工具用来生成密钥对，并对images进行签名，其中包括SPL1/FDL1；U-boot/FDL2; bootimage，recoveryimage，modem，dsp。RSAKeyGen, BscGen, VLRSign, WriteIMEI

1)      RSAKeyGen：用来生成密钥对。

2)      BscGen：对fdl1.bin和u-boot-spl-16k.bin进行签名。

3)      VLRSign：对U-boot/FDL2；bootimage，recoveryimage，modem，dsp进行签名。需要注意的是对U-boot/FDL2和bootimage/recoveryimage/modem/dsp签名时的不同，在对U-boot/FDL2进行签名时需要勾选工具中的“insert public key”选项。

2.2. Secure Boot Process

2.2.1. Secure Boot概貌

Secure boot的基本思想是从Romcode到Images的多层链式校验机制（如图Fig.2所示）。Romcode利用Hash函数来验证BSC的完整性，用RSA算法来验证SPL的完整性；然后SPL将会验证U-boot；最后U-boot来验证bootimage，recoveryimage，modem，dsp等，所有的boot images会通过RSA算法的私钥加密并在生产阶段载入手机，每个image文件的RSA公钥保存在前一级用私钥签名的image当中，而计算得到BSC的Hash值和第一级的公钥则保存在芯片的一次可编程模块中，以防止其被修改。需要注意的是，RSA私钥是Secure boot的保障，需要被小心的保存起来。

Fig.2 Secure boot概貌.

2.2.2. 分区介绍

1)        Romcode

Romcode位于芯片的ROM内，芯片出厂后不能修改，它包含了SHA1和RSA算法，且BSC的Hash值也保存在芯片的一次性可编程模块（efuse）中。Romcode在下载或启动会比较efuse和BSC的Hash值。

2)        SPL

bootloader的一部分，它会被加载到芯片的内部RAM中，所以其大小受芯片内部RAM大小的限制，SPL的主要作用是初始化外部内存，即我们常说的DDR。

3)        U-boot

bootloader的另外一部分，其作用是将images加载到RAM，并进行验证。

4)        Bootimage，recoveryimage，modem，dsp

这些images通过PC工具签名，由U-boot验证、加载。

5)        FDL1，FDL2

与SPL和U-boot的作用类似，用于下载模式。

2.3. 签名文件下载

2.3.1. PC Download/Update

当secure boot功能enable时，对于我们的SPL/FDL1，U-boot/FDL2，Bootimage，Recoveryimage等需要签名后才能下载，在下载过程中，前面所提到过的链式校验的任一个环节验证失败都会导致这些images不能成功下载到手机。在手机启动时，同样也会对这些images进行链式校验。

2.3.2. Fastboot

如果手机的secure boot功能打开，在Fastboot模式下载images时会先对签名的image进行验证，认证的签名image才会被下载到手机。

2.3.3. Recovery

Recovery模式下的手机升级和启动过程一样，会对所有的签名images进行校验。需要注意的是，升级前后的签名密钥必须相同才能升级成功。

3. 产线实施流程

综合以上，产线实际生产时的具体步骤会分为以下几步：

1)   编译secure enable的images。

2)   用密钥工具生成密钥对。

3)   对SPL/FDL1进行签名。

4)   对U-BOOT/FDL2，boot, modem, dsp, recovery中的部分文件进行签名。

5)   对签名过的images打包生成PAC文件。

6)   在相关的校验和测试完成后，最后烧写efuse并开机。

总的来说，Secure boot相比之前多出了几个需要引起我们注意的环节：images签名、efuse烧写、Recovery升级。

3.1. Images签名

用签名工具对Images进行签名时，需要注意的是，不同的images可能使用不同的签名工具（BscGen，VLRSign），而且在用VLRSign对FDL2/U-BOOT签名时需要勾选“insert public key”。工具的具体用法如下：

1)   RSAKeyGen：用来生成密钥，如Fig.3；需要输入Product Name和Password（密码必须是8位，例如Product Name：7730ec；Password：12345678，后面工具会用到）；然后点Generate，下方会出现7730ec的字样。

Fig.3 RSAKeyGen工具示图.

2)   BscGen：对SPL/FDL1签名，如Fig.4，需输入步骤1）中的Product Name和Password；Code File：选择要签名的SPL或FDL1；Out File：选择签名后的文件名及其存放的路径；然后点Generate。

Fig.4 BSCGen工具示图.

3)   VLRSign：对FDL2/U-BOOT等签名，如Fig.5，输入步骤1）中的Product Name和Password；VLR Image：选择要签名的文件，注意FDL2/U-BOOT签名时需要勾选“insert public key”；Signed Image：选择签名后的文件名及其存放的路径，然后点Sign。

Fig.5 VLRSign工具示图.

由于非授权签名以及采用不同的密钥签名后的image文件不会成功的下载到手机，所以若由签名完成的Images打包生成的PAC文件下载到手机并开机OK时，即可认为images 签名过程OK。具体需要签名的文件名及其使用的工具见下表：

	VLRSign.exe		BscGen.exe
Tshark	boot.img/recovery.img/*_modem_*.bin/Dsp_*.bin/wcnmodem.bin	Fdl2/u-boot.bin （VLRSign.exe需勾选“insert public key”）	u-boot-spl-16k.bin fdl1.bin
T8	boot.img/recovery.img/*_modem_*.bin/Dsp_*.bin/pm_*arm7.bin/sml.bin
sharkl	boot.img/recovery.img/*_modem_*.bin/Dsp_*.bin/pm_*arm7.bin

注：*号代表名字中包含其它字符，如*_modem_*.bin文件可以是7730_modem_EC.bin，具体名称以PAC包内的文件为准。

3.2. efuse烧写

efuse的烧写过程对secure boot来说是至关重要的，错误和失败的烧写都会导致手机无法开机，所以这个过程需要更为严格的要求。

3.2.1. 烧写efuse环境需求

1)  系统环境：

建议使用Win-XP SP3或者Win7 SP1版本。

2)  测试治具、线材及供电仪器等：

测试治具的探针也需要按照一定周期进行替换，以防止与手机通信或供电时的不稳定现象； USB线材的线阻也要尽可能的做到最小，比如USB线阻如果大于0.1欧姆就很可能会通信不正常，线材的长度以不超过1.1米为参考。

因为efuse烧写时所需电压较为精准，供电仪器建议使用精密型的程控电源，如果使用较为老旧的直流Power，上下浮动可能会比较大，易导致通讯宕机甚至掉电，这些都有可能使efuse烧写失败甚至芯片报废。建议电压稳定 4.0V。

3.2.2. efuse烧写流程

1)        工具设置：

模式选择选项如上图所示，选择常规写号模式

设置选项如上图所示，注意勾选上program  key功能，后面的下拉框选择Enter WG mode。

 

2)        操作流程

(1)按上面两幅图设置好工具，并在工具上点击写入按钮。

(2)确保手机处于关机状态，USB线拔出，电池拔出。

(3)手机先插USB线，再上电池（确保两个动作之间间隔时间短，几乎同时）。全过程不要按开机键或者音量键。

(4)在PC端的设备管理器上会看到弹出一个USB口，叫做sprd u2s，4秒时间左右，该口消失，再等15秒左右，该口又会重新弹出。

(5)写号完成，对于第一次写号的手机，工具上会提示绿色窗口，显示pass。对于异常流程，工具上会提示红色窗口，显示timeout(超时)。

3.2.3. efuse烧写异常处理

efuse烧写可能出现的问题：

1)   提示烧写失败，手机可开机：可以尝试再重复写efuse，若还是失败，表示efuse无法写入正常值，也无法再写efuse，但该手机可当一般机器出货。

2)   写入错误的Hash值导致手机无法开机：secure boot功能已经enable，但写入的efuse内容是错的，出现这种情况后该手机的芯片无法再使用，须换芯片后重新烧写。目前新版本中已对这种情况进行处理，在enable之前会读取芯片内的Hash值并作对比，发现Hash值错误后不会进行enable，从而可以保证手机正常开机。

3.3. Recovery升级

Recovery升级制作升级包的方法以及升级的方法基本没有变化，主要不同点在于secure boot方案在制作升级包时需要进行签名，手机升级时会对所有的签名images进行校验，因此在发布版本和制作升级包时应使用相同的密钥。具体制作方法如下：

1)  使用make 命令先将所有的image编译OK。

2)  将所使用版本的bp文件copy到device/sprd/spXXXX/modem_bins/目录下（可能需要新建目录），bp文件的文件名有严格要求，根据板子不同而不同，如dsp.bin；wdsp.bin；tddsp.bin；modem.bin；wmodem.bin；pm_*_arm7.bin for sharkl/wcnmodem for tshark;tdmodem.bin；nvitem.bin； wnvitem.bin； tdnvitem.bin； wcnnvitem.bin。具体请参照对应的PAC版本，例如7730ec的对应目录应包含的文件如下图（注意文件名的要求）：

Fig.6 modem_bins示图.

3)  若签名用的是前面提到的工具生成的密钥对（保存在RSAKeyGen工具所在目录下的key.db中文件），须用该key.db替换目录vendor/sprd/proprietories-source/sprd_ secure_boot_tool/下的key.db，比如我们用RSAKeyGen工具生成product_name为7730ec的密钥对，则需将下面左图中的key.db替换掉右图中的同名文件。

Fig.7 Key.db示图.

4)  使用make otapackage编译升级文件，过程中需要输入签名时使用的product_name和passwd，若想服务器自动编译，可将product_name和passwd写到配置文件，并将其路径写入环境变量SPRD_SECURE_BOOT_SIGN_CONFIG，配置文件的格式为： [[[ passwd ]]] product_name。编译后可以得到整体升级包：out/target/product/scx*/scx*-ota-*.zip以及target文件：out/target/product/scx*/obj/PACKAGING/target_files_intermediates/*-target_files-*.zip。注意需保留所发布版本对应的target-files用于制作升级包，例Fig.7中类似。

Fig.8 升级包示图.

5)  利用targes文件制作差分升级包，可以使用工具ota_from_target_files执行一下命令./build/tools/releasetools/ota_from_target_files –i <prev_target_files> -k build/target/product/security/testkey <next_target_files> <差分升级包文件>。

Fig.9 升级包工具示图.

注意事项：必须保证步骤(3)中使用正确的key.db来替换目标路径下的同名文件；同时保证在步骤(4)输入正确的product_name和passwd（使用配置文件自动编译需设置正确）。

4. 常见问题解决

分类	问题描述	原因	参考解决方案(gerrit链接)
Research Download	官方签名fdl1无法下载	没有修改下载配置文件中spl的下载地址	需要将spl的下载地址从0x50000000修改为0x50003000
	Hash值写入efuse后，非官方签名fdl1可以下载	型号的efuse map可能会发生改变，需要对应修改hash值写入的地址。	http://review.source.spreadtrum.com/gerrit/#/c/181111/ http://review.source.spreadtrum.com/gerrit/#/c/181147/
	非官方签名modem bin下载成功	型号modem对应的分区名字可能会发生改变，需增加下载时要校验的分区名字	http://review.source.spreadtrum.com/gerrit/#/c/175976/
	选择官方签名的fdl1,fdl2,u-boot进行下载，u-boot无法下载	对U-boot进行校验的时候需要从spl里面取key	因此需要先下载spl然后才能下载u-boot，第一次下载secureboot使能版本的时候最好同时选上spl u-boot。
Boot	使能secureboot的版本下载后无法开机	使能secureboot后，boot代码里会对所有需要签名的分区进行校验，因此要保证所有要校验的分区都进行了签名。	目前需要签名的分区通常为fdl1 、fdl2、spl、u-boot、boot、recovery、pm、以及modem相关的几个分区。需要全部官方签名后再下载。
Fastboot	Fastboot下载非官方签名spl成功，boot失败	Secureboot的使能位也是写在efuse里面的，如果efuse map发生了变化，读取使能的block地址也应对应修改。	http://review.source.spreadtrum.com/gerrit/#/c/183277/
Porting	已经打开secureboot开关，secureboot功能没有使能	代码porting不全	错误的提交： http://review.source.spreadtrum.com/gerrit/#/c/181802/ 正确的提交： http://review.source.spreadtrum.com/gerrit/#/c/182601/ http://review.source.spreadtrum.com/gerrit/#/c/182610/ http://review.source.spreadtrum.com/gerrit/#/c/182609/
签名工具使用	官方签名的fdl1无法下载	所用签名工具版本是旧的。旧的版本没有在签名部分对fdl1头的长度进行写入	更新签名工具的版本。
	官方签名的fdl2无法下载	Fdl1签名的时候使用的key不当，使用了两次key1进行签名	应该分别选择key1,和key2进行签名。

5. 如何编译使能secureboot的版本

以T8sp9838为例：

5.1. chipram 部分

5.1.1.  chipram\include\configs\sp9838aea_5mod.h

里面打开下面两个宏 在41 42行

//#define CONFIG_SECURE_BOOT

//#define CONFIG_ROM_VERIFY_SPL

5.1.2. makefile

打开sp9838aea_5mod_config下的红色那行。

sp9838aea_5mod_config    : preconfig

@$(MKCONFIG) $@ arm armv7 sp9838a spreadtrum sc9630

@echo "CONFIG_SPL_32K = y" >> $(obj)include/config.mk

@echo "CONFIG_EMMC_BOOT = y" >> $(obj)include/config.mk

@echo "CONFIG_SCX35L64 = y" >> $(obj)include/config.mk

@echo "CONFIG_UMCTL_28NM = y" >> $(obj)include/config.mk

@echo "CONFIG_SP9630_SPL_BASE = y" >> $(obj)include/config.mk

#@echo "CONFIG_SECURE_BOOT = y" >> $(obj)include/config.mk

@echo "CONFIG_USE64 = y" >> $(obj)include/config.mk

5.2. u-boot64部分

u-boot64\include\configs\sp9838aea_5mod.h

里面打开下面两个宏 在12 13行

//#define CONFIG_SECURE_BOOT

//#define CONFIG_ROM_VERIFY_SPL

5.3. device/sprd部分（OTA升级）

device/sprd/scx35l64_sp9838aea_5mod/BoardConfig.mk

# secure boot

BOARD_SECURE_BOOT_ENABLE := false

改为BOARD_SECURE_BOOT_ENABLE := true