让安全启动更加安全

一. 概述

在上篇文章中，我们介绍了安全启动Secure Boot的几个核心的概念。在现实中，用户的计算机通常是加密的，使用TPM来保存加密口令是一个很好的解决方案——用户可以拥有一个加密磁盘，但不必在每次重启时重复输入口令。此外还可以确保当硬盘被恶意者从电脑上拔出来时，由于密钥保存在TPM中，密钥不会泄露。

但如果只用TPM来保存密钥则远远不够。攻击者可以拔出硬盘，然后换上另一个硬盘。如果只将口令直接保存在 TPM芯片中，而没有对系统状态进行验证，那么会有安全问题：任何用户只要能从操作系统层面对机器进行物理访问，就能获取密钥。除此之外，攻击者可以通过更换磁盘并取出密钥，甚至还可以通过更换 initramfs/initrd 或修改 GRUB 启动流程，向 TPM 索要密钥。因此，仅仅使用TPM的系统并不那么安全，至少没有达到我们的目标。

这篇文章并非技术类教程，而是对安全启动的探讨。如果读者有新的想法，欢迎随时留言与沟通。

二. 理想状态下的安全启动

理想的信任链是这样：每一步都受到前一步的信任，并且为下一步奠定了信任基础。对安全启动而言，理想的步骤应当是这样的：

• UEFI受密码保护，没有凭证无法修改。
• UEFI只允许从单个磁盘设备和特定启动文件启动。
• 使用 Secure Boot，只能调用经过签名、未被篡改的二进制文件（例如 GRUB2）。
• GRUB2 EFI 可执行文件配置内嵌，因此无法修改、添加额外参数或中途停止启动过程。
• GRUB2 受密码保护，只允许单个entry启动，不允许添加其他参数。
• GRUB2 仅加载经过签名的内核。
• GRUB2 信任 initramfs/initrd，initramfs/initrd也经过签名。
• initramfs/initrd 调用 TPM获取密钥，并确保/UEFI不会被篡改，因为重置 UEFI密码也会重置 TPM 的内容。
• 系统继续正常启动。

图1. Secure Boot启动过程

通过上述流程可以观察到，启动过程的每一步都受前一步信任，并对下一步信任背书。信任的开始，可以通过使用自签名证书来签名 GRUB2 EFI 可执行文件，并将该证书保存在UEFI的 Secure Boot 部分，从而覆盖 UEFI的其它 "普通 "证书。然后，使用 grub-standalone 而不是普通的 GRUB2，这意味着 GRUB 配置文件和模块被嵌入到一个经过签名的单一可执行文件中，从而防止注入 GRUB 模块（驱动程序）或更改参数。此外，GRUB 还应设置密码。随后，GRUB 将调用签名经过验证的内核和 initramfs/initrd。

这个信任链似乎是合理的，它可以防止干预启动顺序，并确保分区的未加密部分没有被替换。攻击者无法加载任何不同的 GRUB，也无法更改配置、initramfs/initrd、内核。

但上述过程的薄弱环节在于boot loader。在 GRUB 被调用时，攻击者可能会尝试注入内核驱动程序或恶意代码。

为了缓解这一问题，Ubuntu强制使用 shim，这是一种预加载器pre-loader机制。这种情况下，信任链的运作方式略有不同：

• BIOS 信任使用微软证书的 SHIM。
• 使用微软证书签名的 SHIM 信任另一组证书--自签名证书或 Canonical 证书。SHIM 是 GRUB 前的boot loader。
• SHIM 信任由 Canonical 签名的 GRUB EFI 二进制文件。
• GRUB 信任使用 Canonical 证书的内核（所有库存内核都由 Canonical签名），或使用自签名证书的自定义内核（和模块），但需要对使用的每个内核和该内核使用的每个模块都使用自签名证书。
• GRUB信任 initramfs/initrd。

图2. Secure Boot签名、验签过程

这种流程的问题在于信任链中有外部来源，不同的组件可能会被替换或打补丁。问题在于：

• SHIM 可以用微软信任的其他 EFI 二进制程序（如 Windows 加载器）代替。这将导致跳过整个信任链，进入另一个我们无法控制的流程。
• SHIM可以使用自签名证书进行编译（然后将其作为受信任证书输入 BIOS SecureBoot），但这将给SHIM的部署带来麻烦，每次更新时需要重新编译。
• 使用 grub-standalone需要使用 Canonical 证书或自签名。如果使用自签名，我们将从 SHIM 中移除 Canonical 证书，但这样就必须使用我们的证书重新签名内核。或者我们将自签名证书添加到 SHIM 中，但这样一来，我们被锁定的 GRUB 就可以被替换为由 Canonical 签名的普通 GRUB2，并轻松绕过锁定。
• 默认情况下，initramfs 签名不会被检查。攻击者可以在之前的任何地方使用grub efi取出我们的密钥。

三. 牢牢掌握你的安全启动

3.1

Shim

SHIM默认会信任微软的证书，这意味着你的电脑将会信任所有微软签名的boot loader以及所有由微软签名的内容，因此最好将安全启动掌握在自己手中。

接管安全启动有如下的好处：

• 消除默认密钥所带来的安全隐患：理论上，安全启动应能阻止恶意软件运行。但另一方面，攻击者总是有可能诱骗微软签署恶意软件；或者签署的软件可能存在漏洞。如果使用默认密钥的 Shim，计算机仍会受到这些威胁的攻击。
• 消除操作系统密钥所带来的安全隐患：与前述情况类似，操作系统的密钥也有可能被泄露，在这种情况下，攻击者可能会分发使用泄露密钥签名的恶意软件。
• 无需使用MOKs：Shim 和 Pre Loader 工具都依赖于机器所有者密钥 (MOK)，MOK 与安全启动密钥类似，但更容易安装。由于更容易安装，它们更容易被社会工程或其他手段滥用。因此，取消 MOK 可以提高安全性。
• 方便测试与开发：如果你想开发自己的启动管理器，使用微软安全启动密钥签署文件的过程繁琐而耗时，因此需要用自己的密钥来签署二进制文件。当软件按照预期运行时，就可以将它发送给微软进行签名了。

图3. 使用MOKs

图4. Secure Boot的几类密钥

四. 总结与讨论

这篇文章讨论了安全启动以及可能存在的安全问题。在实际中，与其对所有内容进行自签名，另一种选择是使用 TPM PCR 来更好地保护加密密钥。PCR 包含启动过程中所有内容的hash值，如固件设置、启动顺序、启动加载程序内容（如 shim、grub）、内核和 initrd。可以对 TPM 进行配置，使其只有在 PCR 包含特定值（或与启动前完全相同）的情况下才会释放加密密钥。这有助于防止数据被盗，因为如果攻击者更换硬盘或改动boot loader，就会扰乱 PCR，TPM 就会拒绝释放密钥，从而保证数据的安全。

Secure Boot、TPM可以为计算机的启动环节奠定安全基础，但Secure Boot 也不是万能药。在实际执行过程中，需要从多个层面保障安全，避免在引入了先进技术的同时，却忽略了最基础的信任根。

内容编辑：创新研究院 高 翔

责任编辑：创新研究院 董炳佑

本公众号原创文章仅代表作者观点，不代表绿盟科技立场。所有原创内容版权均属绿盟科技研究通讯。未经授权，严禁任何媒体以及微信公众号复制、转载、摘编或以其他方式使用，转载须注明来自绿盟科技研究通讯并附上本文链接。

关于我们