云中的 HSM 和 TPM 安全性 -现实攻击和下一代防御

大家读完觉得有帮助记得关注和点赞！！！

随着组织迅速迁移到云，加密密钥管理的安全性已成为日益关注的问题。硬件安全模块 （HSM） 和可信平台模块 （TPM） 传统上被视为保护加密密钥和数字信任的黄金标准，但越来越受到云原生威胁的挑战。

现实世界的违规行为暴露了云部署中的弱点，包括配置错误、API 滥用和权限升级，使攻击者能够访问敏感的密钥材料并绕过保护。这些事件表明，虽然硬件仍然安全，但周围的云生态系统引入了系统性漏洞。

本文分析了涉及 HSM 和 TPM 的显着安全故障，确定了常见的攻击媒介，并质疑了关于其在分布式环境中有效性的长期假设。我们探索了机密计算、后量子密码学和去中心化密钥管理等替代方法。

我们的研究结果强调，虽然 HSM 和 TPM 仍然发挥作用，但现代云安全需要更具适应性、分层的架构。通过评估当前的弱点和新兴模型，这项研究为云架构师和安全工程师提供了在不断变化的威胁形势中加强加密信任的策略。

关键字：硬件安全模块 （HSM）、可信平台模块 （TPM）、机密计算、虚拟 TPM （vTPM）、英特尔 SGX、AMD SEV-SNP、后量子密码学 （PQC）、多方计算 （MPC）、密钥管理、云安全、侧信道攻击、IAM 错误配置

1介绍

加密密钥的安全性是现代网络安全的支柱[1].组织依靠加密来保护敏感数据、确保安全交易并维护数字信任。但是，加密的有效性完全取决于加密密钥本身的安全性。如果攻击者获得了对这些密钥的访问权限，即使是最强的加密也变得毫无用处。

为了降低这种风险，HSM[2]TPM 作为可信硬件解决方案引入，以高度安全的方式生成、存储和管理加密密钥。HSM 是专用硬件设备，旨在保护加密密钥免受外部威胁[3]，而 TPM 在计算设备内的硬件级别提供内置加密功能。这些技术已在云基础设施中广泛采用，用于保护静态数据、加密通信通道和验证关键交易[4].

然而，云计算的兴起带来了新的安全挑战，而传统的 HSM 和 TPM 从未设计过这些挑战来解决这些挑战[5].

1.1为什么 HSM 和 TPM 在云安全中失败？

在传统的本地环境中，组织可以完全控制其硬件安全模块。他们可以物理限制访问，执行严格的安全策略，并在需要时维护气隙基础设施。然而，云环境引入了一种完全不同的威胁模型——传统的 HSM 和 TPM 架构从未设计过能够处理的威胁模型。

与本地部署不同，基于云的 HSM 和 TPM 面临着独特的挑战，包括：

API 驱动的攻击[6]– 基于云的 HSM 公开用于远程管理和关键作的 API。攻击者利用弱 API 身份验证和错误配置的权限来远程提取加密密钥。权限提升漏洞 – 云环境中错误配置的角色和权限使攻击者能够获得对 HSM 和 TPM 的管理访问权限，从而完全绕过安全控制。多租户风险 – 云提供商在共享基础设施上托管多个客户端。一个租户的 HSM 实例中的漏洞可能会将加密密钥暴露给其他租户。[5]

这些挑战导致了多起备受瞩目的安全事件。例如，2023 年，一家大型云提供商遭遇了安全漏洞，攻击者利用了基于云的 HSM 实施中的 API 漏洞，使他们能够提取敏感的加密密钥。此次泄露不仅损害了加密数据，还破坏了对云提供商安全框架的信任。

1.2本研究范围

本文旨在通过以下方式批判性地分析 HSM 和 TPM 在云环境中的不足：

检查暴露了基于云的 HSM 和 TPM 实现中弱点的真实世界攻击[7][8].识别关键漏洞，例如配置错误、API 风险和权限提升缺陷[6].探索机密计算等新兴安全替代方案[9]、后量子密码学[10]，以及去中心化的密钥管理[11]以确定它们是否为云中的加密安全提供了更有效的方法。

1.3关键研究问题

为了应对这些挑战，本研究旨在回答以下关键问题：

为什么 HSM 和 TPM 在云环境中失败？哪些现实世界的攻击暴露了他们的弱点？基于云的加密密钥管理有更好的替代方案吗？

通过回答这些问题，本文为寻求增强加密安全态势的云架构师、安全专业人员和组织提供了可作的见解。最终，这项研究有助于云安全策略的持续发展，确保加密仍然是一种值得信赖的保障措施，而不是单点故障。

