简介：华中科技大学可信计算线上测试题目及答案文档，面向网络空间安全及相关专业学生，用于备考可信计算课程测验或复盘核心考点。内容围绕可信计算的担忧、TPM技术发展、Hash算法、对称与非对称加密算法、PKI与证书、可信计算基本属性等展开，并给出简答题形式的参考答案，便于理解理论要点与出题思路。文档对可信计算理论研究滞后、动态可信度量缺失、信任链损失度量等关键问题进行了提炼，梳理了TPM芯片与CPU的连接方式及TSS软件栈的作用，对比了MD4、MD5、SHA-1等常见Hash算法和DES、AES、RC5、Blowfish等对称加密与RSA、ElGamal、ECC等非对称加密算法的特点、应用场景，还涉及PKI缘何必要、证书与公私钥对的关系、平台状态报告方式、可迁移密钥等考点。资源为单个docx文档，大小558KB，结构清晰，包含多道典型题目及完整解答，查阅方便。目前已有329人学习下载，适合考前冲刺或系统梳理可信计算知识体系。
1. 可信计算线上测试在考什么：一份题目文档背后的知识骨架
临考前一晚才打开那份《可信计算线上测试题目及答案》的人，十有八九会先去背“可信计算的三个目标”，可真正拉开差距的题目，往往是那些把信任链、PCR 和远程证明揉在一起问的流程题——你对着答案能看懂每一步，合上答案却不知道先迈哪条腿。这份标题看似只是一份备考资料，实际上它把可信计算最核心的知识骨架抖了出来：信任根从哪来、信任链怎么传、平台状态如何被证明、验证方凭什么相信这份报告。
线上测试很少跳出这个框架，但跳进去的考生普遍容易掉坑，因为这门课和普通网络安全课有一个本质区别：它考的不是怎么攻破系统，而是怎么建立和传递信任。适合读这篇文章的人也很明确：正在准备高校可信计算课程测验的在校生、要在项目中做可信启动评估的工程师，以及刚接触 TPM、TCM 相关概念的安全新人。
2. 信任根与信任链：读懂题目答案前先补齐的三块基石
2.1 从 TPM 到 TCM：为什么信任根必须沉到硬件里
可信计算区别于传统软件安全的关键，在于它把信任的起点放在了芯片里。软件可以被篡改，运行环境可以被劫持，唯独一个物理上隔离、具备独立密码引擎和存储单元的模块，才能充当“信任根”的角色。测试题里最常见的概念题就是让你对比 TPM 与 TCM，很多人的失分点在于只背了英文缩写，却说不清两者的架构差异。
| 对比维度 | TPM（国际规范路线） | TCM（国密体系路线） |
|---|---|---|
| 规范基础 | 以 TPM 2.0 系列规范为主流 | 以国密相关可信计算规范为主线 |
| 核心算法 | RSA/ECC/SHA-1/SHA-256，授权协议较复杂 | 以 SM2/SM3/SM4 为核心，强调密码算法自主可控 |
| 信任根形态 | 通常为独立安全芯片或 CPU 内置安全引擎 | 可以是独立芯片，也可以集成在固件中 |
| 线上测试常见考点 | PCR 结构、EK/AK 密钥层次、授权会话 | 国密算法在度量与签名中的用法、TCM 的密钥管理体系 |
答题的时候不要只写“算法不同”，这拿不到满分。我一般建议按三层来答：先说共性，两者都是硬件信任根，都提供度量、存储、报告三类能力；再写差异，算法体系和授权协议不同；最后补一句结论，二者可以共存于同一平台，实际项目中经常通过适配层统一调用。这种答法覆盖了大部分判分点，尤其是“为什么国内方案要基于国密算法重做一套”这类延伸追问。
动手验证是最好的记忆方式。要确认一台机器是否真的暴露了 TPM 设备，在 Linux 下先看内核导出的设备目录，再用 tpm2-tools 读取固定属性：
# 查看本机 TPM 设备是否挂载，出现 tpm0 目录说明驱动已识别 ls -l /sys/class/tpm/tpm0/ # 读取 TPM 固定属性：厂商信息、PCR 数量、支持的算法集合 tpm2_getcap properties-fixed # 查看当前可用的 PCR bank 与索引范围 tpm2_getcap handles-pcr第一条命令的路径来自内核安全子系统的设备模型，如果没有 tpm0，可能是固件里没开 TPM，也可能运行在未配置 vTPM 的虚拟机上；第二条命令的 properties-fixed 属性可以在不建立会话的情况下读取，适合用来判断平台能力；第三条命令的 handles-pcr 则告诉你当前 TPM 支持哪些算法 bank。线上测试里常有“某平台 PCR 是否有 SHA-1 bank”这种判断题，真机上跑一次就有答案，比死记规范里的默认配置靠谱得多。
2.2 PCR 扩展规则：测试里所有计算题的同一个套路
平台配置寄存器（PCR）是 TPM 内部最核心的状态载体，它保存的不是业务数据，而是一串度量结果的摘要值。PCR 的更新方式非常特殊，不是直接覆盖，而是链式扩展。扩展规则可以写成一行公式：PCR_new = H(PCR_old || data)。这里的 || 表示字节拼接，H 是当前 bank 指定的哈希算法。
用通俗的话解释：每次往 PCR 里“写入”新事件，TPM 会把当前值取出来，拼上新增事件的哈希，再整体做一次哈希，把结果存回去。这个设计的精妙之处在于，PCR 的最终值依赖所有历史事件的顺序。把两个事件的顺序颠倒，最终结果完全不同，所以 PCR 能记录平台启动过程的完整性轨迹。
这个规则直接决定了计算题的答案。真题里如果给你两个度量事件和一组初始值，让你算扩展后的 PCR 值，最常见的错误是直接对两个事件分别做哈希再拼接，或者把拼接顺序写成 data || PCR_old。我在模拟环境里验证 PCR 扩展时用的命令如下：
# 把字符串“boot_loader_measurement”作为引导事件摘要 digest=$(echo -n "boot_loader_measurement" | sha256sum | awk '{print $1}') # 扩展 0x01 号 PCR 的 sha256 bank tpm2_pcrextend 0x01:sha256=$digest # 读取扩展后的 PCR 值，与手动计算做对比 tpm2_pcrread 0x01:sha256digest 变量里存的是十六进制摘要；tpm2_pcrextend 的参数格式是PCR索引:算法=值，多个 bank 可以用逗号分隔；tpm2_pcrread 输出的是该 PCR 当前全部 bank 的值。第一次扩展时 PCR 的初始值由平台规范和 TPM 厂商决定，有的规范约定为全零，有的约定为特殊初值，线上测试为了简单通常会直接告诉你初值。注意不要在同一状态下反复扩展同一个值，否则结果会持续变化，这与真实启动过程每次都追加新事件是等价的。
2.3 信任链的“先度量后使用”：题目里藏着时序陷阱
有了信任根和 PCR，还需要一条把信任传递出去的路径，这就是信任链。在常见的 PC 平台中，信任链从 CRTM（核心信任根度量）开始，依次覆盖 BIOS 固件、引导加载程序、操作系统内核、关键应用。每一层在把控制权交给下一层之前，必须先度量下一层代码，并把度量值扩展进指定的 PCR，然后再跳转执行。
这个“先度量后使用”的顺序是整个信任链的生命线。如果先执行代码再做度量，恶意代码就有机会篡改度量逻辑或者伪造结果，后面拿着 PCR 报告去验证也没有意义。测试题里但凡画出启动流程图问你某一步为什么必须在另一步之前，本质上都在考这个时序原则。答题时我习惯点出两层意思：一是度量动作本身由 TPM 完成，不依赖被度量代码的配合；二是任何使用动作发生前必须已经有对应的 PCR 扩展，否则后续证明缺少依据。
要直观验证信任链是否真实工作，可以读取内核维护的事件日志。现代 Linux 系统会把 TPM 记录的启动事件暴露给用户态，命令如下：
# 读取二进制的启动度量子事件日志 sudo tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements输出里每一条记录都包含事件序号、PCR 索引、事件类型和事件摘要。观察时要注意字段之间的对应关系：PCR 索引告诉你这个事件扩展到了哪个寄存器，事件类型描述了被度量的对象，摘要值必须和 tpm2_pcrread 读到的最终 PCR 值存在链式关系。借助这种验证方法，你可以亲手把自己主机的启动链条走一遍，而不是只在纸上画箭头。
最后还要强调一条容易被忽略的边界：信任链解决的是“平台是否按照预期方式运行”的问题，它不解决“代码有没有漏洞”的问题。度量只是如实记录状态，判定动作由验证方策略引擎完成。答题时混用这两层概念，在最近几年的题目里基本都会被扣分。
3. 高频题型与破题思路：概念辨析、流程排序与原语计算的通用拆法
3.1 概念辨析题：可信、安全、可靠是三个层面
线上测试很喜欢在一道多选题里混杂“可信”“安全”“可靠”三个词，让考生判断某个场景属于哪个范畴。这三者在日常中文里经常混用，但在可信计算语境下边界很清晰：可信关注的是平台行为是否符合预期，安全关注的是能否抵御恶意攻击，可靠关注的是长时间运行下的容错能力。我用一张表来区分它们：
| 维度 | 可信 | 安全 | 可靠 |
|---|---|---|---|
| 核心问题 | 平台是否按预期方式运行 | 系统能否抵御攻击 | 系统能否持续无故障服务 |
| 典型手段 | 度量、存储、报告 | 漏洞修复、访问控制、防火墙 | 冗余、容错、故障恢复 |
| 判定依据 | PCR 值、基准值、签名报告 | 攻防对抗结果 | 统计指标与测试结果 |
| 常见误用 | “哈希校验过”=可信 | “没有漏洞”=安全 | “设备不宕机”=可靠 |
遇到“某程序完整性校验通过，因此它是可信程序”这种判断题，正确结论是“不严谨”。完整性校验只是可信度量的一环，一个完整可信判定还需要身份认证、策略比对和审计记录共同参与。答题时建议直接用三段式：先给出定义，再指出题干缺少哪些条件，最后补一句“度量不等于校验，校验不等于信任”。
这种题还有一个延伸版本：问“可信计算能否完全替代安全防护”。参考答案的得分点在于“不能替代，只能提供基础信任支撑”。可信计算解决的是平台是否被篡改的问题，而业务层的越权、注入、逻辑漏洞需要传统安全手段来覆盖。
3.2 流程排序题：远程证明的时序表与必答关键字
远程证明是可信计算测试中大题的常客，它要回答的问题是：一个远程验证方如何确认另一台平台处于可信状态。很多考生把远程证明和“把 PCR 值发过去”画等号，这在流程排序题里必扣分。完整的远程证明流程至少包含五个环节，且顺序不可颠倒：
- 挑战方生成一段随机数 nonce 并发送给被验证方；
- 被验证方从 TPM 读取指定 PCR 的当前值；
- 被验证方用 AIK 私钥对 nonce 和 PCR 值进行签名；
- 被验证方把签名结果和 PCR 值一并返回给挑战方；
- 挑战方校验 AIK 证书链，验证签名有效，确认 nonce 一致，再与基准值比对。
nonce 是整个流程的题眼。为什么必须在第一步生成随机数？因为如果 nonce 固定或可预测，攻击者可以提前构造一份合法的 PCR 签名报告，后续直接重放给验证方。验证方校验签名之前必须先确认接收到的 nonce 与自己在第一步发出的值完全一致，否则签名验得再漂亮也防不住重放。
答题时要把密钥层次写清楚：EK（背书密钥）是 TPM 出厂时固化的身份根，一般不做签名；AIK（平台身份认证密钥）是用于远程证明的签名密钥，由 EK 派生并经过证书背书。AIK 只负责给平台配置状态签名，不负责加密业务数据。验签阶段只需要校验三件事：AIK 证书链是否有效、签名是否由对应 AIK 产生、PCR 值是否与基准匹配。把这三句话写进答案，流程排序题基本就稳了。
3.3 原语计算题：用一个小脚本把 PCR 扩展算给你看
计算题在可信计算测试里占比不高，但一旦出现就是区分度最高的题。题干通常会给你两个度量事件和一组初始 PCR 值，要求你计算某个事件扩展之后的 PCR 值。这类题的核心就是 2.2 节里的公式 PCR_new = H(PCR_old || data)，写一段 Python 就能完全复现：
import hashlib def pcr_extend(current, data, algo="sha256"): """模拟 TPM 的 PCR 扩展：PCR_new = H(PCR_old || data)""" h = hashlib.new(algo) h.update(current + data) # 先拼旧值，再拼新事件 return h.digest() # 演示用初始值：32 字节全 0，物理 TPM 的初值由规范决定 initial = bytes(32) # 模拟引导加载程序的度量事件 boot_data = b"boot_loader_measurement" pcr_after_boot = pcr_extend(initial, boot_data) # 模拟操作系统内核的度量事件，传入上一次的扩展结果 kernel_data = b"kernel_measurement" pcr_after_kernel = pcr_extend(pcr_after_boot, kernel_data) print("after boot :", pcr_after_boot.hex()) print("after kernel:", pcr_after_kernel.hex()) # 验证顺序敏感性：交换两个事件后结果完全不同 reversed_value = pcr_extend(initial, kernel_data + boot_data) print("reversed :", reversed_value.hex())pcr_extend 函数的入参 current 是扩展前的旧 PCR 值，data 是当前事件的原始字节；函数体内先 update(current) 再 update(data)，严格保持公式里的拼接顺序。执行结果中的 after_kernel 用的是上一次的扩散结果，体现了链式依赖。最后输出 reversed 行的意义是验证 PCR 对事件顺序的高度敏感性，也解答了“为什么 PCR 能防篡改”的底层逻辑。
参数说明：algo 默认使用 sha256，与 TPM 2.0 最常见的 bank 保持一致；如果题目给的是 SM3，需要根据本地 OpenSSL 的算法支持把 algo 换成 "sm3"。考场上手算大型摘要不现实，但你可以把递推公式完整写出来，再代入两个事件值，明确写出 PCR_old 与 data 的拼接顺序。只要拼接顺序正确，判卷时至少能拿到一半以上的步骤分。
4. 可信计算测试里的避坑记录：四个高频翻车现场与排查路径
4.1 把“度量过”等同于“平台安全”
现象：做简答题时写“某组件已经过完整性度量，因此平台是安全的”，结果被扣分。
原因：度量的职责是记录事件，检验和判定属于验证方策略引擎。TPM 只是忠实地把测量值扩展进 PCR，它不知道也不关心这个值代表的状态是好是坏。把“度量过”等同于“安全通过”，混淆了度量层和判定层。
解决：回答问题拆成两层。先说被验证方做了什么度量、扩展到了哪个 PCR；再说验证方如何拿 PCR 值与可信基准比对，最终得出可信结论。结论只能写“符合预期的可信状态”，不要直接写“没有漏洞”。这套表述在任何一道 PCR 相关简答题里都通用。
4.2 重启之后 PCR 值“神秘”归零
现象：在实验环境里用 tpm2_pcrextend 扩展了 PCR，重启之后再用 tpm2_pcrread 读，发现值变成了初始值或者完全不连续。
原因：PCR 的复位语义在不同实现下不一致。物理 TPM 的某些 PCR 在平台复位后会被重置，而软件模拟 TPM（比如用 swtpm 搭建的虚拟设备）在重启后所有寄存器都会恢复初值。另外，部分模拟器只实现了规范要求的子集，PCR 持久化行为与真实固件不同。
解决：动手验证之前先确认后端是什么。Linux 下检查设备路径是 /dev/tpm0 还是 /dev/tpmrm0，后者可能是内核资源管理驱动，不代表硬件存在。如果环境里同时有模拟器和物理机两种后端，实验结论必须注明“本次结果基于软件模拟器”，并把预期值与实测值一起打印出来。这种环境差异我一开始也当玄学处理，后来发现八成是命令集合与复位语义没有对齐。
4.3 远程证明里漏掉 nonce，重放攻击也能通过
现象：写远程证明 Demo 时，把上一次捕获的签名报告原封不动地发给验证方，验证方竟然放行了。
原因：实现里只校验了 AIK 签名和 PCR 值，没有生成 nonce，也没有把 nonce 绑定进待签名的数据。验证方无法区分是本次新生成的报告还是被重放的历史报告。
解决：挑战方每次生成随机 nonce，被验证方把 nonce 与 PCR 值拼接后一起签名；验证方先比对 nonce 与本地存储的值一致，再验签名和基准值。线上测试如果出“请补全远程证明流程”，nonce 往往就是那个关键空位，写入答案时顺手标注“防重放”三个字能显著提高得分率。
4.4 模拟器上能跑的命令，物理机上报“不支持”
现象：tpm2_pcrextend 在 swtpm 模拟器里执行成功，换到物理机上却返回命令错误，报错码指向不支持的命令。
原因：PC 客户端规范允许平台实现命令子集，不同厂商固件的功能集合本来就有差异，模拟器往往实现了更完整的命令集，反而让你误以为所有 TPM 行为都是标准化的。
解决：报错时先执行 tpm2_getcap commands-fixed 查看平台实际支持的命令集合，再检查命令参数里的算法是否在当前 bank 列表中。如果物理机固件里没启用 TPM，还需要重启进固件设置打开相关开关。这个坑提醒我们：可信计算测试里的“标准答案”是理想模型，真实平台总是带约束的。
5. 用 tpm2-tools 在本地把答案验证一遍：最小复现清单
5.1 采集平台能力信息：先知道你的 TPM 支持什么
与其对着答案背参数，不如让你的 TPM 亲口告诉你答案。在测试环境里，我习惯先把平台能力完整采集一遍，再开始做扩展实验，命令如下：
# 列出所有可用的 PCR bank，确认算法覆盖范围 tpm2_getcap handles-pcr # 列出平台实际支持的命令集合，排查“命令不支持”问题 tpm2_getcap commands-fixed # 读取当前全部 PCR 值，保存为原始事实依据 tpm2_pcrreadhandles-pcr 的输出会告诉你当前平台有哪几个算法 bank，例如 sha1、sha256 同时存在；commands-fixed 的输出用于确认固件实现了哪些命令；pcrread 的原始值则可以作为实验的“前状态”，方便后续对比。
5.2 复算一次 PCR 扩展，把公式变成你手上的证据
最后一个技巧是把 2.2 节的理论公式用真机复算一遍，让 TPM 给你签一张“答案确认书”：
# 选择一个未被使用的 PCR 号，避免影响系统度量状态 pcrid=15 # 用固定字符串构造扩展事件摘要 digest=$(echo -n "online_test_check" | sha256sum | awk '{print $1}') # 执行 PCR 扩展 tpm2_pcrextend ${pcrid}:sha256=$digest # 读取扩展后的值，与实验前状态对比 tpm2_pcrread ${pcrid}:sha256PCR 号选 15 的原因是平台启动链通常只用前 8 个左右的寄存器，后面的寄存器在某些规范里供操作系统和应用使用，测试时干扰最小。如果 tpm2_pcrextend 返回错误，优先检查该 PCR 是否被固件锁定，以及当前用户是否有权限访问 TPM 设备节点。
我第一次备考时只在文档里画箭头，觉得 PCR 扩展公式简单到不需要验证，直到某次把 PCR_old 和 data 的拼接顺序写反，才发现自己一直背的是错误版本。那次教训之后我养成了习惯：凡是题目里出现算法与流程，先到本地把命令跑通，再回来看参考答案，用 TPM 实测的输出反向校准自己的理解。希望这些方法也能让你的可信计算测试备考少走几步弯路。
本文还有配套的精品资源，点击获取
