3. TPM硬件与软件架构
理解TPM，不能只把它当成一个“密码学黑盒”。在工程实践中，TPM既可能是一颗焊在主板上的独立安全芯片，也可能是CPU内部的一块可信执行区域，甚至可能是一段运行在普通环境中的模拟程序。它们对外提供的命令接口大体一致，但底层实现、性能、安全边界和部署方式差异很大。与此同时，TPM之上还有一整套软件栈，负责把应用层的可信计算需求翻译成TPM能理解的命令，并管理有限的片上资源。本节从硬件形态和软件栈两个维度，建立TPM的整体架构认知。
一、TPM芯片的基本结构
无论哪种形态，TPM在逻辑上都包含若干核心组件。首先是密码引擎，负责执行RSA、ECC、SHA、HMAC、AES等算法，密钥运算在芯片内部完成，私钥永不外泄。其次是非易失性存储，用于保存持久化数据，例如背书密钥EK、存储根密钥SRK、所有者授权信息和NV索引。第三是易失性存储，包括平台配置寄存器PCR、会话上下文和对象上下文，其中PCR是远程证明的核心度量寄存器。第四是随机数发生器，为密钥生成和会话提供熵源。第五是授权与执行控制逻辑，负责校验命令授权、执行策略并防止物理与逻辑攻击。
这些组件通过内部总线连接，对外则通过TPM接口暴露命令。常见的物理接口有LPC、SPI、I²C，现代平台多采用SPI或厂商专用总线。命令以字节流形式传输，遵循TPM 2.0规范定义的结构：标签、命令大小、命令码、参数区。理解这一结构，是后续使用TSS进行开发的基础。
二、四种硬件形态与模拟器
按照实现载体，TPM可以分为离散TPM、集成TPM、固件TPM和TPM模拟器。它们在成本、安全性、可升级性和适用场景上各有取舍。
| 形态 | 实现方式 | 典型接口 | 优势 | 局限 |
|---|---|---|---|---|
| 离散TPM | 独立安全芯片，焊于主板 | SPI / LPC | 物理隔离强，抗篡改等级高 | 成本高，占用板面空间 |
| 集成TPM | 集成在CPU或SoC内部 | 内部总线 | 成本低，性能好，启动链紧耦合 | 与CPU厂商绑定，审计依赖厂商 |
| 固件TPM | 由CPU可信固件模拟TPM功能 | 内存映射/专用指令 | 无需额外芯片，可随固件升级 | 安全边界依赖固件与CPU隔离能力 |
| TPM模拟器 | 纯软件实现，运行于用户态 | Socket / 字符设备 | 便于开发调试、CI测试、教学 | 无硬件信任根，不能用于生产证明 |
离散TPM是最传统的形态，独立芯片拥有自己的时钟、存储和防护层，即使主机被攻破，芯片内部的密钥仍受保护。集成TPM把可信根放进CPU，启动时由微码或安全固件初始化，与Boot ROM、微码更新机制配合，形成更紧密的信任链。固件TPM则常见于虚拟化或服务器平台，由Hypervisor或系统固件提供TPM命令服务，适合大规模云环境。TPM模拟器如IBM的swtpm，常用于开发阶段验证命令流程，但必须清楚：它没有物理防篡改能力，不能作为生产环境的信任根。
三、软件栈：TSS、TAB与资源管理器
应用不会直接向/dev/tpm0写字节流，而是通过TSS（TPM Software Stack）完成命令封装、会话管理和密钥对象处理。TSS通常分为多层：最底层是TCTI，负责与设备驱动或模拟器通信；其上是SAPI，提供接近TPM 2.0规范的底层接口；再往上是ESAPI和FAPI，分别提供增强接口和面向应用的高级接口。开发者可根据控制粒度选择层级。
TAB（TPM Access Broker）解决的是多进程并发访问问题。TPM是单命令执行设备，同一时刻只能处理一个命令。TAB负责在多个进程之间仲裁和转发，避免命令交错导致会话上下文混乱。在Linux上，TAB通常由tpm2-abrmd守护进程实现，通过D-Bus向客户端提供访问入口。
Resource Manager则管理TPM有限的易失性资源。TPM内部对象槽位和会话槽位数量有限，当应用创建大量密钥或会话时，资源管理器会把暂时不用的对象换出到主机的安全存储中，需要时再换入。它还必须保证换入换出过程中上下文不被篡改，因此会结合加密和完整性校验。TAB与Resource Manager常常协同工作：TAB负责访问仲裁，Resource Manager负责资源调度。
四、典型场景：从应用到TPM命令的完整路径
假设一个远程证明客户端需要读取PCR值并生成Quote。它的调用路径大致如下：应用调用FAPI的tpm2_quote接口，FAPI完成密钥查找、会话建立和参数组装，交给ESAPI；ESAPI通过SAPI构造TPM2_Quote命令；SAPI经TCTI把命令发送到TAB；TAB仲裁后交给Resource Manager；Resource Manager确认所需密钥对象已在TPM中，若不在则先执行上下文换入；最终命令到达TPM设备，TPM执行签名并返回结果。整个过程对应用透明，但每一层都承担了明确的职责。
# 使用 tpm2-tools 查看软件栈与设备
$ tpm2_getcap properties-fixed
TPM2_PT_MANUFACTURER: 0x49424d
TPM2_PT_VENDOR_STRING_1: "IBM"
TPM2_PT_FIRMWARE_VERSION_1: 0x00010002
# 查看 TCTI 与 TAB 状态
$ tpm2_abrmd --version
$ systemctl status tpm2-abrmd
# 读取 PCR 0 的度量值
$ tpm2_pcrread sha256:0
sha256:
0 : 0x9F2C...A1B3五、常见误区与复盘
- 误区一：模拟器可以替代真实TPM做远程证明。模拟器没有硬件信任根，其EK和PCR可被随意伪造，只能用于功能验证，不能作为生产证明依据。
- 误区二：TAB和Resource Manager是同一个东西。TAB解决并发访问仲裁，Resource Manager解决对象槽位不足，两者职责不同，但在Linux上常由同一守护进程协同实现。
- 误区三：集成TPM一定比离散TPM弱。集成TPM的安全等级取决于CPU的隔离与固件保护能力，现代集成方案在启动链绑定和性能上往往更有优势，关键看是否满足目标安全 profile。
- 误区四：应用直接操作/dev/tpm0即可。绕过TSS和TAB会导致会话冲突、资源泄漏和并发错误，生产环境应通过标准软件栈访问。
总结来看，TPM的硬件形态决定了信任根的物理边界，软件栈决定了应用能否安全、高效地使用这一信任根。离散、集成、固件和模拟器各有适用场景，TSS、TAB与Resource Manager则共同构成从应用到芯片的完整通路。掌握这张架构图，后续学习密钥层级、PCR度量和远程证明流程时，就能清楚每一步发生在哪一层、由谁负责。