信任之根-- RoT如何认证更高级别软件的一般机制

Question

我一直在阅读许多关于RoT的研究文章--信任的根--用于建立从BIOS到内核的连锁信任根。然而，这篇文章的大部分内容都简要介绍了RoT如何为不同的品牌工作。关于RoT的一篇好文章是劳伦斯·刘( Lawrence )的RoT:安全的基础。

但是，我面临的最大问题之一是如何使用引导、操作系统和应用程序建立信任机制，即RoT如何确保它们的真实性。

例如，假设我破坏了引导加载程序，RoT机制如何检测它？它是否检查了引导加载程序代码的哈希，但是如果有公司更新呢？

请给我看相关的文章。

Answer 1

问得好！你所链接的那篇文章，对我来说，用了很多话说得很少(我发现它缺乏具体细节)。相反，我的答案将建立在这一页上：

• 安全引导Microsoft文档

本文使用了与您链接的文章不同的术语。我将使用微软的术语。我相信“安全启动”==“信任之根(RoT)"，但我不是百分之百肯定。

Disclaimer1:下面是我对这个复杂过程的理解，我仍然是这个领域的学生。欢迎改正。

Disclaimer2:我对“固件”这个词的使用有点草率，使用它意味着启动序列中的任何预操作系统内核。

安全启动

安全引导是一小部分固件代码。这是启动的第一件事。它提供了一个地方数据库，其中包括：

• 允许对此设备的固件进行签名的公钥(即批准的软件供应商)，以及
• 允许固件代码的散列(即批准的软件二进制文件)。

如果在给定平台上可用硬件TPM，则这可能是或不可能得到硬件TPM的支持。

安全引导固件本身的

保护和

更新

安全启动代码本身不会在运行时进行验证，但是，由于它是在系统启动时运行的第一段代码，所以更新或修改它的唯一方法是要求它更新自己，并且在更新固件存储中的自己的代码之前，它将检查任何更新包上的代码签名。因此，假设您信任设备上提供的原始安全启动代码，您可以信任它的所有更新。

检测受损固件

当引导序列中的固件尝试加载另一个固件模块时，它将首先询问安全引导模块“这允许运行吗？”安全启动模块将执行以下检查：

• 这个二进制文件上有代码签名吗？
  • 如果是，是否由数据库中的签名公钥之一生成？
    • 如果是，此二进制文件在此签名下有效吗？
      • 如果是，成功；二进制是可信的。
      • 如果没有，则失败；二进制文件已被修改/篡改。

    - If no, fail; binary is signed by an untrusted vendor.

- If no, hash this binary and check if it is directly listed in the database? 
    - If yes, succeed; binary is trusted.
    - If no, fail; binary is not trusted.

这意味着，如果其他固件是由受信任的供应商生成的，或者是在安全引导本地数据库中显式信任的，那么安全引导将只允许其他固件运行。