##背景 固件是一种特殊类型的软件，主要用于硬件底层的交互和控制，固件的范畴过于广泛，不同领域的固件牵涉的安全防护的问题差异较大，本文仅讨论基于通用计算机的固件，比如服务器，笔记本和台式机的上运行的固件。

##当前问题 目前固件的主流方案依然是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。