这已经不是我第一次撰写关于可信计算基础 (TCB) 的文章了，所以如果这个概念对您来说是新的，我建议您看看 什么是可信计算基础？ 以了解我在这里要讨论的内容。在那篇文章中，我指出了 TCB 大小的重要性：“您想要的是一个小的、易于测量和易于审计的 TCB，您可以在此基础上构建系统的其余部分——您可以从中构建一条‘信任链’到您关心的系统的其他部分。”
在本文中，我想讨论 TCB 大小的重要性、您可能如何测量它以及减少其大小有多困难。 让我们按顺序看看这些问题。
评估大小
无论您如何测量它——我将在下面介绍——TCB 的大小都很重要，原因有两个
- TCB 越大，可能存在的错误就越多。
- TCB 越大，攻击面就越大。
这些中的第一个适用于任何系统。 虽然可能可以通过证明所有（或更可能只是部分）系统的正确性来减少错误的数量，但错误既难以消除又具有弹性； 如果您删除一个，您很可能会引入另一个（或更糟，几个）。 您可以通过多种技术来减少错误的种类和数量，从语言选择（例如，选择 Rust 而不是 C/C++ 来减少内存分配错误）到更好的规范，再到改进的测试覆盖率和模糊测试。 然而，最终，TCB 越小，您必须信任的代码（或硬件——别忘了我们在这里考虑的是更广泛的系统）就越少，其中出现错误的空间就越小。
攻击面的概念很重要（就像 TCB 一样，它也是我之前介绍过的——请参阅什么是攻击面？）。 与错误一样，可能没有绝对的危险：攻击面比率的衡量标准，但您的 TCB 越小，受攻击的可能性就越小，这是一件好事。 与减少错误一样，您可能需要应用许多技术来减少攻击面，但根据定义，攻击面越小，攻击者尝试破坏系统的机会就越少。
测量
测量 TCB 的大小真的非常困难。 或者也许我应该说，提出一个可以与其他 TCB 进行比较的绝对衡量标准真的非常困难。 问题是，您可以进行如此多的测量。 您关心的可能是那些可以与攻击面相关的测量。 但是可能有许多不同的攻击向量与 TCB 相关，因此可能存在多个攻击面。 一些可能的测量包括
- API 方法的数量
- 可以通过每个 API 方法传递的数据量
- 可以通过每个 API 方法传递的参数数量
- 打开的网络套接字的数量
- 打开的本地（例如，Unix）套接字的数量
- 从本地存储读取的文件数量
- 动态加载的库的数量
- 直接内存访问 (DMA) 调用的数量
- 代码行数
- 执行的编译优化量
- 二进制文件的大小
- 内存中执行代码的大小
- 与其他进程共享的内存量
- 各种缓存（L1、L2 等）的使用
- 进行的系统调用次数
- 使用
strings命令或类似命令可见的字符串数量 - 不受恒定时间检查约束的加密操作的数量
这并非详尽的列表；它只是显示了可能出现漏洞的不同领域的范围。 设计您的应用程序以减少一个可能会增加另一个； 一个非常简单的例子是尝试通过增加每个调用上的参数数量来减少暴露的 API 调用数量； 另一种可能是通过使用更多动态链接库来减小二进制文件的大小。
这引出了一个重要的观点，我不会在本文中详细讨论，但对于理解 TCB 至关重要：如果没有威胁模型，考虑您的 TCB 是什么就没有什么意义。
减小 TCB 大小
我刚刚展示了降低 TCB 大小很困难的主要原因之一：它可能需要在不同的措施之间进行权衡。 如果您所要做的只是制作有竞争力的营销材料，在其中您说“我的 TCB 比你的小”，那么您很可能会错过重点。 TCB 的重点在于拥有一个定义明确的计算基础，可以防范特定威胁。 这要求您清楚地了解需要信任哪些功能，它在系统中的位置，以及系统中其他组件如何依赖它。 换句话说，他们有什么信任关系。
最近，我和一位同事交谈，他通过讲述一个软件项目的故事说：“我们通过非常仔细地设计它并检查我们如何实现它，将我们的 TCB 减少到这个很小的组件。” 但我的同事忽略了一个事实，即堆栈的其余部分（包含完整的 Linux 发行版和应用程序）的信任度与以前一样。 威胁模型（如果存在一个——我们没有进入细节）似乎假设只有 TCB 会受到攻击。 这完全错过了重点； 它只是在堆栈中添加了另一个“乌龟”，而没有解决可能存在的问题：提高系统的安全性。
通过人为地定义 TCB 是什么来适应您的能力或围绕它应该保护什么的特定信念来减少 TCB 不仅没有帮助，而且会产生积极的反作用。 这是因为它忽略了一个事实，即 TCB 的存在是为了满足更广泛系统的需求，如果孤立地考虑它，那么它就会变得无关紧要：它作为什么的基础？
总之，说“我们有一个很小的 TCB”很好，但您需要知道您在保护什么，免受什么保护，以及如何保护。
本文最初发表在 Alice, Eve, and Bob 上，并经作者许可转载。
1 条评论