馮云龍，張宏科，劉林海

(中國電子科技集團(tuán)公司 第54研究所，石家莊 050081)

0 引言

由于在設(shè)備生命周期的早期階段，防火墻和反病毒軟件等傳統(tǒng)對策尚未啟用[1]，設(shè)備在啟動過程中遭到的攻擊很難被檢測到，導(dǎo)致系統(tǒng)安全受到影響。近年來，隨著密碼學(xué)的發(fā)展，安全啟動(Secure Boot)方案較好地解決了這一問題。它可以防止惡意軟件和其他惡意操作對啟動過程進(jìn)行攻擊[2]，強(qiáng)制每個引導(dǎo)階段對后續(xù)階段進(jìn)行身份驗(yàn)證，只有經(jīng)過授權(quán)實(shí)體簽名的固件才能被加載，從而在整個引導(dǎo)過程中建立信任鏈，保證系統(tǒng)的安全。在此過程中，設(shè)備通常需要借助efuse、BootROM等相關(guān)硬件作為信任根(RoT，root-of-trust)來引導(dǎo)信任鏈[3]?？梢姡布ο到y(tǒng)的安全性非常重要。

然而，日益復(fù)雜的全球化硬件供應(yīng)鏈正在威脅著核心硬件的可信度。安全引導(dǎo)中的RoT不可避免地受到了供應(yīng)鏈的攻擊[4]。具體來說，現(xiàn)在許多原始設(shè)備制造商將其硬件或固件開發(fā)外包給第三方供應(yīng)商，而沒有對其安全狀況進(jìn)行全面檢查[5]，在這種情況下，設(shè)備可能會在多次中轉(zhuǎn)中被攔截并被植入破壞組件[6]。上述情況表明，系統(tǒng)啟動時硬件必須真實(shí)可信。例如，攻擊者可以攔截客戶的嵌入式設(shè)備并用惡意的處理器替換原處理器，或者植入一個額外的芯片破壞處理器間的通信，這些攻擊被稱為中間人攻擊。這些攻擊可能會導(dǎo)致惡意映像的加載，從而在啟動階段就控制了系統(tǒng)。上述情況表明，系統(tǒng)啟動時硬件必須真實(shí)可信。

隨著科學(xué)技術(shù)的發(fā)展，很多研究人員對硬件在保護(hù)系統(tǒng)安全方面做了深入研究。Jiang等人[7]提出了一種基于ARM TrustZone技術(shù)的安全引導(dǎo)方案，在傳統(tǒng)Secure boot的基礎(chǔ)上，借助開源OP-TEE和ARM硬件的支持，該方案在ZC702上實(shí)現(xiàn)了同時運(yùn)行OP-TEE可信操作系統(tǒng)和Linux系統(tǒng)，敏感操作在OP-TEE中執(zhí)行，結(jié)果通過驅(qū)動接口返回給Liunx，較好地保護(hù)了用戶的信息安全。Kumar等人[8]提出了一種后量子安全引導(dǎo)(PQSB)方法，該方案完全由硬件實(shí)現(xiàn)，雖然其安全性高，速度快，但是不便于部署在已有設(shè)備上。Ehret等人[9]設(shè)計(jì)了一個以安全為重點(diǎn)的低功耗SoC架構(gòu)，具有硬件信任根，用于邊緣設(shè)備。該體系結(jié)構(gòu)被命名為最優(yōu)資源分配的可重構(gòu)邊緣計(jì)算。Pocklassery等人[10]基于物理不可克隆技術(shù)提出了一種針對FPGA的自認(rèn)證安全引導(dǎo)方法。上述這些方案都默認(rèn)了設(shè)備本身的真實(shí)可信，僅實(shí)現(xiàn)了設(shè)備對用戶身份的單向認(rèn)證，忽略了設(shè)備本身也可能成為攻擊者的事實(shí)。

