搜尋此網誌

顯示具有 EFI/UEFI Secure Boot 標籤的文章。 顯示所有文章
顯示具有 EFI/UEFI Secure Boot 標籤的文章。 顯示所有文章

2017年3月8日 星期三

Check Legacy BIOS Image from UEFi Shell

//The program is for searching and dumping Legacy BIOS Image between 0 to 1M system Memory.
EFI_STATUS
EFIAPI
InitializeUIApplication (
    IN EFI_HANDLE           ImageHandle,
    IN EFI_SYSTEM_TABLE     *SystemTable
) {
    EFI_STATUS Status = EFI_SUCCESS;
    EFI_SHELL_APP_INIT (ImageHandle, SystemTable);
    {
        UINT64 addr, offset;
        UINT16 count = 0, i;
        Print(L"Detecting....\n");
        //for (addr = 0xC0000; addr < 0xE0000; addr += 0x200)
        for (addr = 0x0000; addr < 0x100000; addr += 0x200)
{
    //Print(L"address=0x%x\n", addr);
            if (
                ((*(UINT16 *)(addr + 0x00)) == 0xAA55) &&
                ((*(UINT16 *)(addr + 0x20)) == 0x8086) && //Vendor ID
                //((*(UINT16 *)(addr + 0x22)) == 0x27D8) && //Device ID
                (1)) {
                    Print(L"Legacy BIOS is at:0x%08x\n", (UINT32)(UINT64)addr);
                    for (offset = 0; offset < 4; offset ++){
                        Print(L"%08x: ", (UINT32)(addr + offset * 0x10));
                        for (i = 0; i < 16; i ++) {
                            Print(L"%02x ", (UINT8)*((UINT8 *)addr + offset * 0x10 + i));
                        }
                        for (i = 0; i < 16; i ++) {
                            if (((UINT8)*((UINT8 *)(addr + offset * 0x10 +  i)) >= 0x20)
                                && ((UINT8)*((UINT8 *)(addr + offset * 0x10 +  i)) < 0x80))
                                Print(L"%c", (UINT8)*((UINT8 *)addr + offset * 0x10 + i));
                            else
                                Print(L".");
                        }
                        Print(L"\n");
                    }
                    count ++;
            }
        }
        if (count == 0)
            Print(L"No found any BIOS image.\n");
    }
    {
         Print(L"System BIOS remaining memory[0040h:0013h]=0x%x(%d KBytes)\n", *(UINT16 *)0x413, *(UINT16 *)0x413);
         Print(L"Length of EBDA[0040h:000Eh]=%xh:0000h=%dk\n", *(UINT16 *)0x40e, *(UINT8 *)((UINT32)*(UINT16 *)0x40e << 4));
    }
    return Status;
}

2014年7月10日 星期四

[Windows]如何檢查目前是使用什麼系統模駔[Legacy BIOS or UEFI]開機?

1. 按住[Start] + [R] Keys
2. 輸入msinfo32
3. 檢查System Summary
    目前使用UEFI開機(64位元的平台),開啟Secure Boot State的功能。

2014年2月26日 星期三

How to enable Secure Boot checking in ASUS and GIGABYTE MB?

  • CSM(Compatibility Support Module)=>Boot Device Control=> please choose [UEFI Only] or [UEFI and Legacy OpROM] 
  • Secure Boot=> please choose [Windows UEFI Mode]
 Below Steps are for ASUS MB.


 Boot up OS.
 The UEFI system is supported GPT format.
 In Win8.1 OS, you will see the Secure Boot Item is ON.
 No Boot device.

Below Steps are for Gigabyte MB.

choose UEFI only or UEFI and Legacy OptionRom.


 Load default key settings.

System Summary showed the Secure Boot is ON.




2014年2月20日 星期四

How to enable/disable Secure Boot in UEFI MB?


  1. Legacy BIOS is no supported Secure Boot. 
  2. Go to check the MB whether it has below item and choose "Windows UEFI Mode" , then save the config (The Secure Boot will be enable after reboot the system). The Secure Boot Check will be enable. If a UEFI driver or Option ROM is not able to work in this time that it has not gotten the secure boot sign from MS.
  3. Choose "Other OS" the Secure Boot will be disable.

2013年8月27日 星期二

安全啟動概述(Secure Boot Overview) --- UEFI

From: http://technet.microsoft.com/en-us/library/hh824987.aspx

適用作業系統: Windows 8, Windows 8.1, Windows Server 2012, Windows Server 2012 R2

安全開機(Secure Boot)是一個在個人電腦上,以UEFI為基礎的功能;它幫助增加個人電腦的安全,以防止未被授權軟體在開機啟動程序期間被執行在個人電腦上。它檢查每個軟體程式區段是否擁有一個有效的簽章,包括作業系統被載入時也須被檢查。

當安全開機(Secure Boot)在個人電腦上被啟動,它會檢查每個軟體程式區段,在韌體中包含Option ROMs、UEFI驅動程式、UEFI應用程式、還有作業系統,違反已知良好簽章的資料庫維持著。如果每個軟體程式區段都是有效,此韌體執行這軟體與這作業系統。

