點擊上方藍字談思實驗室

獲取更多汽車網絡安全資訊

1.1 先搞清楚威脅從哪來

你要理解一個功能，先得知道它防的是誰。安全啟動防的不是意外，是惡意。

第一類威脅，固件篡改。攻擊者把固件逆向出來，改幾行邏輯，比如把電池管理里的過充保護閾值改掉，把制動相關的標定參數改掉，然后把改過的固件刷進 ECU。這種攻擊不需要多高的技術，工具鏈現在很成熟。車一旦跑起來，后果就是實打實的安全事故。

第二類威脅，非法刷寫。這不一定是為了攻擊，更多是為了利益。有人想繞過付費功能，有人想去 4S 店之外刷機，有人想把高配功能刷進低配車。這些行為本身可能沒有惡意，但它們用的通道和工具不受控，刷進去的東西沒人給你保證質量，出事了算誰的？車廠肯定不認。

第三類威脅，降級攻擊。這個最陰。某版本固件修了一個安全漏洞，攻擊者沒法把惡意代碼刷進去，但他可以把你系統里記錄"當前已是最新版本"的機制繞過去，刷回一個存在已知漏洞的舊版本，然后利用那個漏洞發起攻擊。這就是為什么要有防回滾，后面單獨講。

還有一類，供應鏈側的。產線、維修站、第三方供應商，只要有人能接觸到燒錄工具和密鑰，就有風險。安全啟動設計的時候，默認這些人也不完全可信。

1.2 一句話說清 Secure Boot

Secure Boot 的本質

Secure Boot，安全啟動，本質就是一條驗簽鏈。每次上電，從信任根開始，每一級代碼先驗證下一級代碼的簽名和完整性，驗證通過了，才把執行權交給它。任何一級驗不過，啟動流程立刻終止，絕不繼續往下走。

注意這個設計思路：不是"驗證完整個系統再啟動"，而是"邊啟動邊驗證，逐級放行"。好處是每一級只信任它直接驗證過的下一級，中間不需要一個全知全能的驗證器。壞處是鏈條上任何一環出問題，整條鏈就斷了，表現就是啟動失敗、黑屏、進不去系統。

1.3 信任根（Root of Trust）

"信任根"這個名字起得很形象。整條驗證鏈的信任，最終都要追溯到某一個起點，這個起點就是信任根。它有一個關鍵特性：它自己不被任何東西驗證，它必須是先天可信的。

憑什么先天可信？因為它在物理上改不了。車載里常見的做法有兩種。

一種是把一段代碼固化在芯片的 ROM 里，出廠就燒好了，芯片流片之后就再也改不了，這種叫 BootROM。上電以后，CPU 執行的第一條指令就來自這里。

另一種是把公鑰燒死在一次性可編程存儲器里，叫 OTP 或者 eFuse。熔絲結構，燒進去就斷，物理上不可逆。這根公鑰就是整條鏈的信任錨點，所有驗簽最終都歸結到"用這把公鑰驗"。

信任根是整個安全啟動的地基。地基要是塌了，上面蓋什么都白搭。后面講踩坑的時候你會看到，很多重大事故的根源就是信任根沒守住。

1.4 信任鏈（Chain of Trust）

有根還不夠，光有一個可信的起點，管不了后面那么長的啟動流程。所以要把信任一級一級傳遞下去，這就叫信任鏈。

典型的車載啟動鏈長這樣：ROM Code → Bootloader（可能分好幾級）→ 應用固件。

每一級做什么？驗證下一級的簽名和完整性，驗證通過就把執行權交出去。信任像接力棒一樣，一級一級傳下去，最后傳到應用固件。應用固件能跑起來，意味著整條鏈上的每一環都驗證過它后面的那一環。

信任鏈的設計有個核心原則：每一級只信任它驗證過的東西，絕不在沒有驗證的情況下加載任何外部代碼。任何繞過這個原則的設計，都是在給攻擊者留后門。

2.1 第一級：ROM Code

