在 TPM 中签署 TLS 握手：守护机器身份
Signing TLS handshakes inside a TPM
我在做机密虚拟机的远程证明工作时发现，将私钥存储在文件中并非真正的机器身份，而是一张随时可能被窃取的可转移凭证。一旦攻击者获得读取权限，他们就能通过内存转储或核心文件获取密钥，从而冒充该机器访问所有受信任的服务。为了解决这个问题，我利用 TPM 在内部完成 TLS 握手签名，确保私钥永远不离开硬件，且无需额外凭证即可访问。这种方法不仅避免了将密钥暴露在内存中，还消除了对远程 KMS 的依赖，让机器身份真正不可窃取。
存储在文件中的密钥并非真正的机器身份，它只是一张恰好存放在机器上的凭证，任何读取它的人都能在任何地方冒充这台机器。
HN 评论区
46- bob1029
我觉得这取决于你的威胁模型。
TPM 能提供更强的保证，证明某台机器确实拥有某个密钥，但专用 HSM 在提取密钥材料方面可能更难被攻破。
TPM 位于机器内部是一把双刃剑。一方面，它让远程证明（attestation）变得可行；但另一方面，这个安全黑盒现在与使用它的机器处于同一个物理域内。当这些系统共存时，侧信道提取的风险会急剧上升。相比之下，通过网络对 HSM 进行探测要难得多。
- KaiserPro
在我工作的公司，我需要将一台机器通过未知渠道运输，并确信它没有被动过手脚。
我的威胁模型是：某个技术工程师出于某种原因更换了硬盘，或者有人声称这台机器“不一样”。（没有国家级势力的介入）
机器镜像完成后，它会连接我们的中央配置服务器，获取主机名并交换密钥，这些密钥会被嵌入到 TPM 中。
一旦机器发货并启动，它就会进行签到并签署挑战（challenge）。中央 API 上的任何操作都可能触发挑战。每台机器至少每小时被证明一次。
我不确定整个方案有多“安全”，但看起来是有效的。
- duk3luk3
听起来挺有意思；可惜我们得到的只是由 LLM 生成的文字，而不是作者本人的任何见解。
- ted_dunning
TAS 很好地建立了远程证明与密钥之间的关联。TAS 提供证书，而 Spiffe 则要求此类证书来颁发 SVID，该 SVID 用作 mTLS 的证书。
这意味着信任根通过软件（TAS）贯穿始终，该软件已验证你的证明证据与实时策略相匹配。这无需对 Spiffe 做任何修改即可实现。
这并不能完全满足你将密钥保持在内存之外的要求，因为生成的 SVID 会在内存中保留几分钟，但这确实满足了大多数人的需求。
- yusufmotiwala
这不是一个已经被广泛讨论的问题吗？而且并不特定于 TPM。
我们遇到过类似的问题（我们使用 OpenSSL）。OpenSSL 确实有 OPENSSL_secure_malloc()，可以防止敏感内存被转储。但问题是，并非所有路径都使用了安全分配器。例如，这个问题：https://github.com/openssl/openssl/issues/27603
不确定 OpenSSL 4.x 中是否有所改变，但这确实是一个值得追求的特性。