此外，傳統(tǒng)secure boot方案存在如下問題：首先，認(rèn)證方式都是基于證書的公鑰基礎(chǔ)設(shè)施(PKI，public key infrastructure)體制，在設(shè)備增多時，證書的管理會變得復(fù)雜。其次，采用的鏈?zhǔn)叫湃捂溸^長，導(dǎo)致信任值損失較多。而基于標(biāo)識的密碼體系(IBC，identity-based encryption)是一種密碼學(xué)體制，旨在解決傳統(tǒng)PKI中的密鑰分發(fā)與管理問題。在傳統(tǒng)的PKI中，用戶需要通過證書頒發(fā)機(jī)構(gòu)來獲取公鑰證書。而在IBC中，用戶可以直接使用自己的身份信息作為公鑰，無需經(jīng)過第三方機(jī)構(gòu)的證書頒發(fā)?？紤]到上述優(yōu)點(diǎn)，提出了一種基于IBC體制的Secure boot方案，簡稱為IBCEB方案。以Xilinx的Zynq7000 系列SoC為例介紹傳統(tǒng)Secure boot流程并進(jìn)行分析，詳細(xì)介紹IBCEB方案并對其進(jìn)行安全性分析，介紹雙向認(rèn)證在ZC706評估板上的實(shí)現(xiàn)過程，總結(jié)并展望未來工作。IBCEB方案實(shí)現(xiàn)了在啟動過程中的無證書雙向認(rèn)證，并且優(yōu)化了信任鏈的傳遞，降低了信任傳遞的損失。

1 傳統(tǒng)Secure boot

Xilinx推出的Zynq-7000 系列SoC，已廣泛應(yīng)用于各行各業(yè)。ZYNQ-7000系列所支持的Secure boot非常具有代表意義。本節(jié)將以Zynq系列為例介紹并分析傳統(tǒng)Secure boot的過程。

1.1 安全啟動鏡像

啟動鏡像文件又稱為BOOT.BIN文件，是Zynq啟動的必備文件。它由FSBL、bit流、U-boot、Linux內(nèi)核和BootROM組成。

BootROM程序由Xilinx編寫，出廠后無法更改。BootROM程序?yàn)樵O(shè)備啟動后第一段執(zhí)行的代碼，其主要作用有根據(jù)輸入信號初始化CPU、初始化基本系統(tǒng)功能和判斷啟動方式等。在其執(zhí)行完畢后會將CPU控制權(quán)移交給FSBL。另外，如果啟用Secure boot，那么BootROM還會負(fù)責(zé)完成對FSBL的驗(yàn)簽以及解密工作。

FSBL作為一段Secure boot中的核心程序，它的作用有進(jìn)一步初始化PS、使用bit流文件對PL側(cè)編程、裝載裸機(jī)程序或者U-boot、執(zhí)行用戶定義的代碼，并移交CPU控制權(quán)。如果啟用了Secure boot功能，F(xiàn)SBL還會對接下來的程序進(jìn)行RSA的驗(yàn)簽認(rèn)證以及AES解密工作。

在實(shí)際操作時，BOOT.BIN由Xilinx提供的BootGen工具生成。BootGen可以整合從FSBL到APP的所有代碼，并且支持選擇每一塊區(qū)域是否需加密或者驗(yàn)簽。在整合的過程中，會先添加一段引導(dǎo)頭信息，每一段程序都會變?yōu)橄鄳?yīng)的分區(qū)(Partition)，每個分區(qū)的數(shù)據(jù)都可被AES加密、RSA簽名，以確保鏡像無法被隨意讀取，并且如果啟用RSA認(rèn)證，那么在每個分區(qū)后會追加數(shù)字證書，以確保分區(qū)數(shù)據(jù)的可信性。BOOT.BIN的結(jié)構(gòu)如圖1所示。

圖1 BOOT.BIN格式

