6

我被要求使用 TPM 为具有 TPM 芯片的 x86_64 设备实施相当于许可证加密狗的内容。本质上，所需要的是确保为设备发布的软件只能在设备本身上运行，这样如果软件被迁移到虚拟机或其他硬件，它将拒绝运行。

我不希望该解决方案能够抵抗逆向工程，而是一种典型的“加密狗”类型的解决方案，它将阻碍普通用户并让企业客户保持诚实。

我已经成功构建并包含了 TPM 模块以及TrouSerS和 openssl-tpm-engine 代码——我可以成功获得 TPM 的所有权，但除此之外，可用的文档并没有完全涵盖这个用例——或者如果到目前为止，我一直无法找到一个简单的英文解决方案。

如果可能的话，我宁愿依赖存储在 TPM 中的私钥的秘密性质，而不是利用平台组件哈希（硬盘驱动器可能会死掉，CPU 可能会被更换等。我宁愿在客户的一方，这样系统不会在例行硬件升级后变得无法使用。

同样，理想情况下，我怀疑可以设计此解决方案，以便在制造过程中收集每个设备的公钥并将其添加到签名钥匙串中，以便可以根据每个设备可能存储在 TPM 中的单个密钥对软件进行签名，而不是要求对软件进行多次签名？我在这里可能弄错了，但必须有一些满足平台身份验证方法的批量方法，否则它似乎很难扩展。

4

1 回答 1

5

如果设备由您设置，您可以遵循以下方案：

A. 发货前：

  1. 取得所有权 - 还创建一个存储根密钥 (SRK)
  2. 创建不可迁移的签名密钥
  3. 将打包的密钥存储在平台上的可信密钥库中
  4. 将创建的密钥的公钥存储在 DB/file-system/what-so-ever 中的某处

B. 准备申请：

  1. 您必须将公钥与应用程序的二进制文件一起发送
  2. 我不会将公钥编译为二进制文件，而是更喜欢使用类似于 CA 系统的东西，其中只编译根 CA 公钥。然后可以将 TPM 签名密钥的公共部分作为证书文件提供。这可以防止单独为每个设备编译二进制文件。

C. 启动应用程序时：

  1. 创建一个随机数
  2. 让 TPM 签署 NONCE
  3. 阅读证书并进行验证
  4. 从已验证的证书中提取公钥
  5. 使用获取的公钥验证 TPM 返回的签名（当然还要检查签名数据是否等于 NONCE）
  6. 如果签名有效 =>你很高兴

注意 1：从理论上讲，这种解决方案是不安全的，因为可以修补二进制文件。你知道，所以这应该有效。

注意 2：如果设备不是您自己设置的，则您不能信任客户可能给您的公钥。

编辑1：更准确地解释某些观点

@A.2：由于我使用jtt & jTSS而不是 TrouSerS 我不知道 TrouSerS 包中是否包含用于创建密钥的命令行工具。但我确信它提供了适当的 API 来执行此操作。无论如何，例如 jtt 有一个执行create_key此操作的命令。当您使用此工具时，您会遇到 jTSS 和 TrouSerS 的密钥库与 AFAIK 不兼容的问题。

@A.3：不，除了存储根密钥 (SRk) 和背书密钥 (EK) 之外，TPM 中没有存储任何密钥。但是 TPM 保证属于 TPM 的密钥的任何私有部分都不会以未加密的格式出现在 TPM 之外。因此，您有一个密钥库，它以某种方式由包含加密密钥材料的可信软件堆栈（TSS -> jTSS，TrouSerS）管理。TSS 还负责在将它们用于签名操作之前在 TPM 中加载正确的密钥。

@C*：应用程序端的加密部分非常标准。我不知道你在这方面的知识如何。对于 TPM 部分，TSS 再次提供高级 API。我不知道是否有用于使用 TPM 进行签名的现有命令行工具。

于 2012-02-03T18:35:11.807 回答