基于標識密碼的雙向認證的安全啟動協議

馮云龍，張宏科，劉林海

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

0 引言

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

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

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

此外，傳統secure boot方案存在如下問題：首先，認證方式都是基于證書的公鑰基礎設施(PKI，public key infrastructure)體制，在設備增多時，證書的管理會變得復雜。其次，采用的鏈式信任鏈過長，導致信任值損失較多。而基于標識的密碼體系(IBC，identity-based encryption)是一種密碼學體制，旨在解決傳統PKI中的密鑰分發與管理問題。在傳統的PKI中，用戶需要通過證書頒發機構來獲取公鑰證書。而在IBC中，用戶可以直接使用自己的身份信息作為公鑰，無需經過第三方機構的證書頒發。考慮到上述優點，提出了一種基于IBC體制的Secure boot方案，簡稱為IBCEB方案。以Xilinx的Zynq7000 系列SoC為例介紹傳統Secure boot流程并進行分析，詳細介紹IBCEB方案并對其進行安全性分析，介紹雙向認證在ZC706評估板上的實現過程，總結并展望未來工作。IBCEB方案實現了在啟動過程中的無證書雙向認證，并且優化了信任鏈的傳遞，降低了信任傳遞的損失。

1 傳統Secure boot

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

1.1 安全啟動鏡像

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

BootROM程序由Xilinx編寫，出廠后無法更改。BootROM程序為設備啟動后第一段執行的代碼，其主要作用有根據輸入信號初始化CPU、初始化基本系統功能和判斷啟動方式等。在其執行完畢后會將CPU控制權移交給FSBL。另外，如果啟用Secure boot，那么BootROM還會負責完成對FSBL的驗簽以及解密工作。

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

在實際操作時，BOOT.BIN由Xilinx提供的BootGen工具生成。BootGen可以整合從FSBL到APP的所有代碼，并且支持選擇每一塊區域是否需加密或者驗簽。在整合的過程中，會先添加一段引導頭信息，每一段程序都會變為相應的分區(Partition)，每個分區的數據都可被AES加密、RSA簽名，以確保鏡像無法被隨意讀取，并且如果啟用RSA認證，那么在每個分區后會追加數字證書，以確保分區數據的可信性。BOOT.BIN的結構如圖1所示。

圖1 BOOT.BIN格式

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

表1 認證相關秘鑰

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

1.2 Secure Boot流程

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

表2 Secure boot中各符號含義

傳統Secure boot流程如圖2所示。

圖2 傳統Secure boot流程

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

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

H(PPK)=eFuse1

(1)

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

(2)

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

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

(3)

p=DeFuse2(EAES(p))

(4)

1.3 傳統Secure boot方案分析

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

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

2 IBCEB方案

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

2.1 方案模型

本方案系統模型如圖3所示。

圖3 系統模型

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

表3 IBCEB中的符號

KGC：秘鑰生成中心，方案中的核心機構，負責用戶和設備的簽名私鑰生成和私鑰分發。假設KGC完全可信，其私鑰ks永遠不會泄露。

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

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

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

2.2 方案設計

IBCEB方案主要包括系統初始化、啟動鏡像生成和設備啟動3個步驟。其中涉及橢圓曲線參數、簽名私鑰生成、簽名算法和驗簽算法，以上均按照SM9國家標準進行選取和實現。

2.2.1 初始化階段

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

2)用戶對IoT設備運行PUF模塊，得到IoTid；

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

4)用戶將自身Uid和設備IoTID發送給KGC；

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

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

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

2.2.2 鏡像生成階段

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

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

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

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

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

(4)最后得到加密后的partition結構如圖4所示。

圖4 加密后partition結構

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

2.2.3 啟動階段

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

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

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

(3)調用PUF模塊獲得IoTid，并使用IoTid計算VIoTid(SdsAI(Ppub-s))若驗簽通過則繼續，不通過則終止啟動。

(4)使用分區中提供的Uid計算VUid(SdsAU(EAES(p)))，若驗證通過則繼續啟動，不通過則終止啟動。

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

(6)轉移CPU控制權給FSBL。

2)FSBL階段：

(1)讀取Partition2，即bitstream。

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

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

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

(5)轉移CPU控制權給Linux Kernel。

3 安全性分析

IBCEB方案實現了用戶和設備的雙向認證，能夠抵御偽造設備攻擊。IBCEB方案的信任鏈采用了星型和鏈型相結合的方式。

3.1 信任鏈模型

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

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

(5)

通過公式(5)可知，鏈式模型在信任傳遞過程中，信任傳遞次數多，導致了信任值損失多，此外鏈中任意節點出現問題都會摧毀整條信任鏈，而星型信任鏈沒有多級信任傳遞，信任值損失小[16-18]。IBCEB方案采用了鏈式與星型信任鏈結合的方式，縮短了信任的傳遞路程，減少了信任值損失。信任鏈模型如圖5所示。

圖5 信任鏈模型

3.2 安全性分析

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

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

假設敵手試圖修改鏡像文件，試圖使用惡意代碼對AES解密引擎進行攻擊。這種攻擊在本方案下是無效的。因為所有的partition都經過了dsAU的簽名，且BootROM在解密前會先使用Uid進行驗簽，驗簽不通過則無法進入AES解密階段。由于dsAU是KGC由用戶標識Uid生成，在驗簽通過的同時還可實現設備對用戶身份的認證。

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

4 實驗分析

為了驗證基于標識密碼的雙向認證的安全啟動協議方案的可行性，選擇在Xilinx ZC706測試評估板上進行實驗分析。ZC706搭載的芯片為XC7Z045，屬于Zynq7000系列。

4.1 實驗過程

SM9標識加密算法是基于標識的非對稱加密算法，256 bit的SM9算法加密強度等同于2 048 bit密鑰的RSA加密算法，并且運算速度優于RSA。因此，基于標識密碼的雙向認證的安全啟動協議方案中認證算法選擇了國標SM9算法，IBC體系的SM9算法在2020年納入國家標準(GB/T 38635.2-2020)。SM9國標中選取了高效率的配對友好曲線，并且選擇了運算速度快的R-ate雙線性對運算，以減少Miller循環次數，提高計算效率。

SM9算法需要在有限域上進行雙線性對的計算，由于其計算過程復雜，完全重新實現并不現實。因此在實際實現中，選擇了由北京大學開發并維護的開源國密算法庫GmSSL。GmSSL中實現了對所有國密算法、標準和安全通信協議的全面功能覆蓋。其中，在SM9算法的實現上，GmSSL實現了定義在上橢圓曲線的各種運算和各類數據轉換，以及雙線性對的計算，并且在其中加入了常見的優化方法。

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

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

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

圖6 生成啟動鏡像

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

圖7 對BOOT.BIN簽名過程

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

圖8 燒寫AES密鑰

4.2 實驗結果與分析

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

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

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

圖9 設備成功啟動

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

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

圖10 啟動驗證失敗

5 結束語

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