Commit to Memory - @JessFraz

2020年2月4日
第17卷，第6期

内存提交

保护启动过程

硬件信任根

Jessie Frazelle

机器的启动顺序通常从BMC（基板管理控制器）或PCH（平台控制器中心）开始。对于Intel CPU，Intel Management Engine在PCH中运行，并在CPU之前启动。在配置机器的硬件后，BMC（或PCH，取决于系统）允许CPU退出复位状态。然后，CPU从SPI（串行外围接口）闪存加载启动固件（或UEFI，统一可扩展固件接口）。启动固件然后访问机器持久性存储上的启动扇区，并将引导加载程序加载到系统内存中。启动固件然后将执行控制权传递给引导加载程序，引导加载程序从存储器将初始操作系统映像加载到系统内存中，并将执行控制权传递给操作系统。例如，在流行的Linux发行版中，GRUB（源自Grand Unified Bootloader）充当引导加载程序，并为机器加载操作系统映像。

这很像接力赛，一个团队成员将接力棒传递给另一个成员以赢得比赛。在接力赛中，您希望了解您的团队成员并信任他们为团队完成自己的部分以到达终点线。对于机器，这种信任链更为复杂。我们如何验证启动序列中的每个步骤都在运行我们知道是安全的软件？如果在启动序列中的任何时候我们的硬件或软件被破坏，那么攻击者就拥有我们系统上的最高权限，并且很可能可以做他们想做的任何事情。

硬件信任根的目标是验证安装在硬件每个组件中的软件是否是预期的软件。这样，您可以毫无疑问地验证和了解机器的硬件或软件是否已被对手入侵或覆盖。在mod芯片¹⁶、供应链攻击、邪恶女仆攻击⁷、云提供商硬件组件漏洞²和其他攻击媒介的世界中，确保硬件和软件的完整性变得越来越必要。这是对一个复杂主题的介绍；有些章节只是触及表面，但目的是提供安全启动机制世界的完整图景。

可信平台模块 (TPM)

可信平台模块是一种专用微芯片的标准，旨在通过集成的加密密钥保护硬件安全。TPM由国际标准化组织 (ISO) 和国际电工委员会 (IEC) 于 2009 年标准化为 ISO/IEC 11889⁹。TPM通常安装在计算机的主板上，并通过硬件总线与系统的其余部分通信。

TPM 具有以下功能：¹⁸

• 随机数生成器

• 生成加密密钥的方法

• 完整性测量

• 证明

• 密钥封装/绑定

• 密钥密封/解封

完整性测量

测量是收集和摘要系统软件、硬件和配置信息的过程。在加载时，TPM 使用哈希函数来指纹可执行文件及其配置。这些哈希值用于证明，以可靠地向远程或本地验证者建立代码身份。哈希值也可以与密封存储功能结合使用。秘密可以与允许解封秘密的程序哈希值列表一起密封。这允许创建只能由特定应用程序打开的数据文件。

证明

证明报告硬件和软件配置的状态。负责创建用于配置数据的哈希密钥的完整性测量软件决定了摘要的范围。证明的目标是向第三方证明您的操作系统和应用程序软件是完整且可信的。验证者信任证明数据是准确的，因为它由 TPM 签名，TPM 的密钥由证书颁发机构 (CA) 认证。TPM 在制造时内置了一对公钥/私钥对，称为认可密钥。认可密钥对于特定的 TPM 是唯一的，并由受信任的 CA 签名。对证明数据的信任取决于对最初签署认可密钥的 CA 的信任。

证明可以可靠地告诉验证者客户端机器上正在运行哪些应用程序，但验证者仍然必须判断每个给定的软件是否可信。

密钥封装/绑定

使用 TPM 的机器可以创建加密密钥并对其进行加密，以便只有 TPM 才能解密它们。此过程称为封装或绑定密钥，可以帮助保护密钥免遭泄露。每个 TPM 都有一个主封装密钥，也称为存储根密钥，它存储在 TPM 本身内。在 TPM 中创建的存储根密钥或认可密钥的私有部分永远不会暴露给任何其他设备、进程、应用程序、软件或用户。

密钥密封/解封