RSA認(rèn)證模式為傳統(tǒng)的PKI體系。在該體系下，會建設(shè)一個證書權(quán)威中心CA(Certificate Authority)。傳統(tǒng)Secure Boot中關(guān)于認(rèn)證涉及4種秘鑰：主公鑰PPK、主私鑰PSK、次公鑰SPK、次私鑰SSK。其中PPK和PSK作為CA用于發(fā)放數(shù)字證書的秘鑰對。RSA秘鑰的詳細(xì)信息如表1所示。

表1 認(rèn)證相關(guān)秘鑰

每一個Partition后的證書含有RSA認(rèn)證的參數(shù)Modulus(n)、PPK、SPK、PSK對SPK的簽名值和SSK對Partition內(nèi)容的簽名值。

1.2 Secure Boot流程

傳統(tǒng)Secure Boot方案一般分為3個階段：準(zhǔn)備階段、認(rèn)證階段和解密階段。在啟動過程中，需要每一分區(qū)對下一分區(qū)進(jìn)行認(rèn)證和解密。為了存儲信任根，需要使用到eFuse(Electronic Fuse)。它是一次性可編程存儲器，在向其燒寫內(nèi)容后用戶層面是無法讀取的。在Zynq平臺上，PS側(cè)和PL側(cè)均有一個eFuse。PS側(cè)的eFuse用于驗(yàn)證CA是否合法。PL側(cè)的eFuse存放AES加密的秘鑰，用于給每個分區(qū)解密。為了簡化說明將PS側(cè)的eFuse稱為eFuse1，PL側(cè)的eFuse稱為eFuse2。下面介紹各階段完成的工作，其中，Secure boot中各符號含義如表2所示。

表2 Secure boot中各符號含義

傳統(tǒng)Secure boot流程如圖2所示。

圖2 傳統(tǒng)Secure boot流程

準(zhǔn)備階段：用戶需要生成AES密鑰和RSA密鑰(SPK，SSK)，并向指定CA注冊數(shù)字證書，即可獲取SPSK(SPK)。然后向eFuse1中燒寫CA的公鑰的哈希值H(PPK)，最后為了實(shí)現(xiàn)AES的加密，需要向eFuse2中燒寫AES密鑰。準(zhǔn)備完畢后按照上一節(jié)的啟動鏡像格式生成BOOT.BIN文件。

認(rèn)證階段：1)為了確定當(dāng)前分區(qū)中的簽名是否來自合法的CA，設(shè)備將比較計(jì)算式(1)，如果一致則說明該鏡像來自可信的CA授權(quán)的用戶；2)為了確認(rèn)用戶的身份是否真實(shí)，設(shè)備將讀取分區(qū)中的SPK值和證書，計(jì)算式(2)進(jìn)行比較。如果相等則說明用戶身份也真實(shí)。

H(PPK)=eFuse1

(1)

VPPK(SPSK(H(SPK)))=H(SPK)

(2)

解密階段：3)解密之前需要計(jì)算式(3)，確保分區(qū)的完整性，以防止惡意鏡像對AES引擎的攻擊。4)讀取eFuse2中的AES密鑰，然后將該分區(qū)送入AES引擎解密，即計(jì)算式(4)。之后將CPU控制權(quán)移交給下一分區(qū)。隨后下一分區(qū)重復(fù)上述步驟，直到最后一塊分區(qū)完成，設(shè)備的信任鏈構(gòu)建成功，則視為安全啟動成功。

VSPK(SSSK(H(EAES(p))))=H(EAES(p))

(3)

p=DeFuse2(EAES(p))

(4)

1.3 傳統(tǒng)Secure boot方案分析

傳統(tǒng)Secure boot的認(rèn)證方案中采用的PKI技術(shù)綜合使用了數(shù)字摘要技術(shù)、數(shù)字簽名等密碼技術(shù)以及一套完整的證書管理機(jī)制來提供安全服務(wù)[11]。系統(tǒng)建設(shè)有公信力的認(rèn)證中心(CA，certification authority)鑒定用戶身份，然后為用戶簽發(fā)數(shù)字證書。數(shù)字證書安全地將用戶身份和用戶密鑰綁定在一起。用戶在業(yè)務(wù)系統(tǒng)中先交換證書，然后使用公私鑰完成用戶的身份認(rèn)證、訪問控制和信息安全傳遞等操作。它的特點(diǎn)是簡單易懂，但是其中存在著證書管理復(fù)雜，鏈?zhǔn)叫湃捂溞湃沃祿p失多，需要消耗的計(jì)算資源高等缺點(diǎn)，可能并不適合部署在計(jì)算資源緊缺的嵌入式設(shè)備上。

