远程证明

范围和主要用例

• 许多评论者强调，这篇文章讨论的是基础设施安全，而不是消费级产品。
• 远程证明被描述为大型组织中的标准做法，用于工作负载认证、基于 mTLS 的基础设施、VPN 访问控制和零信任架构。
• 它用于在授予访问权限之前，确保企业或嵌入式设备上安装了特定的软件版本和安全工具。

安全收益

• 被视为抵御 rootkit、引导加载程序恶意软件和配置错误系统的强力防线。
• 基于 TPM 的证明为可信启动、不可变文件系统、签名更新以及叠加 EDR 等其他控制措施提供了“基石”。
• 也有人提到一些现实中的成功用例：企业设备群、医疗保健网络，以及安全消息系统中的联系人发现保护。

消费端、自由与权力方面的担忧

• 强烈担心同样的机制会锁定消费级设备、强制 DRM，并加深企业控制（例如流媒体、智能手机、浏览器）。
• 担忧未来互联网接入需要通过政府或供应商批准、并通过证明的设备，从而阻止替代操作系统、广告拦截器和独立软件。
• 这被视为对自由软件、竞争（例如禁止 Firefox/WINE 类层）、可修复权和设备再利用的重大长期威胁；也担心法律会强制要求 TPM/远程证明。

技术限制与批评

• 硬件漏洞、SGX 密钥提取以及 TPM 漏洞被用来说明“永远可信”的保证并不成立；与软件不同，存在缺陷的硬件很难修补。
• 证明只能说明“软件与某个参考值一致”，并不能证明它是安全的或没有 bug。
• 有人提出疑问：如何安全地将 TPM 绑定到某一具体物理设备，以及如何防御中间人/代理设备攻击，尤其是在通过简单总线连接的离散 TPM 场景下。
• 还有人指出，服务器端 TPM 和当前 Linux 工具链还不成熟或难以使用；文档和开源实现也被认为不足。

替代方案与用户可控模型

• 一些人认为，只要密钥归用户/企业所有，而不是由制造商控制，证明就是可接受甚至有益的。
• 例子包括 GrapheneOS 风格的证明，以及将 TPM 用于个人磁盘加密或 SSH 密钥。
• 总体共识是：它很强大，但也是一把双刃剑；治理方式和密钥所有权决定它是在保护用户，还是在损害用户。