使用 TPM 的机器还可以创建一个密钥，该密钥不仅被封装，而且还与某些平台测量相关联。只有当这些平台测量值与创建密钥时的值相同时，才能解封这种类型的密钥。此过程称为将密钥密封到 TPM。解密密钥称为解封。TPM 还可以密封和解封在 TPM 外部生成的数据。使用此密封密钥和软件，您可以锁定数据，直到满足特定的硬件或软件条件。

定制硅

重要的是要注意 TPM 的局限性以及针对这些局限性的一些解决方案。TPM 可以证明机器上运行的固件是我们想要运行的固件，但是 TPM 中没有机制来验证代码是否安全。用户有责任验证固件的安全性并确保它不包含任何后门，如果代码是专有的，这是不可能的。

安全地启动机器时，您希望在该机器上运行的第一个指令是您期望运行的指令。TPM 不足以验证要执行的实际代码位是否安全，因此一些公司创建了自己的硅芯片，以扩展 TPM 的安全性。

谷歌的 Titan

对于谷歌的基础设施以及 Chromebook，谷歌使用他们自己的芯片 Titan 扩展了 TPM 的安全性。谷歌在 2019 年 10 月开源⁵了 Titan¹⁴ 的一个版本（包括规格和代码），该版本正在积极开发中。在创建 Titan 时，谷歌添加了 TPM 不存在的两个新功能：第一条指令完整性和补救。

第一条指令完整性

第一条指令完整性允许验证每台机器启动周期中运行的最早代码。Titan 通过将其自身置于 BMC（或 PCH）的启动固件闪存（BIOS）和主 CPU 之间（通过 SPI 总线）来观察启动固件的每个字节。因此，具有 Titan 芯片的机器的启动顺序与正常的启动顺序不同。

具有 Titan 的启动顺序如下

• Titan 将机器保持在复位状态。

• Titan 的应用程序处理器从其嵌入式只读存储器（启动 ROM）执行代码。

• Titan 运行内存内置自检，以确保所有内存（包括 ROM）未被篡改。

• Titan 使用公钥密码学验证其自身的固件，并将此经过验证的代码的身份混合到 Titan 的密钥层次结构中。

• Titan 加载经过验证的固件。

• Titan 验证主机的启动固件闪存（BIOS/UEFI）。

• Titan 发出就绪信号，以将机器的其余部分从复位状态释放。

• CPU 从启动固件闪存加载基本固件（BIOS/UEFI），这执行进一步的硬件/软件配置。

• 标准启动顺序的其余部分继续。

在 Titan 以加密方式验证启动固件时，将机器保持在复位状态，Titan 实现了第一条指令的验证。Titan 从第一条指令开始就知道在我们的机器上启动了什么启动固件和操作系统。Titan 甚至知道在启动固件的第一条指令之前可能已获取了哪些微代码补丁。

补救

当我们需要修补 Titan 固件中的错误时会发生什么？这就是补救发挥作用的地方。在修补 Titan 固件中的错误时，可以通过补救重新建立信任。补救基于强大的加密身份。为了提供强大的身份，Titan 芯片制造过程为每个芯片生成唯一的密钥材料。基于 Titan 的身份系统不仅验证了创建证书签名请求 (CSR) 的芯片的出处，还验证了芯片上运行的固件，因为固件的代码身份被哈希到芯片上的密钥层次结构中。此属性允许谷歌修复 Titan 固件中的错误并颁发只能由修补后的 Titan 芯片使用的证书。基于 Titan 的身份系统使后端系统能够安全地将秘密和密钥配置到单个启用 Titan 的机器或在这些机器上运行的作业。Titan 还能够链接和签名关键审计日志，使这些日志具有防篡改功能。这确保了即使是具有相关机器root访问权限的内部人员，审计日志也不能被更改或删除而不被检测到。

微软的 Cerberus

微软开源¹¹了他们的芯片 Cerberus 的规格。（在撰写本文时，只有规格已开源）。与 Titan 一样，Cerberus 介入 SPI 总线，固件存储在该总线上以供 CPU 使用。这允许 Cerberus 持续测量和证明这些访问，以确保固件完整性，从而防止未经授权的访问和恶意更新。

苹果的 T2

苹果是安全启动设备的典范。大多数人还记得当 FBI 想要在 iPhone 中安装后门时，Tim Cook 拒绝了¹⁰。在 Mac、iPhone 和 Chromebook 之间，产品行业标准包括默认安全性。