ROM Code 是芯片上電后的第一條代碼，固化在芯片內部，不可修改。它的任務很純粹：初始化最小限度的硬件環境，把信任根的代碼和公鑰準備好，然后驗證 Bootloader 的簽名。

別小看這一級，它有幾個設計要點。

第一，ROM Code 要盡可能小。芯片 ROM 空間有限，塞不下復雜邏輯。所以 ROM Code 一般只做最必要的事：設置時鐘、初始化內存控制器、把 Bootloader 從存儲介質里讀出來、驗簽、跳轉。

第二，ROM Code 里要處理多種啟動介質。NOR Flash、eMMC、SD 卡、串口、USB，不同的存儲介質有不同的初始化流程和讀取方式。ROM Code 通常支持從多個介質啟動，并且有優先級順序。

第三，ROM Code 本身沒有回頭路。它一旦把執行權交給 Bootloader，就退出了舞臺。所以它必須保證交出去的 Bootloader 是可信的，這是它存在的唯一意義。

有些芯片的 ROM Code 還支持安全啟動模式選擇。通過熔絲或者引腳配置，可以選"強制驗簽模式"和"兼容模式"。量產的時候必須強制驗簽模式，兼容模式是給開發調試用的，出廠前要關死。

2.2 第二級：Bootloader

Bootloader 是整個啟動鏈里最復雜的一級，因為它承擔了最多的職責。在車載系統里，Bootloader 通常還分階段，比如 BL1 和 BL2，或者叫 SBL（Secondary Boot Loader）和 FSBL（First Stage Boot Loader），叫法不同，思路一樣：一小段代碼先起來，把環境準備好，再加載更大的一段。

Bootloader 要干的活包括：

• 加載和驗證應用固件。

  這是安全啟動的核心職責，從存儲介質讀出應用固件鏡像，驗簽，驗完整性，過了才跳轉。

• 管理啟動項。

  多系統、多分區的情況下，Bootloader 要決定啟動哪個分區、哪個系統。這個選擇本身也要受保護，不能被人隨意改。

• 管理版本和回滾。

  升級失敗要能回退，但回退要有底線，不能隨便退到有漏洞的版本。版本號的管理邏輯一般就在 Bootloader 里。

• 記錄啟動日志。

  驗簽結果、失敗原因、啟動路徑，這些都要記下來，不然出了問題沒法排查。

還有一個容易忽略的點：Bootloader 自身也是要升級的。Bootloader 升級的安全性和應用固件升級一樣重要，因為 Bootloader 一旦被換掉，整條鏈就失守了。所以 Bootloader 升級通常有更嚴格的保護，比如要求更高的權限認證。

2.3 第三級：應用固件

應用固件是啟動鏈的最后一環，也是用戶能感知到的一環。它被 Bootloader 驗證通過之后，才真正開始運行。

這里有個容易忽略的細節：應用固件的驗證粒度。有的系統只驗證整個固件鏡像，有的系統會把鏡像拆成多個部分，分別驗證。比如把安全關鍵模塊單獨拎出來驗證，非關鍵部分可以放寬。粒度越細，安全性越高，但啟動流程也越復雜，啟動時間越長。怎么平衡，是架構設計時要權衡的事。

還有一類系統會在應用運行起來之后做"運行時校驗"。啟動時驗一次，運行過程中再周期性地校驗關鍵代碼段的內存內容，防止運行期間被篡改。這屬于安全啟動的延伸，叫運行時完整性保護，和啟動時的驗簽是互補關系。

2.4 每一級到底驗什么

很多人以為驗簽就是驗個簽名，其實每一級驗證的內容至少有三項，缺一不可。

每一級驗三件事

第一項，簽名，驗證身份。用公鑰對固件簽名做驗簽運算，確認這份固件確實是由持有對應私鑰的合法簽發方簽發的。這一項解決的是"你是誰"的問題。

第二項，完整性，驗證內容。對固件鏡像做哈希運算，和簽名里攜帶的期望哈希比對，一致說明內容沒被改過。這一項解決的是"你有沒有被動過"的問題。

第三項，版本，驗證新舊。檢查固件版本號是否滿足防回滾策略，比如不低于當前記錄的最低版本。這一項解決的是"你是不是被降級了"的問題。