傳統(tǒng)Secure Boot的安全模型是建立在使用者是攻擊者，設(shè)備是被攻擊者的基礎(chǔ)上，只實(shí)現(xiàn)了設(shè)備對用戶的認(rèn)證。如今，芯片供應(yīng)鏈在設(shè)計(jì)、制造和分銷等方面都已全球化[12]。PCB設(shè)計(jì)人員僅在內(nèi)部設(shè)計(jì)和生產(chǎn)一小部分組件，而依賴于合同制造商、分銷商和EDA工具等各種可能含有惡意的第三方組件，從而使偽設(shè)備攻擊供應(yīng)鏈。這種情況下設(shè)備成為攻擊者，僅僅實(shí)現(xiàn)單向認(rèn)證是不安全的。

2 IBCEB方案

IBCEB方案采用了基于標(biāo)識密碼體制的SM9算法，可以直接使用身份信息進(jìn)行密碼運(yùn)算，簽名私鑰則通過可信第三方密鑰生成中心(KGC，key generation center)生成。此外，為了檢測到設(shè)備是否被篡改以及實(shí)現(xiàn)用戶與設(shè)備的雙向身份認(rèn)證，需要使用物理不可克隆函數(shù)(PUF，physical unclable function)技術(shù)[13-15]。PUF會根據(jù)生產(chǎn)電路板時微小的差異產(chǎn)生唯一設(shè)備ID。此ID結(jié)合 SM9即可實(shí)現(xiàn)用戶和設(shè)備的雙向認(rèn)證。

2.1 方案模型

本方案系統(tǒng)模型如圖3所示。

圖3 系統(tǒng)模型

涉及4個實(shí)體和3個階段。下面對這4個實(shí)體、3個階段以及相關(guān)安全假設(shè)做簡要介紹。其中，IBCEB中的符號如表3所示。

表3 IBCEB中的符號

KGC：秘鑰生成中心，方案中的核心機(jī)構(gòu)，負(fù)責(zé)用戶和設(shè)備的簽名私鑰生成和私鑰分發(fā)。假設(shè)KGC完全可信，其私鑰ks永遠(yuǎn)不會泄露。

User：IoT設(shè)備的所有者和使用者。用戶ID可以是其手機(jī)號、郵箱等序列。User會保存向KGC申請的用戶簽名私鑰dsAU，以及向KGC申請的IoT設(shè)備的簽名私鑰dsAI。假設(shè)用戶存放的dsAUdsAI是安全的不會泄露。

IoT設(shè)備：指用戶使用的產(chǎn)品，在某一臺設(shè)備到達(dá)用戶手中后，用戶會通過PUF技術(shù)為設(shè)備生成唯一的序列號IoTid，并發(fā)送給KGC注冊得到dsAI簽名私鑰。隨后用戶會向其eFuse1中燒寫H(Ppub-s||Uid)。假設(shè)eFuse中數(shù)據(jù)除了設(shè)備本身，無法被他人讀取。

BOOT.BIN：IoT設(shè)備的啟動鏡像文件，該文件由用戶使用各個分區(qū)文件經(jīng)過AES加密和SM9簽名后生成。BOOT.BIN在生成并存入IoT設(shè)備之后，就代表著用戶的身份，與設(shè)備進(jìn)行認(rèn)證。

2.2 方案設(shè)計(jì)