对于苹果机器，安全启动是通过他们的 T2 芯片¹完成的。苹果公司的 Ivan Krstić 在 blackhat¹² 上发表了一个演讲，详细介绍了使用苹果 T2 芯片的 Mac 的启动过程。与介入 SPI 闪存的 Titan 和 Cerberus 不同，T2 通过 eSPI（增强型串行外围接口）总线提供固件并启动 CPU。

苹果对 T2 的要求如下

• 完整启动链的签名验证

• 系统软件授权（服务器端降级保护）

• 授权“个性化”或请求设备（不可移植）

• 降级安全启动策略需要用户身份验证

• 安全启动策略受到物理篡改保护

• 系统始终可以恢复到已知良好状态

使用 T2 芯片的机器的启动顺序如下

• 机器已通电。

• T2 ROM 已加载并执行。

• T2 ROM 传递给 iBoot，引导加载程序。

• 引导加载程序执行 bridgeOS 内核，T2 芯片的内核。

• bridgeOS 内核传递给 T2 芯片的 UEFI 固件。

• T2 芯片然后允许 CPU 退出复位状态，并加载 CPU 的 UEFI 固件。

• CPU 的 UEFI 固件然后加载 macOS 引导程序，引导加载程序。

• macOS 引导程序然后执行 macOS 内核。

T2 芯片的一个重要设计要素是苹果如何验证计算机上运行的 MacOS 版本。T2 根据运行批准的哈希列表验证 MacOS 的哈希值。苹果公司处于独特的地位，可以进行这种级别的验证，因为他们拥有整个堆栈并阻止用户在其设备上运行任何其他操作系统。如果您想更深入地了解 T2 芯片的内部结构，我建议您阅读 Ivan Krstić 在 blackhat 演讲¹² 的幻灯片。

平台固件弹性

芯片供应商正在根据美国国家标准与技术研究院 (NIST) 指南¹⁵投资平台固件弹性 (PFR)。这些指南侧重于确保固件保持完整性状态，检测何时固件已损坏，并将固件片段恢复到完整性状态。

PFR 解决了企业服务器的漏洞，这些服务器包含多个处理组件，每个组件都有自己的固件。这种固件可能会受到黑客的攻击，他们可能会偷偷地在组件的闪存存储器中安装恶意代码，这些代码会隐藏在标准系统级检测方法之外，并使系统永久受损。

PFR 规范基于以下原则

• 保护：确保固件代码和关键数据保持完整性状态，并受到保护免受损坏，例如确保固件更新的真实性和完整性的过程。

• 检测：检测固件代码和关键数据何时已损坏。

• 恢复：在检测到任何此类固件代码或关键数据已损坏时，或在被迫通过授权机制恢复时，将固件代码和关键数据恢复到完整性状态。

供应商一直在围绕 NIST 的 PFR 指南构建功能。英特尔⁸和莱迪思半导体¹³各有产品。

UEFI 安全启动

UEFI 安全启动²¹ 旨在确保在启动期间执行的 EFI 二进制文件经过验证，通过校验和或有效的签名进行验证，并由本地信任的证书支持。当使用 UEFI 安全启动的机器通电时，UEFI 固件验证每个 EFI 二进制文件是否具有有效的签名，或者二进制文件的校验和是否在允许列表中。与允许列表相反的是拒绝列表，该列表也经过检查，以确保其上不存在任何二进制文件的校验和或签名。用户可以将受信任证书和校验和列表配置为 EFI 变量。这些变量存储在 UEFI 固件环境使用的非易失性存储器中，以存储设置和配置数据。

UEFI 内核极其复杂，有数百万行代码。它由启动服务和运行时服务组成。规范¹⁹ 非常冗长和复杂。UEFI 内核是许多漏洞的常见向量，因为它具有一些在许多不同平台上使用的相同专有代码。UEFI 内核在多个平台上共享，使其成为攻击者的绝佳目标。此外，由于只有 UEFI 可以重写自身，因此可以使漏洞具有持久性。这是因为 UEFI 存在于处理器的固件中，通常存储在 SPI 闪存中。即使用户擦除整个操作系统或安装新的硬盘驱动器，攻击也会在 SPI 闪存中持续存在。

