PDF迈向机密云计算
将硬件强制加密保护扩展到使用中的数据
Mark Russinovich, Manuel Costa, Cédric Fournet, David Chisnall, Antoine Delignat-Lavaud, Sylvan Clebsch, Kapil Vaswani, Vikas Bhatia
尽管现代云的发展在很大程度上是由规模经济驱动的，但它也提高了安全性。大型数据中心提供聚合的可用性、可靠性和安全保证。确保操作系统、数据库和其他服务具有安全配置的运营成本可以在所有租户之间分摊，使云提供商能够聘请负责安全的专家；这对于小型企业来说通常是不可行的，在小型企业中，系统管理员的角色常常与许多其他角色混淆。
云数据中心也受到严格的物理安全保护：具有物理访问权限的人数受到限制，并且对他们访问权限的控制比在本地部署的数据中心更为严格——本地部署的数据中心通常容易受到内部威胁的影响，例如心怀不满的前雇员带着敏感数据或物理介质（包括现场备份）离开。
云提供商系统地加密传输中（在网络上）和静态（在磁盘和备份上）的数据，使用与租户关联的密钥：即使攻击者获得对数据中心的访问权限，他们也无法看到租户数据的明文，除非他们也设法泄露了他们管理的密钥。云中安全性的这种提升趋势将继续下去；下一步是机密计算，将硬件强制加密保护扩展到使用中的数据（即，在计算期间）。
信任云
为什么租户会表面上接受来自云的安全保证？租户对提供商的信任程度各不相同。有些人可能完全信任云能够保证他们的数据安全。有些人可能会担心其他租户、软件错误或内部攻击（例如，来自数据中心技术人员的攻击）。有些人可能需要遵守严格的隐私法规。有些人可能还会怀疑提供商执行其声明的安全政策的意愿或能力——例如，保证他们的数据永远不会在未经他们同意的情况下被使用——甚至担心在其云运营所在司法管辖区内的传票和其他法律攻击。为了解决这些担忧，租户越来越期望以下几点：
• 其敏感工作负载的最小硬件、软件和运营 TCB（可信计算基础）。
• 技术强制执行，而不仅仅是业务政策。
• 关于他们获得保证、剩余风险和缓解措施的透明度。
机密计算通过允许租户完全控制用于运行其云工作负载的 TCB 来满足这些期望：机密计算允许租户精确定义所有可以访问其工作负载（数据和代码）的硬件和软件，并提供技术机制来可验证地强制执行此保证。简而言之，租户保留对其机密的完全控制权。
特别是，机密计算可以使工作负载对云提供商不透明，因为租户可以使用这种精确的控制级别来防止 hypervisor 和其他云托管基础设施访问他们的机密。这可以防止来自云结构及其运营商的攻击，并补充了保护云结构免受潜在恶意租户侵害的更传统的安全目标。
这种控制级别超越了防止云托管基础设施的访问：它允许租户指定特定的机密集只能由特定的代码模块处理。这种能力非常强大，因为它可用于设计具有缩小攻击面的弹性系统。对机密云服务中放置的信任的精确控制使得在不完全信任彼此的多方之间实现有用的场景成为可能。例如，租户可以反过来为其自己的客户部署具有强大隐私保证的服务；并且竞争方可以共同配置和运行多方云计算（例如数据分析或机器学习），并对他们汇集数据的使用提供强大的技术保证。
向机密计算的转变是整个行业共同努力的一部分。成立于 2019 年的机密计算联盟包括阿里巴巴、AMD、Arm、谷歌、华为、英特尔、微软、英伟达、Oracle、红帽以及许多其他公司。该联盟的存在是因为认识到要过渡到机密计算成为所有云服务的默认设置的世界，需要在堆栈的各个层面付出巨大的努力，从硬件开始，包括 hypervisor、操作系统内核和云服务。
机密计算平台
让我们来看看可信执行环境、此类环境的动态实现、盲 hypervisor 以及各种平台抽象。
硬件基础：可信执行环境
在堆栈的最底层，硬件必须能够提供 TEE（可信执行环境），将给定机密工作负载的代码和数据与系统中运行的任何其他代码隔离——包括在最高特权级别运行的代码。硬件还必须支持对其所有 I/O 进行加密，因为数据在 TEE 内外流动，并且能够测量和签名 TEE 的内容，以生成可验证的证据证明它是安全的。这反过来需要一个硬件信任根来保存平台根机密和签名密钥，以及一个公钥基础设施来认可这些密钥。值得庆幸的是，这些功能通常可以安装到新一代现有平台中，因此它们可以在机密模式下使用，而无需专用硬件和软件。
隔离。为了保密性和完整性，在 TEE 中运行的软件必须安全，免受系统中其他部分的窥探或干扰。这可能涉及围栏和锁定机制，以防止在可信代码加载和测量后对其进行更改，并为 TEE 的独占使用保留核心或内存缓存等资源，以减轻侧信道攻击。许多 TEE 使用加密来保护其所有状态或存储在可信紧耦合内存之外的部分。侧信道，例如 Spectre 和 Meltdown 系列漏洞或差分功耗分析，有可能突破隔离。TEE 的完整硬件/软件堆栈必须针对威胁模型范围内的任何漏洞提供防御——例如，编译器中的推测性加载硬化3，或硬件中的安全缓存8,13和安全推测机制9,14。其中一些防御措施可能完全在软件层面构建——例如，通过使用数据轨迹不可知的的数据结构。5
硬件信任根。保护必须植根于硬件；否则，云运营商可以很容易地通过在软件中模拟 TEE 来打破隔离。每个支持 TEE 的设备都必须具有唯一的身份，并使用硬件机密进行加密保护。例如，此机密可以在设备制造过程结束时在设备内的熔丝组中采样和记录，并且制造商可以收集相应的公钥以颁发平台证书。TPM（可信平台模块）提供了离散信任根的早期示例，但对物理攻击的保护有限。谷歌最近发布的 OpenTitan 内核和微软的 Pluton 子系统是更先进的集成硬件信任根的示例。Pluton 最初是为 Xbox One 游戏机创建的，因此在可能具有敌意的环境中大规模部署方面拥有悠久的历史。它还集成到 Azure Sphere IoT（物联网）设备中，并已授权给主要的 CPU 供应商（AMD、英特尔和高通），它最初提供 TPM 接口，并且可以为机密计算系统提供硬件信任根。
尽管硬件信任根现在已经确立，但它们传统上保护在设备上提供服务的人（游戏发行商或在我们的例子中是云提供商）免受滥用，而机密计算进一步要求它们保护第三方免受对设备具有物理访问权限或对设备非机密部分具有逻辑访问权限的攻击者的侵害。例如，允许云提供商签名的固件直接访问硬件机密的机制违反了机密计算的承诺。
证明。证明是建立对机密计算信心的机制。与加密消息传递系统一样，没有完整性的机密性是不够的。能够以云提供商无法检查或篡改的方式运行软件是没有用的，如果你不能保证它确实是你期望运行的软件。
证明使用从硬件信任根维护的硬件机密派生的密钥来签名证据，证明 TEE 处于受真实硬件设备保护的已知良好状态。此证据类似于安全启动签名：TEE 的一组测量值，例如，初始内存内容的哈希，以及各种安全关键寄存器的状态。远程用户或软件组件在接收和验证此证据后，可以确信 TEE 的完整性，然后通常会建立加密通道以部署机密和控制 TEE 内部的计算。
硬件进步：动态 TEE 实现
物理隔离是保证保密性和完整性的最简单方法——例如，通过使用具有简单 I/O 接口的隔离核心。这是 Apple 的安全元件（在 iOS 设备和最近的 Mac 中发现）所采用的路线。当 TEE 中运行的代码具有预先知道的计算和存储需求，并且由单个供应商提供时，这就足够了。这在具有弹性需求和许多租户的云环境中是不够的：云结构必须能够创建可变大小的 TEE，在单个系统上托管多个 TEE，并动态地为 TEE 分配/解除分配资源。
作为机密计算工作的一部分，TEE 在过去几年中在大多数通用处理器上变得可用。Arm 的 TrustZone 提供了早期的 TEE 实现，允许在启动时将内存分配给两个世界之一——安全或正常——并允许安全世界中的小型可信内核提供隔离的进程。在此模型中，所有安全世界组件都必须信任安全内核（以及安全 hypervisor，如果存在），尽管它们不必信任正常世界的 hypervisor 和操作系统内核。
英特尔的 SGX（软件保护扩展）更进一步，提供了在用户模式进程的虚拟地址空间中创建隔离内存区域的能力。可以在启动后动态创建任意数量的这些区域，但受资源约束的限制。区域内部的代码和数据受到 CPU 实现的访问控制检查的保护，免受软件攻击：hypervisor 和内核无法看到或篡改区域内部的数据。这些区域还通过内存加密来保护免受物理攻击者的攻击：每当使用中的数据离开 CPU 缓存时，它都会在写回内存之前被加密。
如果你只想保证保密性，而不保证在具有内存总线访问权限的对手存在的情况下进行加密完整性，那么内存加密开销很低。Xbox 360 和更新型号自推出以来一直使用 AES（高级加密标准）进行内存加密，并为游戏（现代 CPU 上最苛刻的工作负载之一）提供了足够的带宽和延迟。主流 CPU 的内存控制器现在正在获得类似的功能，包括支持不同内存区域的不同密钥。保护大规模内存完整性免受物理攻击的成本更高；减少此开销的方案是积极研究的领域。
SGX 的隔离内存区域非常适合小型 TCB 服务10，但使用它们来运行完整的 VM（虚拟机）机密性具有挑战性，因为它们缺乏对多个地址空间以及特权和非特权模式分离的支持。这促使 AMD 开发了另一种专注于 VM 级别隔离的 TEE。AMD 处理器经历了一系列旨在完全从信任边界中移除 hypervisor 的设计迭代。他们的第一步，SEV（安全加密虚拟化）自动加密 VM 使用中的内存。接下来，SEV_ES（具有加密状态的 SEV）在每次转换到 hypervisor 时都添加了 VM 寄存器状态的加密。最后，SNP（安全嵌套分页）提供了额外的保证，即 hypervisor 无法通过篡改虚拟内存映射来破坏内存完整性，从而对机密 VM 执行完整性或重放攻击。总而言之，这些功能保证 hypervisor 无法读取或篡改 VM 状态（即，hypervisor 在 TCB 之外）。英特尔最近宣布的 TDX（信任域扩展）提供了与 SNP 类似的安全保证集，并且它针对全面的 VM 级别机密性。
最后，一些重要的工作负载需要专用处理器，例如 GPU、FPGA（现场可编程门阵列）和其他加速器。这些设备也可以通过 TEE 功能进行增强，并且具有很大的设计空间。12例如，一些加速器可能具有受物理封装保护的大内存（例如，高带宽内存），使得加密的相关性降低。在许多情况下，加速器可以一次分配给单个租户，这消除了攻击并进一步简化了其设计。
为了安全有效地使用这些设备，I/O 总线也需要更改。大多数当前系统都假设 I/O 总线是可信的，但这对于嵌入式系统来说一直是个问题：直到最近，大多数汽车中使用的 CAN（控制器区域网络）总线都没有执行任何端到端身份验证，从而允许受损组件（例如媒体播放器）发送消息，冒充来自发动机管理系统的消息。同样，PCI（外围组件互连）总线规范假设所有端点都是可信的，从而使恶意设备能够欺骗发起者 ID，例如，但机密加速器需要一种机制来在设备和主机 TEE 之间建立端到端安全通道，并在设备和主机之间集成加密。
虚拟化进步：盲 hypervisor
公开机密计算硬件需要更改云结构系统层。这包括更改 hypervisor 以处理它无法查看 VM 状态的约束。主流 hypervisor 设计遵循分层信任模型。hypervisor 完全受访客信任，负责在上下文切换之间存储访客状态，并且可以完全访问访客内存。
大多数半虚拟化设备接口都是在假设任何访客内存都可以用于虚拟等效的 DMA（直接内存访问）缓冲区的基础上设计的。随着 AMD 的 SEV 的引入，这些假设在主流硬件上不再成立。内存加密意味着 hypervisor 必须为访客提供一个弹跳缓冲区的区域，供访客使用。Linux 通过软件 IOTLB（输入/输出转换后备缓冲器）驱动程序支持 SEV 的这种操作模式。
当从 TEE 内部执行到周围环境的显式域转换时，硬件实现通常会保留寄存器上下文。对于异步退出，情况通常并非如此，异步退出可能会泄漏敏感信息。在 hypervisor 受信任的模型中，此信息可能有助于处理 VM 退出。当 hypervisor 不受信任时，要么必须修改它，使其不利用该功能，要么必须添加一个垫片层来清理信息。
例如，考虑二级地址转换中的页面错误。在传统系统中，hypervisor 接收一个陷阱，其中包含完整的寄存器上下文和一个异常寄存器，该寄存器指定错误地址。然后，它可以终止 VM、发出向上调用以请求 VM 的内核处理它，或从后备存储中分页调入缺少的页面。在机密计算系统中，这将允许 hypervisor 单步执行，并在每一步查看寄存器状态。至少，hypervisor 必须仅接收寄存器状态的加密且受完整性保护的版本，但即使知道错误地址也可能泄漏太多信息。在更安全的设计中，TEE 内部的垫片层将接收异步退出，并决定是发出 hypercall 以填充缺少的页面，还是仅通知内核错误。然后，此代码可以强制执行与此类退出的频率相关的策略，以便减轻来自 hypervisor 的可能攻击。
值得注意的是，当硬件隔离不可用时，可以通过信任 hypervisor 来创建 TEE 的一种形式。这是 Windows 基于虚拟化的安全的基础，它随 Windows Server 2016 和 Windows 10 引入，其中关键组件通过 Hyper-V 与 Windows 内核隔离运行。这可以支持与其他 TEE 相同的抽象，包括类似于 SGX 的隔离内存区域，但威胁模型较弱：在这种设计中，hypervisor 仍然是受信任的。这类似于亚马逊的 Nitro Enclaves 最近使用的方法。1
平台抽象：机密 VM、机密容器、飞地
系统层通过一组平台抽象向开发人员和用户公开机密计算硬件：机密 VM、机密容器和飞地。
机密 VM 允许租户拥有完全向后兼容的 VM 体验，运行现有的未经修改的应用程序。在后台，系统记录和检查证明，以验证安全保证并使其可审计。将整个 VM 放置在 TEE 中对于快速简便的采用非常重要，但它也带来了一些问题。例如，VM 的管理员对 VM 具有完全的读/写控制权限，这在许多情况下都过于粗糙。另一个令人担忧的问题是 VM 的 TCB 很大：VM 镜像不仅仅是一个内核和一个应用程序；它包括大量的系统服务。在最坏的情况下，这仍然可能比在本地或现有云基础设施上运行软件更安全，但可能会有更好的解决方案。
机密容器允许租户对 TCB 进行更精细的控制，并机密地运行新的或现有的容器化应用程序。在过去的几年中，容器已成为在云中部署软件的常用方式。确切的技术各不相同，但容器通常是一个小的（通常是分层或虚拟的）文件系统，其中包含运行单个程序所需的最低限度。
最佳实践建议在每个容器中运行单个微服务。然后，编排基础设施支持部署协同工作的微服务容器集群。这有几个优点：容器可以配置为具有比完整机密 VM 更小的 TCB，并且机密容器可以在 VM 中运行，而 VM 管理员无法访问它。为容器提供隔离的 TEE 仍然可以基于 VM 级别隔离机制（SNP、TDX 等），或者它可以基于进程级别隔离。（Haven2 和 SGX-LKL11 [Linux 内核库] 等系统采用了来自库操作系统和 Exokernel 世界的想法，在 SGX 内存区域内运行 Windows 或 Linux 库操作系统。）
微服务的容器部署引入了复杂的证明问题：编排框架需要为这些服务提供足够的状态，以便它们可以获取密钥，并且它们需要管理协议以建立整套微服务的身份。
在理想世界中，为安全性编写的软件将专注于最小的 TCB。为了让开发人员完全控制 TCB，机密计算平台公开了飞地抽象。飞地是完全灵活的。它们可以容纳开发人员希望放入其中的尽可能少或尽可能多的代码——例如，它们可以容纳处理信用卡信息的单个函数或秘密信号处理算法。
与容器一样，飞地的实际硬件级别隔离机制可以是 VM 级别隔离或进程级别隔离。例如，VM 级别隔离可用于创建侧车 VM，该侧车 VM 向基本 VM 公开简单的飞地接口。开发人员可以设计将具有不同特权的代码划分为不同飞地的服务。每个飞地应仅限于访问执行其功能所需的数据。遵循最小特权原则要求开发人员进行额外的服务重构工作，但这会产生最高的安全性和最弹性的应用程序。
飞地将呈现的接口仍然有很大的设计空间。OpenEnclave SDK6 最初来自微软，现在是机密计算联盟的一部分，它提供 C 和 C++ 环境，为针对多种类型的机密硬件的小型 TCB 开发提供了一个相对容易的起点。其他 SDK 已开始为 Rust 等内存安全语言涌现。
机密计算应用
机密计算使将敏感工作负载外包到云成为可能，甚至引入了新的计算模式。例如，它支持安全和机密的的多方计算，其中可能互不信任的用户组可以运行联合计算并共享他们的结果，而无需向彼此或任何可以物理或逻辑访问执行计算的硬件的人员透露他们的私有输入。这应该会导致各种机密计算应用程序的开发——事实上，这些属性已经导致多个应用领域的进步。
机密 AI
机器学习算法正在迅速增加对更多计算和更大数据集的需求。与此同时，它们的应用引发了重大的安全和隐私问题。云的弹性和可扩展性已经成为此类计算的自然选择，但机密计算使其能够利用云获得强大的安全保证。
例如，在医疗和制药应用中，训练数据可能包括个人的私人医疗保健记录，而生成的模型可能用于做出临床决策。在飞地内部运行训练过程可确保数据不会被任何其他人查看或修改。它还提供完整性保证（以及强大的审计日志），证明预期的训练算法已在指定的记录上使用指定的软件堆栈运行。作为这些保证的特例，生成的模型可以被加密、签名并配备密钥释放策略，以确保它仅在另一个将强制执行特定访问控制和使用限制的飞地内解锁。例如，飞地可以通过限制模型被查询的次数并在其结果中添加噪声来强制执行差分隐私。
例如，租户可以利用机密云计算为其自己的客户提供医疗诊断服务，并提供技术保证，保证：（1）它无法窃取或滥用为此目的由专业第三方提供和维护的模型；（2）它无法访问任何个人医疗信息来查询、存储或将模型用于任何其他目的。
机密数据库和分析
数据库系统存储和处理敏感且业务关键的数据，例如个人记录、财务信息和政府数据。未经授权访问此类数据可能会造成严重后果，包括人身伤害以及客户信任和竞争优势的丧失。当前的数据库系统提供复杂的访问控制机制，例如基于角色的访问控制。这些机制在对抗更强大的攻击者（例如那些具有管理或物理访问服务器权限的攻击者）时效果有限。在一个常见的例子中，负责管理数据库的个人或外包团队对公司构成了巨大的内部威胁。因为此个人或团队正在管理数据库系统，所以他们能够看到所有机密数据，即使他们没有访问权限的需要。
在过去的几年中，加密数据库的概念已被提出作为一种强制执行更强大的加密访问控制的方式。在加密数据库中，数据在静态和计算期间都保持加密状态，使用的密钥甚至数据库或服务器管理员都无法访问。数据仅在数据所有者定义的可信边界内以明文形式出现。
加密数据库可以通过多种方式实现。一种方法（由 CryptDB 和其他相关系统提出）是在可信客户端上使用部分同态加密方案加密数据。另一种方法是在可信执行环境（例如英特尔 SGX 飞地）中解密、处理和重新加密敏感数据。EnclaveDB7 提出了这种方法，微软的 SQL Server 在 Always Encrypted 功能中采用了相关方法。设计范围从在处理时将流式列式数据导入飞地到将所有敏感数据和查询放置在飞地内。基于 TEE 的方法有可能提供更强的安全保证，例如查询处理的完整性和新鲜度、查询的机密性、防篡改审计等。它们也更灵活（即，它们允许任何类型的计算，并且可以支持复杂的访问控制策略，例如基于属性的访问控制）。除了数据处理外，TEE 还是强制执行和审计细粒度密钥释放策略的自然选择。
机密多方协作
飞地5支持的安全和机密的多方计算也促进了数据集所有者之间的新型协作，从而使训练数据的数量成倍增加。因此，多方模型可以基于来自多家医院的联合数据集进行训练，而无需泄露组成数据集（通常受复杂的法规和商业考虑因素的约束），而不是仅限于来自单个医院的数据。尽管可能无需汇集数据集即可训练类似的模型，例如，使用联邦学习或本地差分隐私，但这些替代方案将涉及算法更改、额外资源和效用损失。机密多方协作的场景存在于许多其他领域，包括金融、能源、气候研究和政府。
机密账本
在云数据中心中运行的通用应用程序需要一种方法来说服其用户它们正在正确运行。已经出现了新的框架来帮助开发人员构建这种新型的可信应用程序。这些框架提供了一种构建在 TEE 内部运行并生成其执行的可验证账本的可信应用程序的简单方法。例如，CCF（机密联盟框架）4 在键值存储上提供防篡改账本和事务性更新。这用于构建许多云服务，例如 Azure 机密账本，它提供防篡改、高性能、机密账本，应用程序可以使用它来存储用于可审计性和可验证性的通用日志记录。这些属性允许一类新的应用程序，这些应用程序需要互不信任的各方之间的协调，以及出于法律原因需要可验证执行的应用程序。
可信应用程序通常使用 TEE 证明以及安全消息传递通道。这使用户确信他们正在以安全和机密的方式连接到正确的应用程序。CCF 和其他类似的框架还分发和复制应用程序逻辑的执行，以确保执行的活性和完整性，即使系统中的一部分节点是恶意的或被破坏的。特别是，CCF 支持拜占庭容错，其中可以容忍任意恶意行为，以及崩溃容错配置。
基础服务
可用性对于任何旨在广泛采用的安全技术至关重要。很容易想象一个简单的配置开关，让租户可以开启现有工作负载的“机密计算”，但这究竟意味着什么？例如，加密虚拟机增加了一些纵深防御，但在很大程度上是安全上的障眼法，除非它与可信的内容证明机制相结合：如果提供商控制了初始虚拟机，而租户没有任何机制来审查它，那么提供商仍然是完全可信的。
为了获得有意义的端到端保护，工作负载的输入和输出必须加密，并且相关的数据密钥必须仅发布给为该工作负载分配的 TEE。这涉及到跟踪为此工作负载授权的平台和代码，同时启用平台和代码的更新。为了方便起见，大多数租户可能会选择将这些任务委托给云服务。为了安全起见，这些服务本身必须部署在 TEE 中，彼此依赖以实现诸如安全身份、密钥和日志记录等核心功能。
下一节概述了机密计算生态系统核心的服务，以支持部署机密工作负载的租户和贡献代码的应用程序开发人员。
密钥管理和证明服务
如果机密服务需要访问任何持久性数据（例如，虚拟机磁盘映像），那么它需要从某个地方检索密钥。对于传统的客户端磁盘加密，密钥可以存储在 TPM 中，并由租户输入密码来解锁。在云场景中，存储部分相对容易解决，可以使用托管 HSM（硬件安全模块），通过诸如 Azure Key Vault 之类的服务，或者使用管理密钥存储的持久性机密计算服务。然而，要求租户为他们启动的每个虚拟机、容器或其他服务输入密码，并不是一个可扩展的解决方案。
当租户授予对其数据的访问权限时，他们是基于对证明中包含的信息以及他们可用的其他元数据的审查做出策略决策。此过程可以由机密云服务自动化，例如 Microsoft Azure Attestation：在机密计算开始时，新创建的 TEE 与证明服务建立安全连接，并提交其证明材料。该服务根据租户先前上传的授权策略检查这些材料，如果成功，则颁发相应的凭据。然后，TEE 可以使用这些凭据来访问租户数据。例如，它可以出示由证明服务颁发的令牌，以从 HSM 获取当前的解密密钥。
云提供商在一组授权的 TEE 之上运行证明服务，然后租户可以执行一次手动设置步骤（相当于输入密码），并提供策略和凭据，以便该服务可以代表他们自动授权数千个虚拟机。例如，在云中，该服务可以自动授权 TEE 之间的迁移以及从其加密检查点恢复。
为此，该服务维护一个最新的、一致的平台证书缓存，用于其数据中心中预置的所有 TEE。它频繁检查证书吊销，并且可以管理可信硬件的固件或微代码更新的一致部署（通常需要新的证书集合）。因此，该服务可以支持精确的、有状态的策略声明，例如“此任务必须在 SGX enclave 中运行，在 Intel SGX v2.1 平台上运行，部署在德国 Azure 数据中心中，在分配给租户的虚拟机中运行，并由截至今天有效的证书支持”，而不仅仅是“此任务必须在 enclave 中运行”。
从云的角度来看，重要的是既要最大限度地减少不同硬件产品的数量，又要确保软件在所有产品之间的可移植性。X86 虚拟机可以愉快地在 Intel 或 AMD 硬件上工作，即使两者上的虚拟化扩展不同。如果机密虚拟机需要在 AMD 和 Intel 硬件之间以不同的方式实现，这将大大增加采用的障碍。通过分解出特定于硬件的细节，证明服务使其他服务能够独立于平台。例如，它使传统 HSM 的集成成为可能，而无需为不同形式的机密 enclave、虚拟机和容器定制它们。
代码透明性
远程证明使租户（或他们信任的服务）能够验证其计算的平台和软件 TCB，但它不能确保此 TCB 是可信的。为此，租户最好收集并审查其应用程序、运行时 SDK 和库以及编译工具链的所有源代码的安全性。然后，他们将重建其工作负载的软件映像，并检查其哈希是否与证明中提供的哈希匹配。由于以下几个原因，这项任务令人望而生畏
• 即使对于简单的应用程序，它也涉及来自不同来源的大量软件。
• 这部分软件可能是专有的或机密的，阻碍了对其的审查。
• 现代构建系统对其环境中的细节很敏感，导致代码不可重现。
• 云计算鼓励敏捷开发，并促进无缝代码更新，通常无需重启应用程序。
• 可能需要紧急补丁来缓解新披露的漏洞，并且它们很难等待对每个受影响的应用程序进行安全审查。
为了方便这项任务，或者至少分摊其成本，代码透明度服务可以安全地记录用于机密计算的软件依赖项、构建环境和生成的二进制文件。云提供商可以将此服务作为机密账本运营，系统地执行代码更新策略，签署生成的二进制文件，并维护其所有操作的公共、不可变的日志。因此，租户可以将云证明和密钥管理服务配置为授权任何此类签名的二进制文件用于机密应用程序。
例如，租户可以将代码透明度服务配置为从信誉良好的软件供应商处自动安装紧急补丁，前提是它们已正确签名并发布在其指定的 GitHub 项目的发布分支上。（更保守地，他们可能还需要来自云提供商或指定专家的签名认可。）即使补丁已损坏，该服务至少将提供强大的审计跟踪，以便事后对其进行审查。软件供应商可能仍然能够破坏租户的安全保证，但这样做会使其声誉受到威胁。代码透明度服务还可以用于缓解软件供应链攻击，因为它为软件物料清单 (SBoM) 提供可审计的出处和监管链。
机密计算是云的未来
机密计算通过使租户能够远程控制其工作负载的 TCB 来提供强大的云安全保证：它明确了他们仍然需要信任的（最小）硬件、软件和服务；并且它提供了强大的技术保护，以防止来自其余部分的任何攻击——防止来自其他租户甚至来自云提供商的潜在攻击。这反过来使租户能够为其最敏感的数据开发和部署他们自己的机密应用程序。
机密云计算仍处于起步阶段，但我们相信它最终将变得无处不在，就像其他隐私和完整性机制（如 TLS 和静态加密）一样。机密计算的硬件（CPU、FPGA 和加速器）应该快速发展，这是整个行业共同努力的结果，旨在提供开放、稳健、标准化、平台无关的功能。随着这些功能的可用，它们将为云结构奠定基础，该结构将被划分为小的 TCB，其中每个组件将仅有权访问执行其功能所需的信息。
这个基础将支持运行机密虚拟机，以及更高级别的平台服务。虽然某些服务可能永远不会在完全机密模式下运行，但它们将受益于新的、更安全的基础。随着软件工程工具朝着实现默认机密的分区化开发方向发展，这些保证将很容易添加。
想象一下，在未来，最终用户可以完全且可验证地控制任何云服务如何使用他们的数据。如果他们希望索引其组织的文档，则机密索引服务可以保证组织外部的任何人永远看不到该数据。机密视频会议服务可以保证端到端加密，而不会牺牲录制会话或提供转录的能力，输出发送到机密文件共享服务，除了组织的设备或机密虚拟机外，永远不会在任何地方以未加密的形式出现。机密电子邮件系统可以类似地保护隐私，而不会影响搜索或创作助手等功能。最终，机密计算将实现许多创新的云服务，同时允许用户保留对其数据的完全控制权。
参考文献
1. AWS Nitro Enclaves。AWS；https://aws.amazon.com/ec2/nitro/nitro-enclaves/。
2. Baumann, A., Peinado, M., Hunt, G. 2014。使用 Haven 将应用程序与不受信任的云隔离。《第 11 届 Usenix 操作系统设计与实现研讨会论文集》；https://www.usenix.org/conference/osdi14/technical-sessions/presentation/baumann。
3. Carruth, C. 2018。推测加载硬化。LLVM 编译器基础设施；https://llvm.net.cn/docs/SpeculativeLoadHardening.html。
4. 机密联盟框架。GitHub；https://github.com/microsoft/CCF。
5. Ohrimenko, O., 等人。2016。在可信处理器上进行不经意的多方机器学习。《第 25 届 Usenix 安全研讨会论文集》，619-636；https://dl.acm.org/doi/10.5555/3241094.3241143。
6. Open Enclave SDK。GitHub；https://github.com/openenclave/openenclave。
7. Priebe, C., Vaswani, K., Costa, M. 2018。EnclaveDB：使用 SGX 的安全数据库。《2018 年 IEEE 安全与隐私研讨会论文集》；https://ieeexplore.ieee.org/document/8418608。
8. Qureshi, M. K. 2019。加密地址缓存的新攻击和防御。《第 46 届计算机体系结构国际研讨会论文集》，360-371；https://dl.acm.org/doi/10.1145/3307650.3322246。
9. Sakalis, C., 等人。2019。通过选择性延迟和值预测实现高效的不可见推测执行。《计算机体系结构国际研讨会论文集》；https://www.researchgate.net/publication/333755760_Efficient_Invisible_Speculative_Execution_through_Selective_Delay_and_Value_Prediction。
10. Schuster, F., 等人。2015。VC3：在云中使用 SGX 进行可信数据分析。《2010 年 IEEE 安全与隐私研讨会论文集》，38-54；https://dl.acm.org/doi/10.1109/SP.2015.10。
11. SGX-LKL。GitHub；https://github.com/lsds/sgx-lkl。
12. Volos, S., 等人。2018。Graviton：GPU 上的可信执行环境。《第 13 届 Usenix 操作系统设计与实现研讨会论文集》；https://www.usenix.org/system/files/osdi18-volos.pdf。
13. Werner, M., 等人。2019。ScatterCache：通过缓存集随机化阻止缓存攻击。《第 28 届 Usenix 安全研讨会论文集》；https://www.usenix.org/system/files/sec19-werner.pdf。
14. Yan, M., 等人。2018。InvisiSpec：在缓存层次结构中使推测执行不可见。《第 51 届年度 IEEE/ 国际微体系结构研讨会论文集》；https://iacoma.cs.uiuc.edu/iacoma-papers/micro18.pdf。
Mark Russinovich 是 Microsoft Azure 的首席技术官，他在那里领导微软云计算平台的技术战略和架构。
Manuel Costa 是微软剑桥研究院的合作伙伴研究经理，他在那里领导机密计算研究主题。他对推进安全和隐私、操作系统和编程语言的最新技术感兴趣。
Cédric Fournet 是微软研究院机密计算组的高级首席研究经理。他对安全、隐私、密码学、分布式编程和形式化验证软件感兴趣。
David Chisnall 是微软剑桥研究院的首席研究员，他在那里从事硬件/软件协同安全设计。他的工作范围涵盖计算机体系结构、操作系统、编译器和语言设计。他也是一位活跃的开源开发人员，自 2008 年以来为 LLVM 做出贡献，并在 FreeBSD 核心团队中任职两届。
Antoine Delignat-Lavaud 在巴黎高等师范学院获得计算机科学博士学位，在 Inria Paris 的 PROSECCO 团队从事密码协议、编程语言和形式化验证研究，并将其应用于 Web 安全性。他是微软剑桥研究院机密计算组的首席研究员，正在研究基于硬件安全保证构建机密云服务的协议和系统。
Sylvan Clebsch 是微软剑桥研究院的高级首席研究工程师。他的工作包括机密联盟框架、Verona 和 Pony 编程语言。
Kapil Vaswani 是微软研究院机密计算组的首席研究员。他的研究重点是构建安全、稳健和透明的系统。他率先开展了使用可信硬件的安全数据库和新型可信硬件的研究。
Vikas Bhatia 是 Azure 机密计算的产品主管。在加入 Azure 之前，他曾在 Windows 开发人员平台组、云游戏流媒体、Xbox One 和 Visual C++ 编译器中领导产品团队。
版权 © 2021 归所有者/作者所有。出版权已许可给 。
最初发表于 Queue vol. 19, no. 1—
在 数字图书馆 中评论本文
更多相关文章
Mark Russinovich, Cédric Fournet, Greg Zaverucha, Josh Benaloh, Brandon Murdoch, Manuel Costa - 机密计算证明
证明是用于完整性和隐私的强大工具，使验证者能够委托计算并仍然验证其正确执行，并使证明者能够保持计算细节的私密性。CCP 和 ZKP 都可以实现健全性和零知识，但存在重要差异。CCP 依赖于硬件信任假设，这会产生高性能和额外的证明者机密性保护，但对于某些应用程序来说可能是不可接受的。CCP 通常也更易于使用，特别是对于现有代码，而 ZKP 带来了巨大的证明者开销，这对于某些应用程序来说可能是不切实际的。
Raphael Auer, Rainer Böhme, Jeremy Clark, Didem Demirag - 央行数字货币的隐私格局
随着世界各地的中央银行转向数字化现金，隐私问题需要提到首位。所采取的路径可能取决于每个利益相关者群体的需求：注重隐私的用户、数据持有者和执法部门。
Sutapa Mondal, Mangesh S. Gharote, Sachin P. Lodha - 个人信息隐私
每次与外部服务的在线交互都会创建关于用户的数字记录和存储数据。这些外部服务可能是信用卡交易、医疗咨询、人口普查数据收集、选民登记等。尽管表面上收集数据是为了向公民提供更好的服务，但个人的隐私不可避免地会面临风险。随着互联网的日益普及和生成的数据量不断增加，数据保护，特别是保护个人隐私，已变得尤为重要。
Kallista Bonawitz, Peter Kairouz, Brendan McMahan, Daniel Ramage - 联邦学习与隐私
如果数据管理不当，集中式数据收集可能会使个人面临隐私风险，并使组织面临法律风险。联邦学习是一种机器学习设置，其中多个实体在中央服务器或服务提供商的协调下协作解决机器学习问题。每个客户端的原始数据都存储在本地，并且不交换或传输；相反，旨在立即聚合的重点更新用于实现学习目标。
© 保留所有权利。