常被問的問題:
• 我是否需要安全開機的功能,才能夠升級到最新版本的Windows系統?
◦ 對於x86與x64方面的PC:安全開機(Secure Boot)不是必備的。它是一個可選擇的功能,它能夠經由OEM製造商去加入它,為了增強PC的安全性,還有你將可以發現它在所有的Windows 8.1 搶先版或者是Windows®8的徽標認證的個人電腦。
◦  對於ARM方面的PC:對於Windows RT 8.1搶先版與Windows RT 8.1零售電腦,這安全開機(Secure Boot)是必備的,不能夠被關閉。
•  如果我的新硬體裝置不被系統信任時,會發生什麼事?
你的個人電腦(PC)可能不能夠被開機,這裡有兩種問題會發生:
◦  此韌體不信任此作業系統、Option ROM,驅動程式、或是應用程式,因為它不是被信任經由安全啟動資料庫(Secure Boot database)。
◦  一些硬體要求核心模式驅動程式,它必須擁有簽章。注意:許多舊識的32位元(x86)驅動程式沒有簽章,因為核心模式驅動程式簽章是為了安全啟動最近才被規定的。關於更多資訊,請參閱"Secure boot feature signing requirements for kernel-mode drivers"。
關於更多資訊,請參閱"Windows 8 with Secure Boot enabled may no longer boot after installing new hardware"。
•  如何我才能夠加入硬體或執行軟體或作業系統,當它們不被系統信任時?
◦  你能夠檢查Microsoft或是PC製造商是否有更新軟體。
◦  你能夠聯絡你的製造商並要求新增的硬體或軟體到安全開機資料庫(Secure Boot database)。
◦  對於x86還是x64的PC,你可能必須關閉安全開機(Secure Boot)的功能。請聯絡你的製造商取得相關操作說明。
◦  在某些情況下,你可能需要去改變在系統任體中的相關設定,例如:開啟Compatibility Support Module (CSM)去支援原始BIOS系統。去使用CSM同時,你可能也需要去重新格式化你的硬碟,使用Master Boot Record (MBR)的格式。然後重新安裝Windows。關於更多資訊,請參閱Windows安裝設定:安裝使用MBR或GPT磁區樣式( Installing using the MBR or GPT partition style)。
•  如何我才能夠建立或編輯安全啟動資料庫(Secure Boot databases)?
消費者應該聯絡他們的製造商取得對於他們的個人電腦的操作說明。

製造的需求
安全開機(Secure Boot)要求一部電腦,它符合UEFI規格2.3.1版,Errata C或更高。
全開機(Secure Boot)被支援對於UEFI類別2與類別3的電腦。關於UEFI類別2的電腦,當它的安全開機(Secure Boot)被致能,這compatibility support module (CSM)必須被除能,所以電腦只能夠啟動經授權的UEFI基礎的作業系統。

安全開機(Secure Boot)不要求一個信任的平台模組(Trusted Platform Module (TPM))
啟動核心除錯模式,致能測試簽章(TESTSIGNING),或去除能NX,你必須關閉安全開機(Secure Boot)。關於更多資訊,請參閱"Windows 8 Secure Boot Key Creation and Management Guidance"。

它怎麼運作?
當安全開機(Secure Boot)在個人電腦上被啟動,它會檢查每個軟體程式區段,在韌體中也包含UEFI驅動程式(被稱為Option ROMs)還有作業系統,違反已知良好簽章的資料庫維持。如果每個軟體程式區段都是有效,此韌體執行這軟體與這作業系統。

簽章資料庫與密鑰(Signature Databases and Keys)
之前個人電腦才開始部署,OEM儲存安全啟動(Secure Boot)資料庫到PC上。此包含簽章的資料庫(signature database (db)),撤銷簽章的資料庫(revoked signature database (dbx)),還有密鑰登入密鑰資料庫( Key Enrollment Key database (KEK))到PC上。在製造時期,這些資料庫被儲存到韌體非揮發的記憶體中。

簽章的資料庫(signature database (db))與撤銷簽章的資料庫(revoked signature database (dbx))列出這些簽章者或影像檔UEFI應用程式、作業系統載入器(例如:微軟作業系統載入器、或開機管理程式),或是UEFI驅動程式,它們能夠在個人電腦上被載入,且撤銷影像檔相關條款,它們不再被信任,還有可能不會被載入。

密鑰登入密鑰資料庫( Key Enrollment Key database (KEK))是一個分割簽章密鑰的資料庫,它能夠被應用在更新數位簽章資料庫與撤銷簽章的資料庫。微軟要求一個具體指明的密鑰被加入在KEK資料庫中,以便在未來微軟可以加入新的作業系統到數位簽章資料庫或添加到已知的惡意影像檔到撤銷簽章的資料庫中。

這些資料庫已被增添之後,與最後的韌體查核與測試之後,OEM鎖住韌體的編輯。除了更新,它必須擁有簽章跟正確的密鑰,經由實際存在的使用者,他使用韌體選單,然後產生一個平台密鑰(platform key (PK))。這PK可以被用來簽署更新KEK或關閉安全啟動(Secure Boot)。

在建立這些資料庫,OEMs應該聯絡他們的製造商關於工具與援助。關於更多資訊,請參閱"Windows 8 Secure Boot Key Creation and Management Guidance"。

啟動順序(Boot Sequence)
  1. 在PC的電源被開啟後,簽章資料庫核對平台的密鑰(platform key: PK)。
  2. 如果韌體不備系統信任,UEFI韌體必須開始OEM的特定復原原來已被信任的韌體。
  3. 如果這裡有一個跟Windows開機管理程式(Windows Boot Manager)的問題,此認體將試圖去啟動一個Windows開機管理程式的備份。如果還是失敗,認體必須開始OEM特定的矯正。
  4. 在Windows開機管理程式已經開始運作,如果這裡有一個跟驅動程式或NTOS核心的問題,Windows恢復環境程式(Windows Recovery Environment (Windows RE))會被載入,以至於這些驅動程式或核心影像能夠被復原。
  5. Windows載入非惡意程式軟體。
  6. Windows載入其他核心程式與初始化使用者模式程序。


關於更多資訊,請參閱白皮書: Secured Boot and Measured Boot: Hardening Early Boot Components Against Malware。

也可以閱讀其他的資源:
UEFI Firmware
Secured Boot and Measured Boot: Hardening Early Boot Components Against Malware

2013年8月16日 星期五

UEFI韌體簽章(UEFI Firmware Signing)

From: http://msdn.microsoft.com/en-us/library/windows/desktop/hh973604.aspx

