TPM 2.0：避免每次使用的密钥（重新）生成开销答案

【问题标题】：TPM 2.0: Avoiding key (re-)generation overhead on every useTPM 2.0：避免每次使用的密钥（重新）生成开销
【发布时间】：2020-05-18 00:58:41
【问题描述】：

我正在开发一个应用程序，该应用程序需要在 TPM 中生成一个 RSA 密钥以用于签名操作。公共部分向后端注册一次，然后私有部分重复用于身份验证。这种使用将跨越机器关闭/重启周期。在我的层次结构的根部，我有一个使用 CreatePrimary() 生成的 SRK 密钥（即基于这样的模板）。我知道我可以为后续会话重新生成此密钥（通过将随机输入保存在程序数据中）。程序的实际签名密钥也可以以加密形式保存，然后在重新生成 SRK 密钥后使用 Load 函数加载。

所以功能上一切正常，但我想避免密钥重新生成开销。我在这里有什么选择？

1) 据我所知（但如果我错了，请更正）一个 ContextSave 将无法在电源循环后存活（文档说它会在电源重置期间重置）。请确认是否可以使用 ContextSave。

2) 有一个名为 EvictControl 的函数可以完成这项工作。但它涉及有限的 NV 内存（因此，如果应用程序“忘记”这样的返回句柄，则在不重置整个 TPM 的情况下，永远无法释放内存）并且会磨损 TPM（仅在初始注册时）。这样合适吗？

3) 也许我还没有找到第三种选择？是否有可以使用的“默认”SRK，这样我就不必（重新）生成一个？

如果没有其他方法，我打算使用此功能，但我想知道是否有其他选择。我不明白为什么没有 ExportPrimary()/ImportPrimary() 之类的可以导出可以稍后导入的主文件，而无需触及 NV 存储。导出将在 NV 存储中存储在 TPM 内的密钥下完成（仅在 TPM 清除等时重新生成），因此具有与 EvictControl 相同的安全级别，但不会占用每个生成的密钥的 NV 存储。

【问题讨论】：

标签： tpm

【解决方案1】：

根据我对问题的阅读，您似乎在每次上电时都在重新生成 SRK。你真的不应该这样做，SRK 应该是一个持久密钥，请参阅https://trustedcomputinggroup.org/wp-content/uploads/TCG-TPM-v2.0-Provisioning-Guidance-Published-v1r1.pdf。

至于如何使其持久化，您似乎已经知道如何做到这一点，只需使用 EvictControl。

【讨论】：

有共享和专用 SRK 的概念。在我的用例中，使用共享 SRK 并非没有问题（因为设备可能会或可能不会预先配置，所以我不知道是否有一个写入 NV，我宁愿自己不写）。因此，专用 SRK 是唯一的选择，但这似乎无法将 SRK 保留在 TPM 之外（即使这在技术上是可行的），而只能在 NV 中的 TPM 本身上保留。在我看来，规范中的共享 SRK 应该是强制性的（也在 TPM clear 上清除）。
听起来您有一点流程问题...如果您必须同时处理已配置和未配置的 TPM，那么要涵盖的用例的数量和复杂性将会迅速增长。祝你好运！
好吧，这可能是一个愚蠢的问题：但我是否可以在实践中假设（即在具有 TPM 2.0 的 Windows PC 上）那里已经存在 SRK？我不确定配置是否已完成，例如启用 Bitlocker，或者只要 TPM 开启，SRK 就一直存在（无需用户执行任何操作）？
好吧，如果您清除 TPM，SRK 将不存在。要创建专用的 SRK，您将需要层次结构身份验证，因此必须进行某种级别的配置......我不知道 BitLocker 究竟做了什么，但我假设它在未配置的芯片上做了一些最低限度的配置，例如： docs.microsoft.com/en-us/powershell/module/…