2云环境中 HSM 和 TPM 的背景和安全故障

2.1HSM 和 TPM 在云安全中的作用

硬件安全模块 （HSM） 和可信平台模块 （TPM） 充当加密作的专用硬件守护者[12].HSM 为加密、解密和密钥存储提供隔离环境，而 TPM 则为云标识系统建立基于硬件的信任。主要云提供商通过以下方式实现这些功能：

AWS CloudHSMAzure Key Vault（HSM 支持）谷歌云 HSM云实例的虚拟化 TPM

这些模块通常被视为信任锚，但它们在云原生架构中的有效性越来越受到审查。

2.2云如何打破传统安全模式

虽然 HSM 和 TPM 是为严格控制的本地基础设施而设计的，但将这些技术迁移到云中引入了完全不同的威胁模型[5].本地安全依赖于物理控制，但云环境引入了严重漏洞：

第三方信任依赖关系API 驱动的攻击面权限管理复杂性失去物理隔离

2.3现实世界的安全故障

以下案例研究说明了云原生弱点（而不是加密算法中的缺陷）如何导致涉及 HSM、TPM 或密钥管理系统的重大安全漏洞。

2.3.1案例研究：第一资本 AWS 泄露事件（2019 年）

IAM 配置错误损害云加密安全的最广泛报道的例子之一是 2019 年第一资本违规事件[13].攻击者 Paige Thompson 利用了 Capital One 的 Web 应用程序防火墙 （WAF） 配置中的漏洞，使用服务器端请求伪造 （SSRF） 攻击来查询 AWS EC2 实例元数据服务[14].这使她能够检索与实例分配的角色关联的临时 IAM 凭证。

这些凭证不仅提供对包含敏感数据的 Amazon S3 存储桶的访问，还可能提供对 AWS Key Management Service （KMS） 和 CloudHSM作的访问权限，具体取决于附加权限的范围。如果包含解密或密钥导出权限，攻击者可以使用合法通道访问加密密钥或解密数据，而无需绕过加密算法[15].

这一事件说明了一个关键点：如果周围的身份和访问管理 （IAM） 框架配置不当，那么 HSM 和加密模块的强度就无关紧要。云环境中有效的密钥安全不仅取决于硬件，还取决于最低权限访问控制的实施和密钥管理作的正确分段[16].

2.3.2案例研究：Azure Cosmos DB ChaosDB 漏洞 （2021）

2021 年 8 月，Wiz 的安全研究人员披露了 Azure Cosmos DB 中的一个严重漏洞，称为 ChaosDB，该漏洞展示了云配置错误如何在不直接损害加密算法的情况下破坏加密密钥保护[8].

该漏洞源自 Jupyter Notebook 功能，该功能默认为 2021 年 2 月开始为新 Cosmos DB 用户启用。通过服务器端请求伪造 （SSRF） 攻击和笔记本容器内的权限提升，研究人员能够访问底层 Azure 基础结构并检索用于内部服务的访问令牌和证书[17].

这允许跨区域对 Cosmos DB 实例进行完全管理访问，包括通过内部管理 API 提取主读写密钥的能力，从而有效地绕过客户帐户之间的任何逻辑边界。尽管除了研究人员的概念验证之外，没有证据表明存在利用，但 Microsoft 在全球范围内禁用了笔记本电脑功能，并建议客户立即重新生成他们的主密钥。

ChaosDB 事件强调，即使数据已加密，对加密密钥或密钥授予凭据（例如在托管服务（如 KMS 或 HSM 支持的角色）中存储或处理的凭据）的访问也可能使加密变得毫无意义。它强调了深度防御策略的重要性，包括网络隔离（例如专用链接）、最低权限 IAM 配置、持续密钥轮换和审计日志记录[18].

此案例凸显了多租户云平台中信任边界的脆弱性，以及甚至将零信任原则应用于第一方服务集成的必要性。

2.3.3攻击链可视化

攻击路径利用了默认启用的功能，从 SSRF 发展到凭据盗窃再到完全数据库泄露 - 如下所述：

已启用错误配置的笔记本

元数据服务询

检索到的临时 IAM 凭证

访问的 Cosmos DB API

通过管理端点提取的主键

对加密数据的完全管理员访问权限

图 1：ChaosDB 中的攻击路径：从 SSRF 到全密钥泄露

2.4云安全故障的行业趋势

多份行业报告强调，云复杂性与组织保护云的准备程度之间日益不匹配。根据 Sonatype 的 2021 年云安全报告，83% 的受访者认为他们的组织因云配置错误而面临严重的泄露风险，36% 的受访者在过去一年内已经经历过严重的泄漏或泄露[19].IAM 配置错误被认为是最常见的云安全故障，紧随其后的是不安全的对象存储权限和禁用的加密设置。