IBCEB方案主要包括系統(tǒng)初始化、啟動鏡像生成和設(shè)備啟動3個步驟。其中涉及橢圓曲線參數(shù)、簽名私鑰生成、簽名算法和驗(yàn)簽算法，以上均按照SM9國家標(biāo)準(zhǔn)進(jìn)行選取和實(shí)現(xiàn)。

2.2.1 初始化階段

1)KGC按國標(biāo)SM9選取參數(shù)，并生成(ks，Ppub-s)；

2)用戶對IoT設(shè)備運(yùn)行PUF模塊，得到IoTid；

3)用戶與KGC建立安全的連接；

4)用戶將自身Uid和設(shè)備IoTID發(fā)送給KGC；

5)KGC分別為Uid和IoTid生成dsAU和dsAI，并發(fā)送給用戶；

6)用戶生成加密密鑰KAES；

7)用戶在eFuse1中燒寫H(Ppub-s||Uid)，eFuse2中燒寫AESkey。

2.2.2 鏡像生成階段

1)User準(zhǔn)備好正常啟動所需的FSBL、U-boot、Kernel、APP等相關(guān)文件。

2)對于以上每一個partition執(zhí)行如下操作：

(1)對partition使用AES加密得到EAES(p)；

(2)使用dsAU對EAES(p)進(jìn)行簽名得到SdsAU(EAES(p))；

(3)使用dsAI對Ppub-s進(jìn)行簽名得到SdsAI(Ppub-s)；

(4)最后得到加密后的partition結(jié)構(gòu)如圖4所示。

圖4 加密后partition結(jié)構(gòu)

3)添加相關(guān)控制信息后，將上述合并至一個文件BOOT.BIN中。

2.2.3 啟動階段

1)BootRom階段執(zhí)行如下操作：

(1)讀取Partition1，即FSBL分區(qū)。

(2)讀取分區(qū)中Ppub-s，Uid，并計(jì)算驗(yàn)證H(Ppub-s||Uid)是否等于efuse1中的值，相等則繼續(xù)，不相等則終止啟動。

(3)調(diào)用PUF模塊獲得IoTid，并使用IoTid計(jì)算VIoTid(SdsAI(Ppub-s))若驗(yàn)簽通過則繼續(xù)，不通過則終止啟動。

(4)使用分區(qū)中提供的Uid計(jì)算VUid(SdsAU(EAES(p)))，若驗(yàn)證通過則繼續(xù)啟動，不通過則終止啟動。

(5)使用eFuse2中的KAES解密當(dāng)前Partition。

(6)轉(zhuǎn)移CPU控制權(quán)給FSBL。

2)FSBL階段：

(1)讀取Partition2，即bitstream。

(2)重復(fù)1)中(2)～(6)。

(3)讀取partition3，即U-boot和kernel。

(4)重復(fù)1)中(2)～(6)。

(5)轉(zhuǎn)移CPU控制權(quán)給Linux Kernel。

3 安全性分析

IBCEB方案實(shí)現(xiàn)了用戶和設(shè)備的雙向認(rèn)證，能夠抵御偽造設(shè)備攻擊。IBCEB方案的信任鏈采用了星型和鏈型相結(jié)合的方式。

3.1 信任鏈模型

Demper-Shafer理論適用于分析信任鏈的傳遞過程，其中的信任衰減法則定義如下：A對B的信任值稱為T(A，B)，B對C的信任值稱為T(B，C)，A經(jīng)過B對C的信任值稱為TB(A，C)，則有：

TB(A，C)≤min(T(A，B)，T(B，C) )

(5)

通過公式(5)可知，鏈?zhǔn)侥Ｐ驮谛湃蝹鬟f過程中，信任傳遞次數(shù)多，導(dǎo)致了信任值損失多，此外鏈中任意節(jié)點(diǎn)出現(xiàn)問題都會摧毀整條信任鏈，而星型信任鏈沒有多級信任傳遞，信任值損失小[16-18]。IBCEB方案采用了鏈?zhǔn)脚c星型信任鏈結(jié)合的方式，縮短了信任的傳遞路程，減少了信任值損失。信任鏈模型如圖5所示。

