TPM、PCR与信任链：可信计算题库核心考点解析

简介：华中科技大学可信计算线上测试题目及答案文档面向准备课程线上测试、期末复习及网络安全方向入门的学习者，聚焦可信计算核心概念与常见考点的问答梳理。压缩包共1个docx文件，大小约558KB，内容按题目组织，便于检索和对照背诵。已有331人学习或下载，适合需要快速过一遍知识框架、查漏补缺的读者。文档围绕可信计算的理论担忧、TPM与TSS、Hash算法性质、对称与非对称加密算法、PKI及证书关系、PCR数量与平台状态报告、可迁移密钥等主题给出答案，并补充算法特点和应用场景。读者可据此梳理可信计算的知识脉络，定位易混淆概念，结合课堂笔记完成考前自测与重点复盘。

1. 可信计算题库不是背答案：先把 TPM、PCR 与信任链吃透

带“可信计算”字样的线上测试，翻车点往往不在记不住定义，而在概念之间没有接通：PCR 扩展公式背得出，却说不清为什么它能防篡改；EK、AIK、SRK 三把钥匙的名字记得住，一追问“谁能迁移、谁能加密”就乱。这份整理自线上测试的题目与答案文档，价值不在于给出一份背诵清单，而在于它把 TPM 密钥体系、PCR 度量、静态与动态信任链、虚拟化回滚这几条主线串成了一条可推演的链路。适合正在准备网安方向课程考核、需要快速把零散知识点焊成体系的人，也适合做终端安全、固件安全的技术同学拿来对照自查——毕竟 TPM 这东西，平时藏在主板里没人提，一出问题就是黑匣子。

2. TPM 的物理形态与 TSS 软件栈：从主板芯片到应用调用

可信计算的第一层误解，是把 TPM 当成一颗“加密芯片”就完事了。文档里那句“TPM 通常是 TSSOP28 封装的 IC，既可以独立成片，也可以嵌入主板其他芯片中”，其实点出了它在系统里的位置：它挂在主板上，和 CPU 协同工作，但不等于 CPU 的一部分。后面所有密钥、PCR、报告机制，都建立在这个物理前提上。

2.1 TPM 与 CPU 的连接路径：内存映射寄存器与总线命令

TPM 不是靠某条专用私有协议跟 CPU 对话的。常见的实现方式是：固件和操作系统软件通过访问内存映射寄存器与 TPM 交互，CPU 芯片组把这类访问转换成总线命令下发给 TPM 芯片。也就是说，从上往下看是一条清晰的四层路径：

• 应用层：调用 TSS 提供的高层 API
• 库层：TSS 把 API 调用翻译成等价的 TPM 命令
• 驱动层：设备驱动把命令发送到芯片
• 硬件层：TPM 芯片执行并回传结果

这条链路解释了为什么直接怼寄存器写命令既痛苦又容易错。TPM 命令结构复杂，带标签、长度、授权区、参数区，手工拼字节几乎必然出错。TCG 搞出 TSS 软件栈，就是为了把这层复杂度封起来。实际动手时，我一般先用 TSS 的高层接口跑通流程，等确认逻辑没问题，再往下看它到底生成了什么命令字节，这样排查问题时才有对照。

2.2 用 tpm2-tools 走一遍 PCR 读取与扩展

脱离具体命令谈 PCR 很容易飘。下面这段基于常见 tpm2-tools 的操作，能把“读 PCR—扩展 PCR—再读 PCR”这个闭环跑出来，用来验证你对扩展公式的理解是否真的落地。

# 查看 PCR 0 的当前值（SHA-1 银行） tpm2_pcrread sha1:0 # 手工对 PCR 0 做一次扩展：把一段度量值扩展到 PCR 0 # -C 指定会话句柄，o 指定输出，这里只演示命令形态 echo -n "boot-measurement-demo" | tpm2_pcrextend 0:sha1=$(sha1sum | awk '{print $1}') # 再次读取，观察 PCR 0 的变化 tpm2_pcrread sha1:0 # 查看 TPM 支持的算法与能力 tpm2_getcap algorithms tpm2_getcap pcrs