三項全過，才放行。任何一項不過，啟動失敗。很多事故排查到最后，發現是三項里某一項的實現有問題，比如完整性校驗只查了鏡像頭沒查正文，或者版本號比較的邊界條件寫錯了。

2.5 把啟動鏈畫出來

用文字畫一張圖，這條鏈長這樣：

ROM Code --驗簽--> BL1 --驗簽--> BL2 --驗簽--> 應用固件

每根箭頭都代表一次完整的驗簽過程：加載下一級鏡像、算哈希、驗簽名、查版本。整個啟動過程就是把這根鏈條走一遍。

3.1 非對稱簽名：RSA 和 ECC

驗簽的核心是非對稱密碼學。一套密鑰對，一把私鑰一把公鑰。私鑰簽名，公鑰驗簽。私鑰永遠只存在于簽發方手里，車上的設備只有公鑰。

為什么不用對稱密鑰？因為對稱密鑰雙方都有，設備被攻破，密鑰就泄露了，攻擊者拿到密鑰就能自己簽發固件。非對稱方案里，設備上只有公鑰，公鑰泄露了也沒關系，沒有私鑰就簽不出合法的固件。這就是非對稱方案在安全啟動里不可替代的原因。

具體算法，主流是兩種。

RSA。經典算法，車載上用得很多。常見強度是 2048 位。優點是生態成熟，工具鏈齊全，兼容性好。缺點是驗簽運算量大，尤其是軟件實現的時候，一次驗簽可能幾十到幾百毫秒。RSA 的公鑰長度也大，證書和簽名塊都占空間。

ECC。橢圓曲線算法，用更短的密鑰達到同等安全強度，常見的是 P-256 曲線。驗簽速度快，密鑰短，特別適合資源受限的 MCU 和啟動時間緊張的場合。車載新平臺的驗簽越來越多用 ECC。

很多平臺是混合方案：ROM 和 Bootloader 之間用 ECC，因為要快、要省空間；Bootloader 和應用之間用 RSA，因為要和既有工具鏈兼容；或者反過來。混合方案靈活，但維護成本高，兩套密鑰、兩套工具鏈、兩套流程，都得管好。

3.2 哈希：SHA-256

驗簽的對象不是整個固件，固件太大了。實際做法是：先對固件算一個哈希值，再對哈希值做簽名。驗簽的時候，同樣先算固件哈希，再用公鑰解開簽名得到期望哈希，兩個哈希一致，說明固件完整且簽名有效。

這里哈希算法的作用是把任意長度的固件壓縮成固定長度的摘要，同時保證哪怕固件改了一個比特，哈希值也會面目全非。SHA-256 是目前的主流選擇，輸出 256 位，抗碰撞性在可預見的未來都足夠。要求更高的場合可以用 SHA-384 或者 SHA-512。

哈希計算有個工程細節：大鏡像的哈希計算很耗時，動輒幾十毫秒甚至上百毫秒，而且算的時候要完整讀一遍存儲介質。啟動時間優化的時候，這個往往是重點優化對象。有的方案用 DMA 搬運數據配合硬件哈希加速器，有的方案把鏡像分區、只對關鍵分區做完整校驗。

3.3 公鑰存在哪

公鑰的存儲位置，直接決定了安全啟動的安全性等級。公鑰不怕被人看到，怕的是被人替換。一旦公鑰被換成攻擊者的公鑰，攻擊者就能用他自己的私鑰簽固件，整條驗證鏈形同虛設。

所以公鑰存儲的第一原則是：不能被替換。

最保險的是燒在 OTP 或 eFuse 里。物理熔絲，燒了就斷，改不了。根公鑰必須放這里。代價是：公鑰一旦燒死，將來想換密鑰對，只能換芯片。所以量產前想清楚，公鑰丟了或者想升級算法，成本很高。

次一檔是存在安全存儲區里，比如 HSM 的安全存儲。這種方案可以更新公鑰，但更新必須走安全流程，比如要求舊密鑰簽名授權。好處是靈活，壞處是流程復雜，一旦流程有漏洞，公鑰替換攻擊就會發生。

