随着物联网、边缘计算和工业 4.0 的快速发展，嵌入式系统正从传统的物理隔离环境走向深度网络连接。这种转变使得嵌入式设备面临着前所未有的安全威胁，从远程漏洞利用到物理篡改攻击。在这种背景下，可信平台模块（TPM）作为硬件信任根（HRoT）的核心组件，正在嵌入式领域获得广泛应用。然而，将 TPM 从 PC 环境迁移到嵌入式系统并非简单的移植，而是需要重新审视安全架构、硬件集成和可信计算链的完整工程实践。
TPM 在嵌入式系统中的核心安全功能
TPM 2.0 规范自 2014 年发布以来，已成为硬件安全的事实标准。在嵌入式环境中，TPM 主要提供三大核心安全功能：
1. 秘密存储与密钥管理
TPM 的核心能力之一是保护敏感数据。与软件密钥存储不同，TPM 内部的密钥永远不会以明文形式离开芯片。TPM 2.0 支持多层次的密钥体系结构，其中平台层次（Platform Hierarchy）和存储层次（Storage Hierarchy）是最常用的两种。通过绑定（Binding）机制，子密钥的数据被父密钥加密和认证后存储在外部存储中，形成所谓的 "blob"。当需要使用时，受保护的 blob 被传回 TPM 进行验证和解密。
这种机制特别适合嵌入式系统中的磁盘加密场景。如 sigma-star.at 的安全专家指出："TPM 功能正在通过 systemd 的 LUKS/dm-crypt 工具集成以及欧盟 CRA 等法律要求，进入嵌入式 Linux 领域。"
2. 测量启动与完整性验证
每个 TPM 芯片包含 24 个平台配置寄存器（PCR），这些寄存器存储着反映平台启动和配置状态的哈希值。测量启动（Measured Boot）过程中，启动链的每个阶段（bootloader、驱动程序、固件、配置数据等）都会测量相关组件，并使用这些测量值扩展相应 PCR 的加密哈希。
这种机制创建了不可篡改的启动记录。如果任何组件被篡改，最终的 PCR 值将发生变化，从而指示潜在的安全问题。更重要的是，TPM 密钥可以与特定的 PCR 值绑定（称为密封），只有当 PCR 包含预期值时，TPM 才允许使用该密钥。
3. 远程证明与可信验证
TPM 能够生成系统启动和配置状态的加密证明。通过专门的证明协议，验证方可以确认设备是否处于已知的安全状态。证明过程利用绑定到一组 PCR 值的 TPM 密钥，确保证明只能在系统处于安全状态时运行。
嵌入式环境下的硬件集成挑战
总线安全与物理攻击防护
嵌入式系统中的 TPM 通常通过 SPI、I2C 或 LPC 总线连接到 CPU/SoC。这种物理连接带来了独特的安全挑战：
总线窃听攻击：通过在 TPM 和 CPU 之间的物理通信线上连接探头，被动攻击者可以读取两者之间交换的消息。这是嵌入式设备中常见且直接的物理攻击，特别是在无人值守的环境中。
为缓解此问题，TPM 2.0 支持基于会话的命令和响应参数加密。这需要在客户端和 TPM 之间建立安全会话。然而，关键问题在于 TPM 的会话加密和认证必须由客户端软件显式启用，因为并非所有当前实现都默认启用此功能。缺乏会话加密可能会在总线上暴露敏感数据（如解封的密钥或授权值），使其容易受到被动总线窃听攻击。
TPM 重置攻击：更高级的威胁是总线上的主动攻击者发起的中间人（MitM）攻击。即使使用会话加密，如果客户端没有首先与 TPM 建立信任关系，这种攻击也可能有效。攻击者可以物理重置 TPM，强制其回到未受攻击状态，然后重建 PCR 值以反映未经篡改的启动，从而访问密封到这些特定 PCR 值的密钥。
Linux 内核 6.10 中增加了对此类中间人攻击的检测支持，该机制依赖于 TPM 的 NULL 种子，该种子在每次 TPM 重置时都会更改其值。这使得内核能够派生一个对当前启动会话易失的主密钥。
物理安全等级差异
虽然 TPM 芯片在设计时考虑了安全性，但不同供应商和型号的保护级别差异很大。ISO/IEC 19790 安全等级提供了芯片物理安全能力的指标。不幸的是，大多数商用 TPM 仅达到 1 级或 2 级。需要防篡改或防篡改证据功能的 3 级和 4 级认证对于 TPM 来说极为罕见，通常保留给使用专用硬件安全模块（HSM）的高安全性应用。
固件更新与生命周期管理
嵌入式系统的生命周期通常超过 10 年，远超过典型 PC 的 3-5 年寿命。这种延长的生命周期需要硬件组件（包括 TPM 芯片）的更长支持周期，其固件可能包含需要更新的漏洞。
在常规 PC 上，这通过 UEFI 或 Windows 处理。然而，在嵌入式设备上，保持 TPM 固件最新是生产商的责任。这在出现类似 TPM-FAIL（CVE-2019-16863）的漏洞时尤为关键，因为需要能够更新 TPM 以修补漏洞。
可信计算链的工程化构建
从 Boot-ROM 到应用层的完整性保护
嵌入式设备主要基于 Arm SoC，与 PC 中常见的 x86/amd64 CPU 形成对比。这种区别对于安全启动过程尤为重要，因为 PC 的大部分安全启动由 UEFI 处理，而大多数嵌入式系统没有标准 UEFI。相反，这些系统依赖于供应商特定的 boot-ROM，然后是像 Barebox 或 U-Boot 这样的引导加载程序。
虽然 U-Boot 可以支持在 UEFI 模式下运行，但这在嵌入式领域仍然很少见。然而，正如 Manuel Traut 在 2024 年《All Systems Go!》演讲中演示的那样，没有 UEFI 也可以实现类似的安全态势。
在基于 Arm 的嵌入式系统上，测量启动通常在 SoC 的 boot-ROM 和初始引导加载程序之后开始，这就是为什么 SoC 特定功能（如 NXP 的 HAB）对于保护启动链的最低级别至关重要。
PCR 锁定策略与运行时保护
对于秘密存储，一个强大的加固措施是将 TPM 密钥锁定到一旦不再需要密钥就会更改的 PCR。一旦磁盘在 initrd 中挂载，可以进行额外的测量来更改 PCR 值，使密封的密钥在下次启动之前无法使用。
然而，必须认识到 TPM 无法完全缓解平台上的任何代码执行漏洞。一旦攻击者控制 OS 内核，他们通常可以提取已经在内存中的秘密或从已挂载的未加密磁盘复制数据。因此，额外的深度加固（如 AppArmor、SELinux）、每个进程的最小权限概念以及后端基础设施的加固至关重要。
工程实践建议与可落地参数
1. 会话加密的强制启用
在 TPM 客户端软件中，必须显式启用会话加密。以下是关键配置参数：
- 使用 HMAC 会话进行命令认证和完整性保护
- 对于基于 PCR 值等条件的更复杂授权，使用策略会话
- 确保所有敏感操作都通过加密会话进行
2. 物理安全评估矩阵
在选择 TPM 芯片时，应建立以下评估标准：
| 安全等级 | 防护特性 | 适用场景 |
|---|---|---|
| ISO/IEC 19790 Level 1 | 基本物理防护 | 消费级 IoT 设备 |
| Level 2 | 增强物理防护 | 工业控制系统 |
| Level 3 | 防篡改设计 | 医疗设备、汽车 ECU |
| Level 4 | 防篡改证据 | 军事、金融关键系统 |
3. 可信计算链构建清单
- Boot-ROM 安全启动验证启用
- 引导加载程序（U-Boot/Barebox）支持 TPM 测量
- PCR 扩展策略定义（哪些组件需要测量）
- 密钥密封策略（哪些 PCR 组合用于不同密钥）
- 运行时完整性监控（IMA/EVM）配置
- 远程证明基础设施部署
4. 固件更新机制设计
- TPM 固件更新包签名验证
- 回滚保护机制实现
- 更新失败恢复策略
- 远程安全更新通道加密
5. 纵深防御架构
TPM 不应被视为安全银弹，而应作为纵深防御策略的一部分：
- 应用层：最小权限原则、沙箱隔离
- 系统层：SELinux/AppArmor 强制访问控制
- 内核层：IMA/EVM 完整性保护
- 硬件层：TPM 硬件信任根
- 物理层：防篡改外壳、安全存储
性能考量与优化策略
TPM 速度较慢是一个经常被忽视的事实。因此，将 TLS 等加密密集型协议卸载到 TPM 是不可行的。然而，它仍然可以用于保护长期密钥，并在协议握手期间执行时间要求较低的操作。
需要记住的另一点是，在 TPM 2.0 中，根密钥不是直接存储的，而是从种子派生的。这种密钥派生可能在计算上很昂贵。因此，使用 RSA 密钥可能比使用 ECC 密钥导致更显著的延迟，因为涉及的数学操作。
结论
TPM 芯片可以帮助实现最先进的安全机制，但它不是使事物固有安全的银弹。要正确使用 TPM，必须有一个明确定义的威胁模型。该模型必须明确指定 TPM 的角色以及它旨在防范的攻击类型。特别是在嵌入式系统上使用时，在设计针对某些威胁的保护时必须考虑缺乏人工交互的情况。
嵌入式系统的安全不再是可选项，而是强制性要求。通过正确实施 TPM 安全架构、解决硬件集成挑战并构建完整可信计算链，嵌入式设备制造商可以在日益互联的世界中为其产品提供必要的安全基础。正如安全专家所强调的："安全不再是您运行的应用程序；它必须是平台的固有属性。"
资料来源
- sigma-star.at 博客文章 "TPM on Embedded Systems: Pitfalls and Caveats" (2026-01-19)
- SYSGO 博客文章 "Trusted Platform Module (TPM) in Embedded System Security" (2025-07-29)
- Trusted Computing Group TPM 2.0 规范文档