这段操作背后的逻辑值得逐条说清。tpm2_pcrread读取的是平台状态摘要，PCR 里存的不是原始度量日志，而是 SHA-1 散列值，所以一个 PCR 值只能代表“机器运行到某一步的状态摘要”，不能反推跑了哪些程序。tpm2_pcrextend执行的正是文档里那条公式：PCR[i] = SHA-1(PCR[i] || newMeasurement)。注意新旧值拼接后再哈希，这个顺序不能反，反了就得到完全不同的结果，而且不可逆。tpm2_getcap用来确认你的 TPM 实际支持哪些哈希算法和多少 PCR，不同规范版本下 PCR 数量和用途划分不一样，别拿一份教程的参数硬套到另一台机器上。

参数层面有几个容易忽略的点。哈希银行的选择要跟平台固件实际使用的一致，否则你读到的 PCR 值和固件度量出来的对不上，后面做远程证明校验期望值时就会莫名失败。扩展操作需要相应 PCR 的授权，普通用户态未必有权限，跑不通先看权限和会话句柄，而不是怀疑命令写错。TPM 的 PCR 在重启时会重置（这也是文档强调“只有重启或断电才执行 PCR-Reset”的由来），所以任何依赖 PCR 状态的验证，都必须考虑机器是否刚启动过。

2.3 TSS 分层带来的调试思路

理解 TSS 分层，最大的收益是排错时知道该看哪一层。应用调用失败，可能是 API 参数问题；TSS 翻译出的命令被拒，可能是授权或 PCR 状态不满足；驱动层发不出去，可能是设备节点或权限问题；芯片返回错误码，才轮到硬件或固件层面。很多“TPM 用不了”的抱怨，实际卡在第二层——比如对一个已经扩展过的 PCR 做 Seal 期望它还能解封，这从原理上就不可能成立，跟工具无关。

3. 密钥体系：EK、AIK、SRK 与七类密钥的边界

密钥这一块是文档里信息密度最高的部分之一：EK 是平台身份、AIK 用于签名证明、SRK 是存储根，还有绑定密钥、密封密钥、可迁移与不可迁移之分。死记“能不能迁移”没用，得从“这把密钥保护什么、谁能用它”倒推。

3.1 三把核心密钥的职责划分

把文档里的描述压成一张职责表，比反复读段落有效得多。

这张表背后有个容易被追问的逻辑：EK 不用于加密数据，所以没有任何密钥能拿来加密 SRK，而 SRK 又必须被保护，结论只能是 SRK 常驻 TPM 内部、永不出芯片。这条推理链在答题时经常被考，因为它是“为什么 SRK 不可迁移”的真正原因，而不是一句规定。

密钥加载过程同理。文档里那道“把签名密钥加载到 TPM 做签名”的题，答案是自顶向下逐层解密：用 SRK 私钥解密存储密钥 #1 的私钥，再用存储密钥 #1 解密存储密钥 #2 的私钥，最后用存储密钥 #2 解密签名密钥的私钥。这是一条密钥链，任何一层私钥拿不到，后面全断。这也顺带解释了文档提到的“使用子密钥要父密钥授权、使用前先加载”这条规则。

3.2 用代码验证密钥的创建、加载与签名

光看职责表还是虚的。下面这段演示在主密钥之下创建一个签名密钥、加载并使用它签名的典型流程。

# 1. 创建主密钥（owner 层级），作为后续密钥的保护父级 tpm2_createprimary -C o -c primary.ctx -g sha256 -G rsa # 2. 在主密钥下创建签名子密钥，子密钥的私钥受父密钥保护 tpm2_create -C primary.ctx -G rsa2048:rsassa-sha256 -u sign.pub -r sign.priv # 3. 加载子密钥到 TPM，加载时需要用父密钥上下文解保护 tpm2_load -C primary.ctx -u sign.pub -r sign.priv -c sign.ctx # 4. 用加载后的签名密钥对数据签名 echo -n "platform-integrity-report" > data.bin tpm2_sign -c sign.ctx -g sha256 -o sig.bin data.bin # 5. 用对应公钥验签 tpm2_verifysignature -c sign.ctx -g sha256 -m data.bin -s sig.bin

