在嵌入式系統安全啟動體系中，U-Boot的FIT（Flattened Image Tree）鏡像簽名驗證是一道關鍵防線——它能確保啟動鏡像未被篡改、來源可信，而image-sig.c正是實現這一核心能力的核心文件。本文將從數據結構、函數邏輯、數據流程三個維度，拆解image-sig.c的實現細節，帶你吃透U-Boot鏡像驗簽的底層邏輯。

一、背景：為什么需要FIT鏡像簽名驗證？

傳統的U-Boot鏡像格式（如uImage）功能單一，難以滿足復雜場景下的安全需求。FIT鏡像以設備樹（DTB）為載體，支持多鏡像打包、版本管理、簽名驗證等能力，而簽名驗證則是安全啟動的核心：

?防止鏡像被惡意篡改，保障啟動流程可信；

?支持多種哈希/加密算法，適配不同安全等級需求；

?區分“必需”和“可選”簽名，靈活適配不同場景。

image-sig.c的核心職責就是：管理驗簽所需的算法、解析FIT鏡像的簽名節點、完成哈希校驗與簽名驗證，是FIT鏡像安全的守護者。

二、核心數據結構：算法與驗簽信息的載體

在分析函數前，先理解幾個核心結構體——它們是整個驗簽邏輯的“數據骨架”。

1.哈希算法結構體checksum_algo

