现代流程和可信平台模块支持的功能之一是“动态信任链”（也称为首字母缩略词 DRTM，用于动态信任测量根）。这允许在隔离的执行环境中加载关键软件，在该环境中可以保护它免受系统上其他软件的影响。
该功能通过 SENTER 指令（在 Intel 芯片上）或 SKINIT 指令（在 AMD 上）启动。在英特尔，这是英特尔可信执行技术(TXT) 的一部分。我有时听说过这种名为“延迟启动”的技术：例如，如果您想在系统已经运行时启动虚拟机管理程序或其他关键软件，那么您可以以一种受信任的方式对虚拟机管理程序进行“延迟启动” /软件模块。
DRTM/“延迟启动”提供隔离（使其他软件组件无法篡改以这种方式启动的可信模块的代码或数据）。它还提供密封存储，以便受信模块可以以加密形式存储数据，其中解密密钥将被释放给受信模块的未来调用，而不是任何其他软件组件。
“动态信任链”是否支持远程证明？它是否提供了向第三方证明以这种方式启动的受信任模块的代码的方法？
“动态信任链”是否支持远程证明？
当在内存区域上使用动态启动时，TPM 中的特定 PCR 索引用于记录该软件的状态。如果这些 PCR 索引包含在挑战者的证明请求中，则该软件将在响应中得到证明。这些 PCR 索引为 17-22，如TCG 的 BIOS 规范的 PCClient 实施中所指定，请参见第 30 页。
它是否提供了向第三方证明以这种方式启动的受信任模块的代码的方法？
英特尔在 Linux 上实现的 TXT 支持 tboot 遗漏了一个细节，他们有望很快修复。tboot 不会公开事件日志，它会显示作为 TXT 启动的一部分，哪些软件被扩展为 TPM PCR。这是远程挑战者证明动态启动 PCR 的要求，因此目前还没有完全支持。从技术上讲，您可以找到事件日志，但它不以 TCG 标准格式提供，因此所有用于解析它的常见可信计算工具都无法在 ATM 上运行。
是的。
您可以将这两个功能视为实际上是两个独立的东西，即 DRTM（用于测量的动态信任根）只是扩展 PCR 值（17-22）（如 SRTM）的另一种方式，而远程证明将采用您希望的任何 PCR使用（很像 SEAL 操作）。这些功能之间没有依赖关系或真正的联系。
如果您想了解更多关于 DRTM 和远程认证的内部细节，我强烈建议您阅读 Flicker 的项目论文。Flicker 使用 DRTM 向第 3 方证明执行了特定的 D-MLE（动态测量启动环境）。短篇：http ://www.cs.unc.edu/~reiter/papers/2007/SP.pdf ，长篇：https ://web.archive.org/web/20151011011703/http://research.microsoft .com/pubs/138301/eurosys053-mccune-cr.pdf。
ps 长篇大论似乎有一个错误，他们说 SRK（存储根密钥）是由制造商创建的，而实际上它是由平台所有者在他创建时创建的take ownership。希望他们没有使用 SRK 来证明它是真实/物理的 TPM。只有 EK（背书密钥）才能证明 TPM 是真实的。
如果没有与远程服务的某种类型的预共享密钥或 TPM 拥有的可靠建立的私钥，我不确定它怎么可能。我认为问题在于第三方无法知道是 TPM 执行代码，而不是修改后的变体以在不受保护的空间中运行。如果 TPM 拥有来自第三方的可信私钥，那么第三方就有可能向 TPM 发出挑战，TPM 只能在签名的、受信任的过程中响应，从而实现远程证明目标，但我没有看到如何建立受信任的私钥。
请注意，我纯粹是根据提供的加密系统的描述和我对 TPM 的一般知识来回答的。我对受信任的执行支持什么没有任何额外的具体知识，但我认为这样做的主要目的是为了 DRM 和代码保护目的，而不是远程证明，尽管它肯定是对它的一个很好的扩展。
从 CERT 中找到了一份更详细的文件。关于 TPM 能力的 CERT 文档。