先看攻擊者為什麼搶在 OS 前面
Boot Code 比作業系統與防護軟體更早取得執行機會。這個時間差，正是攻擊者想替換早期映像的原因，也是 Secure Boot 必須把檢查放在執行之前的原因。
十二張圖會從威脅模型開始，依序建立 Reset 起點、Trust Anchor、雜湊、簽章、版本政策、失敗處理與受驗證 Recovery。閱讀時只追一條線：每個下一階段，什麼時候才拿到執行權？
1. 駭客為什麼要偷換 Boot Code？
開機流程從 Reset 開始，接著是 Boot Code，然後才輪到 OS 與防護軟體。惡意程式若能塞進最前段，後面的掃描工具還沒醒來，它就已經拿到執行機會。越早跑，越有機會干預後面載入的東西——這是時間差，不是「一定會成功」的保證。
偷換也有前提：攻擊者得先改到某段 Boot Image。圖上列了三條常見路——可改寫的開機儲存、受污染的更新路徑、實體或高權限存取——旁邊小字提醒：不是每個平台都暴露同一組入口。威脅模型要先問「誰能改什麼」，不能看到韌體兩個字就假定一定換得掉。[1]
惡意 Boot Code 可能想做的事很多：隱藏蹤跡、跨重開機留下來、改寫後續載入、伺機偷密碼或金鑰，甚至讓設備乾脆開不起來。圖上也寫清楚：這些是可能目標，不是每次替換都必然達成。
防禦那一格把方向講清楚：不是先讓它跑，再猜是不是惡意；而是在交出執行權之前，先確認這份 Boot Code 有沒有被授權。閘門標成 VERIFY——PASS 才 EXECUTE，FAIL 就 DO NOT EXECUTE。下一張會把這道閘門叫什麼、檢查什麼講清楚。
2. 怎麼讓惡意 Boot Code 跑不起來？
若順序是 Reset → 惡意 Boot Code 已執行 → OS → 防毒才開始掃描，這時檢查往往已經太晚。被檢查的對象可能已經動過系統；「來得及嗎」這句問得很實際。
Secure Boot 把檢查點往前挪：Boot Image 先過 VERIFY，通過才交出執行權。這比「先跑再說」更貼近攻擊發生的時間點。[1]
閘門通常要回答三件事。完整性：內容有沒有被改。授權：是不是允許的發布者簽出來的。版本：是不是政策禁止的舊版。圖上把這三項並排放，後面幾張會分別拆開。
邊界也要一起讀。它主要擋的是未授權的開機映像；它不讀程式「意圖」；合法簽出的東西仍可能有洞，OS 起來之後還是要更新、隔離與執行期偵測。Secure Boot 是啟動授權閘門，不是整套防毒系統的替代品。[1]
3. Reset 之後，第一段程式碼憑什麼可信？
按下 Reset，CPU 從硬體預定的位置開始跑。這回答「從哪裡跑」，還沒回答「那裡的程式為什麼可信」。OS 還沒醒，也沒有更高層軟體可以請教——起跑點本身就得先站得住。
圖上兩份映像並排：一邊是正常韌體 Boot Image A，一邊是遭換掉的 Boot Image X，兩邊都喊「先跑我」。只靠檔名、位址或外觀，CPU 沒有可信依據可選。OpenTitan 的 Secure Boot 設計也把啟動 ROM 與後續可變映像的信任關係分開處理。[4]
再疊一層可改寫的驗證程式也不夠。誰檢查驗證者 A？驗證者 B？攻擊者可以先換掉驗證者。信任若無限往後問，永遠落不到實處。可改寫，就可能先被換掉。
Reset 只決定起點；信任則需要一個「先被保護」的最小起點。接下來的問題是：第一個驗證者怎麼護住？
4. 第一個驗證者，怎麼保護？
第一階段驗證程式必須比它要驗證的映像更難被換掉。常見做法是放進不可改寫區，或在該平台的威脅模型下實務上難以改寫。Immutable 是威脅模型判斷，不是零件貼紙。[4]
它還得帶著最初的信任資料：受保護的公鑰、金鑰雜湊，或信任政策。圖上把它們收進保險櫃裡，標成 Trust Anchor——後面的授權判斷從這裡開始。驗證者與信任資料只要有一邊能被任意替換，判斷基準就被改寫了。
Hardware Root of Trust 是這個起點的硬體底座，但不要把它收成單一零件名稱。ROM、OTP、eFuse、隔離安全處理器，或它們的組合，都可能承擔一部分角色。真正要查的是三件事：起點是否受保護、信任資料是否防竄改、驗證流程能不能被繞過。[1][4]
工程師延伸：Immutable 是威脅模型判斷
把程式放進 ROM 很常見，但安全判斷仍要涵蓋生命週期、測試模式、Debug 入口與可更新安全處理器。重點是攻擊者在既定能力範圍內，不能修改或繞過第一個驗證者及其信任資料。
下一張先看雜湊：算出同一個摘要，夠不夠當授權。
5. 算出同一個雜湊，就可信了嗎？
雜湊很適合抓內容變動。正常映像與被改過的映像，通常會算出不同摘要；不一樣，就知道內容變了。到這裡為止，它做的是完整性偵測。
問題出在「預期摘要從哪裡來」。若攻擊者能把 Boot Image 和旁邊未受保護的預期摘要一起換掉，新映像仍會算出相符結果。這不是雜湊演算法壞了，是比較基準本身沒有可信來源。
所以相等只證明彼此一致，還沒回答誰批准了這份映像。圖上那句 MATCH ≠ AUTHORIZED 值得單獨記住。預期值必須來自已驗證的管道，或透過數位簽章連到受保護的信任資料。[2]
下一張把簽章流程攤開：誰用私鑰簽、裝置用哪把公鑰驗。
6. 誰批准這份開機映像？
發布者對映像（或明確定義的簽署內容）做雜湊，再用受控私鑰產生簽章。私鑰留在簽署端，不進裝置——圖上這句很關鍵。[2][6]
裝置這邊拿 Image + Signature，用已經納入信任設定的公鑰驗證。公鑰若只是和陌生映像一起寄來，不能靠自我宣稱變成可信；信任起點必須先存在。驗證結果是 VALID 或 INVALID。
VALID 代表兩件事同時成立：內容與簽章相符，而且簽章對應到一把受信任的 key。它沒有證明程式完全沒有漏洞。授權回答「允不允許這份程式跑」；程式品質還要靠開發、測試與更新。圖上那句 AUTHORIZED ≠ BUG-FREE，就是在擋這種過度解讀。
下一張把單一閘門拉成整條鏈：一個守門員怎麼守完整條開機路徑。
7. 一個守門員，怎麼守完整條開機鏈？
受保護的 Stage 0 不必一次載入整個系統。它先驗證 Stage 1，通過後才執行；Stage 1 再用同樣順序驗證 Stage 2。圖上把 VERIFY 與 EXECUTE 交錯排開，標成 AUTHENTICATE, THEN EXECUTE——順序本身就是安全屬性。
信任沿著鏈往下延伸：Trust Anchor → Bootloader → Firmware → OS Loader。Android Verified Boot 與 Trusted Firmware-A 的驗證框架，都把這種分段信任關係寫進實作。[3][5]
任何一節失敗，就不能交出執行權。驗證的物件必須就是接下來取得控制權的物件；畫一串盾牌沒有用，守住順序才有用。
但簽章通過仍然不夠：舊版有真簽章，為什麼還要擋？
8. 舊版有真簽章，為什麼還要擋？
攻擊者找到一份「真的」舊韌體：原廠簽章還在，Signature: PASS，可是後來才發現的漏洞也還在。Authentic 並不等於 current，也不等於目前政策仍允許。[3]
若系統只驗簽章，把 Version 7 降回 Version 3 就可能過關——圖上標成 ROLLBACK ATTACK。漏洞等於被「復活」了。
Anti-rollback 另外檢查最低允許版本。version floor 若是 5，Version 3 即使簽章有效也必須 REJECT。執行條件變成兩道門同時過：SIGNATURE PASS + VERSION PASS。[3]
最低版本狀態本身也是安全資產。它若能和映像一起倒退，版本檢查就失去實際保護作用。
工程師延伸：版本狀態也是安全狀態
最低版本若存在一般可變韌體旁邊，可能和映像一起被回復。實作可採受保護計數器、Fuse、具單調性的已驗證狀態或其他等效機制；更新規則與失敗行為也必須納入分析。
驗證萬一失敗呢？下一張看停機、備援、受限模式與 Recovery 怎麼選。
9. 驗證失敗，是停機還是繼續？
有一條規則不因產品而變：VERIFY: FAIL 之後，這份失敗映像不得執行。圖上把它收成 FAILED IMAGE NEVER EXECUTES。[1][3]
接下來怎麼辦，才依產品設計：停機、切到備援映像、進受限模式，或進入 Recovery。安全底線是「失敗映像拿不到控制權」；可用性策略可以另外設計。Fail-safe 因此不等於一律關機——它要求的是阻止不安全的狀態轉移。
錯誤紀錄可以留下「驗證失敗」與 reason code，方便診斷；但不能順手把私鑰或其他敏感資料印出去。下一張專門盯 Recovery：修復路徑會不會自己變成後門。
10. Recovery 會不會變成後門？
危險做法很直覺：主映像失敗就關掉驗證，接著跑任何 Recovery Image。攻擊者只要先製造一次失敗，就得到任意執行路徑。這不是復原，是後門。NIST 的韌體韌性框架把復原視為回到可信狀態，而不是取消保護。[1][3]
正確做法是讓 Recovery Image 也過簽章與版本檢查。備援 Slot B 只有自己 VERIFY PASS 之後才能執行；Slot A 失敗，不能變成「隨便載入」的許可。
修復入口還需要自己的授權政策：誰能觸發、載入哪把 key、允許哪些版本。它可以採另一套受控規則，但不能離開信任邊界。
工程師延伸：Recovery 是第二套開機政策
Recovery 可以信任不同 key、只接受特定映像類型，或要求實體在場訊號。這些都是政策選擇；任何選擇都不應把驗證失敗轉成執行任意位元組的許可。
防線接起來之後，還要確認它的邊界：Secure Boot 擋什麼、擋不了什麼。
11. Secure Boot 能擋什麼，又擋不了什麼？
它主要擋三類：未授權的開機映像、被竄改的受保護元件、版本政策禁止的舊版。覆蓋範圍只到驗證鏈納入的元件；鏈外東西不會因為系統宣稱支援 Secure Boot 就自動受保護。[1][3]
這些不會自動消失：合法簽出的漏洞程式、簽署 key 已失守、OS 執行期攻擊、未納入驗證鏈的元件。所以還需要安全更新、撤銷與金鑰輪替、隔離與權限控制、執行期偵測。
Secure Boot 決定這份開機程式是否獲准執行。它不替程式做完整漏洞掃描。[1]
最後把威脅模型與整條啟動路徑接起來，也順便分清幾個常被混用的名詞。
12. 從駭客偷換映像到系統啟動，防線怎麼接起來？
把整條防線接回威脅模型：攻擊者想換掉 Boot Image；Reset 則進入受保護的第一階段，底座是 Hardware Root of Trust，信任資料落在 Trust Anchor。每一階段先做雜湊、簽章與版本政策檢查——PASS 才執行，FAIL 則拒絕，或轉入同樣需要驗證的 Recovery。[1][3][5]
整條 Secure Boot 路徑可以濃縮成一句話：從受保護的信任起點開始，只把執行權交給通過授權與版本政策的下一階段。
旁邊三個機制常被混進同一個名詞。Measured Boot 記錄啟動狀態；Attestation 對外報告可驗證的狀態證據；更新框架負責送入與治理新版本。它們能和 Secure Boot 合作，卻回答不同問題。
工程師延伸：三個機制回答三個問題
Secure Boot 在本機執行授權決策；Measured Boot 記錄實際啟動內容；Attestation 讓外部驗證者依自己的政策檢查部分證據。系統可以同時採用三者，但不能把「有量測」直接說成「已阻止執行」。
課末五句
- 威脅是未授權程式搶到早期執行權；實際入口與目標要依平台判斷。
- Reset 只指定起點；第一個驗證者與信任資料必須先受保護。
- 雜湊發現內容變動；簽章把授權連到受信任的 key；MATCH 仍不等於 AUTHORIZED。
- 每一階段先驗證再執行；Anti-rollback 另外拒絕政策禁止的舊版。
- 失敗映像不能執行；Recovery 與備援槽也必須通過驗證與版本政策。
若還想往下挖，一條路是對照 Measured Boot 與 Attestation 各自回答什麼問題；另一條是把已驗證的啟動狀態接到執行期隔離與更新治理。圖給直覺，政策與威脅模型決定實作邊界。
References
- NIST SP 800-193, Platform Firmware Resiliency Guidelines
- NIST FIPS 186-5, Digital Signature Standard
- Android Verified Boot
- OpenTitan Secure Boot
- Trusted Firmware-A Authentication Framework
- Microsoft Secure Boot overview
簽章有效、版本太舊，能執行嗎？
正常 v7 通過 floor 5。再把版本改成 3，或 floor 改成 8，保持簽章有效。接著分別改 image bytes 與驗證錨點，找出拒絕原因。
ECDSA P-256／SHA-256 真正簽署並驗證自編 JSON manifest；manifest 綁定 target、版本與 image SHA-256。模型只「執行」已驗證的固定 byte snapshot，不執行程式。可信錨點、floor 保護、parser、硬體抗 fault 與實際驗證後執行綁定仍是系統責任；成功不證明沒有漏洞。
學習指南
晶片裡的信任，是怎麼建立的？
查看課程大綱 → · 進度只計入已發布課程
先備知識
- 不要求開機安全背景；讀過數位簽章與 HRoT 會更容易銜接
我學會了什麼
- 從攻擊者搶先執行的優勢，推導 Secure Boot 為何必要
- 說明 Reset 不等於信任，以及第一個驗證者為何需要受保護的信任資料
- 區分雜湊一致性、簽章授權與 Anti-rollback 版本政策
- 沿著完整 Chain of Trust 追蹤先驗證、後執行的順序
- 設計失敗與 Recovery 路徑，同時確保失敗映像拿不到控制權