部署安全啟動影像檔與憑證方針(Deploying Secure Boot Image and Certificate Policy)

1.10 部署安全啟動影像檔與憑證方針

此章節描述如何部署影像檔與憑證方針，使用使用安全啟動自訂模式設定功能。

注意：此功能是不包含在UDK2010.SR1釋放，但加入了在EDK2的r13146記錄，還有它將被加入在未來的UDK版本。
本文件中沒有討論其他的方法來展開安全啟動策略利用BIOS供應商或作業系統供應商的特定的工具。
值得注意的，再UEFI2.3.1A規範中，安全啟動自訂模式安裝設定不是必須的，但是被要求通過Windows硬體認證規定，在2011的十二月。
http://msdn.microsoft.com/library/windows/hardware/hh748188
安全啟動影像檔和憑證策略規定是由指定的PK與KEK，還有加入授權憑證和影像檔簽章到授權簽章資料庫變數（DB）和禁用證書和圖像憑證與影像檔簽章到禁用簽章資料庫變數（DBX）。安全啟動自訂模式提供設定畫面用於此目的。

1.10.1 安全啟動安裝設定與使用者模式

UEFI 2.3.1A規格書的27.5章節定義安裝設定與使用者模式。
•     安裝設定模式(Setup Mode) - 當沒有平台密鑰(PK)被記錄發生時，在這個模式，PK、KEK、DB、還有DBX變數能被寫入，且無需授權。
•     使用者模式(User Mode) - 在一個平台密鑰(PK)被登錄與持續直到這個平台密鑰(PK)被清除時，在使用者模式期間，這安全啟動方針是強制執行的。

當前的模式可以被得到，藉由讀取SetupMode變數同樣描述在UEFI 2.3.1A的3.2章節。那裡的值如果為"1"就是SetupMode，若是為"0"就是指示為User Mode。
這片段的程式碼如下範例所顯示，它檢查這SetupMode值經由GetEfiGlobalVariable()函式，它使用EFI_GLOBAL_VARIABLE GUID。此函式被定義在MdePkg\Library\UefiLib\UefiLib.c.
#include〈Uefi.h〉
#include〈Library/UefiLib.h〉
UINT8 *SetupMode;
SetupMode = GetEfiGlobalVariable (L”SetupMode”);
If (SetupMode == NULL) {
//
// Null SetupMode  means no Authenticated Variable
// driver was dispatched. Secure Boot is not supported.
//
…
} else if (*SetupMode == 1 ) {
// platform is in SETUP MODE
…
} else if (*SetupMode == 0 ) {
// platform is in USER MODE

…

} else {

// handle undefined value

…

}

圖6 SetupMode架構變數的檢查值

1.10.2 安全啟動設定標準與自訂模式
安全啟動自訂模式設定功能允許使用者去修改一個實際存在的PK,、KEK,、DB，與DBX變數。此功能被定義在Windows硬體認證需求十二月，2011：
系統主要的UEFI安全啟動韌體，被實現在EDK2的r13146。它延伸使用者模式與兩個附加的模式(標準模式與自訂模式)。

•     標準模式 - 標準模式設定被顯示如圖7。如果一個實際存在使用者被偵測到， 然後轉換到自訂模式已啟動。Nt32Pkg與OvmfPkg，總是允許從標準模式進入到自訂模式。其他平台藉由平台特殊的方式去偵測到物理的存在，例如一個跳線器的存在。
•     自訂模式 - 在這模式PK,、KEK,、DB，與DBX變數能被更新。自訂模式設定被顯示如下面圖8到圖20。
這意味著實際存在的使用者能執行接下來的動作：

•     關閉安全啟動藉由刪除PK。
•     更新PK去開啟安全啟動。
•     記下KEK’s.
•     刪除KEK’s.
•     加入DB或DBX憑證，還是影像檔簽章。
•     從DB或DBX刪除憑證或是影像檔簽章。
這些活動被執行利用安裝設定畫面，顯示在1.10.5章節。

1.10.3  使用安全啟動自訂模式
在開啟UEFI安全啟動(藉由設定PK)以前，在KEK中的白與黑列表，DB與DBX必須被設定經授權的與禁用憑證，還有簽章。