2021 年 Qualys 云安全报告强化了这一说法，64% 的网络安全专业人员将数据丢失或泄露列为他们最关心的问题，46% 的网络安全专业人员表示意外暴露凭据[20].可见性差距、工具不足和缺乏训练有素的人员被认为是改善云安全态势的主要障碍。

Palo Alto Networks 的 2024 年云原生安全状况报告进一步扩大了范围，显示 71% 的组织因仓促部署而面临违规行为，91% 的组织在工具蔓延中苦苦挣扎，61% 的组织对针对云工作负载的人工智能威胁表示担忧[21].这些统计数据表明，组织系统性地无法管理权限边界、验证基础设施配置以及跨云平台实施一致的策略控制。

2025 年 Checkpoint 报告进一步证实了这些系统性风险，显示 61% 的受访组织在过去一年中经历过云安全事件，其中 21% 的攻击者未经授权访问敏感数据，这凸显了界面配置错误和缺乏访问控制的现实后果[22].该研究还确定，API 滥用和运行时可见性不足是凭据滥用和跨云工作负载横向移动的关键载体。

在所有报告中，出现了一个共同的结论：即使是强大的加密基础设施（例如 HSM 和 TPM），如果叠加在配置错误、治理不善或过于复杂的云环境中，也无法防止数据泄露。不安全的接口、多云碎片化和缺乏熟练人员的结合使得加密密钥管理变得脆弱，并且越来越难以大规模保护。

表1：常见的基于云的 HSM/TPM 故障模式

故障类别 对加密安全的影响配置错误（IAM、防火墙、存储） 绕过密钥隔离并允许未经授权访问加密数据API 漏洞利用 允许远程参与者调用敏感作，例如密钥导出或删除权限提升 授予对加密模块和密钥材料的管理访问权限多租户风险 支持受保护加密资产的跨租户泄漏或推断

3比较分析：云安全中的 HSM 与 TPM

3.1HSM：强大的硬件，软目标

硬件安全模块 （HSM） 充当用于加密密钥存储和作的专用硬件支持保管库。AWS CloudHSM、Azure Key Vault（HSM 支持）和 Google Cloud KMS 等云实施依赖于这些模块来实施安全加密、解密和密钥生命周期管理。

虽然 HSM 在硬件级别提供了高度保证，但当集成到复杂的云环境中时，其安全保证可能会受到损害。特别是，API 滥用、凭据泄露和不安全的开发管道为攻击者提供了破坏加密工作流程的间接途径。

供应链和 API 漏洞利用：Wiz Security 报告重点介绍了攻击者利用暴露的 CI/CD 凭据和机密（包括在环境变量、构建工件或 .bash_history 文件中找到的凭据和机密）来冒充合法工作负载并访问 HSM 支持的接口的真实案例[7].这些技术不是通过破坏 HSM 来绕过加密强制执行，而是通过滥用其可信 API 表面来绕过加密强制执行。

举个例子——谷歌的内部知识管理系统：相比之下，谷歌的内部 KMS，正如他们在“地球规模的秘密”演讲中所讨论的那样，强调强大的职责分离、信封加密、区域级隔离和透明的可审计性[23].这强调了将 HSM 的使用与严格的作控制相结合的必要性，而不是仅仅依赖硬件保证。

3.2TPM：信任根，但在云中较弱

受信任的平台模块 （TPM） 提供基于硬件的加密保证，例如证明、测量启动和磁盘加密。在云环境中，这些通常部署为附加到虚拟机或机密计算实例的虚拟 TPM （vTPM）。

虚拟机管理程序级威胁：“Heckler”研究表明，恶意虚拟机管理程序可以将精心设计的中断注入在 AMD SEV-SNP 或 Intel TDX 下运行的虚拟机中，从而破坏可信执行环境的隔离保证，从而损害受 vTPM 保护的工作负载[24].虽然物理 TPM 芯片可能保持安全，但依赖于虚拟机监控程序信任的虚拟实例会公开。

vTPM 实施风险：早期关于 SvTPM 的工作还发现，如果没有强大的 TEE 支持，软件模拟 TPM 将面临严重的隔离和性能问题[25].这可能会导致数据泄露、完整性失败或对证明记录的不当访问，从而有效地削弱 TPM 支持的信任的核心优势。

表2：HSM 与 TPM/vTPM 安全比较