逐行看：tpm2_createprimary建的是密钥树的根，对应文档里“一切密钥都在存储根密钥保护之下”的那一层；-C o表示在 owner 层级下创建，这是平台所有者控制的域。tpm2_create里-u输出公钥、-r输出被父密钥加密保护的私钥，注意私钥落盘时已经是密文，脱离这台 TPM 和这个父密钥就解不开——这正是“不可迁移密钥永久绑定平台”的具体体现。tpm2_load是真正的加载动作，必须提供父密钥上下文，对应文档那道“自顶向下逐层解密”的题。tpm2_sign和tpm2_verifysignature一签一验，参数里的-g sha256指定摘要算法，必须与创建密钥时声明的 scheme 匹配，否则签名会失败或者验签不通过。

这里有个实操上的坑：很多人把tpm2_create输出的私钥文件当普通文件拷到另一台机器上继续用，结果加载失败，然后怀疑工具坏了。实际原因是密钥被父密钥绑定，父密钥又是一个不可迁移的树根，换平台自然解不开。可迁移密钥才有跨平台流转的余地，而文档明确说了单向：不可迁移可转为可迁移，反过来不行。理解这一点，再看绑定密钥“发公钥到别的平台加密数据、本平台解密”的用法，就顺了——绑定密钥的用途是安全传输小规模数据（比如对称密钥），而不是把整个密钥体系搬走。

4. 信任链与证明：静态度量的局限和动态度量的补救

信任链部分最值得花时间，因为它是“能不能用”的分水岭。文档里对静态可信度量根列出了四个问题：易用性、可扩展性、度量时机、包容性；又给出了动态可信度量根如何消掉其中一部分。这套对照关系，是整份材料里逻辑最完整的一段。

4.1 静态度量根的四个先天问题

先把四个问题摊开，因为后面所有动态方案都是冲着它们去的。

易用性问题的场景很具体：挑战者发起挑战时，被证明方需要重启才能给出可信证明。也就是说，“证明我现在是干净的”这件事，在静态模型里往往等价于“重启一次给你看”，这对在线服务显然不友好。

包容性问题更麻烦。要让第三方信服，必须度量整个可信计算基的所有组件，但主流操作系统的 TCB 边界划得有问题，结果系统里几乎所有可执行部件都得进信任链，链子大到不可维护。

可扩展性是包容性的直接后果。链一长，接收方要判定系统可信，就得知道链上每个部件的可信性。换块 BIOS、打次系统补丁，信任链就直接断了。

度量时机问题最关键：系统安全启动并被判定可信之后，攻击者仍可在一个“可信”的系统中利用缓冲区溢出替换可执行文件。静态可信根只能保证装载时的状态，管不了运行时。

4.2 动态度量如何消除缺陷

文档里对德国研究者指出的 TPM 1.0 三个缺陷，以及动态可信度量根如何应对，给出了相当清楚的映射：缺陷之一是引导装载程序里的 bug（装载不完整、度量与扩展分开、异常启动路径不扩展 PCR），缺陷之二是 BIOS 可刷写且启动时不度量，缺陷之三是针对 LPC 总线的 TPM 重启攻击。

动态可信度量根的第一招是砍掉信任链源头里的不可控部分：移除 BIOS 及其配置、可选 ROM 及其配置、以及带 bug 的 bootloader，从根上断掉缺陷一和缺陷二的威胁路径。第二招针对重启攻击，新增 8 个 PCR，初值设为全 1，硬件攻击最多只能把它们维持在全 1，而只有从 CPU 发出的特定指令才能把它们改为 0；初值不同，攻击者很难算出一致的哈希结果。这就是“初值不同”能防重放的原因——攻击者没法把状态伪造成和正常启动一样的摘要。