還有一種常見的分層做法：根公鑰燒在 OTP 里，二級公鑰或者證書放在 Flash 里，用根公鑰驗證二級公鑰的證書鏈。這樣既保證了信任根的不可篡改，又保留了密鑰更新的靈活性。這是車載里最主流的做法。

3.4 防回滾（Anti-rollback）

防回滾解決的是降級攻擊問題。攻擊者刷不回惡意固件，但可以刷回舊版本，利用舊版本里的已知漏洞。

實現思路：在不可篡改的存儲里記錄一個安全版本號或者安全計數器，每次啟動和升級的時候檢查。新固件的版本號必須大于等于記錄值，才允許運行和安裝。一旦升級成功，記錄值就更新到新版本號，并且只能增不能減。

實現思路：在不可篡改的存儲里記錄一個安全版本號或者安全計數器，每次啟動和升級的時候檢查。新固件的版本號必須大于等于記錄值，才允許運行和安裝。一旦升級成功，記錄值就更新到新版本號，并且只能增不能減。

防回滾的設計要小心一個坑：版本號的語義要統一。有的系統用日期當版本號，有的用自增整數，有的用 Build 號。不同系統之間的版本號比較規則必須一致，否則會出現"新版本被當成舊版本拒絕"或者"舊版本被當成新版本放行"的荒謬情況。后面踩坑部分會詳細講。

4.1 HSM 是什么

HSM，Hardware Security Module，硬件安全模塊。名字很直白，就是一個專門干安全活兒的硬件模塊。在車規芯片里，它通常是一個獨立的安全島：有自己獨立的 CPU 核心，獨立的內存，獨立的總線，獨立的真隨機數發生器，還有專門的密碼學硬件加速器。

"獨立"這個詞是關鍵。HSM 和主核之間是物理隔離的，它自己有獨立的電源域、時鐘域，主核出問題、被攻破、甚至主核整個崩潰，都不影響 HSM 的安全功能。

車載領域有個相關的規范叫 SHE，Secure Hardware Extension，定義了 HSM 的密鑰槽位管理、安全啟動模式、計數器保護這些基礎能力。很多車規芯片的 HSM 實現都兼容 SHE 的思路。AUTOSAR 的 Crypto Stack 也定義了主核和 HSM 之間的標準接口，CSM（Crypto Service Manager）負責把密碼學請求分發到硬件。

4.2 密鑰存儲：HSM 的核心價值

HSM 最核心的價值，是密鑰的物理保護。車上的敏感密鑰——驗簽用的根公鑰、升級用的密鑰、安全通信的會話密鑰、數據加密的存儲密鑰——都放在 HSM 內部的安全存儲里。

關鍵特性是：這些密鑰對主核是不可讀的。主核可以請求 HSM"用某把密鑰做驗簽"、"用某把密鑰做解密"，但主核永遠拿不到密鑰本身。這就好比你把保險柜的鑰匙交給保安，你可以讓保安幫你開鎖，但你拿不到保險柜的鑰匙。

物理層面，HSM 還有側信道防護。攻擊者想通過功耗分析、電磁輻射分析把密鑰摳出來，HSM 有對應的防護措施。對芯片做物理探測、用聚焦離子束去切割芯片讀存儲，也有相應的防護設計。當然防護等級和成本成正比，車規芯片的 HSM 防護等級由安全需求決定，不是越高越好。

4.3 驗簽加速

驗簽是啟動鏈上每級都要做的運算，而 RSA 驗簽在軟件實現下非常慢。這里 HSM 的硬件加速器就派上用場了。

同樣一次 RSA-2048 驗簽，純軟件在 MCU 上可能要幾百毫秒，硬件加速器只要幾毫秒，差一個數量級。啟動時間預算通常卡得很緊，冷啟動多少秒以內有硬性要求，驗簽這個環節不加速，整個啟動時間就壓不下來。

