可信软件堆栈和可信计算组的DICE架构

防病毒程序、防火墙、合规性管理、安全通信协议和其他方法可提供自上而下的安全性。自上而下的安全性在机器的启动周期的后期启动，它主要关注密封系统的外部攻击面（将坏东西拒之门外并保守秘密）。如果只使用自上而下的安全技术，那么软件的较低、最关键的层通常容易受到攻击。

TCG 的硬件/固件/软件方法为可以关闭此漏洞的所有层提供了完整的自下而上的防御。图 1 显示了自上而下和自下而上的防御如何结合起来提供“纵深防御”。

图 1. 传统的自上而下的安全方法与TCG的自下而上的技术相比。

支持可信计算的固件建立在“可传递信任链”之上，并使用核心信任根测量 （CRTM） 从引导期间在系统上运行的第一条指令建立系统测量。CRTM 启动了实现纵深防御和保护所有计算设备（包括联网传感器）所必需的自下而上的安全性。

启动固件、操作系统（包括实时操作系统 （RTOS））和受信任的应用程序将全面的代码测量放在 TPM 的可编程配置寄存器 （PCR） 中，以构建其可传递信任链。这些度量值位于 TPM 中，不能被恶意代码更改，被 TPM 中的函数广泛使用。

使用 TSS 2.0 作为功能强大且方便的 TPM 软件服务，以下是使用 TPM PCR 提供的一些主要功能：

通过自身或与其他类型的授权结合使用来授权各种 TPM 操作，以实现多重身份验证

密封系统机密（密钥等），以保护它们免受潜在恶意软件的泄露

系统

安全运行状况的证明 注意：使用 TPM 的证明允许可靠地检查系统的代码度量值。恶意固件无法更改或模拟基于 TPM 的证明，因为它无法看到对用于证明的 PCR 摘要进行签名所需的 TPM 常驻/机密证明密钥。

TPM还具有传统硬件安全模块（HSM）或智能卡的所有功能。使用 TSS 2.0 与 TPM 2.0 接口的 PKCS#11 软件提供了传统上随这些设备提供的所有功能。这使得许多使用 HSM 和智能卡的应用程序可以轻松移植到具有 TPM 2.0 的系统中。

TPM 2.0 是国际标准化组织 （ISO） 标准。它是构建基于硬件的信任根的国际标准。世界贸易组织（WTO）成员不得对ISO标准化安全设备进行进出口管制。这有利于在全球范围内运送设备，而不会因为旨在规范TPM和其他硬件安全模块的贸易壁垒而阻止它们进入市场。它已经或将要被指定为政府，关键基础设施和其他安全合规感知项目（包括带有传感器的项目）的提案请求书（RFP）中的必需项目。

交易系统 2.0

TCG 的 TSS 2.0 是用于使用 TPM 的标准应用程序编程接口 （API）。借助 TSS 2.0 的跨平台支持，用户可以轻松地跨平台移动应用程序。

应该注意的是，一些供应商使用术语“TSS”来描述其专有或非标准TPM软件。在许多情况下，来自政府和具有安全意识的行业的 RFP 要求确实/将专门确定 TCG TSS 2.0 以满足和 RFP 响应的要求。使用TSS 2.0可以提高这些领域组织增加安全性的信心，因为他们知道它是由TCG开发并由TCG的安全专家审查的。TCG TSS 2.0 规范可在 TCG 网站上找到。

安全程序员还可以通过 TSS 2.0 获取 TPM 的关键服务：

与 TPM 通信时所需的编组/取消编组服务

多个 TPM 应用程序可以不受干扰地使用相同的 TPM

对从软件到 TPM 的数据流进行加密，从而阻止侧信道（硬件探测）攻击。

注意：这是通用标准 EAL 4+ 认证所必需的，这是许多客户要求的

简化使用 TPM 的应用程序所需的上下文和会话管理

TSS 2.0 还提供了：

用于与 TPM 通信的同步和异步函数调用模型

分层软件模型，允许不同级别的抽象（取决于所使用的 TSS 层），简化了使用 TPM

的任务 注意：分层软件模型还为不同的代码占用提供了可扩展的解决方案，从最小的物联网 （IoT） 设备（如传感器节点）到服务器应用程序

TSS 2.0 软件模型的各层如图 2 所示。

图 2.TCG 的 TSS 2.0 的分层架构提供了包括传感器节点在内的应用灵活性。

TSS 2.0 层执行以下功能：

设备驱动程序管理与 TPM 设备通信的电子总线。TPM 设备驱动程序现已在 Linux 和 Windows 中可用。其他操作系统和 RTOS 可能需要修改或自定义的驱动程序。

选项卡和资源管理器允许多个应用程序和内核共享 TPM 资源。此代码和设备驱动程序是 TSS 2.0 软件堆栈中特定于操作系统的两部分。

TPM 命令传输接口 （TCTI） 允许开发程序员以平台上的硬件 TPM 以外的 TPM（例如，软 TPM）为目标。这是调试TPM软件的一个非常方便的功能，并允许实现远程TPM。

系统 API （SAPI） 是与 TPM 交互的最低级别（最不抽象）方式。它不需要文件系统或堆。它可以与启动固件集成，也可以用于最小的物联网设备。

增强型系统 API （ESAPI） 具有更轻松的上下文管理，并提供加密到 TPM 的数据流的能力，从而阻止侧信道攻击（对 EAL4+ 至关重要）。

功能 API （FAPI） 提供了 TSS 1.2 所不具备的新易用性。它允许程序员与 TPM 接口，而无需成为 TPM 专家。

TSS 2.0 API 采用简洁的编程技术，遵循行业公认的最佳软件实践。这允许程序员（包括最初编写代码的程序员）返回并使用TSS 2.0轻松阅读，理解和修改应用程序。当您考虑到您的代码必须由各种程序员在产品通常很长的生命周期中理解，维护，测试和可能认证时，这是一个非常重要的因素。

TSS 2.0 中的干净编程技术包括：

无功能过载 – 确保高语义内容

强类型检查 – 无可变参数（参数数量可变）变量

无全局变量

人类可以理解的有意义的变量名称和函数名称

TSS 2.0 API 还提供了强大的代码版本控制和版本控制。这可确保可以识别每个版本的代码行为更改的详细信息。除非版本更改，否则将保持向后代码兼容性。

其他合规性

TSS 2.0 API 的设计特征包括符合汽车工业软件可靠性协会 （MISRA）。这对于工业物联网、汽车和细分市场中的软件安全合规性至关重要，在这些领域，安全是一个关键问题。但是，底层 TSS 2.0 实现可能符合 MISA 标准，也可能不符合 MISA 标准，因此有必要与 TSS 2.0 供应商联系，以了解 MISRA 合规性是否超出 TSS 2.0 API 扩展到实际的 TSS 实施（注意：板载安全 TSS 2.0 符合 MISRA 标准）。

审核编辑：郭婷