RTL Anti-Tampering Design 第十二課：Secure Boot 與金鑰釋出

簽章有效只證明某把信任金鑰簽過這些位元；它不自動證明版本可接受、量測的是即將執行的映像，或金鑰會在正確 lifecycle 釋出。

第十二課：Secure Boot 與金鑰釋出

把驗證結果綁到被執行的映像

倉庫收貨時，封條、批號與箱內物必須對得上；只驗封條不能證明搬運途中沒有換箱。Secure Boot 也要把簽章者、映像摘要、硬體目標、security version、載入位置及最終取指綁在同一筆交易。類比不包含雜湊碰撞假設、DMA競爭與微架構快取。

典型路徑是 immutable/ROM root 取得公鑰或 key identifier，驗證 manifest 與簽章，再檢查版本下限，最後鎖住相關設定並交接執行。若驗證後可寫記憶體被 DMA 改動，先前的 pass 不再代表當前 bytes。把驗證摘要與不可變 buffer/受保護載入區域關聯，並在接受端記錄 commit。OpenTitan key manager 文件將軟體 binding、版本與 sideload outputs 分成明確控制；產品仍須按實際整合判讀。Key manager。

最常漏掉的是「檢查完成」與「使用」之間的時間差：rollback counter 若只在軟體端讀一次，並發更新可能換掉版本；key release 若只看 boot_done sticky，可能沿用前一映像的授權。將 transaction ID、digest、version、lifecycle 與目的 key slot 綁定，失敗時採拒絕釋出；安全拒絕仍需避免永久不可恢復的拒絕服務。

把資產邊界定為「第一個取指」及「第一個 sideload key 使用」。First fetch 要確認簽章、版本、摘要與 transaction ID 都來自同一筆交易。Key release 還要符合 lifecycle 與目的 key slot 政策。RTL/SVA 示意不是產品 assertion，尚未接線或編譯。

尋找 TOCTOU 與 rollback

依序比較：合法新映像；簽章正確但版本低；簽署摘要為映像 A、取指卻來自映像 B；前次啟動的 boot_done sticky；debug lifecycle 下請求 production key。每種都要保留第一個違規接受邊緣及拒絕理由。

離線互動實驗

RTL／SVA 審查方向

以下為性質草案：先定義 harness 的 transaction、reset 與 oracle，並確認取樣邊界，再接入設計；尚未編譯或證明。

assert property (@(posedge clk) disable iff (!rst_n)
  key_release |-> signature_ok && reference_signature_valid && active_txn_id == reference_txn_id &&
                 active_digest == reference_digest && active_version >= security_version_floor &&
                 reference_key_release_allowed && key_slot == reference_key_slot);

assert property (@(posedge clk) disable iff (!rst_n)
  first_fetch |-> fetch_digest == reference_digest && fetch_txn_id == reference_txn_id &&
                  signature_ok && reference_signature_valid &&
                  fetch_version >= security_version_floor && reference_fetch_policy_ok);

cover property (@(posedge clk) disable iff (!rst_n)
  key_release && signature_ok && reference_signature_valid && reference_key_release_allowed);

cover property (@(posedge clk) disable iff (!rst_n)
  first_fetch && signature_ok && reference_signature_valid && reference_fetch_policy_ok);

reference_*、reference_signature_valid 與 security_version_floor 必須來自獨立 harness oracle，不可直接複製 DUT 的 sticky/pass 訊號。first_fetch 與 key_release 若位於不同時鐘域，須各自在事件所在時域檢查；本草案未證明 CDC。

此片段不證明 CDC、timing、side-channel 或實體注入；需由各自工具與測量提供證據。

檢核問題

辨認：有效簽章證明了什麼，還有哪些決策未完成？ 推理： 它在指定金鑰下驗證一串已簽署位元。版本政策、目標綁定、最後 fetch 的位元組，以及金鑰釋出政策仍要分開檢查。
比較：security version floor 與簽章驗證有何不同？ 推理： 舊映像也可能有有效簽章。Version floor 依政策拒絕 rollback；它本身不驗證映像內容。
情境：DMA 能在第一筆 instruction fetch 前修改已驗證 buffer。設計要綁定或保護什麼？ 推理： Digest 必須對應 CPU 最後 fetch 的相同位元組。可鎖定載入區域，或在實際使用邊界重新驗證。
故障診斷：sticky boot_done 來自上一筆 boot transaction。為什麼它不足以授權 key release？ 推理： 這個 bit 沒有指出目前映像或 transaction。釋出時要綁定 transaction ID、digest、lifecycle、version 與目的 key slot。
設計風險／轉移：debug lifecycle 可 fetch 已簽署映像，但不可使用 production sideload key。應分別記錄哪些結果？ 推理： 第一筆 fetch 與第一筆 key release 要分開記錄。Fetch 可以允許，production key release 同時維持拒絕。

延伸閱讀

OpenTitan Key Manager · NIST SP 800-193

MY ACADEMY · LESSON FILM

教學影片

影片依序說明本課的資料路徑。看完一段，可以回到下面的互動練習，改變輸入或故障條件。動畫呈現教學模型；它沒有替代 RTL 模擬。

圖卡的範圍說明
教學模型 · 非 RTL 模擬或晶片實測
性質草案未編譯／證明；不替代 CDC、side-channel 或實體注入證據

下載 MP4 · 字幕 VTT

旁白使用合成聲音。互動教學與動畫均有模型邊界；請以本課的來源與驗證範圍解讀結果。

Wrap-up｜把這一課帶回設計審查

威脅模型與成立條件: 單筆啟動交易含映像摘要、簽章結果、版本下限、lifecycle 與 key slot；最終取指/釋出是資產邊界。
失效原因: 驗證結果和後續使用對象脫鉤，或 rollback / 前次 sticky 讓過期授權沿用。
防護方法: 以不可變 transaction context 綁定 bytes、version、lifecycle、key slot，失敗預設拒絕，並保護接受端。
驗證方式與待做檢查: 對合法、過期、篡改、映像替換及 lifecycle 不符逐案檢查；RTL/簽章與記憶體整合尚未實測。
防護界線與未驗證項目: 未分析金鑰管理政策、供應鏈根信任、side-channel、實體 key vault 與 recovery image 的產品細節。

換個情境再想一次

加入 rollback counter 更新與並發 DMA；說明何處必須鎖定內容，以及何時才可釋出 sideload key。

以上整理對照本課的教學案例、參考資料與實驗範圍；未列為已完成的驗證，都是後續工作。