實際工程里，驗簽流程通常是：主核把鏡像的哈希和簽名數據交給 HSM，HSM 用存儲的公鑰做驗簽運算，返回結果。主核只負責編排流程，重活全在 HSM 里干。有些實現里，哈希計算也在 HSM 里做，主核只負責搬數據，性能更好。

4.4 安全存儲

除了密鑰，HSM 還提供安全存儲能力，用來存那些"必須防篡改、防回退"的數據。典型的就是防回滾的安全計數器、設備證書、密鑰版本信息、啟動配置。

HSM 安全存儲的特點是：寫入受權限控制，讀取受權限控制，數據有完整性保護和防回退保護。普通代碼沒權限訪問，主核上的軟件攻擊拿不到這些數據，篡改更不可能。

這里有個設計要點：哪些數據必須進 HSM 安全存儲，哪些放普通存儲就行。原則是，凡是影響安全決策的數據，都要進安全存儲。比如防回滾計數器，進普通 Flash 等于沒有。比如啟動配置里決定"是否強制驗簽"的開關，也必須進安全存儲，不然攻擊者改一個字節就關掉了安全啟動。

4.5 HSM 與主核的分工

最后把 HSM 和主核的分工理清楚。

主核負責：系統啟動流程的編排、外設初始化、操作系統加載、應用運行。主核的定位是"快而全"，性能優先。

HSM 負責：密鑰管理、驗簽運算、加解密、真隨機數、安全存儲、安全計數器。HSM 的定位是"小而專"，安全優先。

兩者之間通過定義好的接口通信。主核發起安全請求，HSM 處理完返回結果。這個接口的設計要特別注意：要有明確的握手和超時機制。主核和 HSM 的啟動是各自獨立的，如果主核在 HSM 還沒就緒的時候就發請求，就會得到錯誤結果或者卡死。這是實際工程里非常常見的問題，后面踩坑部分會講。

還有一個重要觀念：主核和 HSM 的信任關系是單向的。HSM 不信任主核，主核的任何請求都要經過授權和校驗；而主核必須信任 HSM 返回的結果。這個單向信任是安全架構的基石，設計接口的時候不要搞反。

5.1 密鑰丟了，車變磚

先講最慘的。某項目量產前夕，發現產線燒錄用的簽名密鑰不知道在誰手里，中間換過幾個人，交接文檔只寫了"密鑰在服務器上"，服務器密碼又沒人知道。結果就是：固件簽不了名，產線停產，OTA 升級包發不出去。更麻煩的是，安全啟動一旦開啟，沒有合法簽名的固件根本刷不進去，等于所有設備鎖死。

這種坑的根源不是技術，是管理。密鑰管理必須制度化：測試密鑰和量產密鑰嚴格分離，密鑰生成、存儲、使用、銷毀全流程記錄，密鑰備份離線冷備，至少兩個人分別保管備份。別覺得這是小題大做，真出事的時候，一顆密鑰能讓整個項目停擺。

還有一類密鑰事故是開發階段的：開發板用的測試密鑰，忘了換，帶著測試密鑰上了量產。測試密鑰可能已經在各種文檔、代碼倉庫、教程里出現過，等于公鑰對不上或者私鑰泄露，安全啟動形同虛設。

5.2 公鑰被替換

這個坑出在設計階段。某項目把公鑰存在普通 Flash 里，理由是"方便升級公鑰"。結果安全評估的時候發現，攻擊者只要拿到寫 Flash 的權限，就能把公鑰換成自己的，然后用自己簽的固件刷機，安全啟動完全失效。

正確的做法前面講過：根公鑰必須燒 OTP，可更新的公鑰要走證書鏈驗證。凡是把公鑰放普通存儲、又沒有完整性保護的方案，都默認是裸奔。

還有一個容易被忽略的點：公鑰在加載進內存之后，內存里的公鑰同樣可能被篡改。驗簽之前要確認公鑰來源可信，驗簽用的公鑰要來自安全存儲或者受保護的加載路徑，而不是從鏡像里隨便讀出來的。

5.3 驗簽太慢，啟動超時