配合这一机制的是 Locality。TPM 1.2 有 5 个 Locality，作用就是鉴别一条 TPM 请求的发起者身份：Locality 4 对应可信硬件（也可表示动态可信度量根），Locality 3 是可选辅助组件，Locality 2 是可信操作系统运行时使用，Locality 1 是可信操作系统提供给应用的执行环境，Locality 0 用于向下兼容。理解了 Locality 是“谁在敲门”的身份标签，就能明白为什么动态度量方案要依赖它来区分请求来源。

4.3 本地报告与远程证明的操作化

文档把报告分成本地和远程两种，这个区分必须抓住。

本地报告的核心是 Seal/Unseal：把机密信息绑定到一组指定 PCR 值上，机器状态符合时才释放。正常启动后销毁该秘密、再扩展 PCR 改变状态，后来者就无法 Unseal。这条机制在代码上是可以直接验证的：

# 将一段秘密数据密封到 PCR 0 的当前值上 echo -n "sealed-secret-demo" > secret.bin tpm2_createpolicy --policy-pcr -l sha1:0 -L policy.digest tpm2_create -C primary.ctx -G keyedhash -u seal.pub -r seal.priv -i secret.bin -L policy.digest tpm2_load -C primary.ctx -u seal.pub -r seal.priv -c seal.ctx # 此时 PCR 0 未变，解封应成功 tpm2_unseal -c seal.ctx -p pcr:sha1:0 # 扩展 PCR 0 改变平台状态，再次解封应失败 echo -n "state-change" | tpm2_pcrextend 0:sha1=$(sha1sum | awk '{print $1}') tpm2_unseal -c seal.ctx -p pcr:sha1:0

逻辑说明：tpm2_createpolicy生成一条基于 PCR 的策略，把 PCR 0 的当前值写成策略摘要；创建密封对象时用-L绑定该策略；解封时 TPM 会重新计算 PCR 策略摘要并与绑定时比对，一致才释放。参数上最容易错的是 PCR 选择要与策略里声明的一致，以及扩展之后必须用新的 PCR 值重新走一遍策略，不能拿旧策略反复解封。这个例子把文档里“Seal 把数据可访问性与机器状态绑定”抽象说法变成了可观察的成功—失败对比，比背定义扎实得多。

远程证明则是另一条线：挑战者要求一次摘要，客户端用 AIK 对指定 PCR 和 nonce 签名，同时附上度量日志和 AIK 证书；挑战者验证签名与 nonce，验证 AIK 证书合法性，再读取度量日志 SML，模仿 PCR 扩展顺序重新计算期望值，与客户端返回的 PCR 比对。这里的关键点是“用日志重算期望值”，因为 TPM 里只有摘要，原始度量记录必须在日志里，而日志不防篡改也没关系——攻击者改了日志，重算出的摘要就对不上 PCR，立刻暴露。

5. 虚拟化场景：vTPM、回滚矛盾与半回滚方案

到了云和虚拟化这一层，TPM 1.2 的模型就不够用了。文档指出得很直接：一台物理机只对应一个 TPM，如果一台虚拟机进入安全环境，其他虚拟机就得暂停；而实际场景里我们希望每台虚拟机都有自己的安全环境、互不干扰，有时还只想验证某一台虚拟机而不必挑战整个物理平台。vTPM 就是冲这个来的：用一个 TPM 满足多个虚拟机，且验证粒度更细、效率更高。

5.1 回滚为什么和可信计算打架

回滚是虚拟化的常规操作，但在可信计算语境下它直接制造矛盾。虚拟机回滚而 TPM 不回滚，TPM 和系统状态的一致性就破了——先正常启动让 TPM 处于正常状态，再把虚拟机回滚到含恶意代码的状态，此时 TPM 已经无法证明平台安全性，因为两者对不上。

反过来，单纯回滚 TPM 也解决不了。回滚 TPM 数据会让新产生的密钥等数据丢失；更糟的是重放攻击：攻击者每次远程证明前都回滚到可信状态，入侵痕迹就被抹掉了。