特征 HSM（云）TPM/vTPM核心力量 用于安全密钥管理的专用硬件硬件根证明、磁盘加密、安全启动云漏洞 API 滥用、CI/CD 令牌泄露、供应链泄露虚拟机管理程序权限、弱 vTPM 隔离、虚拟化风险真实世界事件 用于访问 HSM API 的机密[7]虚拟机管理程序注入破坏了 vTPM 的信任[24]运营挑战 需要复杂的访问控制和监控取决于 TEE/虚拟机管理程序的完整性;难以审核关键外卖 硬件安全;但 API 和作是薄弱环节理论上是合理的;但云抽象层会创建攻击面

3.3结论：生态系统故障，而不是硬件缺陷

这种比较分析表明，虽然 HSM 和 TPM 提供了强大的加密基础，但它们在云环境中的有效性受到周围生态系统漏洞的影响。

攻击者不需要破解加密或篡改安全芯片，相反，他们利用范围不当的 IAM 权限、不安全的 API 或受损的虚拟机管理程序。这些导致密钥泄露的间接路径使硬件保护无效，除非与作强化、环境隔离和一致的可审计性相结合。

4云安全中 HSM 和 TPM 的未来替代方案

虽然 HSM 和 TPM 提供硬件支持的加密保证，但它们在云环境中的有效性越来越受到旨在支持它们的基础设施的影响。它们的安全边界严格限制在物理或虚拟机管理程序级别的信任范围内，但云原生威胁出现在 API、编排和多租户层。本节探讨不断发展的加密方法，这些方法旨在增强或在某些情况下挑战当前对传统 HSM 和 TPM 的依赖。

4.1机密计算：大规模隔离执行

机密计算提供[26]通过可信执行环境 （TEE） 实现硬件强制内存和执行隔离。来自 Azure 和 Google 的 Intel SGX、AMD SEV-SNP 以及基于云的机密 VM 等实现使工作负载能够在隔离的内存区域中运行，从而保护机密免受特权系统软件的影响。

Azure 机密 VM[9]，例如，利用 AMD SEV-SNP 确保客户机虚拟机使用的内存页面经过加密并防止虚拟机管理程序访问。Microsoft 报告称，越来越多地采用此类技术来保护加密作，特别是在安全密钥生命周期管理和 AI 模型推理等用例中。[27]

尽管机密计算前景广阔，但它也不能免受侧信道威胁[28].功率分析攻击，例如 PLATYPUS 攻击框架中演示的攻击[29]，仍然可以通过利用微架构的副作用来泄露受飞地保护的机密。此外，TEE 依赖于可信计算基础 （TCB），如果受到损害或配置错误，就会破坏飞地的隔离保证。

4.2后量子密码学：为下一个时代构建加密货币

随着量子计算的进步，RSA 和 ECC 等经典密码原语（通常在 HSM 和 TPM 中受到保护）面临过时。后量子密码学 （PQC） 旨在通过引入抗量子算法来应对这种威胁。

NIST PQC 项目于 2024 年结束了第三轮标准化，选择 CRYSTALS-Kyber 进行加密，选择 CRYSTALS-Dilithium 进行签名。这些算法现在正在 AWS、Google 和 Microsoft 在云环境中进行测试，通常与传统加密系统并行。

然而，将 PQC 集成到 HSM 和 TPM 中存在挑战。现有硬件可能不支持 PQC 方案所需的大密钥大小或不同的计算模式。需要硬件更新周期和固件更新，没有它们，云硬件安全将滞后于密码创新。

4.3去中心化和多方密钥管理

传统的 HSM 集中了密钥存储，从而产生了单点故障。去中心化密钥管理框架，包括多方计算 （MPC）[30]和 Shamir 的秘密共享，旨在在多个节点或实体之间分配信任。

Fireblocks 和其他企业 MPC 平台已经使用这些技术来大规模保护数字资产和私钥。使用 MPC，没有一个节点拥有完整的密钥;相反，签名或解密等作是通过分布式共识执行的，从而增强了对违规或内部入侵的抵抗力。

然而，MPC 系统引入了协调复杂性和新的攻击面，特别是在缺乏强大身份保证和同步机制的环境中。它们最适合安全优势大于运营摩擦的用例，例如数字托管和组织间信任模型。

4.4保护 vTPM：增强对虚拟化硬件的信任

机密虚拟机和虚拟化信任模块的兴起需要重新评估云原生环境中的 TPM 安全性。标准 vTPM 通常依赖于虚拟机管理程序保证，而这可以通过侧信道或控制平面作来颠覆。