英特尔的启动卫士

启动卫士是英特尔验证处理器固件签名的解决方案。启动卫士的工作原理是在制造过程中将 BIOS 签名公钥闪存到现场可编程熔丝 (FPF) 中，FPF 是英特尔管理引擎 (ME) 内的一次性可编程存储器。然后，机器拥有 BIOS 的公钥，并且可以在随后的每次启动期间验证正确的签名。但是，一旦制造商启用了启动卫士，就无法禁用它。

启动卫士的问题在于只有英特尔或制造商拥有用于签署固件包的密钥。这使得无法在这些处理器上使用 coreboot、LinuxBoot 或任何其他等效项作为固件。如果您尝试这样做，固件将不会使用正确的密钥签名，并且失败的启动尝试将使主板变砖。

Matthew Garrett 写了一篇关于启动卫士的精彩文章，强调了用户在固件⁴方面的自由的重要性。硬件的所有者也有权拥有固件。启动卫士阻止了这一点。在 2018 年开源固件会议⁶的安全主题演讲中，Trammel Hudson 描述了他如何找到绕过启动卫士的漏洞 CVE-2018-12169³。该漏洞²⁰允许攻击者使用未签名的固件并正常启动，完全否定了启动卫士的目的。由于启动卫士与 CPU 绑定，因此它不具有自定义硅硬件信任根在系统其他组件固件方面所具有的控制权。

系统透明性

Mullvad 写了一篇关于他们称之为系统透明性¹⁷的论文。其目的是通过为每台服务器提供唯一的身份、限制固件中的攻击面和可变状态，并允许所有者和用户验证平台上运行的所有软件（从通电后执行的第一条指令开始）来促进对系统组件的信任。

ST 通过遵循七个原则来实现这些目标

1. 身份绑定。 每台服务器的关键仪式，将服务器的唯一身份与难以伪造的物理人工制品（如视频）绑定。

2. 固件的物理写入保护。 可写代码段是可变状态，因此系统透明性限制了对此关键代码段的可能更改。只读代码也充当所有其他软件强制安全机制的信任根。

3. 篡改检测。 无法阻止攻击者通过更换实际芯片来更改固件闪存的内容。因此，需要检测到服务器硬件物理完整性的违反。

4. 测量启动。 系统透明性的目标是让所有各方了解作为系统启动一部分运行的代码。测量启动与远程证明相结合，允许第三方获取启动的加密日志。

5. 可重现的构建。 确保二进制工件构建一次后，可以一次又一次地构建并生成相同的工件。这在人类可读代码和使用测量启动机制证明的二进制文件之间建立了一个可验证的链接。

6. 不可变基础设施。 只有当对操作系统的更改受到限制时，系统透明性才有效。允许某人登录系统并进行任意更改会使测量启动的所有保证无效。

7. 二进制透明日志。 可以在系统上启动的所有固件和操作系统映像都由系统所有者签名，并插入到公共的、仅附加日志中。系统的用户可以监视此日志中的新条目，并捕获恶意系统所有者在新服务器上启动后门固件。

开源固件的重要性

显然，使用硬件信任根保护启动过程在整个行业中具有各种实现。如果没有开源固件，启动过程的专有部分仍然缺乏可见性和可听性，以确保我们的软件是安全的。即使我们可以通过硬件信任根验证专有固件的哈希值是我们已知为真的哈希值，我们也需要固件源代码的可见性，以确保它不包含任何后门。通过这种可见性，我们还可以轻松地调试和修复问题，而无需依赖供应商。

固件分散在机器及其组件的主板上；它位于 CPU（中央处理器）、NIC（网络接口控制器）、SSD（固态驱动器）、HDD（硬盘驱动器）、GPU（图形处理单元）、风扇等中。为了确保机器的完整性，必须验证所有这些组件。在未来，这些定制硅芯片不仅会介入 SPI 闪存，还会介入与 BMC 通信的每个其他设备。

如果您想帮助开源固件运动，请向您使用的供应商和平台施压，使其固件开源！

致谢

感谢 Ivan Krstić、Matthew Garrett、Kai Michaelis、Fredrik Strömberg 和 Trammell Hudson 在该领域的所有研究和工作，这帮助我撰写了本文！

参考文献