UEFI簽署是在對話板(DASHBOARD)呈現,讓您針對x86或x64平台去簽署UEFI韌體二進位檔,因此它們可以被安裝在Windows PC上。

提交您的韌體
1. 使用您的Microsoft帳戶登入,然後點擊“硬體認證"。

2. 在創建提交對話板(DASHBOARD),在“硬體認證"頁面,產生呈遞區塊,點擊“創建UEFI呈遞"。

在進行之前,可能會需要您簽署一份法律協議。繼續的檢閱此文件,新增您的簽章,加入日期,然後單擊提交。每個組織只需要簽署此協議一次。

3. 所有UEFI呈遞必須是唯一的,簽章的CAB檔案與包含所有的UEFI檔案。CAB檔案簽章必須符合Authenticode證明檔關於您的公司。根據您的證明提供者,您可能需要使用一個對外的網路窗口或使用signtool。

4. 創建UEFI的網頁上,瀏覽去找出您想要呈遞的CAB檔案,然後單擊”遞交“(submit)。

重要
EFI ByteCode(EBC)檔案必須使用/ ALIGN:32旗標編譯對於處理接替。
提交包應該是一個CAB檔案庫,它不包含資料夾和只有這個*.efi檔案被簽章。

當對話板完成處理您提交的結果,它發送結果檔案經由電子郵件到工作電子郵件網址。

管理您的韌體
1. 對話板與您的Microsoft帳戶登入,然後單擊“硬體認證"。

2. 在"硬件認證“網頁上,在管理提交區塊中,點擊管理呈遞書(Manage submissions)。

3. 在的管理提交頁面,從提交類型(Submission type)列表中,選擇了UEFI表格。

4. 選擇您要管理的呈遞書。

5. 在詳細資訊圖中,您可以看到您的提交狀態,如果它是完成的,請下載此擁有簽章的二進制檔案。

[DASHBOARD]
https://sysdev.microsoft.com/en-us/desktop/Default.aspx?ReturnURL=%2fen-us%2fdesktop%2fmember%2fdefault.aspx

2012年11月19日 星期一

