Windows 安全開機金鑰建立和管理指南
本文件有助於引導 OEM 和 ODM 在製造環境中建立和管理「安全開機」金鑰和憑證。 文中討論了建立、儲存和擷取平台金鑰 (PK)、安全韌體更新金鑰，以及第三方金鑰交換金鑰 (KEK) 的相關問題。
注意
裝置 OEM、企業和客戶可以在 Microsoft 安全開機開放原始碼存放庫中找到 Microsoft 建議的 PK、KEK、DB 和 DBX 二進位檔。 二進位檔會被格式化為預期的 EDKII 格式，以輕鬆地整合到韌體中。
注意
Microsoft Corporation KEK CA 2011 將在 2026 年到期，而且所有 OEM 都必須建立、簽署和提交新 Microsoft Corporation KEK CA 2023 的更新給 Microsoft。 如此 Microsoft 即可使用新的 Microsoft KEK CA 來更新市場上的裝置，讓系統在 2026 年之後能夠繼續接收 DB 和 DBX 更新。 如需指示和測試附隨品，請造訪 https://aka.ms/KEKUpdatePackage
有關 UEFI 和「安全開機」的 Windows 需求，請參閱 Windows 硬體認證需求。 本文沒有介紹新的需求，也不代表官方 Windows 程式。 除了認證需求之外，也提供了如何建立高效率和安全的程序的指引，以建立和管理「安全開機金鑰」。 這很重要，因為 UEFI「安全開機」在執行之前必須使用「公開金鑰基礎結構」來驗證程式碼。
讀者應該知道 UEFI 的基本概念、對「安全開機」具有基本了解 (UEFI 規格的第 27 章)，也要了解 PKI 安全性模型。
驗證 Windows 上安全開機的需求、測試和工具，目前可透過 Windows 硬體認證套件 (HCK) 取得。 不過，這些 HCK 資源不會處理與 Windows 部署金鑰的建立和管理有關的問題。 本文將金鑰管理視為一種資源，有助於引導合作夥伴部署韌體所使用的金鑰。 不應將本文視為規範性指引，其中也不包含任何新的需求。
在此頁面上：
- 1. 安全開機、Windows 和金鑰管理包含適用於 Windows 和「安全開機」時之開機安全性和 PKI 架構的相關資訊。
- 2. 金鑰管理解決方案有助於合作夥伴設計符合其需求的金鑰管理和設計解決方案。
- 3. 摘要和資源包含附錄、檢查清單、API 和其他參考。
本文件可做為開發可供客戶使用的電腦、處理站部署工具和重要安全性最佳做法的基礎。
1. 安全開機、Windows 和金鑰管理
UEFI (整合可延伸韌體介面) 規格會定義稱為「安全開機」的韌體執行驗證程序。 「安全開機」是一種業界標準，用來定義平台韌體如何管理憑證、驗證韌體，以及作業系統如何與此程序互動。
「安全開機」使用「公開金鑰基礎結構 (PKI)」程序驗證模組，模組在通過驗證後才可執行。 這些模組可以包含韌體驅動程式、選項 ROM、磁碟上的 UEFI 驅動程式、UEFI 應用程式或 UEFI 開機載入器。 透過執行前的映像驗證，「安全開機」可降低開機前遭受惡意程式碼 (例如 rootkit) 攻擊的風險。 Microsoft 採用 Windows 8 和更新版本中的「UEFI 安全開機」作為其「信任式開機」安全性架構，為我們的客戶改善平台安全性。 如 Windows 硬體相容性需求中所定義，Windows 8 和更新版本用戶端電腦以及 Windows Server 2016 都需要「安全開機」。
「安全開機」程序的運作方式如下，如圖 1 所示：
- 韌體開機元件：韌體會驗證 OS 載入器是否受信任 (Windows 或其他受信任的作業系統。)
- Windows 開機元件：BootMgr、WinLoad、Windows 核心程序啟動。 Windows 開機元件會確認每個元件的簽章。 如果是不受信任的元件，不會被載入而且會觸發「安全開機」補救。
- 防病毒軟體和反惡意程式碼軟體初始化：此軟體會檢查 Microsoft 發行的特殊簽章，確認其為信任式開機關鍵驅動程式，且會在開機程序初期啟動。
- 開機關鍵驅動程式初始化：所有開機關鍵驅動程式上的簽章，都會在 WinLoad 的「安全開機」驗證中被檢查。
- 其他 OS 初始化
- Windows 登入畫面
圖 1：Windows 信任式開機架構
Microsoft 的「信任式開機架構」包含於 Windows 8.1 導入的「UEFI 安全開機」的實作。 惡意程式碼攻擊的方式不斷進化，鎖定開機路徑作為慣用的攻擊媒介。 這類攻擊一直難以防範，因為惡意軟體可以將反惡意程式碼軟體產品停用，導致它們無法完全載入。 使用 Windows「信任式開機」架構及其透過「安全開機」建立的信任根，可以確保在作業系統本身載入之前，只會執行經過簽署、認證的「已知良好」程式碼和開機載入器，保護客戶不會在開機路徑中執行惡意程式碼。
1.1 公開金鑰基礎結構 (PKI) 和安全開機
PKI 會在系統中建立真實性和信任。 「安全開機」會利用 PKI 進行兩個高階用途：
- 在開機期間，判斷是否可信任執行早期開機模組。
- 若要驗證服務要求的要求，包括修改「安全開機」資料庫和平台韌體更新。
PKI 包含：
- 發行數位憑證的憑證授權單位 (CA)。
- 驗證向 CA 要求憑證的使用者身分識別的註冊授權單位。
- 用來儲存和索引金鑰的中央目錄。
- 憑證管理系統。
1.2 公開金鑰密碼編譯
公開金鑰密碼編譯使用一對數學相關的密碼編譯金鑰，也就是公開和私密金鑰。 如果您知道其中一個金鑰，則無法輕易計算出另一個金鑰是什麼。 如果使用一個金鑰來加密資訊，則只有對應的金鑰可以解密該資訊。 針對「安全開機」，私密金鑰用來數位簽署程式碼，而公開金鑰則用來驗證該程式碼上的簽章，以證明其真實性。 如果私密金鑰遭到入侵，則具有對應公開金鑰的系統將不再安全。 這可能會導致開機套件攻擊，並損害負責確保私密金鑰安全性的實體信譽。
「安全開機」公開金鑰系統的內容如下：
1.2.1 RSA 2048 加密
RSA-2048 是非對稱密碼編譯演算法。 以原始格式儲存 RSA-2048 模數所需的空間是 2048 位元。
1.2.2 自我簽署憑證
與憑證公開金鑰相符的私密金鑰所簽署的憑證，稱為自我簽署憑證。 根憑證授權單位 (CA) 憑證屬於此類別。
1.2.3 憑證授權單位
根憑證授權單位 (CA) 會發出已簽署的憑證，確認憑證主體的身分識別，並將該身分識別繫結至憑證中包含的公開金鑰。 CA 會使用其私密金鑰簽署憑證。 它會在自我簽署的根 CA 憑證向所有相關方發出對應的公開金鑰。
在「安全開機」中，憑證授權單位 (CA) 包括 OEM (或其代理人) 和 Microsoft。 CA 會產生構成信任根的金鑰組，然後使用私密金鑰簽署合法作業，例如，允許的早期開機 EFI 模組和韌體服務要求。 對應的公開金鑰會內嵌在已啟用「安全開機」之電腦上的 UEFI 韌體，並用來驗證這些作業。
(有關 CA 使用方式和金鑰交換的詳細資訊，可從與「安全開機」模型有關的網際網路上取得。
1.2.4 公開金鑰
公開「平台金鑰」會隨附於電腦，且可供存取或「公開」。 在本文件中，我們將使用尾碼 "pub" 來表示公開金鑰。 例如，PKpub 表示 PK 的公開部分。
1.2.5 私密金鑰
若要讓 PKI 運作私密金鑰，必須安全地管理。 應該由組織內少數高度信任的個人存取，且位於具有強式存取原則限制的實體安全位置。 在本文件中，我們將使用尾碼 "priv" 來表示私密金鑰。 例如，PKpriv 表示 PK 的私密部分。
1.2.6 憑證
數位憑證的主要用途是驗證已簽署資訊的來源，例如二進位檔等。憑證的常見用法是使用傳輸層安全性 (TLS) 或安全通訊端層 (SSL) 實現網際網路訊息安全性。 使用憑證驗證已簽署的資料，可讓接收者知道資料的來源，以及資料是否已在傳輸中變更。
概略地說，數位憑證通常包含一個辨別名稱 (DN)、一個公開金鑰和一個簽章。 DN 會識別實體 (例如，一家公司)，該實體會保留符合憑證公開金鑰的私密金鑰。 使用私密金鑰簽署憑證並將簽章放在憑證中，會將私密金鑰連結至公開金鑰。
憑證可包含其他資料類型。 例如，X.509 憑證包含憑證格式、憑證序號、用來簽署憑證的演算法、發行憑證的 CA 名稱、要求憑證的實體名稱與其公開金鑰，以及 CA 的簽章。
1.2.7 鏈結憑證
來源：憑證鏈結：
圖 2：三個憑證鏈結
使用者憑證通常會由不同的私密金鑰簽署，例如 CA 的私密金鑰。 這就會構成雙憑證鏈結。 驗證使用者憑證是否為正版時需要驗證其簽章，而這需要從其憑證中取得 CA 的公開金鑰。 但在可以使用 CA 的公開金鑰之前，必須驗證封入 CA 憑證。 因為 CA 憑證是自我簽署的，因此會使用 CA 公開金鑰來驗證憑證。
使用者憑證不需要由根 CA 的私密金鑰簽署。 使用者憑證可以由中繼憑證的私密金鑰簽署，而該中繼的憑證是由 CA 的私密金鑰所簽署。 這是三個憑證鏈結的實例：使用者憑證、中繼憑證和 CA 憑證。 但鏈結中可以有多個中繼，因此憑證鏈結可以是任何長度。
1.3 安全開機 PKI 需求
UEFI 定義的信任根包含平台金鑰，以及 OEM 或 ODM 包含在韌體核心中的任何金鑰。 UEFI「安全開機」程序不會處理進入 UEFI 之前的安全性和信任根，而是由本文中提及的國家標準暨技術研究院 (NIST) 和信賴運算群組 (TCG) 發行集處理。
1.3.1 安全開機需求
在實作「安全開機」時請考慮以下參數：
- 客戶需求
- Windows 硬體相容性需求
- 金鑰產生和管理需求。
您必須挑選硬體進行「安全開機」金鑰管理，例如硬體安全性模組 (HSM)，考慮出貨給政府和其他機構之電腦的特殊需求，最後是建立、填入和管理各種「安全開機」金鑰生命週期的程序。
1.3.2 安全開機相關金鑰
用於「安全開機」的金鑰如下：
圖 3：與安全開機相關的金鑰
上圖 3 代表具有「安全開機」之電腦中的簽章和金鑰。 平台會透過 OEM 在製造期間安裝在韌體中的平台金鑰來保護。 「安全開機」使用其他金鑰來保護存取儲存金鑰的資料庫，以允許或不允許韌體的執行。
授權的資料庫 (db) 包含代表受信任韌體元件和作業系統載入器的公開金鑰和憑證。 禁止的簽章資料庫 (dbx) 包含惡意和易受攻擊元件的雜湊以及遭入侵的金鑰和憑證，並阻止執行這些惡意元件。 這些原則的強度是以使用 Authenticode 和公開金鑰基礎結構 (PKI) 簽署韌體為基礎。 PKI 是一個完善的程序，用於建立、管理和撤銷在資訊交換過程中建立信任的憑證。 PKI 是「安全開機」安全性模型的核心。
以下是這些金鑰的詳細資料。
1.3.3 平台金鑰 (PK)
根據 UEFI 2.3.1 Errata C 的第 27.5.1 節，平台金鑰會在平台擁有者和平台韌體之間建立信任關係。 平台擁有者將金鑰 (PKpub) 的公開部分註冊到 UEFI 2.3.1 Errata C 第 7.2.1 節中指定的平台韌體。此步驟會將平台從安裝模式移入使用者模式。 Microsoft 建議使用
EFI_CERT_X509_GUID類型的「平台金鑰」，使用公開金鑰演算法 RSA、公開金鑰長度為 2048 位元，以及簽章演算法 sha256RSA。 如果顧及到儲存空間，平台擁有者可能會使用EFI_CERT_RSA2048_GUID類型。 如本文件稍早所述，公開金鑰是用來檢查簽章。 平台擁有者稍後可以使用金鑰的的私密部分 (PKpriv)：- 若要變更平台擁有權，必須將韌體放入 UEFI 定義的安裝模式，該模式將停用「安全開機」。 只有在製造期間需要執行此動作時，才還原為安裝模式。
- 針對桌面和伺服器裝置，OEM 可以管理與其相關聯的 PK 和必要的 PKI，或選擇使用 Microsoft 管理的 OEM PK。 Microsoft 管理的 PK 由 Microsoft HSM 保護，並視為PKI 最佳做法的一部分來管理。 它是 Windows 生態系統的慣用 PK。
1.3.3.1 註冊或更新「註冊平台金鑰的金鑰交換金鑰(KEK)」
平台擁有者會呼叫 UEFI 開機服務 SetVariable() (如 UEFI Spec 2.3.1 errata C 第 7.2.1 節所指定) 註冊平台金鑰 (PKpub) 的公開部分，並重設該平台。 如果平台處於設定模式，則新的 PKpub 應使用其 PKpriv 對應項簽署。 如果平台處於使用者模式，則新的 PKpub 必須使用 PKpriv 簽署。 如果 PK 是
EFI_CERT_X509_GUID類型，則這必須由直接 PKpriv 簽署，而不是 PK 下發行之任何憑證的私密金鑰。1.3.3.2 清除平台金鑰
平台擁有者會呼叫 UEFI 開機服務 SetVariable() (變動大小 0) 清除平台金鑰 (PKpub) 的公開部分，並重設該平台。 如果平台處於安裝模式，則不需要驗證空白變數。 如果平台處於使用者模式，則必須使用目前的 PKpriv 簽署空白變數；如需詳細資訊，請參閱 UEFI 規格 2.3.1 Errata C 下的第 7.2 節 (變數服務)。 強烈建議切勿使用生產 PKpriv 來簽署封裝以重設平台，因為這會允許透過程式設計停用「安全開機」。 這主要是生產前測試案例。
平台金鑰也可以使用安全的平台特定方法清除。 在此情況下，全域變數「安裝模式」也必須更新為 1。
圖 4：平台金鑰狀態圖表
1.3.3.3 PK 產生
根據 UEFI 建議，公開金鑰必須儲存在電腦上防竄改和防刪除的非揮發性儲存體。 私密金鑰在合作夥伴或 OEM 的安全性辦公室中是安全的，且只有公開金鑰會被載入平台。 更多詳細資訊請參閱第 2.2.1 和 2.3 節。
Microsoft 提供 OEM PK 以消除維護和保護 PK 憑證的責任。 PK 由 Microsoft HSM 保護，並作為 Microsoft PKI 作業的一部分進行管理。
平台擁有者 (OEM) 自行決定產生的 PK 數目。 這些金鑰可能是：
每台電腦一個。 每個裝置都有一個唯一金鑰。 這對於具有高安全性需求的政府機構、金融機構或其他伺服器客戶，可能是必要的。 它可能需要額外的儲存體和密碼編譯處理能力，才能為大量電腦產生私密和公開金鑰。 這會在未來將韌體更新傳送至裝置時，增加對應裝置與其對應 PK 的複雜性。 有幾個不同的 HSM 解決方案可用來根據 HSM 廠商管理大量金鑰。 如需詳細資訊，請參閱使用 HSM 保護開機金鑰產生 。
每個模型一個。 每個電腦型號都有一個金鑰。 此處的取捨是，如果金鑰遭到入侵，相同型號內的所有機器都會容易受到攻擊。 這是 Microsoft 針對桌面電腦的建議。
每一個產品線一個。 如果金鑰遭到入侵，整個生產線就會容易受到攻擊。
每個 OEM 一個。 雖然這可能是最簡單的設定，但如果金鑰遭到入侵，您製造的每個電腦都會容易受到攻擊。 為了加快工廠車間的作業速度，PK 和其他金鑰可能會預先產生並儲存在安全的位置。 稍後可以在裝配線中擷取及使用它們。 第 2 章和第 3 章有更多詳細資訊。
1.3.3.4 重設 PK 金鑰
如果 PK 遭到入侵，或客戶基於安全而決定註冊他們自己的 PK，就可能需要重設金鑰。
您可以根據選取要建立 PK 的方法，為模型或電腦進行重設密鑰。 所有較新的電腦都會使用新建立的 PK 進行簽署。
更新生產電腦上的 PK 需要以取代 PK 或韌體更新程式封裝的現有 PK 簽署變數更新。 OEM 也可以建立 SetVariable () 封裝，並使用簡單的應用程式分配封裝，例如只變更 PK 的 PowerShell。 韌體更新程式封裝會由安全韌體更新金鑰簽署，並由韌體驗證。 如果執行韌體更新來更新 PK，請務必小心，確保將 KEK、db 和 dbx 保留。
在所有電腦上，建議不要使用 PK 作為安全韌體更新金鑰。 如果 PKpriv 遭到入侵，則安全韌體更新金鑰也會遭到入侵 (因為它們相同)。 在此情況下，可能無法註冊新的 PKpub 更新，因為更新程序也遭到入侵。
在 SOC 電腦上，有另一個不使用 PK 作為安全韌體更新金鑰的原因。 這是因為安全韌體更新金鑰會永久寫入符合 Windows 硬體認證需求之電腦的可燒毀保險絲上。
1.3.4 金鑰交換金鑰 (KEK) 金鑰交換金鑰會建立作業系統與平台韌體之間的信任關係。 每個作業系統 (以及可能需要與平台韌體通訊的第三方應用程式) 都會將公開金鑰 (KEKpub) 註冊到平台韌體上。
1.3.4.1 註冊金鑰交換金鑰
金鑰交換金鑰會儲存在簽章資料庫中，如 1.4 簽章資料庫 (Db 和 Dbx) 中所述。 簽章資料庫會儲存為已驗證的 UEFI 變數。
平台擁有者會依照 UEFI 規格 2.3.1 Errata C 的 7.2 (變數服務) 中所指定呼叫 SetVariable () 來註冊金鑰交換金鑰。 具有
EFI_VARIABLE_APPEND_WRITE屬性集和包含新金鑰的 Data 參數，或使用 GetVariable () 讀取資料庫，將新的金鑰交換金鑰附加至現有的金鑰，然後使用 UEFI 規格下第 7.2 (變數服務) 中指定的 SetVariable () 讀取資料庫，將新的金鑰交換金鑰附加至現有的金鑰，然後使用 UEFI 規格 下第 7.2 (變數服務) 中指定的 SetVariable () 寫入資料庫 2.3.1 沒有EFI_VARIABLE_APPEND_WRITE屬性集的 Errata C。如果平台處於安裝模式，則簽章資料庫變數不需要簽署，但是SetVariable () 呼叫的參數仍應依照第 7.2.1 節中已驗證的變數所指定來準備。 如果平台處於使用者模式，則必須使用目前的 PKpriv 簽署簽章資料庫
1.3.4.2 清除 KEK
可以「清除」(刪除) KEK。 請注意，如果未在平台上安裝 PK，則不需要簽署「清除」要求。 如果簽署了清除要求，則若要清除 KEK 需要 PK 簽署的封裝，而且要清除 db 或 dbx 需要由 KEK 中任何實體簽署的封裝。
1.3.4.3 Microsoft KEK
需要以下 2 個 Microsoft KEK 憑證才能透過更新 dbx 來撤銷不良映像，並可能更新 db 以準備更新的 Windows 簽署映像。
Microsoft Corporation KEK CA 2011
- SHA-1 憑證雜湊：
31 59 0b fd 89 c9 d7 4e d0 87 df ac 66 33 4b 39 31 25 4b 30。 - SignatureOwner GUID：
{77fa9abd-0359-4d32-bd60-28f4e78f784b}。 - Microsoft 會將憑證提供給合作夥伴，並可新增為
EFI_CERT_X509_GUID或EFI_CERT_RSA2048_GUID類型簽章。 - Microsoft KEK 憑證下載位置：https://go.microsoft.com/fwlink/?LinkId=321185。
- SHA-1 憑證雜湊：
Microsoft Corporation KEK 2K CA 2023
- SHA-1 憑證雜湊：
45 9a b6 fb 5e 28 4d 27 2d 5e 3e 6a bc 8e d6 63 82 9d 63 2b。 - SignatureOwner GUID：
{77fa9abd-0359-4d32-bd60-28f4e78f784b}。 - Microsoft 會將憑證提供給合作夥伴，並可新增為
EFI_CERT_X509_GUID或EFI_CERT_RSA2048_GUID類型簽章。 - Microsoft KEK 憑證下載位置：https://go.microsoft.com/fwlink/?linkid=2239775。
- SHA-1 憑證雜湊：
1.3.4.4 KEKDefault 平台廠商必須在 KEKDefault 變數中提供一組預設的金鑰交換金鑰。 如需詳細資訊，請參閱 UEFI 規格 第 27.3.3 節。
1.3.4.5 OEM/第三方 KEK - 新增多個 KEK
客戶和平台擁有者不需要有自己的 KEK。 在非 Windows RT電腦上，OEM 可能會有額外的 KEK，以允許其他 OEM 或信任的第三方控制 db 和 dbx。
1.3.5 安全開機韌體更新金鑰安全韌體更新金鑰是在韌體需要更新時用於簽署韌體。 此金鑰必須具備 RSA-2048 的最低金鑰強度。 所有韌體更新都必須由 OEM、其信任的委派 (例如， ODM 或 IBV (獨立 BIOS 廠商)，或安全簽署服務安全地簽署。
根據 NIST 發行集 800-147 現場韌體更新必須支援指導方針的所有元素：
任何韌體快閃存放區的更新都必須由建立者簽署。
韌體必須檢查更新的簽章。
1.3.6 建立安全韌體更新的金鑰
所有韌體更新都將使用相同的金鑰來簽署，因為公開部分將位於電腦上。 您也可以使用鏈結至「安全韌體」更新金鑰的金鑰，來簽署韌體更新。
每部電腦可能會有一個金鑰，例如 PK 或每一個型號或每一個產品線一個。 如果每部電腦有一個金鑰，表示需要產生數百萬個唯一的更新封裝。 請根據資源可用性來考慮您適用哪種方法。 每個型號或產品線都有金鑰是很好的折衷方案。
安全韌體更新公開金鑰 (或其用來節省空間的雜湊) 會儲存在平台上的一些受保護儲存體中，通常是受保護的快閃 (電腦) 或一次性可程式化保險絲 (SOC)。
如果只儲存此金鑰的雜湊 (為節省空間)，則韌體更新會包含金鑰，而更新程序的第一個階段，將會驗證更新中的公開金鑰是否符合儲存在平台上的雜湊。
膠囊是作業系統在重新開機時將資料傳遞至 UEFI 環境的方法。 Windows 會呼叫 UEFI UpdateCapsule () 來傳遞系統和電腦韌體更新。 在呼叫 ExitBootServices () 之前，Windows 會在開機時間將 Windows 驅動程序存放區中找到的任何新韌體更新傳入 UpdateCapsule ()。 UEFI 系統韌體可以使用此程序來更新系統和電腦韌體。 利用此 Windows 韌體支援，OEM 可以依賴相同的通用格式和程序來更新系統和電腦韌體的韌體。 韌體必須實作 ACPI ESRT 資料表，才能支援適用於 Windows 的 UEFI UpdateCapsule ()。
如需實作 Windows UEFI 韌體更新平台支援的詳細資訊，請參閱下列文件：Windows UEFI 韌體更新平台。
更新膠囊可以位於記憶體或磁碟上。 Windows 支援記憶體更新。
1.3.6.1 膠囊 (內存膠囊)
以下是記憶體內部更新膠囊運作的事件流程。
- OS 中的應用程式會將膠囊放入記憶體中
- 信箱事件設定為將擱置更新通知 BIOS
- 電腦重新開機、驗證膠囊映像和更新是由 BIOS 執行
1.3.7 一般韌體更新的工作流程
- 下載和安裝韌體驅動程式。
- 重新開機。
- OS 載入器會偵測和驗證韌體。
- OS 載入器會將二進位 Blob 傳遞至 UEFI。
- UEFI 會執行韌體更新 (此程序是由矽片廠商所擁有)。
- OS 載入器偵測成功完成。
- OS 完成開機。
1.4 簽章資料庫 (Db 和 Dbx)
1.4.1 允許的簽章資料庫 (db)
EFI
_IMAGE_SECURITY_DATABASEdb 的內容可控制驗證已載入映像時所信任的映像。 資料庫可能包含多個憑證、金鑰和雜湊，以識別允許的映像。下列 2 個憑證必須包含在 db 中，才能允許 Windows OS 載入器載入：
Microsoft Windows Production PCA 2011
- SHA-1 憑證雜湊：
58 0a 6f 4c c4 e4 b6 69 b9 eb dc 1b 2b 3e 08 7b 80 d0 67 8d。 - SignatureOwner GUID：
{77fa9abd-0359-4d32-bd60-28f4e78f784b}。 - Microsoft 會將憑證提供給合作夥伴，並可新增為
EFI_CERT_X509_GUID或EFI_CERT_RSA2048_GUID類型簽章。 - 您可以從這裡下載 Windows Production PCA 2011：https://go.microsoft.com/fwlink/p/?linkid=321192。
- SHA-1 憑證雜湊：
Windows UEFI CA 2023
- SHA-1 憑證雜湊：
45 a0 fa 32 60 47 73 c8 24 33 c3 b7 d5 9e 74 66 b3 ac 0c 67。 - SignatureOwner GUID：
{77fa9abd-0359-4d32-bd60-28f4e78f784b}。 - Microsoft 會將憑證提供給合作夥伴，並可新增為
EFI_CERT_X509_GUID或EFI_CERT_RSA2048_GUID類型簽章。 - 您可以從這裡下載 Windows Production UEFI CA 2023：https://go.microsoft.com/fwlink/?linkid=2239776。
- SHA-1 憑證雜湊：
除了鎖定只供 Windows 開機的系統，OEM 應該考慮包括 Microsoft 第三方 UEFI CA，以允許在電腦上執行來自第三方 UEFI 驅動程式和應用程式，而不需要使用者進行額外的步驟。
Microsoft Corporation UEFI CA 2011
- SHA-1 憑證雜湊：
46 de f6 3b 5c e6 1c f8 ba 0d e2 e6 63 9c 10 19 d0 ed 14 f3。 - SignatureOwner GUID：
{77fa9abd-0359-4d32-bd60-28f4e78f784b}。 - Microsoft 會將憑證提供給合作夥伴，並可新增為
EFI_CERT_X509_GUID或EFI_CERT_RSA2048_GUID類型簽章。 - 您可以從這裏下載 Microsoft Corporation UEFI CA 2011：https://go.microsoft.com/fwlink/p/?linkid=321194。
- SHA-1 憑證雜湊：
Microsoft UEFI CA 2023
- SHA-1 憑證雜湊：
b5 ee b4 a6 70 60 48 07 3f 0e d2 96 e7 f5 80 a7 90 b5 9e aa。 - SignatureOwner GUID：
{77fa9abd-0359-4d32-bd60-28f4e78f784b}。 - Microsoft 會將憑證提供給合作夥伴，並可新增為
EFI_CERT_X509_GUID或EFI_CERT_RSA2048_GUID類型簽章。 - 您可以從這裏下載 Microsoft UEFI CA 2023：https://go.microsoft.com/fwlink/?linkid=2239872。
- SHA-1 憑證雜湊：
1.4.2 DbDefault：平台廠商必須在 dbDefault 變數中提供「簽章資料庫」的一組預設項目。 如需詳細資訊，請參閱 UEFI 規格第 27.5.3 節。
1.4.3 禁止簽章資料庫 (dbx)
在檢查 db 之前，必須先檢查
EFI_IMAGE_SIGNATURE_DATABASE1dbx 的內容，而且任何相符項目都必須防止映像執行。 資料庫可能包含多個憑證、金鑰和雜湊，以識別禁止的映像。 Windows 硬體認證需求指出 dbx 必須存在，因此任何虛擬值，例如0的 SHA-256 雜湊 ，都可以用來作為安全預留位置，直到 Microsoft 開始傳遞 dbx 更新為止。 按一下這裡，從 Microsoft 下載最新的 UEFI 撤銷清單。1.4.4 DbxDefault：平台廠商可能在 dbxDefault 變數中提供「簽章資料庫」的一組預設項目。 如需詳細資訊，請參閱 UEFI 規格第 27.5.3 節。
1.5 在所有電腦上安全開機所需的金鑰
注意
裝置 OEM、企業和客戶可以在 Microsoft 安全開機開放原始碼存放庫中找到 Microsoft 建議的 PK、KEK、DB 和 DBX 二進位檔。 二進位檔會被格式化為預期的 EDKII 格式，以輕鬆地整合到韌體中。
| 金鑰/db 名稱 | 變數 | 負責人 | 備註 |
|---|---|---|---|
PKpub |
PK |
OEM |
PK – 僅 1 個。 必須是 RSA 2048 或更強。 |
Microsoft Corporation KEK CA 2011 Microsoft Corporation KEK 2K CA 2023 |
KEK |
Microsoft |
允許更新 db 和 dbx： |
Microsoft Windows Production CA 2011 Windows UEFI CA 2023 |
db |
Microsoft |
簽章資料庫 (db) 中的此 CA 可讓 Windows 開機：https://go.microsoft.com/fwlink/?LinkId=321192 |
禁止簽章資料庫 |
dbx |
Microsoft |
來自 Microsoft 的已知錯誤金鑰、CA 或映像清單 |
安全韌體更新金鑰 |
OEM |
建議是讓此金鑰不同於 PK |
資料表 1：「安全開機」所需的金鑰/db
2. 金鑰管理解決方案
以下是我們用於比較的一些計量。
2.1 使用的計量
下列計量可協助您根據 UEFI 規格 2.3.1 Errata C 的需求和您的需要來選取 HSM 電腦。
公開金鑰基礎結構 (PKI) 相關
- 它是否支援 RSA 2048 或更高版本？ - UEFI 規格 2.3.1 Errata C 建議金鑰為 RSA-2048 或更高版本。
- 它是否能夠產生金鑰和簽署？
- 它可以儲存多少個金鑰？ 它會將金鑰儲存在 HSM 或附加伺服器上？
- 用於擷取金鑰的驗證方法。 有些電腦支援多個驗證實體可供擷取金鑰。
定價
- 價位是多少？ 根據可用的功能，HSM 的價格介於 1,500 美元到 70,000 美元之間。
製造環境
- 工廠車間的運作速度。 密碼編譯處理器可以加速金鑰建立和存取。
- 輕鬆設定、部署、維護。
- 需要技能和訓練嗎？
- 備份和高可用性的網路存取
標準和合規性
- FIPS 合規性層級為何？ 是否防竄改？
- 支援其他標準，例如 MS 密碼編譯 API。
- 它是否符合政府和其他機構的需求？
可靠性和災害復原
它是否允許金鑰備份？
備份可以儲存在現場的安全位置，這個位置應該是與 CA 電腦和 HSM 不同的實際位置，同時也可以儲存在異地位置。
它是否允許高可用性以供災害復原？
2.2 金鑰管理選項
2.2.1 硬體安全性模組 (HSM)
根據上述準則，這可能是最適合且最安全的解決方案。 大部分 HSM 的合規性都符合 FIPS 140-2 層級 3。 FIPS 140-2 層級 3 合規性是嚴格的驗證規範，而且要求不得從 HSM 匯出或匯入金鑰。
它們支援多種金鑰儲存方式。 它們可以儲存在 HSM 本機，或儲存在連結至 HSM 的伺服器上。 在伺服器上，金鑰會加密並儲存，而且較適合需要儲存大量金鑰的解決方案。
密碼編譯模組安全原則應指定實體安全原則，包括密碼編譯模組中實作的實體安全性機制，例如防竄改密封、鎖定、竄改回應和歸零開關，以及警示。 它也允許指定操作員所需的動作以確保維護實體安全性，例如定期檢查防竄改密封或測試竄改回應和歸零開關。
2.2.1.1 網路 HSM
就安全性、遵循標準、金鑰產生、儲存體和擷取能力而言，此解決方案是同級中最佳的。 這些電腦大多支援高可用性，而且能夠備份金鑰。
根據它們提供的額外服務，這些產品的成本可能高達數萬美元。
2.2.1.2 獨立 HSM
這些適用於獨立伺服器。 可以使用 Microsoft CAPI 和 CNG 或任何其他 HSM 支援的安全 API。 這些 HSM 有多種尺寸，支援 USB、PCIe 和 PCMCIA 匯流排。
它們選擇性地支援金鑰備份和高可用性。
2.2.2 自訂解決方案提供者
公開金鑰密碼編譯是困難的，而且可能需要了解新的密碼編譯概念。 有自訂解決方案提供者可協助讓「安全開機」在製造環境中運作。
BIOS 廠商、HSM 公司和 PKI 諮詢公司提供各種自訂解決方案，讓「安全開機」PKI 在製造環境中運作。
下面列出了一些提供者：
2.2.2.1 BIOS 廠商
有些 BIOS 廠商可能會提供自訂解決方案。
2.2.2.2 HSM 廠商
某些 HSM 廠商可能會提供自訂諮詢。 有關更多資訊，請參閱使用產生和簽署 HSM 安全開機金鑰 (範例)。
2.2.3 信賴平台模組 (TPM)
信賴平台模組 (TPM) 是主機板上的硬體晶片，可儲存用於加密的密碼編譯金鑰。 許多電腦都包含 TPM，但如果電腦不包含 TPM，則無法新增。 一旦啟用，信賴平台模組可協助保護完整的磁碟加密產品，例如 Microsoft BitLocker 功能。 它會將硬碟鎖定或密封，直到電腦完成系統驗證或驗證程序為止。
TPM 可以產生、儲存和保護加密和解密程序中所使用的金鑰。
TPM 的缺點是，它可能沒有快速加密處理器來加速製造環境中的處理。 它們也不適合儲存大量的金鑰。 備份和高可用性以及符合 FIPS 140-2 層級 3 的標準可能無法使用。
2.2.4 智慧卡
智慧卡可以產生和儲存金鑰。 它們確實會共用 HSM 支援的一些功能，例如驗證和防竄改，但不包含太多金鑰儲存體或備份。 它們需要手動介入，而且因為效能可能很低而不適用於生產環境。
智慧卡的缺點類似於 TPM。 它們可能沒有快速的加密處理器來加速製造環境中的處理。 它們也不適合儲存大量的金鑰。 備份和高可用性以及符合 FIPS 140-2 層級 3 的標準可能無法使用。
2.2.5 延伸驗證憑證
EV 憑證是高保證憑證，其私密金鑰會儲存在硬體權杖中。 這有助於建立更強大的金鑰管理做法。 EV 憑證的缺點與智慧卡相同。
2.2.6 以軟體為中心的方法 (不建議)
使用密碼編譯 API 進行金鑰管理。 這可能牽涉到將金鑰儲存在加密硬碟上的金鑰容器中，並可能用於使用虛擬機器的額外沙箱和安全性。
這些解決方案的安全性不如 HSM，而且暴露出更高的攻擊媒介。
2.2.6.1 Makecert (不建議)
Makecert 是 Microsoft 工具，可如下用於產生金鑰。 若要確保受攻擊面最小化，您可能需要將電腦「隔離」。 有 PKpriv 的電腦不應該連接到網路。 它應該放置在安全的位置，而且如果沒有真正的 HSM，最好至少要使用智慧卡讀卡機。
makecert -pe -ss MY -$ individual -n "CN=your name here" -len 2048 -r如需詳細資訊，請參閱憑證建立工具 (Makecert.exe)。
不建議使用此解決方案。
2.3 安全開機金鑰的 HSM 金鑰產生和儲存體
2.3.1 儲存私密金鑰
每個 RSA-2048 金鑰需要 2048 位元空間。 金鑰儲存的實際位置取決於選擇的解決方案。 HSM 是儲存金鑰的好方法。
工廠車間電腦的實體位置必須是一個限制使用者存取的受保護區域，例如安全籠。
根據您的需求，這些金鑰也可以儲存在不同的地理位置，或備份在不同的位置。
這些金鑰的重設金鑰需求會因客戶而不同 (請參閱聯邦橋證書授權機構重設密鑰指導方針的附錄 A)。
這些可以每年完成一次。 您可能需要存取這些金鑰長達 30 年 (視重設金鑰需求等而定)。
2.3.2 擷取私密金鑰
需要擷取金鑰的原因有很多。
- 由於 PK 遭到入侵或為了遵守政府/其他機構法規，可能需要擷取 PK 才能發行更新的 PK。
- KEKpri 將用來更新 db 和 dbx。
- 安全韌體更新金鑰 –pri 將被用來簽署較新的更新。
2.3.3 驗證
根據 FIPS 140-2，驗證是以存取層級為基礎。
層級 2
安全性層級 2 至少要進行角色型驗證，由密碼編譯模組驗證操作員是否有權承擔特定角色並執行一組相應的服務。
層級 3
安全性層級 3 需要身分識別型驗證機制，增強針對安全性層級 2 所指定角色型驗證機制所提供的安全性。 密碼編譯模組會驗證操作員的身分識別，並確認已識別的操作員已獲授權擔任特定角色並執行一組相應的服務。
如 HSM 這樣的電腦支援安全性層級 3，需要身分識別型的 “k of m 驗證”。 這表示 k 實體會透過權杖獲得 HSM 的存取權，但在指定的時間點，至少必須有 k out of m 權杖才能進行驗證，才能從 HSM 取得私密金鑰的存取權。
例如，您應該驗證 5 個權杖中的 3 個才能存取 HSM。 這些成員可以是安全人員、交易授權者和/或執行管理的成員。
HSM 權杖
HSM 的原則可能會要求必須有權杖：
本機
遠端
設定成自動化
最佳做法是，請使用權杖和每個權杖密碼的組合。
2.4 安全開機和第三方簽署
2.4.1 UEFI 驅動程式簽署
如文件中的其他地方所述，UEFI 驅動程式必須由 db 中的 CA 或金鑰簽署，或具有 db 中包含的驅動程式映像雜湊。 Microsoft 將使用 Microsoft Corporation UEFI CA 2011 提供類似於 WHQL 驅動程式簽署服務的 UEFI 驅動程式簽署服務。 由此簽署的任何驅動程式都可在包含 Microsoft UEFI CA 的任何電腦上順暢地執行。 OEM 也可以簽署信任的驅動程式，並在 db 中包含 OEM CA，或在 db 中包含驅動程式的雜湊。 在所有情況下，如果 db 不信任 UEFI 驅動程式 (選項 ROM)，則不得執行。
系統韌體映像中包含的任何驅動程式都不需要重新驗證。 作為整體系統映像的一部分，可以充分保證驅動程式在電腦上受到信任。
Microsoft 已提供給任何想要簽署 UEFI 驅動程式的人。 此憑證是 Windows HCK 安全開機測試的一部分。 請遵循 [此部落格] ((https://blogs.msdn.microsoft.com/windows_hardware_certification/2013/12/03/microsoft-uefi-ca-signing-policy-updates/) 深入了解 UEFI CA 簽署原則和更新。
2.4.2 開機載入器
Microsoft UEFI 驅動程式簽署憑證可用於簽署其他 OS。 例如，Fedora 的 Linux 開機載入器將會由其簽署。
此解決方案不需要將更多憑證新增至金鑰 Db。 除了符合成本效益之外，還可用於任何 Linux 發行版本。 此解決方案適用於任何支援 Windows 的硬體，因此適用於多種硬體。
您可以從這裡下載 UEFI-CA：https://go.microsoft.com/fwlink/p/?LinkID=321194。 下列連結提供有關 Windows HCK UEFI 簽署和提交的詳細資訊：
3. 摘要和資源
本節摘要上述各節的內容，並逐步說明方法：
建立安全的 CA 或識別合作夥伴，以安全地產生和儲存金鑰
如果您不是使用第三方解決方案：
安裝並設定 HSM 伺服器上的 HSM 軟體。 如需安裝指示，請檢查您的 HSM 參考手冊。 伺服器會連接到獨立或網路 HSM。
如需 HSM 設定的相關資訊，請參閱第 2.2.1、2.3 節和附錄 C。
大部分 HSM 都提供 FIPS 140-2 層級 2 和 3 合規性。 針對層級 2 或層級 3 合規性設定 HSM。 層級 3 合規性對驗證和金鑰存取有更嚴格的需求，因此更安全。 建議使用層級 3。
設定 HSM 以進行高可用性、備份和驗證。 檢查您的 HSM 參考手冊。
遵循 HSM 提供者指導方針來設定 HSM 以供高可用性和備份。
此外，網路 HSM 通常有多個網路連接埠來隔離流量；允許伺服器與一般生產網路分開之網路上的網路 HSM 進行通訊。
一旦已識別屬於安全性小組的成員，就會將權杖指派給他們。 您必須設定 HSM 硬體以進行 k-of-m 驗證。
安全開機金鑰和憑證預先產生。 請參閱第 1.3 節至 1.5 節
使用 HSM API 預先產生 PK 和韌體更新金鑰和憑證。。
必要 - PK (建議每個模型 1 個)、韌體更新密鑰 (建議每個模型 1 個)、Microsoft KEK、Db、DbxNOTE：Microsoft KEK、db 和 dbx 不需要由 OEM 產生，並為了完整性而被提及。選用 - OEM/第三方 KEK db、dbx 和任何其他會進入 OEM Db 的金鑰。
將 Windows 映像套用至電腦。
安裝 Microsoft db 和 dbx。 請參閱第 1.3.6 節和附錄 B – 安全開機 API。
將 Microsoft Windows Production PCA 2011 安裝至 db。
如果 Microsoft 未提供空白 dbx，請安裝 。 Windows 會在第一次重新開機時，透過 Windows Update 自動更新 DBX 至最新的 DBX。
注意
使用屬於 Windows HCK 測試一部分的 PowerShell Cmdlet，或使用 BIOS 廠商所提供的方法。
安裝 Microsoft KEK。 請參閱第 1.3.3 節。
將 Microsoft KEK 安裝至 UEFI KEK 資料庫
警告
使用屬於 Windows HCK 測試一部分的 PowerShell Cmdlet，或使用 BIOS 廠商所提供的方法。
選擇性步驟 - OEM/第三方安全開機元件。 請參閱第 1.3.4 和 1.4 節。
識別您是否需要建立 OEM/第三方 KEK、db 和 dbx。
使用 HSM API 簽署 OEM/第三方 db 和含 OEM/第三方 KEK (稍早產生的) 的 dbx。
安裝 OEM/第三方 KEK、db 和 dbx。
UEFI 驅動程式簽署 – 請參閱第 2.4 節。
如果支援增益集卡片或其他 UEFI 驅動程式/應用程式/開機載入器，請將 Microsoft Corporation UEFI CA 2011 安裝至 UEFI db。
安全開機韌體更新金鑰 - 請參閱第 1.3.5 節。
僅限非 Windows RT 電腦：安裝安全韌體更新公開金鑰或其雜湊以節省空間。
只有在 SoC 上您才可能需要執行不同的動作，例如，燒毀安全韌體更新金鑰：公開或其雜湊。
啟用安全開機。 請參閱附錄 B – 安全開機 API。
將 OEM/ODM PKpub (慣用憑證，但金鑰沒問題) 安裝到 UEFI PK。
使用安全開機 API 註冊 PK。 現在應該已啟用電腦的「安全開機」。
注意
如果您在結尾安裝 PK，則 MS KEK、db、dbx 不需要簽署 – 沒有 SignerInfo 必須存在。 這是捷徑。
測試安全開機：依照指示執行任何專屬測試和 Windows HCK 測試。 請參閱附錄 B – 安全開機 API。
發貨平台：P Kpriv 可能永遠不會再次使用，以保護資料安全。
服務：未來韌體更新會使用簽署服務的安全韌體更新「私密」金鑰安全地簽署。
3.1 資源
安全性策略白皮書 - https://go.microsoft.com/fwlink/p/?linkid=321288
Windows HCK 提交 -https://go.microsoft.com/fwlink/p/?linkid=321287
附錄 A – 適用於製造的安全開機 PKI 檢查清單
以下是進階檢查清單，總結了在非 Windows RT 電腦上啟用「安全開機」所需的步驟。
設定安全開機
根據第 4 節的白皮書，定義安全性策略 (識別威脅、定義主動式和被動式策略)。
根據第 4 節中的白皮書，識別安全性小組。
建立安全的 CA 或識別合作夥伴 (建議的解決方案)，以安全地產生和儲存金鑰。
識別您要重設金鑰頻率的原則。 這可能取決您是否有任何特殊的客戶需求，例如政府或其他機構。
如果「安全開機金鑰」遭到入侵，請備妥應變計劃。
根據第 1.3.3 和 1.5 節，識別您要產生多少 PK 和其他金鑰。
這會以客戶群、金鑰儲存解決方案和電腦的安全性為基礎。
如果您使用由第三方進行金鑰管理的建議解決方案，請略過步驟 7-8。
採購伺服器和硬體以供金鑰管理。 – 根據第 2.2.1 節的網路或獨立 HSM。 考慮如果需要高可用性，您需要一個或多個 HSM 以及您的金鑰備份策略。
識別至少 3-4 個小組成員，他們將會有驗證權杖以在 HSM 上進行驗證。
使用 HSM 或第三方預先產生安全開機相關金鑰和憑證。 金鑰將取決於電腦類型：SoC、Windows RT 或非 Windows RT。 如需詳細資訊，請參閱第 1.3 到 1.5 節。
使用適當的金鑰填入韌體。
註冊「安全開機平台金鑰」以啟用「安全開機」。 如需詳細資訊，請參閱附錄 B。
依照指示執行任何專屬測試和 HCK 安全開機測試。 如需詳細資訊，請參閱附錄 B。
寄送電腦。 PKpriv 可能永遠不會再次使用，以保護資料安全。
服務 (更新韌體)
您可能因為多種原因而需要更新韌體，例如更新 UEFI 元件或修正「安全開機」金鑰入侵或定期重設「安全開機」金鑰。
如需詳細資訊，請參閱第 1.3.5 和 1.3.6 節。
附錄 B – 安全開機 API。
安全開機 API
下列 API 與 UEFI/安全開機相關：
GetFirmwareEnvironmentVariableEx：擷取指定韌體環境變數的值。
SetFirmwareEnvironmentVariableEx：設定指定韌體環境變數的值。
GetFirmwareType：擷取韌體類型。
設定 PK
使用 Set-SecureBootUEFI Cmdlet 來開啟「安全開機」。 在您的程式碼設定 PK 之後，「安全開機」的系統強制直到下次重新開機後才會生效。 在重新開機之前，您的程式碼可以呼叫 GetFirmwareEnvironmentVariableEx () 或 PowerShell Cmdlet: Get-SecureBootUEFI 來確認「安全開機」資料庫的內容。
驗證
您可以使用 Msinfo32.exe 或 PowerShell Cmdlet 來檢查「安全開機」變數狀態。 沒有 WMI 介面。 您也可以藉由某人插入未正確簽署的可開機 USB 隨身碟來進行測試 (例如，從 Windows HCK 安全開機手動標誌測試)，並確認其無法開機。
安全開機 Powershell Cmdlet
Confirm-SecureBootUEFI：UEFI 安全開機是否為 “ON”、True 或 False？
SetupMode == 0 && SecureBoot == 1
Set-SecureBootUEFI：設定或附加已驗證的 SecureBoot UEFI 變數
Get-SecureBootUEFI：取得已驗證的 SecureBoot UEFI 變數值
Format-SecureBootUEFI：建立 EFI_SIGNATURE_LISTs 和 EFI_VARIABLE_AUTHENTICATION_2 序列化
Windows HCK 和安全開機指示
下列步驟適用於系統測試和非特定類別驅動程式電腦測試。
停用「安全開機」保護。
輸入您的 BIOS 設定並停用「安全開機」。
安裝 HCK 用戶端軟體。
執行所有 Windows HCK 測試，但下列各項除外：
- 使用 PCR[7] 進行 BitLocker TPM 和復原密碼測試
- 使用「安全開機」的 Arm 電腦進行 BitLocker TPM 和復原密碼測試
- 安全開機標誌測試
- 安全開機手動標誌測試
輸入您的 BIOS 設定、啟用「安全開機」，並將「安全開機」還原至「預設」組態。
執行下列 BitLocker 和「安全開機」測試：
- 使用 PCR[7] 進行 BitLocker TPM 和復原密碼測試
- 使用「安全開機」的 Arm 電腦進行 BitLocker TPM 和復原密碼測試
- 安全開機標誌測試 (自動化)
輸入 BIOS 組態並清除「安全開機」設定。 這會藉由刪除 PK 和其他金鑰，將電腦復原為安裝模式。
注意
x86/x64 電腦需要清除支援。
執行安全開機手動標誌測試。
注意
「安全開機」需要使用簽署的 Windows HCK 或非 Windows RT 電腦上的 VeriSign 驅動程式
Windows HCK 安全開機標誌測試 (自動化)
此測試會檢查適當的現成可用「安全開機」設定。 這包括：
- 「安全開機」已啟用。
- PK 不是已知的，測試 PK。
- KEK 包含生產 Microsoft KEK。
- db 包含生產 Windows CA。
- dbx 存在。
- 許多 1kB 變數都會建立/刪除。
- 建立/刪除 32kB 變數。
Windows HCK 安全開機手動測試資料夾配置
Windows HCK 安全開機手動標誌測試資料夾配置如下所述：
"\Test"資料夾的內容如下：- 製造與服務測試
- 以程式設計方式在測試組態中啟用安全開機
- 維修測試
- 將憑證附加至 db，驗證函式
- 將雜湊附加至 dbx，驗證函式
- 將憑證附加至 dbx，驗證函式
- 將 600+ 雜湊附加至 dbx，驗證大小
- 以程式設計方式變更 PK
"\Generate"資料夾中有顯示以下內容的指令碼：測試憑證的建立方式
包含測試憑證和私密金鑰
建立所有測試的方式
將憑證和雜湊轉換成已簽署的封裝
您可以自行執行此作業，取代自己的憑證
"\certs"資料夾具有讓 Windows 開機所需的所有憑證：注意
請勿使用
"ManualTests\generate\TestCerts"中使用的方法來產生金鑰和憑證。 這僅供 Windows HCK 測試之用。 它會使用儲存在磁碟上且非常不安全且不建議使用的金鑰。 這不適用於在生產環境中使用。
"ManualTests\example\OutOfBox"資料夾內含您可以利用來在生產電腦上安裝「安全開機」的指令碼。"ManualTests\generate\tests\subcreate_outofbox_example.ps1"示範如何產生這些範例，並在合作夥伴可以取代其 PK 和其他中繼資料時，具有 “TODO” 區段。
Windows HCK UEFI 簽署和提交
下面連結提供更多資訊：
附錄 C – 聯邦橋證書授權機構憑證原則保證對應
基本
此層級提供有關個人身分識別的最低保證程度。 此層級的其中一個主要功能是提供所簽署資訊的資料完整性。 此層級與低惡意活動風險環境相關。 它不適用於需要驗證的交易，而且通常不足以用於需要機密性的交易，但可以用於後者，因為後者無法獲得具有更高保證級別的憑證。
基本
此層級提供與資料遭到入侵風險和後果的環境相關的基本保證層級，但這些風險和後果不具有重大意義。 這可能包括存取惡意存取的可能性不高的私人資訊。 此安全性層級假設使用者不太可能是惡意的。
中
此層級與資料遭到入侵風險和後果 (嚴重性中等) 的環境相關。 這可能包括具有大量貨幣價值或詐騙風險的交易，或涉及存取惡意存取的可能性很大的私人資訊。
高
此層級適用於資料受到威脅很高的地方，或安全性服務失敗的後果很高。 這可能包括非常高的價值交易或高層級的詐騙風險。