圖5 信任鏈模型

3.2 安全性分析

假設(shè)敵手試圖在BootROM執(zhí)行期間讀取芯片內(nèi)部的信息。Secure boot是從BootROM開始執(zhí)行，如果BootROM檢測到啟用Secure boot，那么就會禁用PS和PL的debug端口。因此想要通過JTAG接口在啟動階段訪問內(nèi)部寄存器或內(nèi)存數(shù)據(jù)是不可能的[19-21]。

假設(shè)敵手試圖讀取在外部存儲器中的FSBL和操作系統(tǒng)鏡像。鏡像文件是先經(jīng)過AES加密[22-24]，后經(jīng)SM9簽名的。AES秘鑰由用戶自己生成并燒寫到PL的eFuse中，efuse中的秘鑰是安全的，因?yàn)閑Fuse不提供讀取接口，因此敵手無法在沒有AES秘鑰的情況下解密鏡像數(shù)據(jù)。

假設(shè)敵手試圖修改鏡像文件，試圖使用惡意代碼對AES解密引擎進(jìn)行攻擊。這種攻擊在本方案下是無效的。因?yàn)樗械膒artition都經(jīng)過了dsAU的簽名，且BootROM在解密前會先使用Uid進(jìn)行驗(yàn)簽，驗(yàn)簽不通過則無法進(jìn)入AES解密階段。由于dsAU是KGC由用戶標(biāo)識Uid生成，在驗(yàn)簽通過的同時還可實(shí)現(xiàn)設(shè)備對用戶身份的認(rèn)證。

假設(shè)敵手使用惡意設(shè)備替換原設(shè)備來試圖竊取用戶信息。這種偽造設(shè)備攻擊在本方案下也是無效的。因?yàn)镮BCEB不僅使用dsAU對partition進(jìn)行簽名，還用dsAI對Ppubs進(jìn)行簽名。在啟動過程中，由用戶代碼讀取設(shè)備IoTid并對Ppub-s進(jìn)行驗(yàn)簽，以實(shí)現(xiàn)用戶和設(shè)備的雙向認(rèn)證。偽造設(shè)備計(jì)算得到的標(biāo)識IoTid必定與原設(shè)備不同，這就保證了偽造設(shè)備是無法通過認(rèn)證的。

4 實(shí)驗(yàn)分析

為了驗(yàn)證基于標(biāo)識密碼的雙向認(rèn)證的安全啟動協(xié)議方案的可行性，選擇在Xilinx ZC706測試評估板上進(jìn)行實(shí)驗(yàn)分析。ZC706搭載的芯片為XC7Z045，屬于Zynq7000系列。

4.1 實(shí)驗(yàn)過程

SM9標(biāo)識加密算法是基于標(biāo)識的非對稱加密算法，256 bit的SM9算法加密強(qiáng)度等同于2 048 bit密鑰的RSA加密算法，并且運(yùn)算速度優(yōu)于RSA。因此，基于標(biāo)識密碼的雙向認(rèn)證的安全啟動協(xié)議方案中認(rèn)證算法選擇了國標(biāo)SM9算法，IBC體系的SM9算法在2020年納入國家標(biāo)準(zhǔn)(GB/T 38635.2-2020)。SM9國標(biāo)中選取了高效率的配對友好曲線，并且選擇了運(yùn)算速度快的R-ate雙線性對運(yùn)算，以減少M(fèi)iller循環(huán)次數(shù)，提高計(jì)算效率。

SM9算法需要在有限域上進(jìn)行雙線性對的計(jì)算，由于其計(jì)算過程復(fù)雜，完全重新實(shí)現(xiàn)并不現(xiàn)實(shí)。因此在實(shí)際實(shí)現(xiàn)中，選擇了由北京大學(xué)開發(fā)并維護(hù)的開源國密算法庫GmSSL。GmSSL中實(shí)現(xiàn)了對所有國密算法、標(biāo)準(zhǔn)和安全通信協(xié)議的全面功能覆蓋。其中，在SM9算法的實(shí)現(xiàn)上，GmSSL實(shí)現(xiàn)了定義在上橢圓曲線的各種運(yùn)算和各類數(shù)據(jù)轉(zhuǎn)換，以及雙線性對的計(jì)算，并且在其中加入了常見的優(yōu)化方法。

