先用一句話抓住這篇
從更新授權、設備相容性與防回退，走到斷電安全安裝、試開機、簽署金鑰輪替和復原策略。
先把這篇當成一張閱讀地圖：上方摘要說明問題，圖片先建立直覺，下面文字再補上真正的技術取捨。
如果第一次讀覺得名詞很多，可以先記住比喻與結論；第二次再回頭看名詞，會順很多。
偏遠山區有一座水位監測站，平常自動回報水情，維護人員可能幾個月才到現場一次。某天，廠商修補了一個韌體漏洞，管理中心得透過網路把新版送過去。可是，下載途中可能斷線，安裝時可能突然停電；更麻煩的是，攻擊者也許會把一份「以前確實由廠商簽署、如今卻已含有漏洞」的舊版重新送來。
這時候，設備不能只問「檔案下載完成了嗎？」它還得判斷：誰授權這份更新？它是不是給這個型號的？內容有沒有被換掉？是不是有人重送過去的舊宣告，讓設備退回含漏洞的韌體？如果安裝一半失敗，設備能不能回到可用狀態？接下來我們跟著水位站逐項做決定，也會看見簽章、版本政策和復原機制各自負責什麼、又有哪些做不到的事。[1][2][3]
1. 遠端水位站需要安全修補，會遇到什麼問題？
先把故事中的設備想清楚：水位站安裝在偏遠地點，負責讀取感測器、保存資料並回報管理中心。廠商修正了韌體漏洞，設備需要安裝新版；但它使用的網路可能不穩定，維護人員也無法隨時趕到。一次更新失敗，可能不只是畫面跳出錯誤，而是讓整個站點停止回報。
威脅模型要先圈出資產和攻擊者。要保護的是可信的韌體、設備持續服務的能力，以及「誰能批准程式執行」這項權限。攻擊者可能攔截或控制傳輸路徑、重送過去合法簽署的映像，或利用停電讓更新落在不完整狀態；這個課程不假設攻擊者已能任意改寫晶片內受保護的信任根，因為若信任根本身失守，更新流程需要另外的復原途徑。
於是設備至少要回答幾個不同問題：簽署者是否有權批准？這個套件是否適用於目前型號？檔案是否與核准內容一致？舊版是否已被政策禁止？寫入途中失敗時，又該如何安全恢復？把這些問題分開，才不會把「簽章有效」誤當成整份更新流程都安全。[1][2][3]
2. 下載得到，不代表有權安裝
管理中心可能從廠商伺服器下載更新，也可能經過電信閘道、快取節點或企業內部鏡像站。這些服務的任務是傳送資料，不代表每一個傳輸節點都有權決定設備該執行哪一套韌體。若其中一個伺服器遭入侵，它或許能把錯誤檔案送到設備面前。
因此設備需要一條本機可檢查的信任路徑：例如用已受信任的公鑰驗證廠商簽署的更新宣告或 manifest。這份宣告可說明映像的摘要、適用產品、版本政策等資訊。設備不是相信下載位置上的名字，而是依照預先建立、且受到保護的信任資料核對簽章與授權範圍。[1][2]
網路加密仍然有用，它能保護傳輸中的機密性與連線，但不能取代韌體來源授權。若設備會透過同一條不可信的下載路徑，直接接受伺服器提供的新信任金鑰，那麼攻擊者便可能連「誰有權簽署」也一起換掉。傳送、驗證和核准是不同工作，設計上要明確分工。
3. 真正簽署的版本也可能裝錯設備
假設廠商真的簽署了一個更新映像，但它是給另一款電路板使用。兩款設備外觀或名稱很像，裡面的記憶體配置、感測器介面、周邊控制器或開機設定卻可能不同。把韌體裝錯，不一定會出現清楚的錯誤訊息，也可能讓設備部分功能失效，甚至改變原本的安全行為。
所以設備要同時核對「誰簽署」和「這份更新的適用對象」。更新宣告可以列出產品、元件、硬體修訂版與相依條件；設備再用自己的可信識別資料和目前設定逐一比對。若同一產品家族有多種電路板修訂版，只有寬泛的家族名稱可能不足以區分相容性。
這些欄位不是包裝上的說明文字，而是會影響安裝決策的政策資料。產品設計者需要定義型號如何識別、哪些欄位由誰簽署，以及裝置無法可靠判斷板版時要採取什麼保守行為。簽章只保護被簽署的內容，不能替產品團隊決定哪些目標應該相容。[2]
4. 有效簽章仍可能是舊漏洞
水位站已經安裝修補版，攻擊者卻重新送來更舊的韌體。那份舊檔可能真的是廠商以前發布、也確實經過簽署的版本，所以簽章驗證會成功。但漏洞修補尚未包含在舊檔裡；若設備只檢查簽章，攻擊者仍可能讓它退回較脆弱的狀態。
防回放是防回退政策要處理的一種情況：攻擊者重送先前有效、現在卻不該再接受的更新宣告。一種做法是在簽署的 manifest 中放入單調遞增的序號，設備將已接受的界線保存在受保護的儲存區。假設裝置已接受序號 112，後來收到序號 108，即使它的簽章有效，也會因低於目前政策界線而遭拒。[2]
序號不一定等於給人看的韌體版本。RFC 9124 第 4.3.1 節明確指出，韌體版本可以回退，只要為舊韌體建立一份帶有較新序號的新 manifest。重點不是版本字串看起來比較大，而是這次更新是否符合裝置目前信任的授權與序號政策。[2]
5. 安裝前究竟要檢查什麼？
安裝前的判斷可以拆成一份清楚的檢查單：簽署者是否可信、它是否有權發布這個元件？宣告中的產品與硬體修訂版是否符合本機？下載的映像摘要是否相符？序號是否通過防回放政策？裝置是否有足夠空間和受支援的安裝方式？每一項都各自排除一種錯誤或攻擊。
其中，摘要把簽署宣告與實際映像內容連在一起。設備重新計算收到的映像摘要，若任何位元在簽署方計算後被改動，重新計算結果通常就不會相符。簽章用來驗證宣告受到授權者保護；摘要則協助確認拿來安裝的資料確實對應到宣告。它們都不會自行判斷產品相容性，這需要另一道政策檢查。[1][2]
還要確定「檢查過的內容」就是「最後執行的內容」。如果設備驗證一份可修改的檔案，驗證結束後卻改從另一個位置讀取映像，攻擊者可能在兩個時間點之間替換資料。安全設計會把核對結果與待安裝的實際映像綁在一起，並保護暫存內容與啟用資訊，直到切換完成。[1]
6. 為什麼不能直接覆寫唯一映像？
想像設備只有一份可開機韌體，更新程式邊下載邊把它覆寫。若寫到一半突然停電，原本能工作的內容已被擦除，新版又不完整，水位站便可能失去唯一的啟動路徑。即使下載檔案本身合法，更新順序仍可能造成無法使用的結果。
較有韌性的做法，是先保留目前正在工作的映像，把候選版本寫到另一個區域。裝置完成寫入並驗證後，才更新受保護的啟用狀態，讓下次開機嘗試新版本。這把「準備新映像」和「正式切換」分開；寫入途中失敗時，原本的已知可用版本仍可能保留下來。
不過，多一份映像不會自動形成安全設計。切換紀錄若能被任意竄改，兩份映像都可能被破壞，或設備可能被誘導不停切換。A／B 分槽、復原分割區、現場維修介面各有儲存成本、複雜度、耗損與可用性取捨；產品必須保護啟用狀態，並實際測試斷電時每一個步驟會留下什麼狀態。[1][3]
7. A／B 槽如何保留退路？
在 A／B 設計裡，A 槽可能是目前正在工作的版本，更新程式則把候選映像寫入 B 槽。裝置先確認 B 槽內容已完整、簽章與政策檢查通過，再把它標記成「試開機」目標。這段時間不應急著把 A 槽抹掉，因為它仍是可能的回復選項。
第一次從 B 槽啟動後，設備可以依產品定義進行有限次的健康檢查。必要服務啟動了嗎？感測器能不能正常讀值？資料和設定是否仍然可用？通訊回報是否恢復？如果全部通過，系統才把 B 記為接受狀態；若失敗或一直無法完成試開機，設計上可改試原有映像或進入復原流程。[1][3]
這不是保證每一台 A／B 裝置都會自動回復，也不代表服務完全不會中斷。團隊還得定義試開機的成功條件、最多嘗試幾次、重設後狀態如何保存，以及兩個槽位和切換旗標由誰保護。A／B 只是一種韌性模式，不能代替簽章驗證、防回退政策與整體復原規劃。
安裝 sequence 與開機最低安全版本，可能是不同的受保護欄位。本課互動選擇在 trial 確認後，原子提交 active slot 與已接受 sequence；之前保留 A 與 sequence 112。這是自編政策，不是所有產品的固定順序。若實際設計太早提高開機最低版本，可能連準備用來復原的 A 都被擋下。團隊必須一起設計 floor、試開機、可接受的復原版本與斷電後的提交狀態。
8. 試開機要確認哪些健康條件？
「處理器有跑起來」不等於「產品已恢復正常」。新版可能成功顯示啟動畫面，感測器驅動程式卻失效；也可能讀不到舊設定，或無法把資料送回管理中心。對水位站而言，這些情況都代表核心任務沒有完成，不能只因為 Bootloader 沒回報錯誤就正式接受更新。
健康檢查要從產品工作出發，挑選少而關鍵的指標。例如，確認感測器能初始化並讀取合理範圍的數值、必要設定仍可讀取，以及設備能向監控中心傳送狀態。Watchdog 可用來偵測程式長時間沒有進展，但 watchdog 沒有觸發，只能說沒有觀察到那一類停滯，並不能證明感測數值一定正確。
接受規則應明確而且有限。新版本尚未通過必要檢查前，不該獲准更改更新信任政策，也不應先抹掉唯一可復原映像。檢查失敗時，設備可能重試、回到先前版本、維持受限服務或等待人員處理；不同產品選擇不同，服務也可能暫停，這些代價都要在設計階段納入。[1][3]
9. 更新與網路都失敗時怎麼復原？
更新流程最需要復原計畫的時候，通常正是一般安裝已經失敗的時候：寫入時突然斷電、候選映像在試開機階段無法運作，或設備暫時連不到更新伺服器。復原方法可能是使用保留的已知可用映像、等待連線恢復後重新下載核准版本，或由維修人員透過受控介面處理。
復原本身仍然要驗證。若只要故意觸發錯誤就能進入一條不檢查簽章的特殊路徑，攻擊者可能把復原模式當成繞過正常政策的方法。無論是維修憑證、實體服務程序或另一個更新通道，都需要明確的管理者、使用範圍、撤銷方式與維護責任。[1][3]
設備也應留下足以協助處理故障的紀錄，例如哪項檢查失敗、嘗試了哪個發布版本、是否發生槽位切換。紀錄不能洩漏祕密，也不能被用來當成未授權的命令通道。復原可以把系統帶回安全狀態，但未必能在現場無人協助時完成，也不保證服務不中斷；設計承諾的是有規劃的處理方式，而不是永不故障。[1][3]
10. 如何受控地例外安裝舊版？
有時新版帶入了新的缺陷，或現場必須暫時使用已完成驗證的舊版以維持服務。若政策只說「任何情況都不能回復」，一次發布失誤可能讓設備長時間停擺；但如果操作員能任意關閉防回滾檢查，攻擊者便可藉機重裝含已知漏洞的韌體。
比較安全的做法，是把「舊」和「未授權」分開處理。依某種 manifest 架構，授權發布者可簽署一份新的宣告，序號高於設備已接受的界線，並明確授權特定舊映像用於限定型號或復原目的。設備仍檢查簽署者、適用範圍、映像摘要和目前序號政策，而不是接受任何被拿來的舊檔。[2]
例外也要能說清楚：誰核准、為什麼需要、適用哪些設備和映像，以及何時到期或由哪一份正式發布取代。這會留下可稽核的決策紀錄，而不是藏在流程裡的政策旁路。不同產品架構對序號和例外的實作可以不同；RFC 9124 提供一種 manifest 資訊模型，不是所有設備都必須照抄的通用規則。
11. 簽署金鑰也要更換時怎麼辦？
韌體發布者可能因為金鑰即將退役、管理制度改變，或懷疑私鑰已遭竊，而需要輪替簽署金鑰。已部署的設備只認得舊金鑰，接下來就必須有安全方法告訴它：哪一把新金鑰取得授權？若把一個新金鑰檔和韌體放在同一個未驗證的下載位置，金鑰本身並不能證明自己可信。
事先規劃的輪替，可以透過既有且仍可信的授權者核准新金鑰，再確認設備已正確驗證並保存新的信任資料，之後才依政策逐步改用。更新格式也許會包含金鑰識別、撤銷資訊與序號規則；但無論格式如何，設備都要能追溯到一個受保護的根，或另外一條獨立可信任的復原管道。[1][2]
若根授權本身已失陷，再用同一把根金鑰簽署「新金鑰」不會自動恢復信任。廠商可能必須使用隔離保存的復原權限、實體維修程序或產品特定的重新佈署流程。平時要測試正常輪替和緊急撤銷，說明誰可以核准，也要保留哪些信任資料已安裝的紀錄；等事故發生才設計這條路，通常已經太晚。[1][2]
12. 回到遠端水位站：從更新走到可信復原
我們再走一次水位站收到修補的流程。它先驗證 manifest 的簽署權限，再確認適用型號、依賴條件和映像摘要，接著依受保護的序號政策判斷是否允許這次更新。新的韌體先寫入候選區域，舊版保留作為設計中的復原選項；通過檢查不代表流程結束，設備還要安全地切換並進入試開機。
試開機時，設備確認感測器與回報功能是否符合事先定義的必要條件。通過後才提交更新；若寫入或健康檢查失敗，就依產品設計採取復原步驟。這可能需要再次取得授權映像、由人員前往現場處理，或讓回報服務暫時中斷。誠實標示這些限制，才能讓維護者在部署前規劃風險與服務安排。[1][2][3]
這堂課的主線是把不同責任一項項接起來：確認授權來源、把映像綁定到正確設備、阻止不允許的舊宣告重播、避免安裝時失去退路、檢查設備核心功能，並維護受控的復原和金鑰輪替流程。Secure Boot 可以在開機時管制哪些程式能執行；安全更新則要先確保改變韌體的整條路徑也受到管理。[1][2][3]
五點回顧：安全更新要保護整條路徑
- 下載伺服器負責傳送候選套件；設備仍要自行驗證授權者和授權範圍。
- 簽章有效，不代表映像適用這台設備，也不代表目前政策仍接受這個版本。
- 受保護的 Manifest 序號能拒絕過期重播；它與供人閱讀的韌體版本不同。
- 暫存、A／B 槽與試開機是保留復原選項的設計方式，不是零停機保證。
- 復原與簽署金鑰輪替也是安全路徑，同樣需要授權、驗證、負責人與測試。
換個條件想想： 假設水位站只有一個韌體儲存區，更新時遠端網路又因停電中斷，維修人員帶來的筆電裡有一份檔案。能不能直接清除舊韌體，再安裝這份尚未驗證的檔案？
不應這樣做。筆電只是傳送途徑，不能證明檔案獲得授權。產品必須事先定義能驗證來源、並適用於單映像設計的維修／復原程序；若現場沒有這些保障，維護人員不應以關閉檢查來臨時解圍。A／B 不是唯一答案，但經測試的復原計畫不可少。
下一課會把視角轉到除錯介面和實體接觸：攻擊者能碰到設備本身時，還有哪些防線？
參考資料
- IETF RFC 9019：物聯網韌體更新架構——更新架構中的授權、安裝、中斷處理與復原考量。
- IETF RFC 9124 第 4.3.1 節：單調遞增序號——說明序號不是韌體版本欄位，也說明較新的 Manifest 序號可以授權安裝較舊韌體。
- NIST SP 800-193：平台韌體韌性指引——平台韌體的保護、偵測與復原概念。
主題標籤：#硬體安全 #韌體更新 #防回退 #安全復原
更新寫到一半斷電，哪個 slot 還能啟動？
從 active A:v7、已接受 sequence 112 開始。先在寫入或 trial boot 時斷電，再走正常確認流程。比較 active slot 與 sequence floor 何時一起提交；改 sequence 112，觀察舊包直接拒絕。
這是一種明確的 A/B 產品政策，假設封包簽章／target 檢查結果由你指定。v8 與 sequence 113 是不同欄位，不能當通用版本規則。提交被模型視為原子且受保護；實際 flash、斷電窗口、試啟動 watchdog、recovery 與 floor 提交順序必須另行設計驗證。它不是 SUIT parser 或耐斷電證明。
學習指南
晶片裡的信任，是怎麼建立的？
查看課程大綱 → · 進度只計入已發布課程
先備知識
- 理解 Secure Boot 與數位簽章會更容易銜接
我學會了什麼
- 區分套件傳送、授權與相容性
- 說明有效簽章為何無法阻止舊版重播
- 比較分階段安裝、試開機與復原