1. 配置經授權的簽章憑證與影像檔的簽章。當安全啟動被開啟時，這裡有兩個方法授權給影像檔去執行：

• 所有影像檔簽章經由一個簽章憑證，它能被授權藉由登入這簽章憑證：(在範例中，它是KekRoot.cer)在KEK(請看圖17與圖18)。
• 個人影像檔簽章藉由另一個簽章憑證，它能被授權無須登入。那簽章憑證藉由登入各個影像檔簽章在DB中(請看圖17與圖18)。

2. 下個配置禁用簽章憑證與影像檔的簽章。

• 如果特定的簽章憑證或影像檔的簽章已經被列入黑名單，登入它們到DBX(請看圖20)。

3. 最後，登入PK(PkRoot.cer在這範例中)重新開啟安全啟動(請看圖13)。

1.10.4 安全啟動自訂ModeSetup畫面
此章節顯示提供這個功能，依據安全啟動自訂模式的實行在EDK2 r13146。其他的實現可能使用不同的選單。

1.10.4.1 標準模式 – 安全啟動配置
安全啟動被配置從設定經由選擇裝置管理員，然後安全啟動配置從裝置列表。
這呈獻安全啟動配置畫面，顯示在圖7，這顯示系統是一個標準模式(如在1.10.3節所描述)與那試圖安全啟動被開啟。

注意:   此“嘗試安全啟動” 項目顯示目前安全啟動UEFI變數狀態與無關安全啟動配置模式。換言之，安全啟動可以被開啟或關閉，在任意標準安全啟動配置模式或自訂安全啟動配置模式。

Figure 7 Standard Mode Screen

1.10.4.2 自訂模式 – 安全啟動配置
如果一個實際存在使用者被偵測到，(這是總是都在OVMF或Nt32Pkg實例下)選擇安全啟動模式範圍允許自訂模式被挑選，它呈現在自訂模式顯示在圖8，它允許安全啟動影像檔與簽章策略被改變(請看圖11自訂安全開機模式選項顯示)。

圖9 安全啟動配置 - 關閉

在這實例中，自安全啟動模式沒有被開啟以來，這試圖安全啟動是空白的。

1.10.4.3 開啟安全啟動
開啟安全啟動利用自訂模式設定畫面，接著這些步驟：
•     配置KEK。請看圖14。
•     隨意地, 配置DB。請看圖17。
•     隨意地, 配置DBX。請看圖20。
•     配置PK去開啟安全啟動。請看圖13。
一個安全啟動配置畫面範例，接著這些步驟被顯示在圖9之後。

圖9 安全啟動配置 - 開啟

這個例子，企圖安全啟動被開啟(X) ，安全啟動模式從未被配置。

圖10 關閉安全啟動畫面

1.10.4.4 關閉安全啟動
安全啟動被關閉，藉由移除PK如圖10所示，這會造成準備安全啟動區域還原成空白，如圖8中所示。

1.10.4.5 自訂安全啟動模式選項
這自訂安全啟動模式項目畫面顯示在圖11。圖11自訂安全啟動模式項目畫面提供存取的畫面，如：
•     記錄或刪除PK (請看圖12)
•     記錄或刪除KEK密鑰與憑證(請看圖14)
•     記錄或刪除DB憑證與簽章(請看圖17)
•     記錄或刪除DBX憑證與簽章(請看圖20)

圖11 自訂安全開機模式項目畫面

1.10.4.6 PK項目
此PK選項項目鏈結到圖12的PK選項畫面，它允許PK被登入（請參閱圖13）或刪除。

圖12 PK項目畫面

1.10.4.7 記錄PK使用檔案
圖13登入PK畫面，允許PK被載入從一個檔案，例如從一個隨身碟。

圖13 記錄PK畫面

1.10.4.8 KEK項目
圖14 KEK選項鏈結到登入KEK畫面(圖15)或刪除KEK畫面(圖16)。

圖14 KEK項目畫面

1.10.4.9 記錄KEK
圖15登入KEK畫面允許KEK被載入從一個檔案，例如從一個隨身碟。

圖15 記錄KEK畫面

