##背景 固件是一種特殊類型的軟體，主要用於硬體底層的交互和控制，固件的範疇過於廣泛，不同領域的固件牽涉的安全防護的問題差異較大，本文僅討論基於通用計算機的固件，比如伺服器，筆記本和台式機的上運行的固件。

##当前问题 目前固件的主流方案依然是UEFI，而UEFI的生態存在以下幾個問題：

• 由於技術架構設計並沒有考慮其複雜的供應鏈生態，tianocore/ EDK2的參考實現和OEM出廠實現差異過大。 通過測試和逆向分析可以發現某些廠商的OEM固件中DXE模組有大量基於SMM的實現，這也是導致固件安全的高風險環節之一，SMM是x86平臺下Host CPU的最高許可權運行模式，俗稱“Ring -2”，操作系統難以檢測Ring 0以下的威脅的原因很簡單：根本在不同維度上作戰。

• 設計和實現的缺陷導致了諸多固件安全風險

• 修復鏈條過長，這使得漏洞的修復週期會比較長，任何一個環節的廠商延遲或者拒絕修復已知漏洞都會增高用戶生產環境的風險

• 不可審計性，由於主流的OEM並不對使用者開放原始程式碼，所以原始程式碼級別的審計是無法實現的，漏洞的審計只能依靠二進位審計或者模糊測試進行，而沒有原始程式碼對於發現後門或者具有後門性質的調試特性會極高的增加成本， 雖然Intel在2019年嘗試以Minimum平臺解決開放性的問題， 但目前而言其覆蓋度不及預期。

‘“‘下一代’”’ 固件

1999年冬天，洛斯阿拉莫斯國家實驗室的研究員Ron Minnich發起了一個叫LinuxBIOS的專案，其目標是用自由軟體去替代私有的固件，LinuxBIOS設計思路是讓盡量少的代碼做硬體初始化的工作， 當硬體初始化完成後就載入一個基於Linux內核的執行載荷，這個專案後來更名為coreboot，今天的coreboot支援除了Linux以外的多種執行載荷，這種架構也成為了2020年代當業界重新審視固件問題和探討“下一代”固件時的重要基礎，這或許是必然性和偶然性並存所致。

如果把固件架構簡化為兩個階段：硬體初始化和載荷。 硬體初始化通常由coreboot的ROMstage或者UEFI PEI完成，進入2010年代後，業界開始探索各種固件安全的方案，UEFI中被稱為「Secure Boot」是一種以驗證簽名構建信任鏈條的VerifiedBoot實現， 而基於TPM的MeasuredBoot則因為Intel晶片組對TXT支援限制以及TCG標準中的其他可信計算特性難以在UEFI中實現，2016年，對沖基金Two Sigma的研究員Trammell Hudson借鑒了LinuxBIOS的思路，基於Linux開發了一個名為heads的執行載荷並用coreboot進行載入，把所有包括部分可信計算在內的安全特性都放進了載荷中， 這樣以低成本的方式解決了UEFI生態持續數年都難以解決的問題，業界繼續在1999年版本的“下一代固件”架構的基礎上前行。 2017年，Google和heads社區聯合開發了名為NERF的執行載荷，NERF採用了保留PEI和最小化DXE的模式去相容OEM的UEFI固件，但有一些機型的重定向問題難以解決， NERF另一個特性是用戶態基於Go運行時，有趣的是，NERF的嘗試讓基於Linux的執行載荷方案進入到了一個更標準化的階段：LinuxBoot。

從上圖可以看出，LinuxBoot這個“下一代固件”架構依然沒有走出1999年的LinuxBIOS經典模型，只是其目標是標準化的前提下相容更多的硬體初始化的固件方案。

VaultBoot: 剛鐸的心臟

VaultBoot 是一個專注於固件安全，可信計算以及高級防禦的固件載荷執行體，其設計可以在coreboot平台上發揮出最卓越的防護效果，包括CBnT和多種ACM的開箱過程都可以基於coreboot完成。

VaultBoot 也相容主流廠商的UEFI，由於賽博堡壘是長期的heads社區的貢獻者，公開版本是基於heads開發的，但VaultBoot 也相容LinuxBoot的形式，並且可以提供C和Go兩種運行時環境。

以下為 VaultBoot 的主要特性：

• VerifiedBoot，此項特性在UEFI廠商的市場宣傳中被稱為“Secure Boot”，只允許在正常啟動過程中載入已簽名的內核以及附帶數據（例如，initrd）以啟動，由於在 UEFI 中簽名應與內核存儲在同一檔中，因此需要專用工具（例如，shim），並且簽名過程難以操作。 而在 VaultBoot 中，簽名驗證過程由捆綁的 gnupg 工具完成。 包含公鑰的專用 gnupg 鑰匙鏈可以捆綁到 VaultBoot 的 initrd 中。 操作系統的內核、initrd 和引導配置將由存儲在智慧卡中的相應私鑰進行簽名，簽名將作為獨立文件存儲在引導分區中，而簽名過程也可以在密鑰管理的作業系統中完成從而無需修改內核檔本身。 如果簽名失效，自動啟動過程將被中斷，VaultBoot將為使用者提供shell以便手動啟動操作系統或修復簽名鏈條。

