一、TPM 基础概念：什么是 TPM、物理形态与逻辑架构、在安全启动中的角色

各位同学，咱们今天正式开课。第一讲，先把 TPM 这个“黑盒子”拆开看看。

TPM 是什么？说白了，它是一个专门干“脏活累活”的安全芯片。你想想看，CPU 要跑操作系统，内存要存数据，硬盘要存文件——这些部件都太“忙”了，而且容易被攻击。TPM 不一样，它只做一件事：保护密钥和度量信任链。

我个人习惯把 TPM 比作“保险柜里的保险柜”。你的私钥、平台度量值、加密种子，都锁在这个小芯片里。就算操作系统被攻破，攻击者也拿不走 TPM 里的秘密。

核心定义：TPM（Trusted Platform Module，可信平台模块）是一个独立的硬件安全协处理器，提供密钥生成、安全存储、平台完整性度量、远程证明等基础安全能力。

1.1 TPM 的物理形态

TPM 长什么样？这得看你在什么平台上干活。

形态 典型场景 特点
独立芯片（dTPM） 台式机、服务器 焊接在主板上，通过 LPC/eSPI 总线通信
固件 TPM（fTPM） 笔记本、嵌入式设备 集成在 BIOS/UEFI 或 SoC 中，无独立硬件
虚拟 TPM（vTPM） 云服务器、虚拟机 由 Hypervisor 模拟，用于云环境
软件 TPM（sTPM） 开发调试 纯软件实现，绝对不能用于生产环境

我在项目中遇到过最坑的事：某厂商的服务器主板，BIOS 里明明开了 TPM，但操作系统就是检测不到。查了半天，发现是 LPC 总线上的电阻虚焊了。嗯，硬件问题有时候比软件更头疼。

避坑指南：我曾经在选型时忽略了 fTPM 的 TCB（可信计算基）问题。fTPM 虽然省成本，但它的安全边界依赖于 SoC 的固件安全。如果 SoC 本身有漏洞，fTPM 的保护就形同虚设。所以，高安全场景请优先选 dTPM。

1.2 TPM 的逻辑架构

TPM 内部长什么样？我画了一张图，帮你把它的“五脏六腑”看清楚。

TPM 逻辑架构图 TPM 逻辑架构 TPM 芯片边界 I/O 接口 LPC / eSPI / I²C 密码引擎 RSA / ECC / SHA / AES NVRAM EK / SRK / 平台证书 易失性存储器 PCR 值 / 会话密钥 RNG 真随机数发生器 执行引擎 TPM 命令解析 / 策略执行 关键说明： • I/O 接口：TPM 与 CPU 通信的唯一通道，命令通过 TIS（TPM Interface Spec）传输 • 密码引擎：硬件加速 RSA/ECC 签名、SHA-256 哈希、AES 加解密 • NVRAM：出厂写入的 Endorsement Key（EK）和 Storage Root Key（SRK） • PCR：Platform Configuration Registers，用于存储度量值，断电不丢失 • RNG：基于硬件噪声源，产生真正的随机数，不是伪随机

这张图里，我特别想强调两个模块：NVRAM 和 PCR。

  • NVRAM：出厂就写死了 Endorsement Key（EK）和 Storage Root Key（SRK）。EK 是 TPM 的“身份证”，全球唯一；SRK 是所有用户密钥的“根”。这两个密钥永远无法从 TPM 中读出。
  • PCR：Platform Configuration Registers。每次系统启动，PCR 会记录 BIOS、Bootloader、OS 内核的哈希值。如果某个环节被篡改，PCR 值就不对。

注意：PCR 有一个“扩展”操作——新值 = SHA-256(旧值 || 新数据)。这意味着 PCR 值只能被“叠加”，不能被“覆盖”。攻击者无法回滚 PCR 到之前的“干净”状态。这是 TPM 度量信任链的基石。

1.3 TPM 在安全启动中的角色

安全启动（Secure Boot）和 TPM 是什么关系？很多人搞混了。我简单解释一下：

  • Secure Boot：由 UEFI 固件实现，验证 Bootloader 的数字签名。签名不对，直接拒绝启动。
  • TPM：不参与签名验证，但它会记录启动过程中每个组件的哈希值到 PCR。

说白了，Secure Boot 是“门卫”，TPM 是“监控摄像头”。门卫拦住坏人，摄像头记录谁来过。

TPM 在安全启动中的具体流程是这样的：

  1. CRTM（Core Root of Trust for Measurement）：CPU 复位后，执行的第一段代码（通常是 BIOS 的起始块）。它测量 BIOS 主固件的哈希值，扩展到 PCR[0]。
  2. BIOS 主固件：测量 Option ROM、Bootloader 的哈希值，扩展到 PCR[2]、PCR[4]。
  3. Bootloader：测量 OS 内核的哈希值，扩展到 PCR[8]。
  4. OS 内核：测量关键驱动、安全策略，扩展到 PCR[9] 及以后。

我在项目中遇到过一个问题：某次固件升级后，系统提示“TPM 度量失败”。查了半天，发现是 BIOS 升级后，某个 Option ROM 的版本变了，导致 PCR[2] 的值和之前备份的不一致。嗯，这就是 TPM 的“诚实”——它不管你对不对，它只记录事实。

实战技巧：我建议你在部署 TPM 远程证明时，先做一次“黄金启动”，记录所有 PCR 值作为基准。后续每次启动，比对 PCR 值是否一致。如果某个 PCR 变了，说明对应的组件被修改了——可能是合法升级，也可能是恶意篡改。

1.4 为什么 TPM 比软件方案更安全？

你可能会问：我用软件模拟 TPM 行不行？答案是：绝对不行。

攻击面 软件方案 TPM 硬件方案
密钥提取 密钥在内存中，可被 dump 密钥在芯片内部，物理不可读
侧信道攻击 无硬件防护 内置时序/功耗/电磁屏蔽
篡改检测 依赖 OS 安全 物理篡改会触发自毁
启动链度量 可被绕过 CRTM 不可篡改

我记得有一次做渗透测试，对方用的是软件 TPM。我直接通过内核漏洞 dump 了内存，找到了 SRK 的种子——然后整个密钥体系就崩了。换成硬件 TPM，这种攻击根本不可能成功。

一句话总结：TPM 不是万能的，但没有 TPM 是万万不能的。它把密钥和度量值锁在硬件保险柜里，攻击者就算拿到 root 权限，也撬不开这个柜子。

← 上一章 📖 返回目录 下一章 →