選擇登入KEK利用檔案與使KEK檔案通過。
選擇GUID簽章與進入此GUID對應到的KEK。
KEK GUID是一個GUID值，來識別KEK。此值必須是以下格式：
11111111-2222-3333-4444-1234567890ab.

1.10.4.10 刪除KEK
圖16 刪除KEK畫面顯示，每個KEK項目憑著GUID與簽章型態，所以對於刪除要求KEK能被識別。

圖16 刪除KEK畫面

圖17 DB項目畫面鏈結到登入簽章(圖18)或刪除簽章(圖19)畫面。

圖17 DB項目畫面

1.10.4.12 記錄簽章
圖18登入簽章畫面允許影像檔簽章或憑證被載入從一個隨身碟。

圖18 記錄簽章畫面

選擇登入KEK利用檔案與使KEK檔案通過。
選擇GUID簽章與進入此GUID對應到的DB項目。
簽章GUID是一個GUID值，來識別此簽章的擁有者。此值必須是以下格式：
11111111-2222-3333-4444-1234567890ab.


1.10.4.13 刪除簽章
圖19 刪除簽章畫面顯示每個項目，所以對於刪除它們能被識別。

圖19 刪除簽章畫面

1.10.4.14 DBX項目
圖20 DBX項目顯示，模仿DB項目畫面...

圖20 DBX項目畫面

1.11 UEFI安全啟動方案
下面的UEFI的安全啟動情況，證明如下：

1. 一個擁有的簽章的UEFI影像檔，它的簽章憑證或簽名被登入。
2. 一個沒有的簽章的UEFI影像檔，它的簽名不被登入。
3. "一個擁有的簽章的驅動程式，它的簽名被登入"與"一個沒有的簽章的驅動程式，它的簽名不被登入"。
4. 啟動一個OS使用一個簽章與登入的驅動程式。

這些範例使用OVMF，如參考平台被描述在1.12章節中。其他的實現可能呈現不同的訊息。

1.11.1 一個擁有簽章的UEFI影像檔，它的簽章憑證或簽章被記錄
在這個實例中，恰好地擁有的簽章的影像檔被執行。如果一個違反安全被偵測到(例如影像檔恰好沒有簽章與影像檔鑑定失敗)，這行為取決於影像檔驗證策略，對於那影像檔型態(例如OptionRom，移動式媒體或固定媒體)。請看圖21與章節1.3。

圖21 正確簽章的應用程式被執行

1.11.2 一個沒有簽章的影像檔，它的簽章沒有被登入
在這個實例中，影像檔鑑定失敗與此影像檔不被執行。請看圖22。

圖22 未簽章的影像檔不備執行

1.11.3 一個擁有簽章的驅動程式(它的簽章被記錄)與一個沒有簽章的驅動程式(它的簽章沒有被記錄)
在這個實例中，有簽章的驅動程式被載入，而沒有簽章的驅動程式則沒有被載入。

圖23 載入簽章與未簽的驅動程式

1.11.4 啟動一個作業系統使用一個擁有簽章與登記的驅動程式
目前正在開發一個在QEMU上可被安全啟動的Linux核心。

1.12 使用OVMF與UEFI安全啟動
1.12.1 概述
OVMF (Open Virtual Machine Firmware)開放式虛擬機韌體能夠被使用如參考平台，對於測試包括UEFI安全開機在內。OVMF執行如同韌體在QEMU( www.qemu.org )，一個開放式來源處理器的模擬。
以QEMU，你能啟動UEFI Shell，執行UEFI 應用程式，開啟UEFI安全啟動與甚至啟動一個作業系統。

關於更多資訊在OVMF，請參閱：
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF

注意：SVN修正r13186被要求Nt32Pkg ，在UDK2010.SR1釋放中，不提供安全啟動的建立選項。

1.12.2 取得QEMU
QEMU是被包含在許多Linux發行版。
在編寫此文件時，在Windows7 *是無效的。請檢查更新在：
http://wiki.qemu.org/Links.

QEMU二進位檔的Windows XP版本能夠在下列鏈結下載：
http://wiki.qemu.org/Links 非正式的QEMU二進位檔的部分。