• MeasuredBoot，如果主機板配備 TPM，coreboot 可被構建為使用它測量其載入的所有元件（包括載荷執行體），VaultBoot也可被構建為支援 TPMv1.2 和 v2.0。 如果啟用了 TPM 支援，VaultBoot 可以將一段隨機秘密封印到 TPM 中一組被 coreboot 用於測量自身的 PCR 上，並在引導過程中將該隨機秘密作為 TOTP 呈現出來，以便用戶驗證。 如果固件被更改，PCR將發生變動，之前封印的、被使用者驗證過的秘密不能再從 TPM 中解封，以便向使用者警告韌體被意外修改。 這是本地證明的一種形式，如果啟動過程中驗證TOTP不方便，則可以使用遠程證明。 如果秘密未能解封，自動啟動過程將中斷，並將提供恢復shell。

• Vault_SMM，這是賽博堡壘獨特的加固模式，即把晶元組除了 CBnT 這類開箱類特性外的加固特性都延期到載荷階段啟用並且使用 SMM 模式進行加固，這樣保證安全性的同時也兼顧可維護性，這一設計在2019年得到了LinuxBIOS創始人的讚賞，VaultBoot把SMM這個高安全風險的運行模式用於安全加固， 但值得注意的是這個方案必須配合coreboot才能發揮其優勢。

• 全盤加密，如果 TPM 可用，並且操作系統在啟動過程中需要解鎖 LUKS，則 VaultBoot 可以在LUKS中添加隨機密鑰，並將金鑰封印到 TPM 中（無論有沒有密碼）。 如果密鑰可以成功解封，VaultBoot將複製作業系統的 initrd 到其 tmpfs 中，將該金鑰和一條 crypttab 條目附加到複製的 initrd 中，然後用修改後的 initrd 啟動作業系統，因此 LUKS 將在啟動過程中由密鑰解鎖。 添加密鑰后，LUKS 頭將被測量進入PCR，這是封印解鎖密鑰的 PCR 之一。 因此，如果固件或 LUKS 頭被更改，金鑰將無法解封，自動啟動過程將中斷，當然，如果改動是因為使用者主動更新了固件或改動了 LUKS 頭，只要還有其他解鎖 LUKS 以添加密鑰的手段，使用者可以為 LUKS 生成並封印一段新密鑰。

• 基於硬體內置金鑰交換的參數加密，在 TPM2 中，引入了一項新特性來加密敏感參數（例如針對明文的封印/解封操作），會話密鑰與 TPM 內部生成的密鑰交換，VaultBoot將利用此功能來防禦部分物理攻擊，比如TPM Genie。

• Intel CSME由於涉及諸多版本以及風險評估本身的複雜性，在本文中不多作探討，有興趣的讀者可以閱讀賽博堡壘關於CSME的企業安全風險評估報告。

##总结 固件的運行級別高於操作系統所在的RING 0，如果使用者的威脅模型中包含攻擊者持久化這一項，那固件安全就無法忽視， 這個領域的攻防越來越受到業界的關注，美國國家標準與技術研究院（NIST）早在2011年4月即發佈了：

• NIST SP 800-147：BIOS保護指南
• 2011年12月發佈了NIST SP 800-155：BIOS完整性度量指南
• 2014年8月發佈了NIST SP 800-147B：伺服器BIOS保護指南
• 以及目前最重要的固件安全合規指南：2018年5月發佈了NIST SP 800-193：BIOS平臺固件彈性指南。

2021年5月26日，美國網路安全和基礎設施安全域（CISA）在RSA 2021大會上公開了VBOS計劃，其目的是連同操作系統在內以及更底層元件的安全都需要防護，雖然過去的15年固件層面的安全對抗從未停止，VBOS計劃是第一次把隱蔽戰爭放到了桌面上。

歐洲方面，雖然並沒有像美國一樣有系統性的固件安全合規指南，但從幾個方面可以看到其重視程度，歐盟委員會自從2014年發起的「地平線2020」計劃中資助了大量的開源晶元和固件安全專案，而德國聯邦資訊安全辦公室（簡稱BSI）多次公開的提到對開放固件的支持和跟進工作，2019年，BSI認證了德國老牌安全廠商genua GmbH的網路安全產品（編號：BSI-DSZ-CC-1085-2019）支援開放固件體系實現固件安全特性。

在全球高級威脅防護的大趨勢下，固件屬於整體防禦中核心的環節之一，VaultBoot根據當前的攻擊方法制定了一系列的防禦措施的同時盡量的兼顧使用者方便使用，目前賽博堡壘可提供x86下KabyLake到CoffeeLake的1U伺服器方案，VaultBoot計劃會在2022財年支援arm64。