現代系統啟動安全與國家級指導的必要性

在當代運算環境中，系統的開機流程已成為惡意程式攻擊與持續性駐留的關鍵目標區域。傳統的惡意軟體解決方案往往仰賴作業系統核心（OS Kernel）的保護與可視性，然而，一旦惡意程式成功在韌體或開機載入程式階段植入，即所謂的「Bootkit」，它將能完全規避作業系統層級的安全防禦，並在系統啟動的第一時間獲得最高權限，從而對資產造成毀滅性的、難以偵測的破壞。

統一可延伸韌體介面（UEFI）所內建的「安全啟動」（Secure Boot）機制，正是為了對抗這類威脅而設計的基石技術。其核心宗旨是建立一個從硬體到作業系統的數位信任鏈，確保只有經設備擁有者信任或允許的二進位檔案才能在啟動時執行。

鑑於UEFI安全啟動的複雜性、配置上的普遍誤解，以及重大漏洞攻擊的持續出現，美國國家安全局（NSA）正式發布了一份名為《UEFI 安全啟動管理指南》（Guidance for Managing UEFI Secure Boot）的網路安全資訊文件（CSI）。這份指南不僅標誌著國家級安全機構對底層系統安全的高度關注，更為企業組織提供了一套系統化、可操作的框架，以應對安全啟動配置所帶來的持續性挑戰。

UEFI安全啟動的核心機制與信任資料庫

UEFI安全啟動的運作，是透過一套嚴格的密碼學策略來實現的，它依賴四個關鍵的證書和雜湊值儲存區來定義和執行安全啟動策略：

1. 平台金鑰（Platform Key, PK）： 這是安全啟動策略的最高權限金鑰。 任何對安全啟動配置的變更，特別是修改Key Exchange Key (KEK) 列表，都必須使用當前已安裝的PK進行簽署或授權。PK的安裝標誌著平台進入「使用者模式」（User Mode），即安全啟動強制執行模式。 如果PK被移除，系統將進入「設定模式」（Setup Mode），安全啟動將失效，允許未簽署的程式碼執行。在企業環境中，組織應考慮是否使用自己的PK來取代製造商預設的PK，以完全控制啟動信任鏈。

2. 金鑰交換金鑰（Key Exchange Key, KEK）： 這些金鑰用來簽署被允許或拒絕的啟動映像檔（Boot Images）的雜湊值列表。 KEK的主要功能是在PK的保護下，管理DB和DBX的內容。OEM（原始設備製造商）和操作系統供應商（例如微軟）都會有他們各自的KEK，這些KEK允許他們在設備發布後，透過標準的軟體更新或作業系統更新（如UEFI更新膠囊）來更新DB和DBX列表，從而撤銷惡意或有漏洞的開機載入程式。 組織也可以使用自己的KEK來授權特定的內部啟動程式。

3. 允許資料庫（Allowed Database, DB）： 包含所有被信任且允許在安全啟動模式下執行的啟動二進位檔案、開機載入程式、或韌體模組的證書（Certificates）和雜湊值（Hashes）。 只有由DB中任一證書簽署的開機載入程式，或其雜湊值直接存在於DB中的二進位檔案，才能執行。DB的內容是系統信任的白名單。 典型的DB會包含微軟Windows作業系統、硬體製造商韌體組件、以及特定Linux發行版所使用的Shim載入程式的證書或雜湊。

4. 拒絕資料庫（Revoked/Denied Database, DBX）： 包含已被撤銷或不被信任的二進位檔案或惡意程式的雜湊值。任何與DBX內容匹配的程式都將被阻止執行。 DBX是針對已知惡意程式（例如Bootkits，如BlackLotus）或已發現嚴重漏洞的合法開機載入程式（例如BootHole漏洞所涉及的GRUB版本）進行緊急封鎖的關鍵機制。DBX的內容是系統信任的黑名單。 KEK擁有者會定期更新DBX，將這些不安全的啟動元件加入黑名單，以強制系統拒絕執行它們。由於DBX通常儲存於有限的NVRAM中，空間限制曾是處理大規模撤銷（如BootHole）時的一大挑戰。