預先編譯的Windows版本(≥ 0.9.1)，提供經由TAKEDA Toshiya QEMU在Windows版本0.13.0 (10/16/2010)上。
http://homepage3.nifty.com/takeda-toshiya/qemu/index.html
注意：這是一個QEMU的舊版本，它可能漏掉一些更新在2010以後。

1.12.3 建立OVMF
EDK2來源程式碼，它包含OVMF：
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2 .

如何編譯OVMF的指令，請參考：
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=How_to_build_OVMF.

OVMF可以被編譯在X64、IA32或IA32X64架構上。
概述，編譯OvmfX64Pkg修改Conf/target.txt如下顯示：
•     ACTIVE_PLATFORM = OvmfPkg/OvmfX64Pkg.dsc or
•     TARGET_ARCH = X64
或OvmfIa32X64Pkg：
•     ACTIVE_PLATFORM = OvmfPkg/OvmfIa32X64Pkg.dsc
•     TARGET_ARCH = IA32 X64
或OvmfIa32Pkg：
•     ACTIVE_PLATFORM = OvmfPkg/OvmfIa32Pkg.dsc
•     TARGET_ARCH = IA32

1.12.4 CryptoPkg的OpenSslLib附屬功能

這安全軟體套件的鑑定變數與安全啟動特徵要求保密圖像提供支援，藉由OpenSslLib 在CryptoPkg中。

OpensslLib不被整合到CryptoPkg中，但包含在EDK2中，在來源編造上。詳細資訊如何下載與安裝OpenSSL對於使用在CryptoPkg的OpenSslLib，在CryptoPkg\Library\OpensslLib\ Patch-HOWTO.txt能夠找到相關資訊。


1.12.5 在OVMF中，開啟UEFI安全啟動
在OVMF，開啟UEFI安全啟動，接下來是編譯指令：
〉build –D SECURE_BOOT_ENABLE

當編譯完成時，OVMF影像檔在編譯的目錄中。例如，如果使用UNIXGCC跟X64工具，這ovmf.fd影像檔會座落於：
Build/OvmfX64/DEBUG_UNIXGCC/FV/OVMF.fd


1.12.6 來源層除錯器
如何使用UDK2010Source Level Debugger的指令，包括OVMF有用的在內：
http://www.intel.com/content/www/us/en/architecture-and-
technology/unified-extensible-firmware-interface/uefi-dev-kit-debugger-tool-
manual.html.

1.12.7 執行OVMF與QEMU
QEMU預期這BIOS是在bios.bin檔案與視訊Rom在vgabios-cirrus.bin。兩者的檔案應該是來自相同OVMF平台。

如在1.12.2章節上描述，QEMU能被執行在任一方的Linux或微軟視窗作業系統。無論如何，系統主機QEMU型態沒有關係到此系統，它主機的簽章工具描述在1.6章節上。那是一個影像檔簽章及Linux主機簽章工具應該辨識到這個影像檔擁有微軟視窗作業系統的簽章反之亦然。再者任一的影像檔可以被執行在任一QEMU環境上。

執行OVMF及QEMU，執行接下來的步驟：
1.   建立一個‘run-ovmf’目錄，在你的編輯樹下去執行OVMF及QEMU
bash$ mkdir run-ovmf
2.   複製或鏈結BIOS與Video Rom 影像檔，如下顯示：
對於Linux主機的QEMU：
bash$ cd run-ovmf
bash$ ln -s ../Build/OvmfX64/DEBUG_UNIXGCC/FV/OVMF.fv bios.bin
bash$ ln -s
../Build/OvmfX64/DEBUG_UNIXGCC/FV/CirrusLogic5446.rom \ vgabios-
cirrus.bin
對於微軟視窗XP主機的QEMU：
〉cd run-ovmf
〉copy  ../Build/OvmfX64/DEBUG_UNIXGCC/FV/OVMF.fv bios.bin
〉copy  ../Build/OvmfX64/DEBUG_UNIXGCC/FV/CirrusLogic5446.rom \
vgabios-cirrus.bin
3.   也複製每個影像檔、憑證、或密鑰， 它們需要被登入在 PK、KEK、
DB或DBX，如1.10.4章節上所描述。
4.   開始QEMU及接下來的指令與等待OVMF去啟動UEFIsshell如圖24下所顯示。
bash$ qemu-system-x86_64 -L . -hda fat:.