傳統(tǒng)Secure boot的RSA認(rèn)證是在FSBL階段調(diào)用RSA庫形式實(shí)現(xiàn)，因此為了方便對比性能差異，需要將FSBL中的RSA認(rèn)證代碼刪除，添加基于GmSSL實(shí)現(xiàn)的SM9驗(yàn)簽部分的代碼。并在FSBL初始化完成之后，加載bit流之前，即在Fsbl Hook Before Bit stream Dload()的hook函數(shù)中實(shí)現(xiàn)。根據(jù)啟動介質(zhì)的不同，對后續(xù)分區(qū)實(shí)現(xiàn)相應(yīng)的驗(yàn)簽操作。

實(shí)際上由于FSBL是由Bootrom搬運(yùn)至OCM執(zhí)行，而OCM的大小僅有256 kB，其中還有64 kB地址不連續(xù)，因此，需要精簡GmSSL庫，只保留驗(yàn)簽所需代碼，且選擇Release模式編譯FSBL，但在精簡至最少代碼時仍然無法通過編譯，此時還需要修改lscript.ld文件，將.heap段映射至ps7_ram_1_S_AXI_BASEADDR中，最終才能實(shí)現(xiàn)將SM9移植到FSBL中。

在實(shí)現(xiàn)了基于SM9的認(rèn)證功能后，還需考慮對鏡像文件的加密。由于zynq本身硬件支持的解密效率高達(dá)100 MB/s，因此仍選擇沿用Zynq7000自身硬件支持的AES算法。最后在實(shí)際生成鏡像文件時，使用BootGen工具，對鏡像進(jìn)行加密以及整合操作。生成啟動鏡像如圖6所示。

圖6 生成啟動鏡像

在啟動鏡像生成完畢后，用戶需使用SM9算法對BOOT.BIN中各分區(qū)添加分區(qū)的簽名信息和Ppub-s的簽名信息。對BOOT.BIN簽名過程如圖7所示。

圖7 對BOOT.BIN簽名過程

eFuse的燒寫需要使用Xilinx提供的eFuse驅(qū)動。在計(jì)算好H(Ppub-s||Uid)后，將值寫入驅(qū)動的配置文件中。在編譯完成后，選擇JTAG引導(dǎo)模式，使用XSCT命令行對eFuse進(jìn)行燒寫?；贏ES密鑰的存儲有兩種方式，一種為存儲至eFuse中，雖然eFuse中更加安全，不會泄露密鑰，但是之后都無法更改；另一種可以選擇存放在BBRAM中，BBRAM是由電池供電的一塊RAM，在開發(fā)板斷電后其中的數(shù)據(jù)不會消失，并且密鑰可以多次修改。為了方便測試選擇了BBRAM形式存儲AES密鑰，BBRAM在開發(fā)板斷電后數(shù)據(jù)不會消失且密鑰可以修改。燒寫AES密鑰如圖8所示。

圖8 燒寫AES密鑰

4.2 實(shí)驗(yàn)結(jié)果與分析

嵌入式設(shè)備的啟動所需的時間一般主要由3部分組成：BootROM將FSBL從存儲介質(zhì)搬運(yùn)至OCM的時間t1，F(xiàn)SBL將后續(xù)U-boot、Kernel從存儲介質(zhì)搬運(yùn)至DDR時間t2，以及U-Boot、Kernel程序自身的初始化時間t3。