这里要特别留意文档里一个明显串题的答案：第 23 题问虚拟机回滚和可信计算的矛盾，给出的却是“对称加密不增加安全性”那段。这是原材料的瑕疵，不是知识点本身有问题。正确理解应当回到第 24、25 题：矛盾来自 TPM 状态与虚拟机状态不同步，以及单纯回滚带来的数据丢失与重放风险。备课时如果照抄这段，考场上被追问会很难看，建议以 24、25、26 题的逻辑为准。

5.2 半回滚方案：PCR 回滚、密钥不回滚、新增两组 PCR

解决思路文档给了两版，内容其实一致。核心是“部分回滚”：PCR 跟着回滚以保证一致性，密钥不回滚以免新密钥丢失、过期密钥不再使用。同时新增两组不回滚的 PCR，把快照时间、执行快照/回滚的用户信息、vTPM 回滚前状态、虚拟机回滚前状态等度量值扩展进去。

这样做的效果是把“回滚”这个动作本身变成可审计的记录：攻击者回滚虚拟机也无法消除痕迹，因为记录回滚轨迹的那两组 PCR 永远不回滚。这套设计对应了 vTPM 在服务一组虚拟机时的几个典型安全问题——安全状态不一致、被 Seal 的密钥无法解封、重放攻击、限量服务被无限使用，其中限量服务那条尤其现实：很多试用限制依赖 vTPM 里的数据，数据能回滚，限制就形同虚设。

5.3 vTPM 管理器的职责

文档引用的网页答案提到管理器有三个线程：一个连 TPM 硬件驱动，一个管理 vTPM 实例，一个连前后端驱动；先判断指令来自哪个 vTPM，再依据 locality 判断层级；用共享内存代替网络传递 TPM 指令以提高效率。这段描述虽然偏实现，但对理解“vTPM 不是简单软件模拟”很有帮助——它要在多实例之间做隔离和路由，还要保持与物理 TPM 的语义一致。文档同时提示了性能与安全两类问题：大量虚拟机需要安全环境时开销集中，以及与物理 TPM 相比，vTPM 管理器自身可能被篡改、管理域也可能被攻破。这两条在做威胁建模时不能漏。

6. 拿这份题库做自测：三个校验动作和两条血泪经验

把文档当背诵材料是浪费。我的用法是把它当“推演触发器”：每道题先合上答案自己推一遍，再用三个动作校验，推不出来或推错的地方才是真正要补的。

第一个动作是公式落地校验。PCR 扩展公式、密钥加载链、Seal/Unseal 的绑定条件，这三处最容易被背成结论。我的习惯是拿前面那几段命令实际跑一遍，尤其是 Seal 之后扩展 PCR 再解封失败这个对比，跑过一次，“为什么日志不需要防篡改”“为什么远程证明要用日志重算期望值”这些连带问题就都通了。跑不通时优先查三件事：PCR 选择是否与策略一致、哈希银行是否匹配固件实际使用、授权与权限是否满足。

第二个动作是概念对照校验。用一张小表把容易混的成对概念摆在一起自查，比反复读段落有效。

第三个动作是瑕疵标注。这份材料里第 23 题的答案与题目明显错位，属于整理时串行；遇到这类地方不要顺着抄，回到第 24 至 26 题重建逻辑，并在自己的笔记里标红。血泪经验有两条：其一，凡是涉及“能不能迁移”“能不能加密”的判断，必须回到密钥用途本身推，硬记结论在变形题前必翻车；其二，凡是涉及 PCR 状态的题，先问“机器重启过没有”，PCR-Reset 只在重启或断电时发生，这条前提错了，后面全错。

从那以后我每次带人过可信计算，都强制先跑一遍 PCR 读取—扩展—再读取，再看一次 Seal 的成功与失败对比，最后才翻开题库对答案。顺序反了，记住的只是字符串；顺序对了，题目怎么变形都能推。希望帮到你。

本文还有配套的精品资源，点击获取