性能坑。某項目用純軟件實現 RSA-2048 驗簽，三級啟動鏈，每級一次驗簽，加上大鏡像哈希計算，冷啟動總時間超標了將近一倍。客戶驗收的標準擺在那，啟動慢就是不合格。

優化思路有幾個方向。

• 第一，換硬件加速。

  驗簽運算交給 HSM 或者芯片的密碼學協處理器，這是最直接有效的。

• 第二，優化哈希計算。

  用 DMA 搬運數據，用硬件哈希引擎，避免 CPU 一遍遍讀存儲介質。

• 第三，流水線化。

  把驗簽和硬件初始化、外設配置重疊起來，別串行地等。

• 第四，分級校驗。

  關鍵分區完整校驗，非關鍵分區抽樣校驗或者延后校驗，把啟動路徑上的熱點時間降下來。

性能和安全是直接沖突的，怎么平衡要看項目需求。但有一條底線：啟動時間的優化不能以犧牲驗證強度為代價，別為了省時間把校驗關了，那等于安全啟動白做。

5.4 防回滾版本號配錯

開頭說的那個黑屏案子，就是版本號配錯。項目里版本號規則不統一：Bootloader 用自增整數，應用固件用日期格式，升級工具里又有一套自己的算法。結果某次升級，新版本按升級工具的規則算出來比記錄值小，被防回滾機制當成降級拒絕；更糟的是另一臺設備上，升級工具寫了一個比實際版本大的記錄值，導致后續所有版本都被拒絕，設備直接變磚，只能返廠。

這個坑的教訓：版本號的格式、語義、比較規則必須在項目里統一，并且要寫清楚。防回滾計數器怎么更新、在什么時機更新、更新失敗怎么處理，都要定義清楚。測試的時候，升級、降級、重復升級、跨版本升級，全場景覆蓋。

還有個細節：防回滾的檢查時機。有的實現只在啟動時檢查，有的在升級時也檢查。如果只在升級時檢查，攻擊者可以繞過升級流程直接刷寫舊版本鏡像，然后正常啟動，防回滾就沒攔住。所以啟動時和升級時的檢查都要有，兩條路都堵死。

5.5 HSM 與主核同步問題

HSM 和主核各自獨立啟動，這里有個天然的同步問題。主核跑得快，HSM 可能還在初始化；主核調用驗簽接口的時候，HSM 還沒就緒，返回錯誤，主核如果沒做容錯，直接把錯誤當成驗簽失敗，啟動就掛了。

這種問題在開發階段表現成"啟動不穩定，十次有兩次失敗"，最難查。排查思路：先確認 HSM 的就緒信號機制，主核必須等 HSM ready 之后再發請求；接口要有明確的錯誤碼和超時處理，不能把超時當成驗簽失敗；日志里要把 HSM 狀態和主核狀態打出來，方便對時間線。

還有一種同步問題在復位場景：看門狗復位、電源波動復位，主核和 HSM 的復位時序不一致，導致狀態錯亂。設計上要保證復位時序可控，HSM 和主核的復位要有明確的先后關系。

6.1 從啟動日志入手

調試安全啟動問題，第一件事是看日志。啟動鏈每一級的驗簽都應該有日志：驗證對象是誰、用的哪把公鑰、驗簽結果、耗時。日志分級要做好：驗簽失敗必須打錯誤級日志，正常流程打信息級或調試級日志，別把正常驗簽打成錯誤，也別把錯誤打成調試，不然日志刷屏找不著重點。

日志里絕對不能出現的東西：密鑰、簽名值、證書內容。這些屬于敏感數據，打到日志里就是給攻擊者送情報。日志要留現場信息：失敗發生在哪一級、錯誤碼是什么、鏡像的來源和版本。

很多芯片的 ROM Code 階段沒有完整日志能力，因為那時串口和存儲都還沒初始化。這種階段的問題要靠別的辦法，比如用調試器、用狀態指示燈、用特殊引腳輸出，甚至用 ROM Code 自帶的診斷模式。

6.2 驗簽失敗怎么定位

拿到日志之后，定位驗簽失敗分三步。