安全啟動的整個信任鏈，從系統啟動的最初階段便開始運作。首先，韌體會在「前可延伸韌體介面初始化階段」（PEI）引入UEFI安全啟動強制執行機制，並利用DB與DBX資料庫進行驗證。接著，在「驅動程式執行環境階段」（DXE）中，會對儲存控制器、圖形、網路等中層資源進行初始化。隨後進入「開機裝置選擇階段」（BDS），啟動管理器被初始化，並從選定的分割區執行開機載入程式。在整個過程中，從韌體到開機載入程式，再到作業系統核心的過渡，都必須通過連續的加密簽名驗證，確保只有被信任的程式碼得以執行。

值得注意的是，現行的安全啟動生態系統正經歷一個重大變革期：行業正在從2011年即將到期的簽名證書，過渡到2新的2023年等效證書。這使得組織比以往任何時候都更需要仔細檢查他們的Secure Boot配置，以確保其準確性和安全性，防止因過期或錯誤的證書配置而導致的安全風險。

美國國家安全局對UEFI安全啟動配置與挑戰的指導原則

美國國家安全局的指南明確指出，儘管UEFI安全啟動功能在多數情況下預設啟用且運作良好，但其作為一個複雜的端點安全生態系統組成部分，仍會在特定情況下帶來挑戰並需要手動配置或審查。

美國國家安全局 (NSA) 發布了一份題為《UEFI 安全啟動管理指南》，旨在指導如何應對安全啟動配置方面的挑戰。該文件旨在解決與安全啟動相關的幾個長期存在的問題，這些問題包括：人們對安全啟動如何與其他保護技術互動仍然存在困惑、新採購的設備缺乏驗收測試、以及關於如何檢測和應對安全啟動相關問題的指導資訊有限。

1. 常見 Secure Boot 攻擊案

近年出現的安全啟動漏洞揭露了可信任啟動流程執行的重大缺陷，常見 Secure Boot 攻擊案例如：

• PKFail 漏洞的出現是由於裝置出廠時預先安裝了主機板或韌體製造商提供的測試證書，而非標準的廠商和微軟安全啟動證書。公開揭露的測試憑證與薄弱的身份驗證機制相結合，使得攻擊者能夠繞過安全啟動保護。

• BlackLotus 利用 Windows 開機載入程式漏洞（CVE-2022-21894、CVE-2023-24932）在開機載入程式和核心階段停用安全啟動強制執行。受影響的系統表面上顯示安全啟動已啟用，但攻擊者註入了自己的引導可執行檔和安全啟動值，從而有效地干擾了後續啟動。由於 DBX 記憶體限制，緩解措施最初較為困難，但最終透過修補程式和更新引導程式強制執行機制得到了解決。

• BootHole漏洞的目標是GRand Unified Bootloader（GRUB），它允許格式錯誤的設定檔在啟動時執行任意程式碼，並繞過Linux shim所使用的安全啟動和MOK擴充。多個GRUB版本受到影響，因此需要更廣泛的DBX撤銷，但一些較舊的裝置記憶體不足，無法完成所有更新。為了解決此問題，已發布了更新的簽名GRUB版本。

2. 確認安全啟動狀態

美國國家安全局強調，設備所有者和管理員不應想當然地認為，即使安裝了可信任平台模組 (TPM)、使用了 BitLocker 等全碟加密 (FDE) 技術，或者啟用了處理器安全功能，也不代表安全啟動功能就一定處於啟動狀態。這些技術提供互補的安全功能，但各自獨立運作。以下注意事項，提供確認安全啟動參考：

• 新設備應經過驗收測試，以驗證安全啟動功能是否已正確設定和啟用。

• 管理員可以使用內建實用程式檢查安全啟動狀態。

• 管理員應驗證安全啟動憑證和雜湊值是否已正確安裝在 PK、KEK、DB 和 DBX 儲存區中，Windows PowerShell 和 Linux 命令可以提取這些值，而 NSA 提供了實用程式來分離憑證和哈希值。

