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. 缩写定义

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

 
   
   
   
   

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

spreadtrum展信平台加密Secure boot流程相关推荐

  1. 展讯平台camera tuning客观流程

    一.步骤 1.首先aoto tuning 生成一版初版参数,然后编译成so文件(本次练习没有编译). 2.做一个曝光表,然后定标LNC. 3.然后进行AWB标定,其中AWB标定分为gray chart ...

  2. ESP32 ECO3 手动启用 Secure Boot V2 与 flash 加密流程

    本篇文档用来说明 ESP32 ECO3 芯片同时使能 Secure Boot V2 和 flash 加密的操作流程,其中,flash 加密使用发布模式(Release Mode),使用主机生成的密钥对 ...

  3. MTK平台Android 安全中secure boot机制

    一.相关名词解释 1.公钥:通俗来说,公钥就是公开的密钥,是私钥拥有者公开的,公钥通常用于加密会话密钥.验证数字签名,或加密可以用相应的私钥解密的数据. 2.私钥:私有的钥匙,不会公开,私钥加密又称为 ...

  4. MTK Android 9.0(Android P) + kernel-4.9 默认关闭DM Verity 和secure boot 解决无法adb remount的问题

    在android P版本上执行adb remount会提示以下错误: remount of the / superblock failed: Permission denied remount fai ...

  5. 源码国际短信平台路由流程搭建后台软件定制-移讯云短信系统

    源码国际短信平台路由流程搭建后台软件定制-移讯云短信系统 短信路由流程 这里说下我们在开发实践过程中实现短信路由的流程 1:设置账号的全网通道.2:设置通道可发的地区.3:设置内容关键字的通道 流程: ...

  6. ESP32 Secure Boot和Flash加密

    ESP32的代码是存在外部Flash中,如果不加密,很容易被窃取代码. ESP32的secure boot和flash加密是两个功能,但是要配合一起使用,其加密效果才好. 一.初次加密. 这里只写可重 ...

  7. 短信平台源码销售短信路由流程—移讯云短信系统

    开发语音:短信平台由c#源代码开发 短信平台服务器配置: 服务器需要 windows 2003以上的服务器 ,iis ,.net4.0,MSSQL数据库,24小时服务器运行短信平台服务程序. 短信平台 ...

  8. 高通平台(8917/8937/8953...) secure boot 软件配置

    以下以8917平台为例,其他平台类似,找到对应配置文件即可 1.新建临时目录 mkdir tmp cd tmp 2.复制openssl文件到临时目录 cp ../LA.UM.*/LINUX/andro ...

  9. Android系统安全 — 3.1-展锐平台secureboot安全启动流程和使用

    概述 本文主要介绍基于 ARM 架构的展锐芯片 sl8541e Android平台的 Secureboot 方案功能设计实现,其他展锐芯片的安全方案设计都差不多,以经典芯片方案授之以渔. 缩略语 1 ...

最新文章

  1. 数据中心的7个新兴发展趋势
  2. 在Unix/Linux上令(java)JVM支持中文输出
  3. [转载] 七龙珠第一部——第091话 克林反败为胜
  4. 51nod 1575 Gcd and Lcm
  5. 第二十五期:搞定Linux Shell文本处理工具,看完这篇集锦就够了
  6. java web的友好页面_JavaWeb 之 由 Tomcat 展示友好的错误信息页面
  7. 【译】Part 1: 介绍和安装
  8. KVC的使用(对一个对象的成员变量进行操作(赋值/取值))
  9. python 结构体数组_关于python:将结构化数组转换为常规NumPy数组
  10. 2018-05-02 os.path
  11. 趣味java_java-趣味算法
  12. 人人都是 DBA(IX)服务器信息收集脚本汇编 (转)
  13. zoj 3690(递推+矩阵优化)
  14. Go channel详解
  15. matlabsvd提取特征值_MATLAB中的SVD函数
  16. c语言间接寻址运算符,间接寻址运算符:*
  17. windows server2012R2 apache+mod_wsgi+django
  18. Skype如何导出某个人的全部记录
  19. 管理员不让我使用计算机管理,用u盘禁用软件教你实现电脑禁止使用u盘、管理员禁止使用u盘...
  20. linux+dns的acl,DNS服务器之三:DNS高级用法(DNS转发、ACL、智能DNS及日志系统) | 旺旺知识库...

热门文章

  1. PowerShell的基本使用方法
  2. 66网整站数据Thinkphp+layui版
  3. Spring AOP @Aspect没反应的处理
  4. mysql 中文截断_Mysql入库汉字被截断问题
  5. 软件设计模式“单例模式”和“工厂模式”
  6. 7 款开源 Java 反编译工具
  7. log4j 打印线程号配置_日志配置log4j 打印线程号
  8. 全国计算机等级考试python试题_全国计算机等级考试二级Python真题及解析(5)
  9. php 获取指定日期所在月份的最后一天
  10. Lammps压力控制之活塞控压—一个代码循环限域空间内的气体分子数