注意：這命令製作這當前的目錄 (run-ovmf在此實例中)硬碟利用經由QEMU。無論如何，QEMU處理此磁碟同唯讀，所以檔案產生在QEMU內部；在QEMU離開後，它們不被看見在run-ovmf中。

圖24 QEMU執行OVMF

下一步選擇檔案系統：
Shell〉fs0:
此檔案複製在步驟2與3上，現在它們將可被看見當輸入"ls"命令。

1.12.8 在OVMF中，開啟或修改UEFI安全啟動
UEFI安全啟動被開啟或修改如同1.10.4章節上所描述。

注意：因為UEFI安全啟動關閉，OVMF初始化。那安全開機的變數值為0x00。所以即使顯示選項的ROM有被簽章過，當OVMF開機它將失效。

注意：自變數不是目前持續的橫越OVMF祈願，UEFI安全啟動必須配置對於每個OVMF的祈願。

注意：如果使用UDK2010.SR1，關於此PcdOptionRomImageVerificationPolicy的系統預設值請看記錄在1.4章節。

1.12.9 QEMU註釋
在QEMU中:
•     輸入Ctl-Alt去釋放滑鼠。
•     輸入Ctl-Alt-3去看序列阜的訊息輸出。
關於更多資訊請瀏覽www.qemu.org。

1.13 使用Nt32PKG與UEFI安全啟動
1.13.1 概要
Nt32Pkg能被利用如同一個IA32提及的平台，對於測試包含UEFI安全開機在內。
以Nt32Pkg，你能啟動UEFI Shell，開啟UEFI安全啟動，與執行簽章的UEFI應用程式。

注意：Nt32Pkg不涵蓋一個視訊選項ROM的模擬，如OvmfPkg做的。所以它不能去驗證簽章選項的ROM對於Nt32Pkg。

注意：SVN修正r13186被要求Nt32Pkg ，在UDK2010.SR1釋放中，不提供安全啟動的建立選項。

1.13.2 建立Nt32Pkg
EDK2原始碼包含Nt32Pkg ，可以在此鏈結取得：
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2 .

修改Conf/target.txt如顯示再去編譯Nt32Pkg：
•     ACTIVE_PLATFORM = Nt32Pkg /Nt32Pkg.dsc
•     TARGET_ARCH = IA32

1.13.3 CryptoPkg的OpenSslLib附屬功能
注意那安全軟體套件的鑑定變數與安全啟動特徵要求保密圖像提供支援，藉由OpenSslLib 在CryptoPkg中。

OpensslLib不被整合到CryptoPkg中，但包含在EDK2中，在來源編造上。詳細資訊如何下載與安裝OpenSSL對於使用在CryptoPkg的OpenSslLib，在CryptoPkg\Library\OpensslLib\ Patch-HOWTO.txt能夠找到相關資訊。

1.13.4 在Nt32Pkg中，開啟UEFI安全啟動
在Nt32Pkg中，去開啟UEFI安全啟動，接下來的是需求的建構指令：
〉edksetup --nt32
〉build –D SECURE_BOOT_ENABLE
Nt32Pkg將啟動，偕同它的檔案系統指在其生成目錄。
…\Build\NT32\DEBUG_VS2008x86\IA32
這裡建立一個子目錄去含蓋影像檔，憑證或密鑰，它們需要被登入在PK中、KEK、DB或DBX，如同在1.10.4章節上所描述。

1.13.5 進行Nt32Pkg
開始進行Nt32Pkg，輸入
〉build run

圖25 執行Nt32Pkg中

接下來選擇檔案系統：
Shell〉fs0:

在1.13.4節上描述的影像檔憑證，密鑰或複製的腳本到該目錄中，當輸入“ls”，將馬上被顯示。

1.13.6 開啟或修改UEFI安全啟動在Nt32Pkg

UEFI安全啟動被開啟或修改如在1.10.4節上所述。方案1, 2 還有3 描述在1.11節上，它也能被執行在Nt32Pkg。方案4中，其中涉及啟動一個OS，那是不被允許。