structchecksum_algo { constchar*name;     // 算法名（sha1/sha256） intchecksum_len;     // 哈希值長度 intder_len;       // DER前綴長度 constuint8_t *der_prefix;// DER編碼前綴（適配ASN.1規范）  EVP_MD *(*calculate_sign)();// 簽名用哈希計算函數 int(*calculate)();    // 通用哈希計算函數};

作用：封裝SHA1/SHA256兩種哈希算法的核心屬性，關聯哈希計算的具體實現，是后續生成/驗證哈希值的基礎。

2.加密算法結構體crypto_algo

structcrypto_algo { constchar*name;     // 算法名（rsa2048/rsa4096） intkey_len;       // 密鑰長度（字節） int(*sign)();      // 簽名函數 int(*add_verify_data)(); // 添加驗證數據 int(*verify)();     // 驗簽函數};

作用：封裝RSA2048/RSA4096兩種非對稱加密算法，關聯簽名/驗簽的核心邏輯，是驗簽的核心執行者。

3.填充算法結構體padding_algo

structpadding_algo { constchar*name;     // 填充方式（pkcs-1.5/pss） int(*verify)();     // 填充驗證函數};

作用：適配不同的RSA填充規范（PKCS1.5是默認，PSS更安全），通過配置開關CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT控制是否啟用PSS。

4.驗簽上下文image_sign_info

這個結構體未在代碼中顯式定義，但從函數參數能看出其核心作用：承載一次驗簽的所有上下文信息，包括：

?算法指針（哈希/加密/填充）；

?FIT鏡像指針、節點偏移量；

?密鑰名、驗證所需的FDT blob；

?必需的密鑰節點索引。

三、核心函數解析：從算法查找到驗簽落地

image-sig.c的函數可分為三大類：算法查找、輔助工具、驗簽核心，我們逐一拆解。

1.算法查找函數：匹配字符串與算法實現

驗簽的第一步是“識別算法”——從FIT鏡像節點的屬性字符串（如sha256,rsa2048）中，匹配到對應的算法結構體。

（1）image_get_checksum_algo：查找哈希算法

structchecksum_algo *image_get_checksum_algo(constchar*full_name);

?輸入：完整算法名（如sha256,rsa2048）；

?邏輯：遍歷checksum_algos數組，匹配前綴（如sha256）且后續字符為逗號，返回對應的哈希算法結構體；

?輸出：匹配到的checksum_algo指針（NULL表示未匹配）。

（2）image_get_crypto_algo：查找加密算法

structcrypto_algo *image_get_crypto_algo(constchar*full_name);

?輸入：完整算法名（如sha256,rsa2048）；

?邏輯：先截取逗號后的字符串（如rsa2048），再遍歷crypto_algos數組匹配算法名；

?輸出：匹配到的crypto_algo指針（NULL表示未匹配）。

（3）image_get_padding_algo：查找填充算法

structpadding_algo *image_get_padding_algo(constchar*name);

?輸入：填充算法名（如pkcs-1.5）；

?邏輯：遍歷padding_algos數組匹配名稱；

?輸出：匹配到的padding_algo指針（NULL表示未匹配）。

2.輔助工具函數：FDT區域到鏡像區域的轉換

structimage_region *fit_region_make_list(constvoid*fit, structfdt_region *fdt_regions,intcount, structimage_region *region);

?核心作用：將FDT（設備樹）格式的區域信息，轉換為U-Boot鏡像驗簽所需的image_region結構體；

?關鍵細節：

a.非SPL構建：自動調用calloc分配內存（SPL為節省代碼量，要求調用者提前分配）；

b.填充image_region的data（鏡像數據指針）和size（數據長度）；

c.輸出調試信息（偏移量、大?。?，方便調試哈希區域。

3.驗簽核心函數：從初始化到最終驗證

驗簽邏輯是層層封裝的，從“單節點驗簽”到“批量驗簽”，再到“配置節點驗簽”，形成完整的驗證鏈路。

（1）fit_image_setup_verify：驗簽前的初始化

staticintfit_image_setup_verify(structimage_sign_info *info, constvoid*fit,intnoffset,intrequired_keynode, char**err_msgp);

?核心職責：為驗簽做準備，填充image_sign_info上下文；

?執行流程：

a.從FIT節點獲取哈希算法名、填充方式（默認PKCS1.5）；

b.初始化info結構體：密鑰名、FIT鏡像指針、節點偏移量；

c.調用算法查找函數，綁定哈希/加密/填充算法；

d.校驗算法是否有效，無效則返回錯誤信息。

（2）fit_image_check_sig：單個簽名節點的驗簽

intfit_image_check_sig(constvoid*fit,intnoffset,constvoid*data, size_tsize,intrequired_keynode,char**err_msgp);

?核心職責：驗證單個簽名節點的有效性；

?執行流程：

a.調用fit_image_setup_verify初始化上下文；

b.從FIT節點讀取預計算的哈希值（fit_value）；

c.構造鏡像區域（image_region），包含待驗證數據的指針和長度；

d.調用加密算法的verify函數，驗證哈希值與簽名是否匹配；

e.返回驗證結果（0成功，-1失?。?/p>

（3）fit_image_verify_sig：遍歷鏡像節點的簽名子節點

staticintfit_image_verify_sig(constvoid*fit,intimage_noffset, constchar*data,size_tsize,constvoid*sig_blob, intsig_offset);

?核心職責：遍歷鏡像節點下的所有簽名子節點（以sig-開頭），批量驗簽；

?執行流程：

a.遍歷FIT鏡像節點的所有子節點，篩選出簽名節點；

b.對每個簽名節點調用fit_image_check_sig驗簽；

c.只要有一個簽名驗證通過，標記verified=1并返回成功；

d.若遍歷出錯（如FDT結構損壞），返回錯誤信息。

（4）fit_image_verify_required_sigs：驗證“必需”的簽名

intfit_image_verify_required_sigs(constvoid*fit,intimage_noffset, constchar*data,size_tsize,constvoid*sig_blob, int*no_sigsp);

?核心職責：只驗證標記為“required=image”的簽名節點（這類簽名必須通過，否則啟動失?。?/p>

?執行流程：

a.查找簽名blob中的sig節點；

b.遍歷子節點，篩選出required="image"的節點；

c.調用fit_image_verify_sig驗證，失敗則直接返回錯誤；

d.統計驗證通過的數量，更新no_sigsp（標記是否有簽名）。

（5）fit_config_check_sig：配置節點的驗簽（進階）

intfit_config_check_sig(constvoid*fit,intnoffset,intrequired_keynode, char**err_msgp);

?核心場景：驗證FIT鏡像的配置節點（而非鏡像數據），防止配置被篡改；

?特殊邏輯：

a.解析hashed-nodes屬性：獲取需要哈希的子節點列表；

b.校驗節點數量（不超過IMAGE_MAX_HASHED_NODES=100），防止棧溢出；

c.調用fdt_find_regions：查找所有需要哈希的FDT區域；

d.處理hashed-strings屬性：將字符串區域加入哈希列表；

e.轉換為image_region后調用驗簽函數，完成配置驗證；

f.適配硬件加密：如RK的SPL+Secure OTP，驗簽后燒錄密鑰哈希。

（6）配置節點驗簽的封裝函數

fit_config_verify_sig/fit_config_verify_required_sigs/fit_config_verify是對fit_config_check_sig的封裝，邏輯與鏡像節點驗簽類似：遍歷配置節點的簽名子節點→驗證“required=conf”的簽名→返回最終結果。

4.特殊場景：回滾保護

代碼末尾的fit_read_otp_rollback_index/fit_rollback_index_verify是“回滾保護”的弱實現：

?讀取OTP中的回滾索引，防止攻擊者降級到舊版本（有安全漏洞的版本）；

?采用__weak修飾，支持廠商自定義實現（如基于硬件OTP的索引校驗）。

四、數據處理全流程：從觸發驗簽到驗證完成

我們以“鏡像節點驗簽”為例，梳理完整的數據走向，流程圖如下：

流程圖核心說明：驗簽流程層層封裝、逐步遞進，優先驗證“必需簽名”，確保啟動安全性；單個簽名節點驗證需完成算法綁定、哈希讀取、匹配校驗三大核心步驟，任一環節失敗則啟動終止。

1.啟動觸發驗簽 → 傳入FIT鏡像指針、鏡像節點偏移量2.調用fit_image_verify_required_sigs → 篩選required=image的簽名節點3.調用fit_image_verify_sig → 遍歷鏡像節點下的sig-*子節點4. 對每個sig節點調用fit_image_check_sig： a. fit_image_setup_verify → 解析算法名→匹配哈希/加密/填充算法 b. 讀取FIT節點中的哈希值（fit_value） c. 構造image_region（待驗證數據的指針+長度） d. 調用crypto_algo->verify → 驗證哈希值與簽名匹配5.驗證通過→返回0；驗證失敗→輸出錯誤信息→返回-16.所有required簽名驗證通過→啟動鏡像；否則→啟動失敗

配置節點驗簽的流程類似，核心差異是：哈希區域從“鏡像數據”變為“配置節點的子節點+字符串區域”。

五、代碼設計的亮點與擴展思路

1.設計亮點

?模塊化：算法與驗簽邏輯解耦，新增算法只需修改checksum_algos/crypto_algos數組；

?可配置：通過宏開關（如CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT）控制功能，適配不同場景；

?內存適配：區分SPL/非SPL構建，兼顧代碼量和易用性；

?調試友好：輸出詳細的調試信息（哈希區域、算法名），方便問題定位。

2.擴展思路

?新增哈希算法（如SHA512）：在checksum_algos數組中添加新項，實現對應的哈希計算函數；

?支持ECDSA加密：擴展crypto_algos結構體，添加ECDSA的簽名/驗簽函數；

?強化回滾保護：基于硬件OTP實現強校驗，替換默認的__weak函數；

?適配TEE：結合OP-TEE（代碼中已引入OpteeClientInterface.h），將驗簽邏輯移到安全世界執行。

六、總結

image-sig.c是U-Boot FIT鏡像安全的核心，它以“算法抽象+流程封裝”的方式，實現了哈希計算、簽名驗證、配置校驗的完整邏輯。理解這份代碼，不僅能掌握U-Boot安全啟動的底層原理，也能為嵌入式系統的安全加固提供思路——比如如何設計可擴展的驗簽框架、如何適配不同的硬件安全特性。

在實際開發中，廠商通常會基于這份代碼做定制化：比如適配自研的硬件加密模塊、強化回滾保護、新增國密算法（SM2/SM3）等。而掌握核心邏輯后，這些定制化開發都會變得清晰可落地。

最后，安全啟動的核心是“全鏈路可信”，image-sig.c只是其中一環，還需要結合鏡像加密、OTP燒錄、硬件隔離等技術，才能構建真正的安全啟動體系。

審核編輯 黃宇