转自：http://1024rd.com/%E5%B1%95%E8%AE%AFsecure-boot%E6%96%B9%E6%A1%88%E4%BB%8B%E7%BB%8D%E5%8F%8A%E5%AE%9E%E6%96%BD%E6%B5%81%E7%A8%8B

展讯Secure boot方案介绍及实施流程

1. Secure boot概述

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

注意事项：

签名的密钥对（公钥和私钥）保存在 key.db中。
key.db是随机生成的，要小心保存，建议上库保存。若丢失，则会导致烧过 efuse的机器报废。
烧写 efuse的版本，不能用本地编译的版本（本地的 key.db有丢失可能性），必须使用服务器编译生成的版本。

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技术方案主要分为三个部分：

文件签名Images signature
Secure Boot Process
签名文件下载Image download/update

2.1.文件签名

2.1.1.签名的原理

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

密钥生成算法，用来输出公钥和私钥。
签名算法，用私钥对给定数据进行加密来生成签名。
签名验证算法，用公钥对加密过的消息进行解密验证。

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

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

2.1.2.签名工具

存放路径如下：vendor/sprd/open-source/tools/sprd_secure_boot_tool

RSAKeyGen：用来生成密钥对，存放在key.db中。
BscGen：对fdl1.bin和u-boot-spl-16k.bin进行签名。
VLRSign：对 U-boot/FDL2；bootimage，recoveryimage，modem，dsp进行签名。
sig_key.ini：生成密钥配置文件。
sig_bin.ini： bin签名配置文件。
sig_script.sh：执行脚本。

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.分区介绍

Romcode

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

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

U-boot

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

Bootimage，recoveryimage，modem，dsp

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

FDL1，FDL2

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

2.3.签名文件下载

2.3.1. PC Download/Update

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

2.3.2. Fastboot

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

2.3.3. Recovery

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

3.实施流程

Secureboot实施流程的具体步骤分为以下几步：

编译secure enable的images，参考第5步。
用密钥工具生成密钥数据库 key.db(此key.db是随机生成的密钥，要小心保存)。对编译出来的image文件签名。
对签名过的images打包生成PAC包。
在相关的校验和测试完成后，最后烧写efuse并开机验证。
Recovery升级，需要烧写efuse后，才能进行Recovery升级。

3.1.生成密钥

密钥（公钥和私钥）是存放在 key.db的数据库中，且是随机生成的密钥，要小心保存 ,建议上库保存，且要备份。密钥key.db生成方法如下：

进入vendor/sprd/open-source/tools/sprd_ secure_boot_tool/下，删除默认的key.db文件(注：不删除无法生成新的 key.db)，且修改配置文件sig_key.ini，如下所示：

# KEY define
PASSW1=12345678
PASSW2=12345678
PASSW3=12345678
BSCKEY1=key1
BSCKEY2=key2
VLRKEY=key3

（注：以上只需要修改蓝色部分的密码，可以自己定义，格式为 8位的数字）
执行脚本文件./sig_script.sh IMAGE_PATH（IMAGE_PATH为待签名镜像所在的路径，签名后的镜像也会放在此路径下，若只是生成密钥key.db，此路径可以为空），生成新的key.db(此key.db是随机生成的密钥，要小心保存 )。

3.2. Images签名

进入vendor/sprd/open-source/tools/sprd_secure_boot_tool/下，使用上一步的配置文件sig_key.ini及生成的key.db，执行脚本文件./sig_script.sh IMAGE_PATH（IMAGE_PATH为待签名镜像所在的路径，签名后的镜像也会放在此路径下）由于非授权签名以及采用不同的密钥签名后的 image文件不会成功的下载到手机，所以若由签名完成的 Images打包生成的 PAC文件下载到手机并开机 OK时，即可认为images签名过程OK。具体需要签名的文件名及其使用的工具见下表：

VLRSignTshark BOOT/Recovery/Modem_*/DSP_*/Modem_WCNT8 BOOT/Recovery/Modem_*/DSP_*/DFS/SMLsharkl BOOT/Recovery/Modem_*/DSP_*/DFS fdl2/u-boot.bin（ VLRSign.exe需勾选“insertpublic key”）BscGenu-boot-spl-16k.binfdl1.bin

注：

红色部分表示从 ResearchDownload工具中解析出来的签名文件所对应的FileID；
*号代表名字中包含其它字符，如 Modem_*文件可以是 Modem_WLTE，具体名称以ResearchDownload的Download settings的显示为准。
目前不支持对system image的校验。

