Secure Boot方案介紹及實施流程

轉自https://blog.csdn.net/weixin_34014555/article/details/86260459

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

展訊secureboot方案