美國國家安全局表示：「安全啟動可以進行自定義，以進一步限制啟動執行，或擴展以支援Linux作業系統。安全啟動有助於緩解計算設備的硬體、韌體和軟體供應鏈中可能存在的威脅。現代用戶設備的啟動速度非常快，以至於安全啟動的作用可能看起來並不明顯。但這絲毫不會削弱安全啟動在限制啟動二進位檔案方面只被認為可信任的裝置所認為的關鍵、裝置所認為的關鍵設備可啟動裝置

報告也指出，安全啟動部署不當會使裝置擁有者面臨韌體中潛藏的引導程式或未經授權的啟動檔案系統（不受作業系統控制）的攻擊風險。此類威脅會在不知不覺中破壞許多反惡意軟體解決方案賴以生存的基礎架構。

系統稽核與配置驗證的技術實務

NSA的指導特別強調了對安全啟動狀態和配置進行系統化稽核的重要性，這是供應鏈風險管理（SCRM）的重要組成部分。由於安全啟動的配置值（PK、KEK、DB、DBX）通常儲存在可信任平台模組（TPM）的平台配置暫存器 7 (PCR 7) 中，管理員可透過專業工具或作業系統內建的指令，提取並分析這些關鍵值。

Windows環境下的驗證 在Windows系統中，管理員可以使用內建的PowerShell指令或系統資訊工具（如msinfo32.exe）來快速檢查Secure Boot的狀態。更進階的稽核則涉及使用如Get-SecureBootUEFI這類PowerShell指令來提取PK、KEK、DB和DBX儲存區的詳細內容，並將觀察結果與行業標準規範或組織定義的信任基準進行比較。

Linux環境下的延伸 在Linux生態系統中，Secure Boot的稽核與執行往往透過Shim開機載入程式、機器擁有者金鑰（MOK）及MOK排除（MOKX）資料庫來擴展功能。這允許Linux發行版無需依賴微軟的韌體證書系統，就能管理自己的受信任證書。管理員必須確保Linux核心和核心模組已適當簽署，並且在適用的配置下，確保Secure Boot的強制執行延伸至核心階段。

緩解、恢復與持續性維護策略

一旦檢測到安全啟動配置存在錯誤或遭受惡意修改，立即的緩解與恢復至關重要。NSA建議了以下行動方案：

1. UEFI介面恢復預設值： 大多數的安全啟動配置問題，可以透過進入UEFI啟動配置介面（通常在開機時按F2、F10、或Del鍵），將設定恢復為標準、出廠預設或強制執行模式來解決。

2. 韌體與系統更新： 系統供應商的韌體更新是解決潛在漏洞（如BootHole）和證書過期的首要途徑。作業系統更新也可能包含UEFI更新膠囊（Update Capsules），用於更新韌體或Secure Boot值。

3. 手動安裝與大規模部署挑戰： 在無法透過自動化更新解決問題的情況下，可以手動重新安裝供應商和微軟的證書。然而，對於擁有大規模基礎設施的組織而言，這是一項資源密集且繁瑣的操作，因此預防性的驗收測試和配置管理顯得尤為重要。

安全啟動是韌體韌性的關鍵支柱

UEFI安全啟動是現代計算設備抵抗硬體、韌體和軟體供應鏈潛在威脅的關鍵防線。儘管其運作在現代快速啟動的過程中可能「看起來不明顯」，但它在約束啟動二進位檔案執行方面，發揮著不可替代的關鍵作用。

組織若忽視安全啟動的配置，無疑會增加遭受駐留在韌體中的Bootkit或未經授權開機載入程式攻擊的風險，從根本上破壞許多依賴底層完整性的反惡意軟體解決方案。因此，嚴格遵循NSA的指導，將新設備的驗收測試、證書及雜湊值驗證，以及啟動狀態的持續監控納入標準操作流程，是構建具有韌性的系統安全基礎架構的必要條件，從而真正實現從硬體到作業系統的完整信任鏈。