2019 年推出的 SvTPM 框架将虚拟 TPM 功能封装在 TEE 中，以降低虚拟机管理程序级风险。最近的评估表明，将 vTPM 包装在英特尔 SGX 等飞地中[26]或者 AMD SEV 提高了机密性和运营完整性。

尽管如此，虚拟化开销和飞地生命周期的复杂性可能会阻碍广泛采用。vTPM 的安全部署必须同时解决硬件级隔离和编排层安全策略。

4.5总结和混合方法

虽然这些方法都尚未完全取代 HSM 或 TPM，但它们提供了增强云中传统信任模型的途径。机密计算提供隔离;PQC 提供加密弹性;MPC 消除了单点妥协;安全 vTPM 为虚拟时代发展了 TPM 范式。

组织可能会采用将这些技术分层的混合模型，平衡硬件安全的优势与灵活的云原生保护策略。随着威胁从芯片转向软件和编排，云加密安全也必须效仿。

表3：新兴替代品的紧凑比较

方法 优势局限性机密计算 使用硬件隔离正在使用的数据容易受到侧信道的影响;TCB 复杂性后量子加密货币 量子安全;NIST 支持需要新的硬件;庞大的密钥和计算成本MPC/去中心化密钥 没有单一故障点;协作信任作复杂性;协调开销安全的 vTPM 通过 enclave 增强 vTPM 信任头顶飞地;设置疼痛

为了将这些技术的集成置于上下文中，图 2 说明了用于云中加密作的分层混合架构。基础是信任的根源[25]，使用 TPM 或安全虚拟 TPM （SvTPM） 实现，在启动时验证系统完整性。在此层之上，英特尔 SGX 或 AMD SEV-SNP 等机密计算环境在执行过程中隔离正在使用的数据。

分布式关键作[11]通过多方计算 （MPC） 进行处理，确保任何时候都没有单个设备拥有完整的密钥材料。后量子加密原语（包括 Kyber 和 Dilithium）在顶部运行，以保护传输中和静态数据免受量子威胁。最后，云 API 层管理访问控制、IAM 策略和审计日志记录，强制实施应用程序层边界并提供对所有加密作的可见性。

该架构强调模块化集成，其中每一层都减轻不同的威胁向量，同时共同加强整个加密信任链。

信任根：TPM / SvTPM

机密运行时：英特尔 SGX / AMD SEV-SNP

分布式密钥作：MPC（例如，Fireblocks）

抗量子加密货币： 凯伯 / 二锂

云 API 层：IAM、安全访问控制、审计

图2：集成机密计算、PQC、MPC、TPM的混合云密码架构

此设计支持垂直信任模型，其中：

vTPM 验证系统的启动完整性。机密 VM 保护运行时密钥材料。MPC 确保分布式签名和解密，没有集中的故障点。PQC 算法使加密层面向未来。IAM/API 网关限制访问并记录每个作。

5结论与建议

这项研究表明，虽然 HSM 和 TPM 提供了强大的基于硬件的保证，但它们在云环境中的有效性会反复受到周围生态系统弱点的影响。配置错误的 API、暴露的凭据、受损的虚拟机管理程序以及缺乏隔离机制使攻击者能够绕过硬件保护，而无需破坏加密原语。

主要观察

云托管的 HSM 受到不安全的 API 表面、令牌重用和供应链泄漏的破坏[7].虚拟 TPM （vTPM） 虽然提供硬件根信任，但很容易受到控制平面攻击，例如中断注入和 VM 逃逸，正如“Heckler”漏洞所证明的那样[24].将 vTPM 逻辑包装在可信执行环境中（例如，基于 SGX 的 SvTPM）可显着增强机密性并降低虚拟机管理程序风险[25].

云原生加密安全建议

采用机密计算：部署基于 AMD SEV-SNP 或基于 Intel TDX 的机密虚拟机，以在运行时隔离内存，甚至与特权主机层隔离内存[9].使用安全区保护 vTPM：使用基于 enclave 的实现（如 SvTPM）来保护虚拟信任锚免受主机纵。为后量子密码学做准备：开始在 HSM 和 vTPM 基础设施中过渡到 NIST 标准化的 PQC 算法，例如 CRYSTALS-Kyber 和 Dilithium[10].采用去中心化密钥模型：使用多方计算（MPC）和密钥共享来消除单点加密故障[11].强化 API 表面：强制实施最低权限 IAM、频繁轮换令牌、限制凭据范围以及检测所有与密钥相关的作的实时审计。

云中面向未来的加密安全需要将重点从硬件保证转移到整体系统架构。硬件安全模块必须在强制执行严格权限、隔离和生命周期控制的环境中运行。只有这样，HSM 和 TPM 才能在现代威胁模型下实现其原始安全目标。