简介华中科技大学可信计算线上测试题目及答案文档面向准备课程线上测试、期末复习及网络安全方向入门的学习者聚焦可信计算核心概念与常见考点的问答梳理。压缩包共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背书密钥标识平台身份用于生成 AIK、确立所有权不可迁移2048 位 RSA每平台唯一不作数据加密与常规签名AIK身份认证密钥对 PCR 值等 TPM 数据签名证明平台身份与配置不可迁移每用户可多个生成通常需可信第三方参与SRK存储根密钥保护其下所有其他密钥存储可信根不可迁移每 TPM 唯一生命周期内不以明文或密文离开 TPM这张表背后有个容易被追问的逻辑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 选择是否与策略一致、哈希银行是否匹配固件实际使用、授权与权限是否满足。第二个动作是概念对照校验。用一张小表把容易混的成对概念摆在一起自查比反复读段落有效。易混对判别要点静态可信根 vs 动态可信根前者只管装载时、链子长、需重启证明后者移除 BIOS 等不可控源头、新增 PCR 防重启攻击EK vs AIKEK 标识平台、生成 AIKAIK 签 PCR 值证明环境配置可迁移 vs 不可迁移不可迁移私钥不出 TPM只能单向转为可迁移本地报告 vs 远程报告本地靠 Unseal 自证状态远程靠 AIK 签名加日志重算比对PCR 回滚 vs 密钥回滚前者要回滚保一致后者不回滚保数据与防重放第三个动作是瑕疵标注。这份材料里第 23 题的答案与题目明显错位属于整理时串行遇到这类地方不要顺着抄回到第 24 至 26 题重建逻辑并在自己的笔记里标红。血泪经验有两条其一凡是涉及“能不能迁移”“能不能加密”的判断必须回到密钥用途本身推硬记结论在变形题前必翻车其二凡是涉及 PCR 状态的题先问“机器重启过没有”PCR-Reset 只在重启或断电时发生这条前提错了后面全错。从那以后我每次带人过可信计算都强制先跑一遍 PCR 读取—扩展—再读取再看一次 Seal 的成功与失败对比最后才翻开题库对答案。顺序反了记住的只是字符串顺序对了题目怎么变形都能推。希望帮到你。本文还有配套的精品资源点击获取
简介华中科技大学可信计算线上测试题目及答案文档面向准备课程线上测试、期末复习及网络安全方向入门的学习者聚焦可信计算核心概念与常见考点的问答梳理。压缩包共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背书密钥标识平台身份用于生成 AIK、确立所有权不可迁移2048 位 RSA每平台唯一不作数据加密与常规签名AIK身份认证密钥对 PCR 值等 TPM 数据签名证明平台身份与配置不可迁移每用户可多个生成通常需可信第三方参与SRK存储根密钥保护其下所有其他密钥存储可信根不可迁移每 TPM 唯一生命周期内不以明文或密文离开 TPM这张表背后有个容易被追问的逻辑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 选择是否与策略一致、哈希银行是否匹配固件实际使用、授权与权限是否满足。第二个动作是概念对照校验。用一张小表把容易混的成对概念摆在一起自查比反复读段落有效。易混对判别要点静态可信根 vs 动态可信根前者只管装载时、链子长、需重启证明后者移除 BIOS 等不可控源头、新增 PCR 防重启攻击EK vs AIKEK 标识平台、生成 AIKAIK 签 PCR 值证明环境配置可迁移 vs 不可迁移不可迁移私钥不出 TPM只能单向转为可迁移本地报告 vs 远程报告本地靠 Unseal 自证状态远程靠 AIK 签名加日志重算比对PCR 回滚 vs 密钥回滚前者要回滚保一致后者不回滚保数据与防重放第三个动作是瑕疵标注。这份材料里第 23 题的答案与题目明显错位属于整理时串行遇到这类地方不要顺着抄回到第 24 至 26 题重建逻辑并在自己的笔记里标红。血泪经验有两条其一凡是涉及“能不能迁移”“能不能加密”的判断必须回到密钥用途本身推硬记结论在变形题前必翻车其二凡是涉及 PCR 状态的题先问“机器重启过没有”PCR-Reset 只在重启或断电时发生这条前提错了后面全错。从那以后我每次带人过可信计算都强制先跑一遍 PCR 读取—扩展—再读取再看一次 Seal 的成功与失败对比最后才翻开题库对答案。顺序反了记住的只是字符串顺序对了题目怎么变形都能推。希望帮到你。本文还有配套的精品资源点击获取