1. Apple. 2018. Apple T2 Security Chip; https://www.apple.com/mac/docs/Apple_T2_Security_Chip_Overview.pdf

2. Cimpanu, C. Hackers can hijack bare-metal cloud servers by corrupting their BMC firmware; https://www.zdnet.com/article/hackers-can-hijack-bare-metal-cloud-servers-by-corrupting-their-bmc-firmware/

3. Common Vulnerabilities and Exposures. 2018; https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12169

4. Garrett, M. 2015. Intel Boot Guard, Coreboot and user freedom; https://mjg59.dreamwidth.org/33981.html

5. Google Open Source Blog. 2019. OpenTitan—open sourcing transparent, trustworthy, and secure silicon; https://opensource.googleblog.com/2019/11/opentitan-open-sourcing-transparent.html.

6. Hudson, T. 2018. Open Source Firmware Conference's Security Keynote; https://trmm.net/OSFC_2018_Security_keynote#Boot_Guard

7. Hudson, T. Thunderstrike EFI bootkit FAQ; https://trmm.net/Thunderstrike_FAQ#Does_anyone_actually_use_evil-maid_attacks.3F

8. Intel. 2017. Intel Data Center Block with Firmware Resilience; https://www.intel.com/content/dam/www/public/us/en/documents/solution-briefs/firmware-resilience-blocks-solution-brief.pdf.

9. ISO/IEC 11889-1:2009. Information technology—trusted platform module; https://www.iso.org/standard/50970.html.

10. Kahney, L. 2019. The FBI wanted a back door to the iPhone. Tim Cook said no. Wired (April 16); https://www.wired.com/story/the-time-tim-cook-stood-his-ground-against-fbi/.

11. Kelly, B. 2017. Open Compute Project—Project Cerberus Security Architecture Overview Specification; https://github.com/opencomputeproject/Project_Olympus/blob/master/Project_Cerberus/Project%20Cerberus%20Architecture%20Overview.pdf.

12. Krstic, I. 2019. Behind the scenes of iOS and Mac security; https://i.blackhat.com/USA-19/Thursday/us-19-Krstic-Behind-The-Scenes-Of-IOS-And-Mas-Security.pdf.

13. Lattice Semiconductors. Universal Platform Firmware Resiliency (PFR)—Servers; http://www.latticesemi.com/Solutions/Solutions/SolutionsDetails02/PFR.

14. OpenTitan. 2019. Introduction to OpenTitan; https://docs.opentitan.org/.

15. Regenscheid, A. 2018. Platform firmware resiliency guidelines. NIST Special Publication 800-193; https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-193.pdf.

16. Robertson, J., Riley, M. 2018. The Big Hack: How China Used a Tiny Chip to Infiltrate U.S. Companies; https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies

17. Strömberg, F. 2019. System transparency; https://mullvad.net/media/system-transparency-rev5.pdf.

18. Trusted Computing Group. 2011. TPM main, part 1, design principles; https://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-1-Design-Principles_v1.2_rev116_01032011.pdf.

19. UEFI. https://uefi.org/specifications

20. Wang, Jian. 2019. Bug 1614 (CVE-2019-11098) - BootGuard TOCTOU vulnerability; https://bugzilla.tianocore.org/show_bug.cgi?id=1614

21. Wilkins, R. 2013. UEFI SECURE BOOT IN MODERN COMPUTER SECURITY SOLUTIONS ; https://uefi.org/sites/default/files/resources/UEFI_Secure_Boot_in_Modern_Computer_Security_Solutions_2013.pdf

现代时代的安全性
安全地运行需要完整系统调用接口的进程
Jessie Frazelle
https://queue.org.cn/detail.cfm?id=3301253

模拟器：过去（和未来）的虚拟机
是时候告别旧硬件了吗？
Bob Supnik
https://queue.org.cn/detail.cfm?id=1017002

自动化软件故障报告
我们只能修复我们知道的错误。
Brendan Murphy
https://queue.org.cn/detail.cfm?id=1036498

Jessie Frazelle 是 Oxide Computer Company 的联合创始人兼首席产品官。在此之前，她从事 Linux 的各个部分，包括容器和 Go 编程语言。

最初发表于 Queue 第 17 卷，第 6 期—
在数字图书馆中评论本文