3.3. PAC包生成

在PAC包生成时，要将fdl1地址从0x50000000改成0x50003000，步骤如下：

修改版本对应的xml文件内的fdl1的地址
并重新打包。
加载原始

pac后替换签名的fdl文件，可获取到签名文件的原始文件路径；

3.4. efuse烧写

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

3.4.1.烧写 efuse环境需求

系统环境：

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

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

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

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

3.4.2. efuse烧写流程

1. 工具设置

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

2. 操作流程

按上面两幅图设置好工具，并在工具上点击写入按钮。
确保手机处于关机状态，USB线拔出，电池拔出。
手机先插USB线，再上电池（确保两个动作之间间隔时间短，几乎同时）。全过程不要按开机键或者音量键。
在PC端的设备管理器上会看到弹出一个USB口，叫做sprd u2s，4秒时间左右，该口消失，再等15秒左右，该口又会重新弹出。
写号完成，对于第一次写号的手机，工具上会提示绿色窗口，显示pass。对于异常流程，工具上会提示红色窗口，显示timeout(超时)。

3. 如何查询

可以通过手机中的暗码（*#*#83781#*#*）查询,路径为：HARDWARETEST>hash value

3.4.3. efuse烧写异常处理

efuse烧写可能出现的问题：

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

3.5. Recovery升级

手机升级时会对所有的签名images进行校验，因此在发布版本和制作升级包时应使用相同的密钥。具体制作方法如下：

使用make命令先将所有的image编译OK，编译之前需要打开secureboot相关宏，具体参考第5步。

将所使用版本的bin文件copy到device/sprd/spXXXX/modem_bins/目录下（可能需要新建目录），bin文件的文件名有严格要求，根据板子不同而不同，如dsp.bin；wdsp.bin；tddsp.bin；modem.bin；wmodem.bin；pm_*_arm7.bin forsharkl/wcnmodem for tshark;tdmodem.bin；nvitem.bin； wnvitem.bin；tdnvitem.bin； wcnnvitem.bin。具体请参照对应的PAC版本，例如7731ea的对应目录应包含的文件如下图（注意文件名的要求）：Fig.6 modem_bins示图.
将之前生成的key.db(此key.db是随机生成的密钥，要小心保存 )替换目录vendor/sprd/open-source/tools/sprd_secure_boot_tool/下的key.db。
请确保签名工具（BscGen，RSAKeyGen，VLRSign）的权限为可读可写可执行。
将product_name和passwd（要和key.db匹配，且为8位数字）写到配置文件（格式为：keyN [[[ passwd ]]] product_name，配置文件名称和位置可以自己定），例如：

配置文件名称和位置参考如下：

vendor/sprd/open-source/tools/sprd_secure_boot_tool/signkey.txt

文件内容参考如下：

key1 [[[ 12345678 ]]] SC9832
key2 [[[ 12345678 ]]] SC9832
key3 [[[ 12345678 ]]] SC9832

　（注：蓝色部分的密码要和 sig_key.ini中的密码相同）

并将其路径写入环境变量SPRD_SECURE_BOOT_SIGN_CONFIG(build/tools/releasetools/sprd_secure_boot_sign.py)，如下所示：将None改成配置文件所在路径如“vendor/sprd/opensource/tools/sprd_secure_boot_tool/signkey.txt”。

使用make otapackage编译升级文件，编译后可以得到整体升级包：out/target/product/scx*/scx*-ota-*.zip以及target文件：out/target/product/scx*/obj/PACKAGING/target_files_intermediates/*target_files-*.zip。注意需保留所发布版本对应的target-files用于制作升级包。同时 out/target/product/scx*/路径下的 image文件是签名后的文件。8）利用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> <差分升级包文件>

4.常见问题解决

1、下载失败
在secureboot实施过程中经常遇到不能下载问题，要检查以下几步是否正确：

检查secureboot功能是否打开；
检查fdl下载地址是否改成了0x50003000；3）只编译chipram和bootloader模块，保证fdl1和fdl2下载正常。

2、制作OTA升级包失败：
根据编译失败信息debug。

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

5.1. chipram部分

5.1.1. chipram\include\configs\sp9838aea_5mod.h

里面打开下面两个宏：

//#define CONFIG_SECURE_BOOT//#define CONFIG_ROM_VERIFY_SPL=>
#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