- 安全啟動依賴 UEFI、金鑰層次結構（PK、KEK）和資料庫（DB、DBX），以確保只執行受信任的韌體和開機載入程式。
- 2011 年的憑證將於 2026 年到期，因此需要更新金鑰和資料庫以維護 Windows 和 Linux 中的啟動保護。
- 韌體加固結合了安全啟動、簽章更新、硬體信任根、加密和持續監控。
- FirmGuard 等解決方案和專業的嵌入式系統合作夥伴有助於實現遠端管理、向 UEFI 遷移以及安全啟動鏈的實施。
在許多電腦和裝置上，韌體會在每次按下電源按鈕時靜默啟動，但其他一切的可靠性——或者說其脆弱性——都取決於這一刻。什麼是韌體？它有什麼用途？安全啟動、UEFI 和強大的韌體加固相結合，決定了系統是能夠抵禦嚴重攻擊還是會被一個簡單的惡意 USB 隨身碟攻破。
本文將直入主題，以冷靜而直接的方式解釋什麼是安全啟動，它與 UEFI 韌體有何關聯，憑證將於 2026 年過期會帶來哪些問題，以及所有這些如何融入 Windows、Linux 和嵌入式系統的安全系統。您還將看到一些進階解決方案，例如遠端 BIOS 管理、完整性監控，以及在情況複雜時專家合作夥伴的角色。
什麼是安全啟動？為什麼它如此重要？
安全啟動是UEFI 韌體中內建的安全功能，用於控制在初始啟動階段可以運行哪些軟體。它的目標很簡單，但有效執行起來很困難：確保只有經過簽署和信任的程式碼（引導程式、UEFI 驅動程式、EFI 應用程式）才能啟動，並阻止任何不符合韌體中定義策略的二進位檔案。
實際上，UEFI 韌體會將即將執行的程式碼的數位簽章與內部儲存的一系列憑證和簽章清單進行比較。如果簽章與受信任資料庫 (DB) 中允許的憑證或雜湊值匹配，則該元件執行；否則，它將被阻止。這樣做是為了防止試圖劫持啟動程序的引導程式和惡意軟體的執行。
安全啟動隨著 Windows 8 的發布而大規模普及，當時那些在作業系統啟動前載入的威脅開始激增。該模型基於信任鏈：UEFI 韌體首先驗證其內部模組（例如 Option ROM），然後檢查引導程式（例如 Windows 啟動管理器或 Linux 中的 shim/GRUB），只有在所有驗證通過後，才會將控制權交給引導程序，引導程式再對內核和其他二進位進行驗證。
關鍵在於，安全啟動的信任機制是由出廠設定的韌體策略定義。此策略透過金鑰和資料庫樹來體現：平台金鑰優先於所有其他金鑰，金鑰執行金鑰擴充 (KEK) 用於授權更改，以及兩個清單 DB 和 DBX，分別規定了允許和禁止的操作。妥善管理此生態系統與在 Windows 11 選單中啟用安全啟動選項同樣重要。
關鍵結構：PK、KEK、DB 和 DBX
安全啟動的核心是金鑰和簽章資料庫的層次結構。理解它對於任何安全加固策略都至關重要，無論是在家庭環境中，尤其是在企業或關鍵任務基礎設施中。
最頂層是平台金鑰 (PK)，通常由硬體製造商產生和管理。該密鑰擁有最終權限：擁有它的人可以更改安全啟動的所有其他元素，因此洩漏該密鑰會危及整個信任鏈。有些組織會將預設的平台金鑰替換為自己建立的金鑰，從而獲得對平台的控制權。
金鑰交換金鑰 (KEK)比安全啟動金鑰低一級，用於授權對資料庫 (DB) 和資料庫交換文件 (DBX) 進行更新。通常會有一個 Microsoft KEK，一個或多個來自硬體製造商的 KEK，以及在企業環境中，組織自身的 KEK。任何擁有有效 KEK 的實體都可以在安全啟動清單中新增或撤銷憑證和雜湊值。
允許的簽章資料庫 (DB)儲存韌體在啟動階段可以執行的二進位檔案的憑證和雜湊值。這包括來自 Microsoft、OEM 以及（如果適用）設備管理公司的憑證。當韌體分析引導程式或選項 ROM 時，它會在資料庫中尋找匹配項，以決定是否載入它。
另一方面，還有已撤銷簽章資料庫 (DBX)，其中包含不再被視為安全的二進位檔案和憑證。微軟會定期更新 DBX，以使存在漏洞的引導程式（如 BootHole 攻擊中出現的）或已被證明不安全的元件失效。保持 DBX 的更新是防止已簽署但已過期的二進位檔案繼續成為攻擊入口點的關鍵。
2026 年到期的安全啟動證書
自從安全啟動引入以來，幾乎所有相容 Windows 的電腦都在金鑰擴充庫 (KEK) 和資料庫 (DB) 中包含了一套通用的微軟憑證。問題在於，其中一些憑證是在 2011 年頒發的，即將過期，這將直接影響數百萬台裝置的啟動保護。
具體來說， Microsoft Corporation KEK CA 2011、Microsoft Windows Production PCA 2011或Microsoft UEFI CA 2011等憑證的有效期介於 2026 年 6 月至 10 月之間。每個憑證都發揮著不同的作用：對 DB 和 DBX 更新、Windows 載入程式、第三方引導程式或第三方製造商的 Option ROM 進行簽署。
為了確保持續安全，微軟在 2023 年發布了新的證書，取代了 2011 年的證書：例如，Microsoft Corporation KEK 2K CA 2023 取代了原始的 KEK，Windows UEFI CA 2023 用於系統引導程序，以及更新了 EFI 應用程式簽名和第三方 Option ROM 的證書。
該公司集中管理Windows生態系統中大部分設備的憑證更新，其方式與分發其他安全性修補程式類似。 OEM廠商也會在必要時發布韌體更新，以整合新憑證或調整安全啟動設定。
如果裝置在目前金鑰過期之前沒有收到新金鑰，它將繼續正常啟動並接收 Windows 更新，但它將無法再對啟動階段套用特定的緩解措施：它將無法接收 Windows 啟動管理員中的某些變更、DB/DBX 更新或針對新發現的底層漏洞的修補程式。
證書到期的影響及必要措施
2011 年證書過期並不意味著您的電腦將無法啟動，但會逐漸降低系統抵禦影響啟動時間的威脅的能力。這可能會對諸如 BitLocker 加固或使用依賴安全啟動信任鏈的第三方引導程式等場景產生影響。
為了最大限度地降低風險，微軟建議（並且在許多情況下會自動執行）將 KEK 和 DB 憑證更新到 2023 年的流程。 IT 管理員和安全人員應驗證其裝置是否已收到這些更新，尤其是在硬體或韌體更新頻率較低的異質叢集中。
行動指南很明確：檢查每種裝置的「安全啟動」狀態，確定是否正在使用舊憑證並製定升級計劃，然後在更新 BIOS 後按照指南啟用「安全啟動」。在託管環境中，通常需要查閱製造商的特定文件或遵循“Windows 安全啟動金鑰建立和管理指南”，才能將新金鑰正確整合到部署過程中。
在某些情況下，尤其是在使用組織自身的憑證自訂了 PK、KEK 或 DB 金鑰時，更新可能需要手動步驟和仔細測試，以避免停用尚未以目前金鑰重新簽署的合法引導程式。此處的協調錯誤可能導致系統在應用安全性修補程式後無法啟動。
安全啟動與 Linux：信任鏈、Shim 和 GRUB2
在 Linux 系統中，這個過程類似，但也有其自身的特色。大多數現代發行版都依賴一個名為 shim 的元件，這是一個由微軟簽署的引導程序，它使 UEFI 韌體能夠直接識別自身。 Shim 充當橋樑：韌體借助微軟的簽名加載它，然後 shim 使用特定於發行版的金鑰驗證 GRUB2 和核心。
在啟用安全啟動的 Linux 系統中，典型的流程如下：UEFI 驗證 shim，shim 驗證 GRUB2，GRUB2 驗證核心。每個階段都依賴數位簽章和金鑰策略，這些金鑰策略存在於 shim 本身以及安全啟動資料庫中。這確保了硬體製造商無需預先知道每個發行版的密鑰，同時仍然能夠控制哪個核心可以啟動。
在這種情況下，我們之前看到的那些要素仍然至關重要：PK 控制誰可以更改韌體中的全域安全啟動配置，KEK 決定誰可以更新 DB 和 DBX，DB 收集受支援的金鑰（包括 shim 所需的金鑰），而 DBX 儲存用於鎖定易受攻擊的二進位檔案的撤銷資訊。
該模型在互通性方面具有優勢，但也增加了操作複雜性。例如，當 shim 或 GRUB2 中出現嚴重漏洞時，需要快速更新受影響的引導程序，同時發布一個 DBX 條目來撤銷舊版本。如果順序錯誤，即使 shim 的二進位檔案已被撤銷，系統最終可能仍然需要舊版本才能啟動。
因此，正確管理 DBX 和 Linux 引導程式簽章成為一項棘手的任務，尤其是在多個發行版、LTS 版本和參與引導的第三方軟體（例如加密管理器或虛擬機器管理程式）共存的環境中。
安全啟動保護哪些內容…以及它不能保護哪些內容。
安全啟動旨在阻止針對啟動早期階段的攻擊。這些攻擊包括修改引導程式以載入自身有效載荷的引導工具包、被惡意版本替換的核心、在作業系統之前運行的偽造選項 ROM，以及為獲得持久性而引入的 EFI 二進位。
透過要求啟動鏈中的每個元件都經過簽署和驗證，可以大幅減少任何試圖「隱藏」在作業系統底層的攻擊者的攻擊面。被攻破的引導程式甚至可以在安全工俱生效之前停用遙測功能、繞過完整性檢查或植入rootkit 。安全啟動旨在堵住這條攻擊途徑。
這也在一定程度上限制了擁有實體存取權限的攻擊者的選擇：僅使用篡改過的充電器從USB啟動已經不夠了，因為韌體會拒絕未經支援證書簽署的二進位檔案。這並不意味著實體安全不再重要，但確實提高了那些企圖利用安全漏洞入侵設備的人的門檻。
然而，安全啟動存在明顯的限制。它無法防範作業系統本身的漏洞，也無法阻止擁有提升權限的使用者濫用合法功能造成損害。此外，它也無法阻止網路攻擊、服務漏洞或應用層配置錯誤。
此外，歷史表明，啟動鏈本身也可能存在漏洞。 Shim和 GRUB2 都曾發生過嚴重故障，例如臭名昭著的 BootHole 事件。在事件中，GRUB2 配置分析中的一個缺陷允許攻擊者在不使簽章失效的情況下篡改啟動過程。針對這些事件的應對措施是透過 DBX 更新二進位檔案並撤銷不安全的版本，這再次凸顯了主動維護安全啟動的重要性。
實施、強化和維護方面的挑戰
大多數安全啟動問題並非源自複雜的攻擊，而是源自於裝置韌體過時、DBX 清單失效，或金鑰自硬體出廠以來就未進行過檢查。換句話說，就是長期操作疏忽所造成的。
在許多情況下，改進的第一步非常簡單，只需係統地應用製造商發布的UEFI/BIOS 更新即可。這些更新不僅可以修復錯誤，還可以包含新的安全功能、金鑰管理改進以及韌體本身漏洞的修補程式。
另一個關鍵領域是金鑰管理。完全依賴 OEM 和微軟 PK/KEK 金鑰的組織完全受制於這些供應商的金鑰更新計劃，而自行管理金鑰的組織則需要一份清晰的金鑰清單：每個金鑰的簽署人、金鑰的到期時間以及輪調計劃。失去對密鑰清單的控制，無疑會在創業初期造成混亂。
資料庫 (DB) 和資料庫交換文件 (DBX) 需要特別監控。幾個月未更新的 DBX 檔案很可能包含已被宣告為不安全的二進位資源。另一方面，未經充分測試的更新可能會破壞與舊版本 shim 或 GRUB2 的兼容性。因此，許多公司會將 DB/DBX 的變更整合到常規的變更管理流程中，並在預發布環境中進行預先測試。
在大型組織中，將安全啟動與啟動過程度量和TPM支援結合的做法越來越普遍。這會將每個啟動階段的雜湊值記錄在TPM中，從而允許遠端驗證系統是否已使用已知且授權的韌體、引導程式和核心組合啟動。
超越啟動：在所有階段保護韌體
安全啟動固然強大，但光靠它本身並不足以保障安全。韌體安全性是一個持續的過程，包括配置、更新、監控和事件回應。其理念是建構相互加強的多層保護。
安全韌體更新至關重要。如果我們允許在任何環境下刷寫固件，卻不進行簽章驗證、不提供防降級攻擊保護，也不提供故障復原機制，那麼依賴安全啟動就毫無意義。更新必須經過數位簽名，並遵循嚴格的流程，理想情況下，還應包含防止回溯到易受攻擊版本的保護措施。
此外，建議充分利用現有的安全硬體：硬體信任根、安全金鑰儲存區、TPM、TrustZone、外部安全模組…這些元件可以隔離加密金鑰，使擁有實體存取權的攻擊者更難在不被發現的情況下提取金鑰或修改程式碼。
在資料方面，驗證啟動加上敏感資訊加密的結合是一項重大進步。如果裝置使用安全啟動來確保只啟動受信任的韌體，就可以將資料解密與該驗證狀態關聯起來。這樣，即使有人複製了內存，除非他們能夠重現相同的合法啟動序列，否則也無法訪問其中的內容。
循環的完成需要運行時保護機制：定期記憶體和韌體完整性檢查、看門狗、與啟動失敗或修改嘗試相關的安全事件日誌，當然還有阻止偵錯介面、保護程式記憶體讀取以及適當的硬體存取控制。
FirmGuard 和遠端 BIOS/UEFI 管理
在企業環境和託管服務提供者中，單獨管理每個裝置的韌體配置既浪費時間又容易出錯。而像FirmGuard 這樣的解決方案則能解決這個問題，它提供了一個集中式平台，可以遠端保護、設定、監控和更新 BIOS/UEFI 韌體。
其主要功能之一是能夠遠端配置關鍵的 BIOS/UEFI 選項（SecureConfig）。這使得管理員能夠系統地啟用安全啟動、調整安全參數、停用從未經授權的裝置啟動，或套用強化配置模板，而無需實際前往每台工作站。
此外，FirmGuard 還整合了持續韌體完整性監控 (SecureCheck) 功能。該平台監控 BIOS/UEFI 的更改，檢測異常修改，並在發現任何可能指向潛在惡意活動或未經授權的配置更改的跡象時發出警報。在韌體日益成為攻擊目標的環境中，這種可見性至關重要。
對於仍在傳統 BIOS 模式下運行的系統，FirmGuard 新增了第三個元件SecureSense，該元件能夠識別仍在使用傳統 BIOS 的系統，並協助其遷移到 UEFI——這是使用安全啟動和其他現代安全功能的關鍵步驟。從企業或 MSP 的角度來看，這意味著從異質且難以管理的系統遷移到更同質化且更易於防禦的系統。
綜合來看，這些類型的解決方案不僅可以降低韌體攻擊的風險，還可以為託管服務提供者提供明顯的附加價值，他們可以透過提供額外的底層保護來脫穎而出，並且透過自動化以前手動且成本高昂的任務來提高利潤率。
嵌入式系統中的韌體和安全啟動
除了個人電腦和伺服器之外，韌體安全性在嵌入式設備中也至關重要，例如工業控制器、醫療設備、消費性電子產品、汽車等等。在這些設備中，韌體故障不僅會導致資料遺失，而且往往還會造成實體安全風險和監管責任。
這些設備的最終用戶通常並不知道其底層運行著有漏洞的韌體。然而，這些事件卻是真實存在的：由於安全問題，醫療設備曾被大規模召回，例如眾所周知的心臟起搏器就因遠程攻擊風險而不得不進行更新或更換。這些情況會影響消費者的信任、收入以及製造商的聲譽。
當嵌入式設備的韌體遭到破壞時，後果可能是毀滅性的：失去客戶信任、代價高昂的召回、認證延遲（醫療保健、汽車、工業）、品牌形象受損，有時甚至會導致關鍵基礎設施的營運中斷。
在這些環境中，安全啟動顯得格外重要。從執行的第一個位元組開始建立信任鏈，確保只有經過製造商（或可信任機構）簽署的韌體才能啟動。之後，啟動過程的每個階段都可以驗證下一個階段：初始開機載入程式、輔助開機載入程式、應用程式韌體、嵌入式作業系統核心等等。
然而，在嵌入式裝置上部署安全啟動並非易事。它需要硬體支援來安全地儲存金鑰，需要一段不可更改的程式碼段作為信任根，還需要一種製造工藝，能夠在不洩露金鑰和憑證的情況下，為每個裝置自訂其金鑰和憑證。在一些功能非常有限的平台上，可能需要實現自訂的安全引導程序，這會帶來效能、資源消耗和成本方面的挑戰。
增加層數以實現真正強大的韌體
為了實現強大的韌體保護，需要多層防護。第一層是安全啟動，但它必須輔以安全的更新機制、受保護的儲存、運行時防禦和完善的組織實踐。
在更新方面，所有韌體和底層軟體鏡像都應進行數位簽名，並且最好能防止降級。空中下載 (OTA) 或本地更新應在接受更改之前驗證簽名，並應遵循軟體安全更新的最佳實踐，制定應急預案（韌體備份、安全恢復模式），以避免故障後系統無法使用。
安全儲存扮演著至關重要的角色。現代微控制器 (MCU)、配備 TrustZone、TPM 或專用安全元件的系統單晶片 (SoC)能夠保護金鑰和敏感數據，即使有人擁有實體存取權限，也無法在不留下痕跡或付出巨大努力的情況下提取它們。將這些金鑰的存取權限與安全啟動的成功掛鉤，進一步增強了安全性。
在執行過程中，必須結合定期完整性檢查、看門狗、記憶體保護（MPU、MMU、鎖定步驟）、啟動失敗嘗試或可疑韌體變更的日誌，以及在非常關鍵的產品中，甚至物理篡改感測器。
最後，如果組織不採用安全的開發和漏洞管理實踐，所有這些措施都將無法有效發揮作用：威脅分析、面向安全的設計、程式碼審查、滲透測試、清晰的事件回應流程，以及安全與品質並進的生命週期管理。韌體不能被視為編寫一次即可置之不理的東西。
擁有韌體和安全方面的專家合作夥伴的價值
鑑於我們所看到的種種情況，不難理解為什麼許多公司在需要加強安全啟動和韌體保護時會求助於專業的嵌入式系統和網路安全合作夥伴。光是掌握程式設計技能是不夠的：你還需要精通硬體、密碼學、工業流程、相關法規以及整個攻擊和防禦生態系統。
優秀的合作夥伴擁有開發引導程式、驅動程式、複雜嵌入式系統、加密機制和硬體控制器的實務經驗，能夠設計真正整合到產品中的安全解決方案，而不是只會增加維護複雜性的臨時附加元件。
它們通常還包括操作手冊和成熟的工具：可重複使用的安全啟動模組、用於管理金鑰和憑證的腳本、韌體加固指南、包含二進位簽章和自動驗證的持續整合 (CI) 管線等等。這可以節省時間，並降低新手犯下代價高昂的錯誤的可能性。
網路安全同樣至關重要。那些持續關注最新漏洞、側通道攻擊、常用物聯網架構缺陷以及安全設計最佳實踐的團隊，有助於從架構階段融入安全措施，而不是在最後階段才進行修補。他們通常秉持「安全設計」的理念，從需求階段就開始進行威脅建模和風險評估。
如果合作夥伴還擁有相關的ISO認證（例如ISO 9001、ISO 13485、ISO 26262等），則能進一步確保其流程經過審核且結構規範。這不僅意味著他們知道需要做什麼，還意味著他們擁有正式的程序和可追溯性，這在醫療保健或汽車等嚴格監管的行業中尤其重要。
最後還有一個因素，雖然不那麼技術性，但同樣重要：溝通和同理心。優秀的合作夥伴不會滿口晦澀難懂的術語，也不會強加那些根本無法在您的時間或預算範圍內實施的解決方案。他們會認真傾聽您的限制，清楚地解釋各種方案，並調整方法，在安全性、成本和上市時間之間找到平衡。在韌體和安全啟動專案中，這種目標一致的感覺至關重要。
簡而言之，實施安全啟動和強化韌體需要結合堅實的技術基礎（UEFI、金鑰層級結構、更新的憑證、維護良好的資料庫/資料庫X檔案）、規範的操作（韌體更新、金鑰管理、定時啟動、監控），以及在必要時借助能夠解決內部漏洞的專業解決方案和合作夥伴的支援。如果所有這些都正確執行，系統就能以可靠的啟動過程啟動，從而強化從核心到最高層應用程式的所有後續安全措施。
