韌體受攻擊面縮小 (FASR)
2019 年 10 月,Microsoft 與我們的 OEM 和晶片合作夥伴密切合作,推出安全核心計算機。 這些裝置具有深度整合的硬體、韌體和軟體,可協助確保裝置、身分識別和數據的安全性增強。 安全核心計算機的核心安全性要素之一是協助為裝置提供韌體保護。 滿足此要素所需的基本硬體型功能是 測量的動態信任根目錄(D-RTM)。 不過,由於基礎晶元組相依於支援這項功能,目前沒有多少裝置提供 D-RTM,這阻礙了我們為所有 Windows 裝置提供及維護高安全性列的承諾。
您可以執行更多動作來增強所有 Windows 裝置的安全性狀態,包括不含 D-RTM 的裝置。 Microsoft正與合作夥伴合作,藉由開發一組開放原始碼 SMM 安全性增強功能,為 OEM 提供額外的彈性,以克服防止記憶體保護在 UEFI 韌體中套用的相容性問題。
為了反映對韌體安全性的承諾,我們識別出新的方法,以確保裝置可以符合安全核心計算機的韌體保護需求。
FASR 概觀
對於缺少硬體型 D-RTM 功能的安全核心計算機,我們必須定義一組小型韌體元件,這些元件會呈現降低的攻擊面,而且可以在操作系統中證明。 這種方法稱為韌體攻擊面縮小(FASR)。 若要讓以 FASR 為基礎的韌體跨不同廠商的計算機進行調整,必須定義韌體開機程式的新方法。
FASR 支援兩個開機路徑:
認證的開機路徑:
只允許執行Microsoft信任、簽署和整合的程序代碼。
操作系統可以偵測到開機路徑的竄改。
下圖顯示認證開機路徑上的 FASR S-RTM 開機流程。 此開機路徑有助於防止非預期的平臺韌體程式代碼執行。 不過,它確實會使用自定義開機路徑所提供的一些平臺特定數據。 下圖顯示認證開機路徑上的 FASR 開機流程。
自定義開機路徑: 所有平臺韌體程式代碼都可以執行。 特定 OEM/平臺專屬的開機重要資訊會轉換成自定義開機路徑上的數據,並由認證開機路徑用來在該開機路徑上正確設定系統。 下圖顯示自定義開機路徑上的 FASR 開機流程。
為安全核心計算機合規性啟用的 FASR 裝置,預設為認證的開機路徑,除非發生導致開機在韌體開機程式中早期切換到自定義開機路徑的事件。 這類事件的範例包括韌體更新、使用者要求韌體 UI,或使用者已選擇停用安全核心計算機,這表示他們一律會在自定義開機路徑上開機,直到重新啟用為止。
自定義開機可用來將支援 FASR 裝置上的平臺韌體所支援的任何操作系統或第三方軟體開機,但 Windows 無法將自定義開機路徑上的開機辨識為安全核心電腦相容。
為了進一步瞭解 FASR 背後的安全性技術,我們想要分享 Windows 開機程式的快速概觀。
Windows 開機程式
信任的根目錄
新式計算機中的初始韌體執行會遵循開機程式,其中一組初始程序代碼會載入其他程序代碼,並在開機進行時擴充功能層級。 每組程式代碼都會驗證下一組構成信任鏈結的程序代碼。 當 UEFI 韌體取得控制權時,它會遵循 驗證軟體簽章的安全開機 標準,以繼續整個操作系統的信任鏈結。 然後,Windows 開機載入器會繼續信任鏈結與 信任開機,這會在載入啟動程式之前先驗證啟動程式中的所有其他 OS 元件。
一般而言,攻擊者會在啟用安全性功能和鎖定之前,盡早在開機程式中取得控制權。 當系統從重設中取出時,執行的初始程式代碼集必須錨定在信任中。 履行執行此早期程式代碼驗證角色的硬體驗證技術稱為 信任根目錄。 雖然確切的詳細數據會因硬體廠商而異,但所有信任根通常會根植於SOC中的不可變硬體或 ROM。
測量開機
安全開機錨定在信任根目錄中有助於確保已驗證所有韌體數字簽名;不過,也想要有確切執行韌體之記錄。 Windows 硬體相容性計劃要求所有 Windows 10 和 Windows 11 計算機都包含稱為信賴平台模組 (TPM) 的晶片。 TPM 包含稱為平台設定緩存器 (PCR) 的記憶體位置。 每個PCR都包含在開機期間載入的程式代碼和/或數據的哈希,例如非揮發式儲存裝置上的韌體程式代碼(例如 SPI 快閃)、PCI 裝置中的選項 ROM 或 OS 開機載入器。 可以儲存在PCR中的值大小取決於支援的哈希演算法摘要大小。 例如,SHA-1PCR 可以儲存 20 個字節,而 SHA-2PC 可以儲存 32 個字節。 與相同哈希演算法相關聯的多個 PCR 稱為銀行。 TCG PC 用戶端 TPM 配置檔規格會定義至少包含一個具有 24 個快取器的PCR銀行。
當 TPM 存在時,每個韌體元件也可以更新或擴充適當的PCR,因為新的程式碼和數據會在開機過程中載入。 擴充程式會使用與新程式代碼或數據自變數串連為輸入的目前PCR 值,更新為哈希演算法的輸出。 結果是在開機程式之後可以檢查 PCR,以判斷執行的內容。 這可讓操作系統中的軟體了解開機程式是否與先前的開機程式不同。 在安全性敏感性環境中,操作系統可以得知特定 PCR 中預期的一組確切程式代碼測量,以偵測非預期的韌體程式代碼執行。 由於銀行中的前 16 個 PCR 只能藉由重設整個 TPM 來重設,因此受信任,以及儲存 TPM 中重要度量的慣用位置。
測量的信任根
既然我們已檢查信任根目錄的角色,以及測量開機的使用方式,我們將探討兩種常見方法,以建立信任根,以向 TPM 報告測量鏈結:靜態和動態。
測量的靜態信任根目錄 (S-RTM) 會在系統重設時建立信任,並要求在整個開機過程中維護信任。 如果在開機程式的任何時間點遭到入侵信任,在系統重設之前將無法復原。 下圖說明如何在認證的開機路徑上使用 S-RTM。
相反地,「測量動態信任根」(D-RTM)只信任早期晶元組初始化韌體代碼的一小部分,以及用來在開機期間動態重新建立信任的硬體代理程式。 系統一開始可以開機進入不受信任的韌體程序代碼,但在啟動后不久,藉由控制所有 CPU 並強制其關閉已知且測量的路徑,還原為信任的狀態。 下圖提供傳統 D-RTM 流程的概觀。
S-RTM 與 D-RTM 之間有取捨。 S-RTM 不需要特殊硬體功能,但需要軟體來更妥善地考慮整個開機期間執行的程序代碼。 D-RTM 需要特殊的硬體功能,但允許軟體在系統存留期間動態啟動為受信任的狀態。
Windows 安全核心計算機已使用安全啟動中的 D-RTM,讓廣大系統製造商在韌體中實作獨特功能和體驗的彈性,同時協助確保系統能夠達到可接受且可接受的受信任和測量狀態,以裝載安全的操作系統環境。 D-RTM 啟動事件可用來在載入安全核心之前,從未知的環境重新建立信任。 下圖顯示 D-RTM 啟動事件,以重新建立已知的系統環境。
過去,S-RTM 可能會因為對特殊硬體功能缺乏相依性來驗證系統的安全性狀態,而無法在更多裝置中實作 S-RTM,但操作系統沒有可靠的方法來確認它可能會信任使用 S-RTM 在任何指定 Windows 裝置上報告的測量。
韌體安全性增強功能
將OS開機路徑中的韌體元件降到最低
信任 S-RTM 測量的其中一種方法是減少允許執行到最小集合的韌體元件。 如果所有使用 S-RTM 的裝置都使用相同的韌體元件集,則操作系統只需要信任一組已知和受信任元件的一組預期的PCR值。 透過此 SRTM 型方法,當一組開機韌體經過驗證時,裝置可以視為符合安全核心計算機的韌體保護需求,只包含 Windows 可證明的已簽署軟體Microsoft。 為了進一步了解這些韌體元件與一般計算機開機中的韌體元件有何不同,讓我們檢查開機程式前後。
由於新式計算機韌體所提供的彈性和豐富的功能集,在操作系統之前執行的程式代碼會導致攻擊面增加。 下圖顯示傳統 S-RTM 開機流程的範例。
在開機期間韌體的主要責任可以大幅簡化為:
平臺特定:僅適用於特定平臺硬體設計的功能。
非平臺特定:業界標準且與其他硬體通用的功能。
較小型的新式韌體子集通常是平臺特定的。 大部分執行一般工作的韌體基礎結構程序代碼,例如配置記憶體、分派韌體驅動程式、處理事件等等,在所有 (或大部分) UEFI 型系統之間都相同。 這些工作的韌體二進位驅動程式可以跨計算機重複使用。 此外,業界標準硬體規格和介面可讓常見的韌體驅動程式初始化硬碟、USB 控制器和其他周邊。 此硬體的韌體二進位驅動程式也可以跨電腦重複使用。 總而言之,計算機可以使用一組最少的通用韌體驅動程式來開機。
減少開機期間載入的韌體驅動程式總計集可能會導致其他優點:
改善的開機時間
已減少更新的廠商協調
降低 Bug 暴露程度
降低受攻擊面
FASR 開機路徑驗證和安全核心合規性
若要讓 FASR 系統符合安全核心計算機的韌體保護需求,其必須在認證的開機路徑上開機。 FASR 韌體可藉由為操作系統提供稱為 FASR 指令清單(測量為 TPM)的Microsoft簽署指令清單,其中包含認證路徑上模組開機順序的預期PCR值,來促進這項操作。 這可以與認證路徑上發生的實際開機順序進行比較。 如果這些度量相符,系統會將系統視為符合安全核心計算機程式的韌體保護需求。 與預期的認證開機路徑序列有任何偏差,會導致對操作系統偵測到之 TPM 平台設定緩存器 (PCR) 進行非預期的測量。
此外,Windows 只會在成功驗證已簽署的 FASR 指令清單時釋放受 Hypervisor 保護的秘密,以針對目前開機期間所記錄的度量。 如果在經過認證的開機路徑或膠囊更新上,FASR 指令清單不存在,簽章驗證會失敗或發生PCR 不符,而且 VSM 秘密不會解除密封或移轉。
FASR 韌體如何處理記憶體保護和 SMM
既然已定義具有最少功能集的單一Microsoft已簽署二進位檔,它可以包含基本但遺漏的韌體安全性保護,Microsoft正與合作夥伴合作,將產品推向市場。 認證開機路徑至少必須符合下列需求:
程序代碼不會讀取/寫入 NULL/第 0 頁
影像程式代碼和數據區段會分開
影像區段會對齊頁面 (4 KB) 界限
數據只會配置至資料記憶體類型,並將程式代碼配置至程式代碼記憶體類型
程式代碼映像不會從散發為 UEFI 二進位檔的程式代碼載入(只有指定的發送器)
程序代碼會保留在配置記憶體緩衝區的界限內,並圍繞頁面配置使用防護頁面
可以偵測堆疊溢位
程式代碼不會從堆疊執行
/NXCOMPAT DLL 特性設定為啟用 NX 保護
第三方選項 ROM、UEFI 應用程式和 UEFI 驅動程式通常未根據這組需求來建置或驗證。 因此,它們不會在認證的開機路徑上執行。 自定義開機路徑可以選擇降低所需的保護層級,但該開機路徑不會被視為操作系統符合安全核心計算機規範。
系統管理模式 (SMM)
SMM 是 x86 架構中的特殊處理器操作模式。 它對系統安全性提出了獨特的挑戰,因為 SMM 環境中執行的程式代碼對操作系統而言並不透明,而且通常會在主機處理器上任何軟體的最高許可權層級執行(有時稱為「Ring-2」)。 輸入時,SMM 會藉由設定分頁表、中斷分派表 (IDT) 和其他系統結構來設定自己的環境。 SMM 代表惡意代碼可用來入侵或規避透過虛擬化型安全性 (VBS) 啟用的OS保護的重大攻擊面。 為了協助減輕 SMM 所造成的危險,SMM 中的功能可以概念上分割成 SMM 核心基礎結構和 SMM 驅動程式,如下所示:
SMM 核心:執行架構和基礎結構責任的所有 SMM 實作通用的程式代碼
SMM 驅動程式:撰寫以在 SMM 中完成平臺特定工作的程式代碼
SMM 生命週期中的一些關鍵時刻如下:
建立 SMM 基礎 (或核心) 時 – SMM 初始程式載入 (IPL)
載入 SMM 驅動程式時 – 稱為 SMM 驅動程式分派
進入 SMM 時 – 透過系統管理中斷 (SMI)
SMM 初始程式載入 (IPL)
CPU 具有特殊功能,可授與 SMM 程式代碼其高許可權,並協助保護它。 例如,已定義機制以透過軟體或硬體事件輸入 SMM、使用 CPU 指令從 SMM 傳回,並定義數個緩存器來控制 SMM 的存取和鎖定設定。 SMM IPL 程式代碼會設定許多這些控制快取器,以限制儲存 SMM 程式代碼和資料所在記憶體區域的存取(稱為系統管理 RAM 或 SMRAM)。
由於SMRAM區域位於主要記憶體中(DRAM),因此在開機期間啟用DRAM之前,無法建立它。 DRAM 啟用程式會因矽廠商而異,但相當多 MB 的程式代碼可以直接從 CPU LLC 快取執行(包括初始化 DRAM 的程式代碼),才能使用主要記憶體。
FASR 韌體比大多數其他系統更早地引進 SMM IPL 點。 這可減少攻擊者在設定SMM之前必須破壞此程式並控制系統的機會。 若要進一步瞭解這一點和其他對 FASR 韌體中 SMM 的改善,我們需要深入瞭解韌體開機程式。
UEFI 韌體中的平臺初始化 (PI) 開機
新式計算機韌體是以許多規格為基礎所建置。 UEFI 規格會定義 UEFI 相容作業系統之間的介面,例如 Windows 和裝置上的韌體。 另一個稱為平臺初始化 (PI) 規格的規格會定義韌體驅動程式的建置方式,並詳細說明開機程式本身。 概括而言,UEFI 規格可以視為允許單一 Windows 映射與許多不同裝置搭配運作的標準化之一,而 PI 規格可視為允許來自不同硬體廠商的眾多韌體映像一起運作的標準化之一。 這兩種規格都由 UEFI 論壇維護。
PI 規格會定義開機階段,以及哪些驅動程式會寫入開機階段。 在韌體開機期間,每個階段都會交出下一個階段,而且在大部分情況下,不再使用階段交接的驅動程式,而且只會將重要的數據傳遞給下一個階段,以便繼續開機程式。 開機階段摘要如下:
SEC – 取得 CPU 重設向量的控制權,並從元件轉換至 C 程式代碼以載入 PEI
PEI – 初始化系統狀態以載入 DXE 並初始化 DRAM
DXE – 執行剩餘的系統初始化,包括提供載入作業系統所需的支援 BDS
BDS – 探索目前開機的開機選項(例如 OS 開機載入器),並嘗試開機該選項
OS – 操作系統核心
保護 SMM 初始程式負載 (IPL)
傳統 UEFI PI 規格相容韌體會在 DXE 開機階段載入 SMM IPL。 FASR 韌體會在PEI開機階段載入SMM IPL。 系統的信任運算基礎 (TCB) 是保護它的總保護機制集,包括硬體、韌體和軟體。 藉由將 SMM IPL 從 DXE 移至 PEI,就會從 TCB 中移除整個 DXE 階段(比 PEI 更大且更豐富的環境)。 下圖顯示 UEFI 開機程式中稍早移動的 SMM IPL。
PEI 和 DXE 程式代碼會在信號 0 上執行,且不會在操作系統中保存(但很少例外)。 SMM 程式代碼以高於通道 0(和 Hypervisor) 的許可權執行,並保存在作業系統中,因此不允許 DXE 弱點影響 SMM 的建立,可降低整體系統攻擊面。 此外,由於 SMM 是在開機程式中稍早啟動,因此設定為協助保護 SMM 的鎖定位可在開機中稍早啟用,進一步將攻擊者的視窗降至最低以入侵 SMM。
保護 SMM 驅動程式分派程式
在 PI 規格中,定義了兩種 SMM 模式:傳統 MM 和獨立 MM。 傳統 MM 相當於過去在 PI 相容韌體中使用的 SMM 軟體模型,這構成業界大部分的 UEFI 韌體。 獨立MM是一種相對較新的模式,可修改歷史模型以改善SMM環境的安全性,並防止傳統MM實作中常見的錯誤,導致多年來許多可移植性和安全性挑戰。
FASR 韌體在獨立MM模式中獨佔運作。 這可讓 FASR 韌體遵循有紀律的方法,在 SMM 中執行軟體。 現今許多以 SMM 為基礎的弱點是由於傳統 MM 中 SMM 程式代碼中允許的不良做法所造成,這些做法只能在獨立 MM 中移除。 概括而言,這是因為在傳統MM模型中,SMM 驅動程式會分派兩次,一次是由信號0中的 DXE 發送器分派一次,再由SMM中的SMM 發送器分派。 這為 DXE 環境中執行的驅動程式程式代碼提供了充足的機會,以快取 SMRAM 外部資源的指標,這些指標在進入點傳回之後不應該存取。 依賴 SMM 程式代碼呼叫 SMM 外部程式代碼的攻擊通常稱為「SMM 圖說文字攻擊」。
保護 SMM 的專案
數據會透過稱為「通訊緩衝區」的結構傳遞至 SMI 處理程式。 SMI 處理程式負責驗證數據是否符合其進入點的特定需求。 Windows SMM 安全性風險降低資料表 (WSMT) 是一種機制,用來協助減輕作業系統中未核取 SMI 處理程式對虛擬化型安全性構成的威脅。 Microsoft已為 TianoCore 專案貢獻程式代碼,以改善通訊緩衝區驗證。 除了套用這兩種技術之外,FASR 程式代碼也會實作嚴格的記憶體存取保護,允許 SMM 程式代碼只存取明確允許的記憶體範圍。
管理模式監督員(MM 監督員)
SMM 核心程式代碼很常見,而且在系統之間幾乎不會變更。 透過將許可權區隔引入 SMM 環境,SMM 所強加的攻擊面可以大幅降低。 基於這個理由,FASR 韌體包含在獨立MM中執行的SMM監督員。 這會導致定義完善的 SMM 環境,且具有從建立強制執行許可權等級的最低 TCB。 MM 監督員會限制 IO 埠存取、模型特定快取器 (MSR) 存取、MMIO 存取、CPU 儲存狀態存取,以及在 SMM 環境中允許的指示。 SMM 監督員原則可用來設定要限制的硬體資源確切詳細數據,而這些確切的詳細數據可能會隨著矽產生而變更。
此原則最近已轉換為預設拒絕方法,可大幅減少 SMM 監督師外部程式代碼可用的硬體資源。 此監督員在沒有硬體相依於新式計算機中通常找不到的任何硬體功能的情況下運作。
MM 監督員用於 FASR 是開放原始碼,且可在 Project Mu MM 監督員存放庫中取得。
符合安全核心計算機需求的 FASR 系統合規性
下表指出安全核心計算機的廣泛安全性要素或目標,以及 FASR 系統如何在認證路徑中啟動,以達到安全核心計算機的需求:
安全性優點 | 安全核心計算機的安全性功能 |
---|---|
建立硬體支援的信任根目錄 | 安全開機 |
信賴平台模組 2.0 | |
直接記憶體存取 (DMA) 保護 | |
防禦韌體層級攻擊(請參閱下面的附註) | 系統防護 安全發射 (D-RTM) 或 S-RTM (FASR FW) |
系統管理模式 (SMM) 隔離或獨立 MM 與 MM 監督員 (FASR FW) | |
防止作業系統執行未驗證的程式碼 | 記憶體完整性(也稱為 HVCI) |
提供進階身分識別驗證和保護 | Windows Hello |
保護遺失或遭竊裝置時的重要數據 | BitLocker 加密 |
如果系統沒有支援 D-RTM 的進階安全性功能,則可以使用 S-RTM 和獨立 MM 與 MM 監督器的組合,滿足韌體保護需求,這兩者都是由 FASR 韌體提供。
摘要
這些是一些Microsoft投資,以解決現今整個產業中日益普遍的韌體攻擊數量。 藉由針對這些變更使用開放原始碼程式代碼,我們授權合作夥伴使用其中一些安全性優點,進而讓更廣泛的生態系統和產業受益。
安全核心計算機方案的主要目標是協助確保客戶能夠存取 Windows 計算機可用的一些最進階安全性功能。 隨著其中一些韌體變更,我們更接近實現該目標,並已更新安全核心計算機的韌體保護需求,以反映此包含專案。 在這裡深入瞭解安全核心計算機。