對于t1，由于BootROM的不可修改性和不可訪問性，導(dǎo)致無法測量t1的準(zhǔn)確數(shù)值，但是一般而言由于FSBL的大小僅為100 kB，相比于bit流、U-Boot、kernel一般20 MB的大小，t1可以忽略不計(jì)；對于t3，在選擇常用版本的Linux，U-Boot的情況下，測量得到U-Boot啟動耗時1 287 ms，Linux內(nèi)核啟動耗時4 065 ms。這里并不包括搬運(yùn)時間，而是指搬運(yùn)至DDR后各自的執(zhí)行時間，此時間和存儲介質(zhì)的傳輸速度無關(guān)，即在不更換CPU和DDR的情況下可以看作固定值；對于t2，在啟用Secure boot時，F(xiàn)SBL在搬運(yùn)之前會先讀取分區(qū)信息進(jìn)行RSA認(rèn)證，通過后再將數(shù)據(jù)通過PCAP總線傳送至AES解密引擎解密，最后再送入DDR。FSBL的代碼可以添加用戶自定義的部分，因此可以便捷地實(shí)現(xiàn)對上述功能計(jì)時。綜上所述，t1無法測量且占比很小，t3為固定值，所以t2是系統(tǒng)啟動時間中有意義的統(tǒng)計(jì)因素。

此次實(shí)驗(yàn)采用了常見的含有Bit流、U-boot、Linux 的23 M的鏡像從SD卡來啟動設(shè)備，設(shè)備成功啟動如圖9所示。

圖9 設(shè)備成功啟動

由此測得t2值為12.39 s。由于從SD卡啟動會涉及文件的讀寫，雙線性對的運(yùn)算復(fù)雜，且OCM僅有256 kB，因此面對較大的bit流、Linux內(nèi)核文件時，會導(dǎo)致效率的下降。雖然IBCEB方案犧牲了部分效率，但是IBCEB方案實(shí)現(xiàn)了設(shè)備與用戶的雙向認(rèn)證，保證了系統(tǒng)的安全。

在安全性方面，為了測試IBCEB能否抵御篡改鏡像攻擊，首先選擇在ZC706評估板上選擇常用的U-Boot、Linux版本實(shí)現(xiàn)了正常啟動。然后通過更換APP中的內(nèi)容來模擬對系統(tǒng)鏡像的篡改攻擊。在啟動時，F(xiàn)SBL計(jì)算驗(yàn)簽的結(jié)果不通過，啟動終止。啟動驗(yàn)證失敗測試結(jié)果如圖10所示。

圖10 啟動驗(yàn)證失敗

5 結(jié)束語

文章提出了基于標(biāo)識密碼的雙向認(rèn)證的安全啟動協(xié)議的方案，簡稱IBCEB方案。文章對該方案進(jìn)行了詳細(xì)的理論分析，同時，在ZC706評估板上進(jìn)行了相關(guān)實(shí)驗(yàn)分析。實(shí)驗(yàn)結(jié)果顯示，實(shí)現(xiàn)了用戶和設(shè)備之間無證書的雙向認(rèn)證協(xié)議，提高了系統(tǒng)的安全性。此外，還對傳統(tǒng)信任鏈模型進(jìn)行了優(yōu)化，采用了星型和鏈?zhǔn)较嘟Y(jié)合的信任鏈，降低了信任傳遞的損失。此方案適用于公共安防、智慧家居等諸多領(lǐng)域，使用前景廣闊。盡管IBCEB方案存在優(yōu)勢，但也存在一些不足。首先，一旦KGC主密鑰被泄露，則任何一個用戶的私鑰都可以被計(jì)算出來，就會嚴(yán)重威脅到系統(tǒng)的安全。其次，雖然理論上SM9的性能優(yōu)于RSA，但是SM9國標(biāo)中的參數(shù)以及驗(yàn)簽算法對于嵌入式設(shè)備來說執(zhí)行流程復(fù)雜，帶來了效率的損失。因此接下來將進(jìn)一步研究由用戶與KGC共同決定簽名私鑰的隱式證書密碼體制，以及在Secure Boot應(yīng)用中，如何輕量化SM9認(rèn)證協(xié)議。