PDF使用 Arm CCA 提升安全性
证明和验证是采用机密计算不可或缺的部分。
Charles Garcia-Tobin 和 Mark Knight
在一些重要市场，例如国防、政府1 和银行9，私有数据中心和本地计算仍然很普遍。虽然公共云中的共享计算可以带来规模经济带来的成本和环境效益，但与内部企业基础设施相比，传统上它与失去一些控制权有关。公共云数据中心由 CSP（云服务提供商）管理，服务器及其管理员可能位于与租用服务的客户不同的司法管辖区。
将日益敏感的工作负载迁移到云端的愿望推动了对机密计算的需求5,8。这是一种计算模型，在这种模型中，工作负载可以部署在第三方基础设施上，并具有高度的信心，即任何第三方都不会损害工作负载的机密性或完整性。除了促进新的基于云的工作负载外，机密计算还代表了现有云工作负载安全性的提升。在最初阶段，机密计算通常是一种可选服务，但随着时间的推移，它很可能成为主要 CSP 的默认服务。
租户和云运营商必须共同努力，构建一个支持机密计算的运营模型。机密计算的主要功能优势在于，它可以在处理数据和代码时保护数据和代码免受某些安全威胁。它通常以基于硬件的隔离技术来实现，该技术在计算工作负载（例如虚拟机）周围创建一个安全护城河，其中大多数计算工作负载需要以未加密的形式存在数据才能进行处理。在云环境中支持机密计算的技术也可以用于加强其他计算环境中的安全性。
支持机密计算
机密计算的实现旨在提升分时计算系统中已有的安全性。传统上，计算硬件提供用于在工作负载之间提供安全隔离的机制。此外，硬件还提供特权级别系统，以确保配置计算平台和访问资源的能力仅限于监管代码，例如操作系统和虚拟机监控程序内核。然后，操作系统通常通过识别和执行权限系统来提供额外的分区，该系统限制不同系统用户的权利。
通过硬件和软件控制的结合，暴露于监管代码接口，因此影响或控制资源访问和配置的能力，仅允许授权的系统服务和管理员使用。然而，高特权系统用户可能不受此类限制，并且通常可以不受限制地访问内存等资源，以及替换系统程序的能力。
机密计算消除了监管代码（以及由此推断的系统管理员）读取或修改客户工作负载的能力，即使它们正在运行。然而，它仍然允许该代码管理平台和工作负载，例如，决定它在内存、处理时间或设备访问方面需要多少资源。
在支持机密计算的平台中，客户工作负载受到硬件和底层固件的混合保护。这些组件提供的服务必须小而可验证，并且两者都必须是可信的。固件和硬件的这种组合构成了 TCB（可信计算基）。
构建支持机密计算的平台需要仔细的系统级设计。平台保护必须扩展到处理元件之外的其他子系统，包括系统缓存、内存、I/O 和可信外围设备（如加速器）。任何将访问敏感工作负载的硬件都必须遵守对机密计算的承诺。例如，在支持机密计算的系统中，内存控制器通常在将数据写入主系统内存之前对其进行加密，以减轻重启攻击的威胁。将需要这种或其他缓解措施，以确保在意外硬件重置后，工作负载的残留内容不会被另一个工作负载读取。
机密计算的证明
最好的安全技术通常对用户来说几乎是透明的，同时为攻击者创建一道不可逾越的障碍。机密计算的实现可能对用户来说几乎是不可见的，但依赖方仍然需要一种远程评估平台提出的安全声明的方法。攻击者可能会尝试替换 TCB，或者他们可能会尝试用被黑的克隆替换整个平台。需要在数据或代码被泄露之前检测到这些威胁。
为了允许依赖方验证平台的完整性，机密计算的实现支持证明和验证过程。验证为依赖方提供了一种在加载敏感工作负载之前远程检查平台运行时属性的方法。
证明是一个多阶段过程（如图 1 所示）
阶段 1. 可信平台的创建者必须以数字方式认可每个可信硬件和软件组件以及相关的安全声明。通常，这需要使用密码学和数字签名，这些签名链回可信 CA（证书颁发机构）。平台的认可可能包括第三方分析、审查和副署，以便测试平台安全声明6。
阶段 2. 虚拟机等工作负载必须能够获得其加载平台的证明报告以及其自身的证明报告。这些报告必须包含有关平台来源和配置的详细信息，并且必须使用安全的片上信任根进行加密签名。报告还包含工作负载自身的测量结果，允许依赖方验证工作负载是否正在执行预期的代码和数据。然后，工作负载可以将证明报告呈现给依赖方。
阶段 3. 然后，任何拥有证明报告的实体都能够验证正在证明的平台和工作负载的完整性，通常与可信验证服务协同工作。在异构设备的复杂网络中，可能需要联合验证模型，以便依赖方可以避免与其网络中的每个平台供应商建立自己的关系。
步骤 2 和 3 必须按需发生，并且通常在几毫秒内完成。如果证明验证失败，工作负载和依赖方可以拒绝平台并在任何数据泄露之前停止执行。
工作负载通常会在其启动序列中向密钥管理服务提供证明报告，确保只有在密钥管理服务确信工作负载在安全平台上运行时，才能解密敏感数据。第三方可以使用协议来获取证明报告，作为安全网络传输（例如 TLS（传输层安全协议）11）的一部分，如果证明验证失败，则拒绝连接。
平台证明必须考虑 TCB 的每个部分，并且可以独立于机密计算来实现。在不支持机密计算的平台上，可以通过证明来验证平台的完整性，但依赖方可能不太确信平台上的特权软件无法访问工作负载。决定是否需要机密计算或平台证明是否足够充分的因素包括威胁模型以及支持这些功能的硬件系统的实际可用性。
新兴技术往往会在市场中逐渐普及。支持机密计算的技术最初部署在云计算市场的服务器上，并且很可能扩展到其他市场和外形尺寸。即使只有一个端点支持机密计算，执行相互平台证明仍然可能具有价值。
机密计算的示例用例
许多完整的计算系统分布在多台独立的计算机上。考虑一个简单的在线银行服务，该服务由云连接的交易服务器和移动应用程序组成，该应用程序是用户的主要客户端界面。服务器通常会向客户端呈现 Web API，并且在使用中通过 TLS 和强大的用户身份验证来保护它。潜在的攻击面包括应用程序 UI 和服务器 Web API。重复身份验证通常部分委托给客户端设备。例如，身份验证密钥通常在初始身份验证成功后存储在每个用户的设备上。然后可以使用客户端生物特征身份验证来解锁这些密钥，以便在每次运行应用程序时无需手动提供凭据即可启动新的用户会话。
安全架构师会考虑各种潜在的攻击，包括
1. 用户的移动设备是否可以可靠地安全存储身份验证密钥，并允许仅在生物特征身份验证后由真正的银行应用程序使用它们？
2. 攻击者是否可以欺骗真正的客户端应用程序并成功直接调用 Web API，从而可能绕过客户端安全控制或利用 Web API 中的漏洞？
3. 服务器是否会被盗或克隆，并且客户端被错误地定向到伪造的服务器，该服务器发起“中间人”攻击？
4. 服务器是否会受到具有物理或管理访问权限的人员的攻击，从而允许劫持经过身份验证的会话并可能注入未经授权的交易？
在每个会话开始时进行强大的相互证明可以帮助缓解这些攻击。
1. 证明可以提供证据，证明移动设备是真实的、未修改的并且以安全方式配置的。当平台支持机密计算时，依赖方可以确信手机的操作系统无权访问敏感的金融服务数据。
2. 如果客户端应用程序和移动设备的证明和验证失败，则可以阻止尝试使用第三方客户端调用 Web API。
3. 服务器证明可以防止在不受信任的平台上提供服务器 API，并使客户端能够拒绝连接到未经授权的服务器。
4. 客户端可以验证服务器安全声明，从而高度确信客户数据保持安全。
正如本示例所示，在第三方数据中心部署关键服务时，证明技术可以提供更高的信心；当依赖移动应用程序作为分布式计算系统的一部分时，相同的技术也可以降低风险。虽然当平台的所有者和用户不同时，最自然地寻求机密计算，但即使平台的所有者和用户相同，它仍然可以减少有权访问用户数据的平台代码量，从而减少可能被利用的攻击面。
Arm 的 Realm Management Extension
Armv9-A 架构广泛部署在各种计算外形尺寸中，例如智能手机、笔记本电脑、服务器和许多 IoT（物联网）设备。Armv9-A 最近通过 RME（Realm Management Extension，领域管理扩展）进行了增强，该扩展提供了一种架构，旨在利用不同外形尺寸上的机密计算技术来保护代码和数据。
在引入 RME 之前，TrustZone 和虚拟化是安全计算的支柱。TrustZone 将计算划分为安全世界（用于运行可信应用程序和可信操作系统）和普通世界（用于运行标准应用程序和操作系统）。安全世界软件有权访问安全物理地址空间，普通世界无法访问该空间。这种隔离保护了可信应用程序和可信操作系统。通常，安全物理地址空间的内存是在启动时静态划分的。
TrustZone 非常适用于数量有限的平台安全用例。然而，机密计算旨在允许任何第三方开发人员保护其 VM 或应用程序。因此，必须可以在运行时保护与 VM 或应用程序关联的任何内存，而没有限制或划分。此外，仍然重要的是支持 TrustZone 以实现平台安全。
RME 硬件
RME 引入了一种新型的机密计算环境，称为领域（realm）。属于领域的任何代码或数据，无论是在内存中还是在寄存器中，都无法被 TCB 之外的代码或代理访问或修改
• 创建领域的监管软件，即普通世界中的内核或虚拟机监控程序。
• 在 TrustZone 内执行的代码。
• 其他领域。
• 领域不信任的设备。
这些实体尝试访问领域的代码、数据或寄存器状态将被阻止，并导致故障异常。
在新的引入的领域世界中运行的领域，以及运行时的内存可以在普通世界和领域世界之间移动，甚至可以在普通世界和安全世界之间移动。这是通过添加到架构中的新数据结构实现的：GPT（Granule Protection Table，粒度保护表）。此结构跟踪页面是否用于领域世界、安全世界或普通世界。硬件在每次访问时检查此表，并强制执行世界之间的隔离，阻止那些非法访问，例如从虚拟机监控程序到领域世界页面的访问。在一个世界内，转换表提供进一步的隔离；这就是领域彼此隔离的方式。虚拟机监控程序或内核可以间接更新 GPT，允许页面在普通世界使用和领域使用之间迁移，甚至在普通世界使用和 TrustZone 使用之间迁移。内存也被加密和擦除，以确保其内容无法被后续用户访问。
GPT 由硬件在页表遍历结束时检查。这在 Armv9-A 架构中称为粒度保护检查。如果这些检查失败，则会向进行访问的代理引发异常。为了减轻检查的成本，RME 允许在每个缓存行的基础上表示地址与世界（领域、非安全或安全）之间的关联。此外，该架构允许 TLB（转换后备缓冲区）缓存页面与给定世界的关联。TLB 可以缓存虚拟地址到物理地址的转换以及 GPT 验证。
为了补充这两种形式的缓存，RME 使用新的指令扩展了 Armv9-A，以管理处理器缓存和 TLB 中的这些新方面。通过 GPT 引入的在不同安全环境之间动态移动内存资源的能力是 RME 为 Armv9-A 架构贡献的最重要的变化。
GPT 不仅由处理器检查，还由 Arm System MMU（系统内存管理单元）3 检查，该单元用于门控设备访问。这与 PCIe（外围组件互连高速）的进步相结合，实现了设备到领域的受信任分配。领域可以证明设备并决定是否信任它。如果设备是受信任的，则允许其直接访问领域的内存。其他领域不必信任它。
此功能由 Arm SMMU（系统内存管理单元）执行的安全检查提供。除了 GPT 检查外，SMMU 还支持检查支持 PCIe ATS（地址转换服务）并使用物理地址发送事务的设备。对于此类设备，SMMU 包括一个设备权限表，该表确保此类事务的目标地址在它们所附加的领域内。
通过页表和 GPT 检查创建的隔离是为领域提供的安全性的主要形式。为了增加纵深防御，可以使用内存加密上下文扩展 (FEAT_MEC) 进一步完成 RME。此扩展允许与领域关联的内存相对于其他领域进行唯一加密。
标准参考固件架构
虚拟机监控程序和内核管理资源（主要是处理器周期和内存）的方式与今天对 VM 和进程的管理方式大致相同。监管软件仍然需要能够创建和销毁领域、向领域添加内存或从领域中删除内存以及调度领域执行。旨在决定何时为 VM 和进程执行这些操作的策略代码可以直接重用于领域管理。然而，机制有所不同，因为监管者被阻止访问领域内容。这些操作需要与安全固件组件交互，这些组件管理 GPT 以及领域转换表和上下文。
RME 定义了一个在硬件中实现的标准架构。平台还需要软件（包括固件）来配置 RME 并为请求证明和验证的工作负载提供服务。RME 允许实施者设计自己的软件架构，但 Arm 还发布了一个名为 Arm CCA（机密计算架构）的开放参考软件架构4。
Arm CCA 标准化了配置和使用 RME 所需的基本软件和固件接口，旨在使构成 TCB 一部分的固件简单、小巧且易于审计和验证。Arm CCA 由这些组件的开源参考实现支持，并且可以免费许可和部署。
Arm CCA 的关键组件如图 2 所示。RMM（领域管理监视器）负责管理工作负载与虚拟机监控程序之间通过监视器的通信。RMM 不做资源决策，例如运行哪个领域或为领域分配多少内存。这些决策仍然由主机虚拟机监控程序决定。
第二个关键组件是监视器，它负责安全状态（领域、安全和非安全）之间的上下文切换以及管理 GPT。
RMM 和监视器与硬件一起构成领域的 TCB。CCA 设计将复杂的策略（例如资源分配、调度或设备分配）保留在非安全主机虚拟机监控程序中。这减少了 RMM 和监视器的代码库，它们仅限于安全检查和机制。例如，Arm 的 RMM 实现甚至不包括内存分配器。有关代码的更多详细信息，请参阅 TF-RMM 开源项目10。
通过选择使用 Arm CCA 和开源实现（如 TF-RMM），更广泛的 Arm 社区分担了实现机密计算的任务，同时可以通过安全研究社区的第三方验证来提高对平台的信任7。
标准、认证和监管
虽然机密计算行业的目标是交付无法观察其托管工作负载的平台，但问题仍然是如何由潜在客户评估平台声明。平台供应商可以选择发布多少关于其实施的安全设计的信息，范围从提供高级营销描述到指向可重现的构建和相应的源代码。有理由假设某些实现将比其他实现更强大。然而，对于每个潜在客户来说，进行他们自己详细的安全和风险分析是不切实际或不可扩展的。随着技术的成熟，行业监管机构可能会帮助引入标准和认证。
最简单的，这可能意味着实施可以选择显示徽标或证书，以提供平台已通过认证以满足特定安全要求的证据。管理金融服务和医疗保健等行业的监管机构可能会建议或管理受监管者使用已成功认证的平台。
监管方面的创新往往落后于技术方面的创新，部分原因是监管机构普遍认为，在法规发布后不久就必须有可能满足法规。然而，随着时间的推移，标准和认证可能会简化选择安全机密计算平台的过程。
总结
机密计算具有巨大的潜力来提高通用计算平台的安全性，方法是将监管系统从 TCB 中移除，从而减小 TCB 的大小、攻击面以及安全架构师必须考虑的攻击向量。机密计算需要平台硬件和软件方面的创新，但这些创新有可能增强对计算的信任，尤其是在第三方拥有或控制的设备上。
证明和验证的使用是采用机密计算不可或缺的一部分，因为依赖方可以通过这些机制快速安全地建立他们希望使用的平台的真实性。
RME 和 Arm CCA 为在实现 Armv9-A 架构的系统上实现机密计算提供了标准架构2。
机密计算的早期消费者将需要就他们选择信任的平台做出自己的决定。然而，随着机密计算成为主流，认证机构和监管机构可能会分担这一负担，使客户能够在无需进行自身评估的情况下做出明智的选择。
参考文献
1. Ali, O., Osmanaj, V. 2020. 政府法规在云计算采用中的作用：地方政府案例研究。计算机法律与安全评论 36； https://www.sciencedirect.com/science/article/abs/pii/S0267364920300017?via%3Dihub。
2. Arm Developer。A-Profile 架构的 Arm 架构参考手册； https://developer.arm.com/documentation/ddi0487/latest。
3. Arm Developer。Arm 系统内存管理单元架构规范； https://developer.arm.com/documentation/ihi0070/latest/。
4. Arm Developer。了解架构：介绍 Arm 机密计算架构； https://developer.arm.com/documentation/den0125/0300/Arm-CCA-Software-Architecture。
5. 机密计算联盟； https://confidentialcomputing.io。
6. Delignat-Lavaud, A., Fournet, C., Vaswani, K., Clebsch, S., Riechert, M., Costa, M., Russinovich, M. 2023. 我为什么要信任你的代码？acmqueue 21(4)； https://queue.org.cn/detail.cfm?id=3623460。
7. Li, X., Li, X., Dall, C., Gu, R., Nieh, J., Sait, Y., Stockwell, G. 2022. Arm 机密计算架构的设计与验证。第 16 届 Usenix 操作系统设计与实现研讨会论文集，465–484； https://www.usenix.org/system/files/osdi22-li.pdf。
8. Russinovich, M. 2023. 机密计算：提升云安全和隐私。acmqueue 21(4)； https://dl.acm.org/doi/pdf/10.1145/3623461。
9. Scott, H. S., Gulliver, J., Nadler, H. 2019. 金融领域的云计算：全球视角。国际金融系统项目； https://ssrn.com/abstract=3427220。
10. 可信固件； https://www.trustedfirmware.org/projects/tf-rmm/ 和 https://www.trustedfirmware.org/。
11. Tschofenig, H., Sheffer, Y., Howard, P., Mihalcea, I., Deshpande, Y. 2023. 在传输层安全 (TLS) 和数据报传输层安全 (DTLS) 中使用证明。IETF Datatracker； https://datatracker.ietf.org/doc/draft-fossati-tls-attestation/。
Charles Garcia-Tobin 是 Arm 架构和技术组的操作系统架构师和研究员。他在 Arm 工作超过 12 年，在处理器、系统和固件架构方面提供解决方案。他的主要目标是创建可以轻松部署在生态系统中并被所有主要操作系统采用的解决方案。他最初的工作是标准化电源管理接口，然后转向一般的服务器标准化，而现在更多地关注安全性。如今，Charles 领导着 Arm 架构组中的 Arm 机密计算架构项目。
Mark Knight 是 Arm 架构和技术组的产品管理总监，负责安全架构，包括于 2021 年 3 月作为 Armv9-A 的一部分发布的 Arm 机密计算架构 (Arm CCA)。他在技术和计算领域从事产品开发超过 30 年，担任工程和产品管理职务，其中超过 20 年专注于安全和密码学。Mark 拥有赫特福德大学计算机科学理学士学位。
版权所有 © 2024，所有者/作者所有。出版权已许可给 。
最初发表于 Queue vol. 22, no. 2—
在 数字图书馆 中评论本文
更多相关文章
Jinnan Guo, Peter Pietzuch, Andrew Paverd, Kapil Vaswani - 使用机密联邦学习的可信 AI
安全性、隐私性、问责制、透明度和公平性原则是现代 AI 法规的基石。经典的 FL 在设计时非常强调安全性和隐私性，但牺牲了透明度和问责制。CFL 通过将 FL 与 TEE 和承诺相结合，弥补了这一差距。此外，CFL 还带来了其他理想的安全属性，例如基于代码的访问控制、模型机密性以及推理期间的模型保护。机密容器和机密 GPU 等机密计算的最新进展意味着可以无缝扩展现有的 FL 框架，以低开销支持 CFL。
Raluca Ada Popa - 机密计算还是密码计算？
通过 MPC/同态加密与硬件 enclave 进行安全计算，在部署、安全性和性能方面存在权衡。关于性能，您考虑的工作负载非常重要。对于简单的求和、低阶多项式或简单的机器学习任务等简单工作负载，这两种方法都可以在实践中使用，但对于复杂的计算（例如复杂的 SQL 分析或训练大型机器学习模型），目前只有硬件 enclave 方法在许多实际部署场景中足够实用。
Matthew A. Johnson, Stavros Volos, Ken Gordon, Sean T. Allen, Christoph M. Wintersteiger, Sylvan Clebsch, John Starks, Manuel Costa - 机密容器组
此处展示的实验表明，Parma（在 Azure 容器实例上驱动机密容器的架构）增加的额外性能开销不到底层 TEE 增加的开销的百分之一。重要的是，Parma 确保了容器组所有可达状态的安全不变性，并以证明报告为根基。这允许外部第三方与容器安全地通信，从而支持各种需要机密访问安全数据的容器化工作流程。公司可以在云中运行其最机密的工作流程，而无需在其安全要求上妥协，从而获得优势。
Gobikrishna Dhanuskodi, Sudeshna Guha, Vidhya Krishnan, Aruna Manjunatha, Michael O'Connor, Rob Nertney, Phil Rogers - 创建首个机密 GPU
当今的数据中心 GPU 具有悠久而传奇的 3D 图形传统。在 1990 年代，用于 PC 和游戏机的图形芯片具有固定的管道，用于使用整数和定点算术进行几何、光栅化和像素处理。1999 年，NVIDIA 发明了现代 GPU，它将一组可编程内核置于芯片的核心，从而能够高效地生成丰富的 3D 场景。
© 保留所有权利。