第一步，確認失敗在哪一級。看日志最后一條有效記錄，是 ROM Code 驗 Bootloader 失敗，還是 Bootloader 驗應用失敗。這一下就把排查范圍縮小到兩級代碼之間。

第二步，確認失敗類型。簽名驗證失敗、哈希比對失敗、版本檢查失敗，三種失敗的排查方向完全不同。簽名失敗查公鑰和密鑰對，哈希失敗查鏡像完整性和燒錄流程，版本失敗查版本號和防回滾配置。

第三步，查具體原因。常見原因排一排：鏡像壓根沒簽名、簽名用的密鑰和驗簽的公鑰不匹配、鏡像在燒錄或傳輸過程中被改、版本號落后于安全記錄值、證書鏈不完整、算法不匹配，比如簽名用的是 SHA-256 但驗簽代碼期待 SHA-384。這幾種原因占了絕大多數問題。

6.3 仿真器和調試器看啟動流程

日志解決不了的時候，上調試器。在驗簽函數的入口打斷點，單步跟蹤，看流程走到哪一步、在哪一步跳到了錯誤分支。

調試器能看的東西很具體：加載進內存的鏡像是不是預期內容、公鑰有沒有被正確加載到驗簽上下文、鏡像頭部解析出來的版本號是多少、簽名塊的長度和位置對不對、HSM 接口調用的參數和返回值。

有幾個細節值得盯。內存對齊：有些哈希引擎和驗簽引擎要求數據對齊，沒對齊直接報錯。端序問題：鏡像的簽名塊如果是大端格式，而驗簽代碼按小端解析，簽名必然驗不過，這種問題在移植代碼的時候特別容易出。還有證書解析：證書格式、簽名算法標識符、有效期這些字段，任何一個不對，證書鏈驗證就會失敗。

仿真器還有個用法：跑完整啟動流程，抓時序。驗證各階段的耗時，看是不是有隱藏的性能瓶頸，比如某個階段的存儲讀取特別慢，或者驗簽等待時間過長。

6.4 一份排查清單

• 公鑰對不對：OTP 里燒的公鑰和簽名密鑰是否配對，可以用已知的測試向量驗證。有的芯片支持回讀 OTP 校驗，有的只能通過簽名驗證間接確認。

• 簽名工具鏈對不對：簽名工具和驗簽代碼是否用同一套算法參數，證書格式是否兼容。工具鏈版本升級之后，這個最容易出問題。

• 鏡像有沒有被處理過：燒錄工具會不會給鏡像加頭、加校驗、加偏移，這些處理和驗簽代碼的預期是否一致。加過頭沒減掉，哈希就對不上。

• 安全配置有沒有生效：強制驗簽模式是否真的開啟，熔絲配置是否燒對，有沒有殘留的調試后門。

• 時鐘和隨機數：驗簽依賴的一些硬件模塊是否完成初始化，比如真隨機數發生器、密碼學協處理器的時鐘。初始化順序不對，驗簽就會出莫名其妙的問題。

• 日志和錯誤碼：錯誤碼定義是否完整，日志是否覆蓋了所有失敗路徑。有些實現失敗路徑不打印日志，排查的時候兩眼一抹黑，這種代碼要及時補上。

安全啟動不是一個開關，是一條鏈。從 ROM Code 到 Bootloader 到應用固件，每一環都驗證下一環，任何一環斷了，整條鏈就斷了。而 HSM 是這條鏈上最值得信任的一環，密鑰、驗簽、安全存儲、防回滾計數器，都壓在它身上。

寫這篇文章最想強調的其實就兩件事。第一，信任根要守住，密鑰要管好，這是安全啟動的地基，地基塌了什么都白搭。第二，別把安全啟動當成一個"加上就完事"的功能，它是整個安全體系里最先執行、也最容易被攻破的一環。從設計、實現到測試，每一步都得認真對待。

希望這篇文章能幫你把安全啟動這條鏈看明白。下次再有人問你"安全啟動到底在驗什么"，你可以直接告訴他：驗的是信任，一級一級往下驗，驗不過，就別想跑。

來源：車載軟件研習社