部署安全啟動影像檔與憑證方針(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,那是不被允許。

2012年10月9日 星期二

轉換簽章驅動程式成.rom檔案

1.7 轉換簽章驅動程式成一個.rom檔案
UEFI 2.3驅動程式寫作指南( Drivers Writers Guide for UEFI 2.3 (DWG) )的第32章中介紹的方法去分散UEFI驅動程式。如果簽章的驅動程式將被安裝在一個PCI卡的Option ROM,它必須從.efi檔案轉換到.rom檔案。
這UEFI DWG描述多種方式去做此轉換。然而,"EfiRom"工具將

然而,"EfiRom"工具將適用於最常使用的方法簽署對簽章影像檔,因為簽章的發生在EDK II的建構後與包裝成Option ROM前. 這EDK II的編譯系統沒有能力去自動簽署UEFI驅動程式的章,在包裝它們一個Option ROM之前。這處理過程被描述在DWG的18.7.1章節。

此"EfiRom"二進制的工具可以發現在BaseTools/Bin/Win32的目錄中,在EDK2的工作區中。

這個範例從剛才作簽章的MyDriver.efi,所創建出來的MyDriver.bin:
〉EfiRom -f 0x1013 -i 0x00b8  -e MyDriver.efi
這裡的–f是廠商辨識ID與 –i是裝置ID。
這個範例顯示對於Cirrus Logic的5446設備在OvmfPkg引含的數值。

1.8 安裝簽章的驅動程式
如果簽章的驅動程式將被安裝在一個PCI裝置卡的Option ROM,接下來更新PCI卡的Option ROM方式將由卡供應商提供。
如果簽章的驅動程式將被分散在EFI系統磁碟分區,它已準備好進行佈置。

1.9 添加簽章驅動程式到開機程序
此簽章的驅動程式在開機維護管理員(Boot Maintenance Manager)設定被添加到開機程序,藉由選擇驅動程式選項,然後加入驅動程式選項用途檔案(Add Driver Option Using File)。

2012年10月8日 星期一

UEFI影像檔上作個簽章

1.6 在UEFI影像檔上作簽章

此章節提供詳細說明如何在UEFI影像檔上作個簽章。
背景資訊關於簽署一個UEFI可執行章經微軟的可信碼(Authenticode)

  • http://msdn.microsoft.com/en-us/library/ms537359.aspx
  • 利用UEFI Shell, 移動平台超脫於DOS,MichaelRothman www.intel.com/intelpress, 請參閱附錄A - “安全注意事項”。
  • 參考PE/COFF與可信碼(Authenticode)說明書,在1.1.1章節。

1.6.1 微軟視窗為主的簽章工具
這部分為:
  • 列出微軟視窗工具的設定,它可以被使用在UEFI影像檔上作一個簽章。
  • 列出哪裡可以得到此工具。
  • 描述如何產生所需的鑰匙與憑證。
  • 具體說明如何使用那些鑰匙與憑證去作一個簽章在UEFI的影像檔上。
當簽可執行的憑證利用微軟可信碼(Authenticode)的簽章工具,這數位簽章被產生,它符合憑證型態WIN_CERT_TYPE_PKCS_SIGNED_DATA,還有它被定義在UEFI 2.3.1A規格書中。

1.6.1.1 需求工具
這節列出工具的設定,那符合簽章的方案,詳細在1.6.1.5與1.6.1.6章節。
這種情況下,需要以下工具:

  • Microsoft* MakeCert – 建立一個私有的祕鑰(.pvk檔案)與X509憑證(.cer檔案).
  • Microsoft* Pvk2Pfx – 轉換.pvk檔案到.pfx檔案。
  • Microsoft* SignTool – 簽署一個PE/COFF影像檔,例如:建立a .efi檔案利用密鑰與憑證,藉由makecert與pvk2pfx工具。
其他的使用資訊關於微軟的工具,可以在MSDN上找到(www.msdn.microsoft.com)。
注意: 這pfx, pvk檔案格式被描述在1.6.1.3章節下面。

1.6.1.2 取得工具
此時,這三個工具的最新版本都被放在Windows 8的消費者預覽版SDK,請造訪:http://msdn.microsoft.com/en-us/windows/hardware/hh852363,在C:\Program Files (x86)\Windows Kits\8.0\bin\... 目錄。
注意:這些工具必須被運行在SDK中的它們的位置,因為他們需要額外的DLL和檔案清單從該位置。換言之.exe的不應該被複製到和執行從另一個位置。
注意: 避免使用舊版本。

1.6.1.3 詳細的檔案格式
本章節提供檔案格式使用上的詳細資訊:
•     .pvk is a Microsoft private key file format.
•     .cer is a X509 certificate format using ASN.1 DER encoding.
•     .pfx format is defined by the PKCS#12 standard
(http://www.rsa.com/rsalabs/node.asp?id=2138 )

1.6.1.4 本文檔中使用的文件
在隨後的章節參考下列檔案使用的情況。
•     Driver being signed - MyDriver.efi
•     Root Certificate.  Use for development and test only.
•     PkRoot.cer  - Root certificate in X509 format.
•     PkRoot.pvk  - The Root Certificate’s private key in Microsoft PVK format. Has a password.
•     PkRoot.pfx - Root Certificate’s private key in PKCS#12 format.
•     Sub-Certificate.  Signed by the root certificate. Used to sign the driver. Will be enrolled in the KEK variable.
•     KekRoot.cer – Sub-certificate in X509 format.  Will be enrolled as KEK.
•     KekRoot.pvk - Sub-Certificate’s private key in Microsoft PVK format. Has a password.
•     KekRoot.pfx - Sub-Certificate’s private key in PKCS#12 format.

1.6.1.5 建立密鑰與憑證用於開發與測試

本節介紹了如何建立關於開發和測試用途,使用Microsoft* SignTool去簽署PE/ COFF影像檔所需要的密鑰和證書。它也有可能使用其他形式的簽署工具,或一個經由OSV或受信任的第三方提供的證書頒發機構CA去簽署開發與測試的影像檔。
注意:這些臨時的自我產生的密鑰和自我簽署憑證的使用目的是,在開發和測試過程中使用,而不是只作為生產用途。
注意:生產的影像的的簽章,需要先進的密鑰管理措施,以確保私鑰的安全和超出此文件的範圍。
注意:下面的範例指令顯示x64可執行檔的Windows8消費者預覽SDK的預設安裝路徑。

在這文件中的範例詳細介紹了使用兩個層次的憑證鏈
步驟如:

  1. 產生一個自我簽名憑證,作為來源的憑證(Root Certificate)。.
  2. 使用此來源的憑證(Root Certificate)去簽署一個子憑證(Sub-Certificate (a.k.a. child certificate))。

1. 產生一個自我簽名憑證。使用該憑證的來源的憑證(Root Certificate)還將它命名為PkRoot.cer。它是不的信任,並僅用於開發和測試使用。其相關的私有密鑰文件為PkRoot.pvk。

在DOS環境下的命令列是:
〉 "C:\Program Files (x86)\Windows Kits\8.0\bin\x64"\ makecert -n "CN=PkRoot " -r -sv PkRoot.pvk PkRoot.cer
Figure 3 PkRoot.pvk設定密碼

系統會提示您去設定的密碼PkRoot.pvk檔案。請記下此密碼待會使用。然後輸入這個密碼,去簽署PkRoot.cer。請參閱圖3。

2. 使用PkRoot.cer去簽署一個子認證,它的名稱是KekRoot.cer。其相關
私有密鑰文件為KekRoot.pvk。
在DOS環境下的命令列是:
〉 "C:\Program Files (x86)\Windows Kits\8.0\bin\x64"\ makecert -n "CN=KekRoot " -iv PkRoot.pvk -ic PkRoot.cer -sv KekRoot.pvk KekRoot.cer
圖4 KekRoot.pvk設定密碼

對於KekRoot.pvk文件,系統會提示您設置密碼,請參考圖4。請記下此密碼待會使用。然後輸入密碼PkRoot.pvk簽署KekRoot.cer。請參閱圖5。

圖5 輸入TestRoot.pvk密碼KekRoot.cer簽證
注意:我們可以用這方法來建立任何子層級的憑證,在這裡我們只是展示出一個兩個層的子憑證鏈。

1.6.1.6 在一個UEFI影像檔上作簽章

下面的步驟需要去簽署一個PE/COFF影像檔:

•     Convert the PVK file to PFX format (PKCS#12).
在DOS環境下的命令列是:
〉 "C:\Program Files (x86)\Windows Kits\8.0\bin\x64"\ pvk2pfx.exe –pvk KekRoot.pvk –pi 〈password〉 –spc KekRoot.cer –pfx KekRoot.pfx –f
注意:不要copy/paste此命令列從此文件到pvk2pfx。這工具不處理Unicode字元。

•    簽署MyDriver.efi利用SHA-256.
注意:signtool修改未簽署的驅動程式,經由添加簽章。如果你想保留一份未簽名的驅動程式,請先將它複製成另一個名稱。
Note:   signtool modifies the unsigned driver by adding the signature.  If you wish to maintain a copy of the unsigned driver, first copy it to another name.
在DOS環境下的命令列是:
〉 "C:\Program Files (x86)\Windows Kits\8.0\bin\x64"\ SignTool.exe sign /ac KekRoot.cer /f KekRoot.pfx /p 〈password〉  /fd sha256 MyDriver.efi

注意:所有的影像檔必須簽署執行一次安全啟動致能(即一旦PK已經登記與該平台是在使用者模式下,如圖6所示)。

1.6.2 Linux為主的簽章
資訊在Linux為主的簽章工具將會被加入,當它可用時。

1.6.3 影像檔驗證規則
所有簽章工具必須遵從微軟的可信碼(Authenticode)與PE/COFF規格書,參考如上。

在這些規範中的詳細規則的總結是:

  • 此影像檔的PE/ COFF部分必須是整齊的。那是每個部分的PointerToRawData應該大於前一個部分的PointerToRawData。
  • 這影像檔的PE/ COFF部分必須是相鄰的。那是不應該有差距當此部分被載入到記憶體,經它們的VirtualSize與VirtualAddress的參數,還有填補,如定義在PE/ COFF的規範書中。
  • 無符號的.efi 影像檔案的大小必須符合Autheticode的雜湊演算法。這概述如下:

a. 無符號的.efi 影像檔案的實際大小,如同存在,透過dir或ls命令或檔案的屬性,應該等於。
b.總和:
  1. The PE/COFF OptionalHeader.SizeOfHeaders
  2. The sum of each section’s SizeOfRawData.

注意:在P /COFF的值OptionalHeader.SizeOfImage的領域可能會有所不同
對於檔案的大小,跟一些工具鏈。

任何其他存在的資料在.efi 影像檔案將會導致影像檔驗證Authenticode失敗。
在微軟視窗系統,這些值可以使用以下方式獲得:
link –dump –headers  file.efi

在Linux系統上:
objdump –x file.efi

顯示出VirtualSize的部分,但不是該SizeOfRawData的部分,它是需要計算的。

2012年9月25日 星期二

UEFI影像檔授權流程

1.5 UEFI影像檔授權流程

在開機期間,授權處理經由那一個不知UEFI影像檔可能被認可去執行,其描述如下。對於更多資訊,請看UEFI規格書的27.7節。

1. 重置
這是當平台開始初始化,在開機期間。

2. 安全開機策略初始化。
初始化平台的安全開機策略,同定義在先前的章節。

3. 驗證UEFI可執行的影像檔。
在一個可執行的UEFI初始化期間,其建構於安全開機策略,開機管理員決定是否此可執行的UEFI應該被初始化。
驗證成功可執行的方法通過鑑定,或者它的簽署的證明書或簽章被發現,在韌體經授權的簽章資料庫與未被發現在禁止的簽章資料庫。除此以外,驗證失敗。
驗證步驟包含:
a. 鑑定影像檔的格式與結構。
b. 如果影像檔是沒有簽章的,還有它的簽章在經授權的資料庫(DB)與沒有在禁止的資料庫(DBX)中,然後執行這影像。
c. 如果影像檔有簽章,第一次檢查,如果它的證明已經被授權。如果影像檔的證明被發現在KEK或者是經授權的資料庫(DB),還有沒有在禁止的資料庫(DBX)中,然後執行這影像。
d.  如果影像檔的證明沒有被授權,檢查如果它的簽章已經被授權或者是禁止。如果它的簽章在經授權的資料庫(DB)與沒有在禁止的資料庫(DBX)中,然後執行這影像,然後執行這影像。
e. 在其他方面有一個違反安全性。檢查平台策略PCD去決定適當的動作。
f. 平台策略PCD對於可執行被載入從3個媒體儲存位置(Option Rom, 硬碟與隨身碟)被描述在1.3章。注意到可執行被載入從儲存裝置包含平台韌體(例如快閃記憶體或唯讀記憶體)被總是信任的。此策略詢問使用者,總是執行,從不執行,或是延後執行。對於詢問使用者,此使用者被詢問對於三答擇一: 'Yes', 'No', 或是'Defer',如下顯示。
注意:此圖來自於UDK2010.SR1釋放,它顯示一個截圖。實際上看到,更多的實施方式輸出可能會有所不同。

影像檔沒被發現在授權的資料庫

‘Yes’的意思,那使用者授權給發行可執行與等同於總是去執行。

‘No’的意思,那使用者否決發行可執行與等同於從不去執行。
‘Defer’的意思,那可執行不目前信賴與等同於延遲去執行。這下個開機選項被喚起。可執行可能是晉升到可信賴狀態與喚起在未來的時間。

4. UEFI可執行簽章通過系統配置表。如果判決是延遲或否定的,然後此影像檔簽章被複製到影像檔可執行資訊表,在EFI系統配置表,在作業系統中它是有效的。一個OS的應用程式可決定是否影像檔應該被信賴與更新在相對應的簽章資料庫。如果判定是‘Yes’,然後發行一般的可執行的UEFI。

5. UEFI可執行簽章增加到簽章資料庫。如果是有效的,經授權的使用者可註冊這簽章在韌體可信賴的簽章資料庫。



2012年9月24日 星期一

系統UDK2010.SR1安全開機策略PCD的設定預設值

1.4 系統UDK2010.SR1安全開機策略PCD的設定預設值

系統平台策略的預設設定在SecurityPkg/SecurityPkg.dec是:

  • 信任來自於Option ROM的所有影像檔。
  • 承認來自於硬碟與移動裝置的所有影像檔為有效的。詢問使用者去做決策,當違反安全的行為發生時。

系統PCD預設值是:
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00|UINT32|
0x00000001 
gEfiSecurityPkgTokenSpaceGuid.PcdRemovableMediaImageVerificationPolicy|0x05|UI
NT32|0x00000002
gEfiSecurityPkgTokenSpaceGuid.PcdFixedMediaImageVerificationPolicy|0x05|UINT32
|0x00000003

注意:平台執行它們的安全策略,經由覆蓋這些系統預設值在他們平台的DSC檔案。
注意:UDK2010.SR1基於平台必須覆蓋此PcdOptionRomImageVerificationPolicy系統預設值在他們平台的DSC檔案,假使Option ROM是否基於驅動程式的安全開機去取得簽章。
注意:BIOS必須被重新建立,當這些值被改變。

2012年9月20日 星期四

UDK2010.SR1 PCD的安全開機策略

1.3 UDK2010.SR1 PCD的安全開機策略

OEM與IBV可以客制劃它們平台的影像檔驗證策略,經由忽視系統預設策略值評估,為了各個裝置型態(硬碟、隨身碟或是Option ROM)在它們平台的DSC檔案。這必須是完成在建立這影像檔以前。此系統預設值被設定在SecurityPkg.dec檔案的[PcdsFixedAtBuild]區中。

下面是PCD的:
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy
gEfiSecurityPkgTokenSpaceGuid.PcdRemovableMediaImageVerificationPolicy
gEfiSecurityPkgTokenSpaceGuid.PcdFixedMediaImageVerificationPolicy

可行的策略有:
ALWAYS_EXECUTE: 
總是信任可執行。允許它去執行。
NEVER_EXECUTE: 
從不信任可執行。不允許它去執行。
ALLOW_EXECUTE_ON_SECURITY_VIOLATION: 
執行影像檔,它被完全地簽署,但它們的簽章沒有被發現在授權的資料庫或被找到在禁用資料庫。
DEFER_EXECUTE_ON_SECURITY_VIOLATION: 
延遲執行og影像檔,那是完全地簽署,但它的簽章沒有被發現在授權的資料庫或被找到在禁用資料庫,與加入一個記錄在影像檔執行資訊表格裡,像定義在UEFI規格書的27章。
DENY_EXECUTE_ON_SECURITY_VIOLATION: 
不執行影像檔,那是完全地簽署,但它的簽章沒有被發現在授權的資料庫或被找到在禁用資料庫,與加入一個記錄在影像檔執行資訊表格裡。

QUERY_USER_ON_SECURITY_VIOLATION:
詢問使用者對於一個判定當一個影像檔被正確地簽署,但它的簽章沒有被發現在授權的資料庫或被找到在禁用資料庫,與加入一個記錄在影像檔執行資訊表格裡,是否使用者沒有允許影像檔執行。目前我們使用UI彈出視窗,像詢問方式一樣。

對於模式資訊, 請看"影像檔授權流程"。

這些值對於這些策略設定是:
ALWAYS_EXECUTE                                                      0x00000000
NEVER_EXECUTE                                                         0x00000001
ALLOW_EXECUTE_ON_SECURITY_VIOLATION        0x00000002
DEFER_EXECUTE_ON_SECURITY_VIOLATION         0x00000003
DENY_EXECUTE_ON_SECURITY_VIOLATION          0x00000004
QUERY_USER_ON_SECURITY_VIOLATION               0x00000005

2012年9月19日 星期三

UEFI安全啟動(Secure Boot)的鑑定變數

1.2 UEFI安全啟動(Secure Boot)的鑑定變數
1.2.1 [鑑定變數的概要]
UEFI鑑定變數服務被定義成一個增強UEFI變數服務。它提供一個方法去確保詳細指明變數的完整性,藉由在前面加上身份證明資料,如EFI_VARIABLE_AUTHENTICATION在下圖所示。這身份證明資料被定義在UEFI 2.3.1A規格書的第3章。
如果一個變數的EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS位元被設定,當這SetVariable被呼叫,運算本身與資料的完整性兩者將被生效,在這變數被寫入到儲存裝置。
既然不是以機密為設計目標,沒有資料的認證,那隨後的讀取使用GetVariable函式。
因此任何人能夠讀取鑑定變數,但只有持有正確密鑰的這些人,他們可以寫或更新鑑定變數。

鑑定變數資料的區塊圖顯示如下:

1.2.2 [鑑定變數的型態]

UEFI 2.3.1A規格書的7.2章節定義鑑定變數的兩個型態:計數器型態與時間型態。
為了預防重演攻擊,計數器型變數包含一個單調的數在EFI_VARIABLE_AUTHENTICATION區段中,而時間型的變數包含一個時間郵戳用於此目的。
各個方法用於不同的情境去部署對應的安全開機策略。儘管如此,當UEFI規格書說明,那時間型的方法是比較好的;計數器型部署的方案是不被描述在這文件中。

1.2.3 [安全開機的鑑定變數]
描述
UEFI安全開機的影像檔與認證策略被控制經由UEFI鑑定變數,它被定義在UEFI 2.3.1A規格書的3.2章節:
  • Platform Key (PK) - 平台密鑰建立一個信賴關係在平台擁有者與平台韌體之間。平台擁有者記下公開二分之一的祕鑰 (PKpub)進入平台韌體。平台擁有者能晚一點使用私有的祕鑰 (PKpriv)去改變平台關係,或記下一個鑰匙兌換的祕鑰。在UEFI 2.3.1方面,它建議平台密鑰的格式是RSA-2048。
  • Key Exchange Key (KEK) -  鑰匙兌換的祕鑰建立一個信賴關係在做鑰系統與平台韌體之間。密鑰的公開部分被記錄到平台韌體。各作業系統(與潛在地,各個第三方的應用,它們需要通訊與平台韌體)能晚一點使用私有的二分之一的祕鑰 ( KEKpriv )去 與韌體通訊在一個信賴的方式。 在UEFI 2.3.1方面,它建議平台鑰匙兌換的祕鑰的格式是RSA-2048。KEK也能包含授權的簽署認證。
  • Authorized Signature Database (DB) - 這資料庫包含授權的簽署認證與數位簽章。一個影像檔簽署一個認證已記錄在DB(或KEK)或它們被授權的數位簽章被記錄在 DB去執行。DB是白表(可信的資料庫)。
  • Forbidden Signature Database (DBX) -  這資料庫包含禁用的認證與數位簽章。 一個影像檔簽署一個認證已記錄在DBX或它們的數位簽章被記錄在DBX,是從不被永許去執行。DBX是黑表(禁用的資料庫)。
  • Setup Mode - 當設定模式是無效的,沒有平台密鑰被記錄與平台被聲明是運行在設定模式。而在設定模式中,平台韌體不鑑定影像檔與安全開機策略能被配置經由寫入PK、KEK、DB,還有DBX變數。當設定模式不是無效,一個平台密鑰被記錄與平台運行在使用者模式中。使用者模式要求全部可執行先被鑑定,在它們允許執行如果它們被載入從位置(硬碟、隨身碟或Option ROM)致能經由安全開機策略PCD敘述下。
  • SecureBoot - 當設定(1),平台是運行在安全開機模式與平台影像檔驗證取決於資料被儲存在DB與DBX,還有安全開機策略PCD敘述下。

2012年9月18日 星期二

安全啟動(Secure Boot)對策的五個要素

要素#1: UEFI 2.3.1平台韌體與韌體 和強大的安全性對策
  • UEFI 2.3.1是一個架構規格書。
  • 但真實的安全優勢是在對策的執行。
  • OEM-ACTION對策必須定鎖不確信的程式碼包含所有的傳統16-bit程式碼
  • 但使用者經驗是接受的關鍵:
- 我們出廠鎖定的安全系統,但有多少的自由度,我想應該給用戶去重新配置?
-  我的UI設計該如何避免用戶混淆使用“不太安全”的系統?
要素#2: 關鍵性資料的硬體保護
  • 硬體保護的關鍵資料庫是不可缺的對於安全的實現。
  • OEM-ACTION運作與你的晶片組供應商,和IBV執行關鍵資料的強健保護。
要素#3: 支援來自IBV, IHV與ISV的合作
  • OEM-ACTION 系統ROM將需要去涵蓋UEFI驅動程式,對於所有電路板上的裝置(無傳統驅動程式)。
  • IHV-ACTION 擴充卡將需要簽證 UEFI驅動程式。
  • ISV-ACTION 預開機軟體工具,例如可開機的恢復磁碟,此工具將需要被簽證。
要素#4: 工廠供應
  • 需要幾個新的步驟在製造廠流程的結尾處。
  • OEM-ACTION供應:
- OS合作夥伴的密鑰
- OEM支援與更新密鑰
- 安裝平台的密鑰去鎖系統。
還有區域支援工具
  • 任何區域支援工具應該是:
- 簽證可執行的UEFI(使用UEFI Shell, 非DOS)
- 出廠時預先簽證經由OEM的密鑰。
  • OEM-ACTION檢驗區域支援流程,例如
- 考慮用戶將來會重新初始化更換主機板?
  •  將來支援 - 企業管理人員安裝企業密鑰
- 能讓企業買家不鎖新系統與重新供應利用你的工具?
要素#5: 安全的韌體更新
  • 韌體的安全層更新必須符合系統的安全性目標。
OEM-ACTION
  1. 簽證所有韌體更新影像檔。
  2. 韌體更新處理必須發生在安全的韌體控制裡(不是在OS)。
  3. H/W快閃記憶體保護必須拒絕任何寫入的動作,對於未被授權的來源。
總結
  • 企業過渡從傳統到UEFI將衝擊所有產業部分在這年。
  • UEFI 2.3.1規格書更新添加有效數字的新值,允許改進過的UEFI系統的防護。
  • 驅動程式簽證與鑑定變數是密鑰工具,為了建造UEFI安全開機。
  • OEMs需要執行UEFI安全開機,如同一個完整的策略的部分在 IHV與ISV的合作會議。
下載新的UEFI 2.3.1規格書從www.uefi.org
  • OEMs需要執行UEFI開機與使用UEFI 2.3.1安全特色去讓它們的系統變強健。
  • OEMs必須與IBV、IHV,還有ISV合作運行在協調一致的途徑。

2012年9月17日 星期一

為什麼要實現UEFI安全啟動(Secure Boot)機制?

為什麼要實現UEFI安全啟動(Secure Boot)機制?


  • 針對薄弱的環節鏈,讓作業系統變得更耐攻擊的威脅。
  • 16-bit 傳統系統開機是不安全的。[[ 它應該不被驚訝。2010年十大殭屍網絡 - 在Damballa威脅報告中,TDL Gang殭屍網絡攀升到排名第一的位置“RudeWarlockMob” ... 老病毒和物件的應用有效的作用。自16位作業系統的日以來,它整合技術已起了作用;像是主要開機記錄磁區(MBR)感染...與較新的惡意軟件技術。(取自http://blog.damballa.com) ]]
  • 安全啟動(Secure Boot)基於UEFI 2.3.1,移除了傳統的威脅。並且提供軟體身份的檢查,每一個開機步驟 - 平台韌體,介面卡,與OS開機載入器。

擴大改善UEFI 2.3.1
  • 平台的安全性與完整性。
- 允許韌體鑑定UEFI影像檔,例如 OS開機載入器。
在擁有者授權的方式,去確保韌體驅動程式被載入
  • 技術包含:
- UEFI可執行的嵌入式的數位簽章的方法,使驅動做簽章,還有從一個授權的來源去驗證簽章。
-  鑑定變數服務。
- 新的全域定義變數。 
UEFI驅動簽章
添加策略大概是UEFI與它的第3方影像檔的伸展性。
- 安全性對於OS開機載入器、應用程式、還有系統的第三方驅動程式。
- 給IT控制大約可執行的這些。
- 偵測/預防惡意程式。
技術包含:
- 支援“已知良好”和“已知的惡意”簽章資料庫。
- 策略取決於更新列表。
- 驗證碼簽章型態(Windows驗證碼輕便可執行的簽章格式)

 UEFI鑑定變數
  • 運用計數器的鑑定變數(UEFI 2.3)
- 使用單調的計算預防可疑的重播攻擊
- 混湊演算法 -  SHA256
- 簽章演算法 -  RSA-2048
  • 運用時間的鑑定變數(UEFI 2.3)
- 使用EFI_TIME如同自動恢復機械作用的保護(時光回溯)
- 混湊演算法 -  SHA256
- 簽章演算法 -  X.509 certificate chains
  • 全面的 X.509證明連鎖
  • 支援中間的證明(非根源的證明如同確信的證明)

安全啟動(Secure Boot) – 全域變數
  • PK - 設置此變數,將機器從非安全的"設定模式"到安全開機的"使用者模式"。變數是自己簽章的。
  • KEK - 一個鑑定的變數涵蓋所有實體公共證明與權限去更新允許和禁止的資料庫。
全域變數內容
  • db - (允許)- 一個鑑定的變數涵蓋軟體簽章者的公共證明。透過這些簽章者被允許在一個安全的開機模式(使用者模式)做模組的簽章。也能包含允許模組的混湊。
  • dbx - (禁用) - 一個鑑定的變數涵蓋撤銷簽章證明,還包含禁用模組的混湊。
  • SetupMode - 經由任體產生一個唯讀系統執行期間的變數,意謂PK是設定值,1 = 設定模式,0 = 使用者模式(PK被設定時,安全開機是打開著)。
  • SecureBoot - 經由任體產生一個唯讀系統執行期間的變數,設定1 = PK外加所有的條件,當預見安全啟動(Secure Boot)。在一些系統上,使用者能夠選擇暫停SecureBoot的檢查,例如恢復,但須停留在使用者模式。這旗號通知作業系統。

2012年9月16日 星期日

UEFI Secure Boot 概要

1.1 UEFI Secure Boot 概要
UEFI安全啟動(Secure Boot)定義平台的韌體如何鑑定一個UEFI影像檔的數位簽章,例如一個作業系統的載入器或一個UEFI驅動程式存在一個Option ROM, 以這樣的方式提供功能去確保那些UEFI影像檔,它們只被載入在一個經所有人授權的方式。當系統執行以UEFI為底的韌體時,所提供大眾的方法去確保平台的安全與完整性。
更多詳細的概要請瀏覽Intel Technology日誌,參考下面章節。

1.1.1 [影像格式]
UEFI影像檔使用PE/COFF格式與簽章如同定義在微軟的Authenticode 說明,請看接項來的說明手冊:
  • Microsoft Portable Executable and Common Object File Format Specification, http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx
  • Windows Authenticode Portable Executable Signature Format, http://www.microsoft.com/whdc/winlogo/drvsign/Authenticode_PE.mspx
1.1.2 [UEFI安全啟動(Secure Boot)方針]
UEFI安全啟動(Secure Boot)的設計與實現接下來的目標:
  • 允許這平台所有者檢查一個已知的影像檔確保其完整性與安全性,這影像檔只能被載入經由此檢驗的方法。
  • 允許這平台所有者管理平台的安全方針像定義一樣,經由UEFI安全啟動(Secure Boot)鑑定變數,它的描述如下。
UEFI安全啟動(Secure Boot)被控制經由一個UEFI鑑定變數的設定與平台PCD(定義如下),它明確說明UEFI安全啟動(Secure Boot)方針。這些方針包含:
  • 影像檔和憑證方針 - 詳細說明它的影像檔和憑證是含有在白表(a.k.a 經授權的簽章資料庫)與黑表(a.k.a 禁用的簽章資料庫)。
  • 影像檔位置方針 - 詳細說明這行為對於影像檔載入從固定的對於可移動的媒體。這些方針包含總是或從不確信的影像檔來自一個出處。例如這策略能夠載入總是確信的影像,從固定媒體,但從PCI裝置卡與移動媒體驗證影像檔載入。
  • 影像檔驗證失敗方針 - 細說明這行為被執行,當影像檔驗證失敗時。這些包含:允許執行,延遲執行,拒絕執行或是詢問使用者。例如這策略可能是詢問使用者,對於允許去執行一個影像檔,這影像檔被驗證失敗。
影像檔和憑證方針被實現,使用這UEFI鑑定變數。它定義在UEFI 2.3.1A規格書,還有被描述在章節1.2下。
影像檔位置方針與影像檔驗證失敗方針是特殊平台與被實現經由OEM和IBV使用UDK2010.SR1安全啟動方針PCD的章節被描述在章節1.3。這些PCD是一個UDK2010.SR1釋出版中的特色與不明確說明在UEFI 2.3.1A說明書中。

1.1.3 [附加的資訊]
附加的資訊在 UEFI安全啟動(Secure Boot) 與鑑定可變因素可以被尋得在接下來的文件:
  • Intel Technology Journal, Volume 15, Issue 1, 201,  UEFI Today: Bootstrapping the Continuum, UEFI Networking and Pre-OS Security, page 80 at http://www.intel.com/technology/itj/2011/v15i1/pdfs/Intel-Technology-Journal-Volume-15-Issue-1-2011.pdf.
  • UEFI 2.3.1A Specification : Sections 7.2 (Variable Services) and Sections 27.2 through 27.8 (Secure Boot)  of the at www.uefi.org.  Please note that the use of the “Secure Boot” in Section 27.1 is an overloaded usage that is unrelated to “Secure Boot” as used in this document.
  • Beyond BIOS: Developing with the Unified Extensible Firmware Interface, 2nd Edition, Vincent Zimmer, ISBN 13 978-1-934053-29-4, Chapter 10 – Platform Security and Trust, www.intel.com/intelpress.
  • Harnessing the UEFI Shell, Moving the platform beyond DOS, Michael Rothman www.intel.com/intelpress.  Appendix A - Security Considerations.
  • Windows Hardware Certification Requirements December, 2011. http://msdn.microsoft.com/library/windows/hardware/hh748188
1.1.4 [文件的優先次序]
若有任何資訊被提供在這份文件(Signing UEFI Applications and Drivers for UEFI Secure Boot)牴觸UEFI 2.3.1A規格書中所包含的資訊,將以UEFI 2.3.1A規格書為主,除非明確的註明。