【论文分享】ShEF: Shielded Enclaves for Cloud FPGAs 22‘ASPLOS

ABSTRACT

FPGA 现在在公共云中用于加速各种应用程序，包括许多处理财务和医疗记录等敏感数据的应用程序。我们推出了 ShEF，这是一种用于基于云的可重构加速器的可信执行环境 (TEE)。 ShEF 独立于基于 CPU 的 TEE，并允许在威胁模型下安全执行，其中攻击者可以控制连接到 FPGA 的 CPU 上运行的所有软件，对 FPGA 进行物理访问，并且可以破坏云提供商的 FPGA 接口逻辑。 ShEF 提供安全启动和远程认证流程，该流程仅依赖于现有 FPGA 机制来实现信任根。它还包括一个 Shield 组件，可在使用加速器时提供对数据的安全访问。 Shield 具有高度可定制性和可扩展性，允许用户以最低的性能和面积开销打造适合其加速器的内存访问模式、带宽和安全要求的定制安全解决方案。我们描述了现有云 FPGA 的 ShEF 原型实现，将 ShEF 映射到高性能且安全的存储应用程序，并使用五个附加加速器衡量可定制安全性的性能优势。

INTRODUCTION

云计算是一把双刃剑。云服务器提供无与伦比的功能，高度可用、易于部署、并具有广泛的可扩展性。这种灵活性对于机器学习等数据驱动的应用程序至关重要。然而，由于云应用程序的可信计算基础（TCB）的相应增长，流经共享基础设施的大量数据带来了新的安全和隐私问题。当用户在云上处理敏感数据时，他们隐含地信任众多实体，包括底层硬件、操作系统/VMM、存储和数据库系统以及身份和访问管理服务的开发人员和运营商。他们还信任能够物理访问基础设施的云服务提供商 (CSP) 的员工。最近的数据泄露表明，堆栈任何层的漏洞都可能导致高度敏感信息的泄露，例如数亿人的健康和财务记录[5,9,66]。

这些问题导致了软件安全机制的发展，以保护云中的敏感数据。用户可以使用纯加密解决方案，例如同态加密（HE）[46]，或集成来自大量库的临时加密方案。不幸的是，对于大多数实际应用来说，HE 的成本过高 [27]。传统的密码库，假设正确性，仍然依赖于大型 TCB，包括由潜在恶意员工控制的 CSP 的多层软件。

基于 CPU 的可信执行环境（TEE），例如 Intel SGX [33] 和 ARM TrustZone [17] 缩小了 TCB。即使受到恶意特权软件和物理攻击，TEE 也可以为用户代码和数据提供基于硬件的隔离。然而，硬件本质上是经过强化的，存在许多安全问题。首先，密码学和密码分析在不断发展；标准和最佳实践不断改进，特别是随着量子计算等新计算范式的引入[26]。其次，应用程序使用多种计算和通信模式，每种模式都需要不同级别的保护。例如，某些应用程序可能只需要对流数据进行身份验证加密，而其他应用程序会对给定地址进行多次读写，因此需要额外的安全性，例如 Merkle Trees [85]。最后，最近直接危害 SGX 的漏洞凸显了在现代 CPU 中实现无错误安全机制的难度 [28, 30, 58, 61, 65, 71, 80, 83, 91×93]。出于这些原因，需要具有增强制造后安全机制的灵活性，这是强化的 CPU 安全机制所不提供的特性。

此外，基于 CPU 的 TEE 不能直接在 GPU [31]、FPGA [45, 95] 或 TPU [55] 等加速器上实现隔离执行。流程扩展的放缓趋势正在推动专用硬件以实现可扩展的性能[50]。因此，包括亚马逊[2]、微软[8]、华为[11]和百度[13]在内的CSP正在快速部署远程FPGA以满足计算量的增加需求，允许用户部署从应用程序代码生成的自定义加速器[32,48,59,69,81]。

因此，支持远程 FPGA 上的安全计算对于许多新兴应用至关重要，例如医疗、金融、机器学习 (ML) 和监管用例，这些应用既需要安全性又需要加速。例如，FPGA 处于加速基因组测序的最前沿 [89, 98]。 FPGA 还广泛用于加速深度神经网络 (DNN) [82]，这对医疗诊断具有重大影响 [40]。最近的工作甚至直接要求加速器 TEE（包括 FPGA）作为云中分布式联合学习的重要组成部分 [101] 和符合 GDPR 的存储系统 [53]。这些敏感的加速器在业界得到广泛采用，Xilinx 直接营销用于基于 ML 的诊断的 FPGA [21]，无数公司为基因组学 [7,14,15]、财务分析 [10] 和网络安全提供 AWS F1 加速器 [ 12] AWS Marketplace 上的应用程序。

不幸的是，最近提出的加速器 TEE（包括 FPGA）要么不安全，无法抵御直接物理攻击 [54, 105]，需要进行根本性的硬件更改 [54, 94, 105]，只能解决孤立的挑战，例如证明 [36, 52, 72] , 99]，或依赖外部 CPU TEE [52, 54, 94]。此外，他们忽略了 Shell 逻辑 [3,57,60,88]，这是云 FPGA 逻辑的基本不可信操作系统。

我们通过云 FPGA 屏蔽区 (ShEF) 框架来应对这些挑战，该框架将基于硬件的定制安全性和可定制的 FPGA 加速结合在一起。 ShEF 将 TEE [78] 提供的机密性、完整性、新鲜性和隔离保证应用于定制 FPGA 加速器，即使存在恶意软件和硬件逻辑或物理攻击。 SheEF 针对当前的云 FPGA 部署和商用 FPGA 硬件。虽然 ShEF 依赖 CPU 进行网络和数据传输，但它与 CPU TEE 或在 CPU 上运行的其他软件分离，并且不信任 CPU TEE 或其他在 CPU 上运行的软件。因此，ShEF 最大限度地减少了 TCB，并避免了上述硬硬件问题。 ShEF 提供定制作为一项关键功能，使用户能够调整安全机制，以满足其加速器独特的带宽要求、内存访问特征和威胁模型。通过仅提供正确级别的保护，ShEF 允许用户以最低的性能和面积成本解决其威胁模型。

ShEF 由两个主要部分组成。 SheEF 启动过程以软件安全内核为中心，该内核在当前现有的 FPGA 安全机制之上构建信任链。其主要目的是 (a) 将加速器加载到 FPGA 上已知且可信的状态，(b) 向用户选择的远程验证器证明该状态，以及 © 确保 JTAG 等敏感端口在运行期间受到保护。运行时。

一旦加速器设计安全启动到 FPGA 上，ShEF Shield 就会与主机软件进行通信，并通过一组高度可定制和可扩展的软逻辑引擎来保护加速器的敏感数据。用户可以自定义一组丰富的参数，例如加密逻辑并行性、内存访问模式的优化、加密原语、身份验证块大小以及各个内存区域的密钥大小。例如，读取大权重块的 DNN 加速器可以选择使用大加密块来分摊完整性检查开销并放弃专门针对这些权重的昂贵的重放攻击对策。执行多个小型读取和写入（例如，用于图形处理）的其他加速器可能相反地选择较小的块大小以防止不必要的数据传输并使用重量级内存身份验证技术[37]。

总之，我们做出以下贡献：

我们确定了在云 FPGA 上启用 TEE 的要求以及由于当前云 FPGA 设备和环境而导致的先前工作未解决的差距。

我们在当前 FPGA 设备上实施端到端工作流程，为云 FPGA 提供第一个全面且可定制的 TEE。

我们在工作流程之上提供了支持重要 TEE 构建块的协议，包括安全启动和远程认证。

我们将可定制性视为云 FPGA 的关键要求，并通过模块化 Shield 提供解决方案，以轻松定制 SheEF，以满足基于 FPGA 的加速器的不同安全和性能要求。

我们在代表性 FPGA 上实现了端到端 SheEF 工作流程，并为具有不同性能要求和访问模式的六个加速器配置了 Shield 的并行性和安全性，包括 GDPR 安全存储基准 [53] 和 DNNWeaver [81]。我们证明，ShEF 将 AWS F1 实例上的开销降至 0-122%，面积为 3.1-11%。 ShEF 是开源的1，允许社区审查并构建其设计。

BACKGROUND AND MOTIVATION

ShEF 的动机是两个重要趋势的融合 [49]。首先，在针对 CPU [28、58、61、65、80]、特别是 SGX [30、71、83、91×93] 的持续微架构侧通道攻击的推动下，硬件安全正在成为一等公民。其次，登纳德缩放的结束正在促使人们转向节能的特定领域加速器（DSA）。目前尚不清楚如何弥补这一差距并为具有不同安全和性能要求的 DSA 提供安全计算。

ShEF 实现了最近对 FPGA TEE 的要求，以提供安全的远程存储 [53]。然而，ShEF 更进一步，提出了利用云 FPGA 的灵活性来实现安全远程加速的关键见解。机器学习 [48]、基因组学 [98]、多方计算 [97] 和模拟 [56] 等众多应用已经在云 FPGA 上使用 DSA。 SheEF 的目标是提供具有同等灵活性的安全保证，并为满足加速器特定需求的云 FPGA 创建定制 TEE。 TEE、FPGA 安全和云 FPGA 都是经过深入研究的领域。然而，合并这些域会带来本节讨论的新挑战。

Trusted Execution Environments (TEEs)

TEE 通过为不受信任方控制的设备上的用户敏感代码提供隔离环境并运行不受信任的特权软件来保护远程计算。

虽然 TEE 存在多种风格 [17、29、33、34、41、42、64、67、74、85×87]，但它们都提供了必要且足够的构建块 [78]。 TEE 构建在信任链上，首先以安全存储在芯片上的私钥形式的基于硬件的信任根开始 [78, 103]。安全启动过程通过在启动期间以加密方式测量每个组件（直至并包括安全应用程序）来扩展信任。然后，在远程证明过程中，以加密方式向安全应用程序的远程用户证明该完整性测量。一旦建立信任，机密数据就会从安全存储和 I/O 通道放入 TEE 中。安全应用程序处理数据，TEE 通过隔离的执行机制确保与系统其余部分的任何交互都是安全的。

在 FPGA 等空间计算平台的背景下，我们断言 TEE 也必须是可定制的。加速器使用精选的 I/O 接口，表现出广泛的内存访问和吞吐量特性，并且需要不同级别的安全机制。为所有加速器提供通用解决方案的静态 TEE 注定要么过度检测并浪费资源，要么无法满足每个加速器严格的吞吐量和安全性要求。

Conventional FPGA Security Mechanisms

Xilinx [20] 和 Intel [16] FPGA 面向国防和网络等关键任务应用，因此采用类似的威胁模型和安全机制 [24, 76]。也就是说，在将设备部署到不受信任的环境中之前，单个比特流开发人员必须能够物理且安全地访问 FPGA。安全机制的目标是确保 (a) 只能加载开发人员签名的比特流，(b) 比特流经过加密以防止逆向工程，以及 © FPGA 可以检测并响应物理篡改。这些机制在 Intel 和 Xilinx FPGA 中通过一系列从 BootROM 和可编程固件执行的冗余嵌入式处理器模块来启用 [24, 76]。以下我们将它们称为安全处理器块 (SPB)。

SPB 可以访问嵌入安全片上非易失性存储中的两条信息：AES 密钥和公共 ECDSA (Intel) 或 RSA (Xilinx) 密钥的哈希值。 AES 密钥可以通过物理不可克隆函数 (PUF) 进一步加密，防止 AES 密钥在物理攻击下受到损害。设备所有者或 IP 开发人员应在部署之前安全地离线嵌入必要的密钥。根据开发人员是否需要加密和/或身份验证，她可以使用 AES 密钥加密比特流和/或使用 ECDSA/RSA 私钥对其进行签名。然后，SPB 可以对比特流进行安全解密（使用 AES 密钥）和身份验证（使用公钥哈希）。最后，SPB 会主动监控任何篡改行为。

Remote FPGAs-as-a-Service

FPGA 正在成为主要云服务提供商 (CSP) 越来越重要的组件 [2,8,11,13]。最常见的示例是 AWS EC2 F1 实例，它提供 1、2 或 8 个专有的 Xilinx Virtex UltraScale+ VU9P FPGA，每个 FPGA 具有 64GB 本地 DDR4 内存，通过专用 PCIe x16 链路连接到主机 CPU。

F1 实例目前以传统的基础设施即服务 (IaaS) 方式提供，如图 1 所示。IP 供应商使用 AWS FPGA 开发套件 [3] 使用 Xilinx 的开发工具（例如 RTL、OpenCL 或C/C++ 高级综合 (HLS)。一旦加速器设计完成，开发人员就会将其编译成比特流二进制文件。 AWS 利用部分重新配置，允许通过单独的部分比特流对 FPGA 结构的不相交空间区域进行编程。 F1 实例配置有两个部分比特流：一个属于包含 Shell 逻辑的 CSP，另一个属于用户的加速器设计。 Shell 类似于操作系统，因为它为加速器提供虚拟化外设和调试功能（虚拟 JTAG/LED），同时保护物理 FPGA 免受恶意逻辑的影响 [88]。 Shell 是静态逻辑，持续在 FPGA 上运行。在设计时，开发人员将加速器模块的 I/O 端口连接到标准 Shell 接口。在部署时，用户利用命令行界面将其选择的部分比特流动态编程到剩余的可重新配置区域。一旦加速器被编程，主机CPU上的运行时程序就会启动加速器并通过在CPU存储器和FPGA器件存储器之间传输数据来促进执行。

Challenges for Secure and Customized Computing

ShEF 旨在通过提供关键的 TEE 构建模块，在云 FPGA 上实现安全和定制的计算。然而，FPGA 制造商做出的基本假设以及 FPGA 和 CPU 云产品之间的固有差异带来了先前工作未解决的重要挑战。

A lack of asymmetric keys.

如第 2.2 节所述，FPGA 制造商假设一个针对单个可信用户的威胁模型，该用户的 AES 密钥和公钥散列被加载到安全设施中的 FPGA 上。相比之下，云 TEE 需要由多个互不信任的各方使用，这些各方从未物理访问 FPGA。因此，FPGA TEE 必须在可用 AES 密钥之上构建硬件信任根和远程证明协议，这与 CPU 和之前的加速器 TEE 所采用的传统私钥相反 [33、51、54、78、94、 105]。

Presence of an untrusted Shell

此外，CPU 用于启用 TEE 构建块的许多机制并不适用于 FPGA 的空间架构。在 CPU 中，属于安全和不安全应用程序的线程在处理器上进行时间切片。因此，飞地可以使用 ISA 扩展直接访问安全硬件[33]，绕过不受信任的操作系统。例如，SGX ISA 扩展允许用户直接访问硬件机制来启动 enclave（ECREATE、EADD、EXTEND 和 EINIT）、生成证明报告和配置机密 (EREPORT)，并提供隔离执行（EENTER 和 EEXIT 以及新交所 MEE [47]）。同样，Keystone [64] 依赖于在 RISC-V 机器模式下运行的安全监视器，控制 ISA 定义的物理内存保护寄存器，以强制执行内存隔离。然而，在云 FPGA 中，结构与持久且不可信的 Shell 逻辑在空间上共享。任何和所有 I/O 端口都是不可信的，因为应用程序的自定义逻辑只能连接到 Shell 定义和公开的一系列 I/O 端口。

Lack of secure and flexible I/O

许多基于 FPGA 的加速器都处理数据密集型问题，并对片外 I/O 施加独特的安全要求。例如，一些加速器（例如，比特币矿工）仅需要安全的寄存器级访问，而其他加速器可能会表现出更复杂的内存访问，包括流式访问（例如，用于 DNN 权重）和随机访问（例如，用于图形处理）。正如我们在第 5 节中探讨的那样，每个加速器都需要不同的安全性和性能级别。目前关于 FPGA 安全性的工作 [25,35,36,52,72,99] 并没有解决由于 Shell 而导致的安全 I/O 的缺乏，也没有提供能够适应不同安全性和性能的安全机制不同加速器所需的级别。

Threat Model

我们假设图 1 中的综合威胁模型。攻击者试图破坏 FPGA 上运行的用户加速器处理的代码和数据的机密性和完整性。攻击者对 FPGA 设备制造后拥有完全的物理控制，并且能够控制特权 CPU 软件，例如操作系统、VMM 和设备驱动程序。此外，攻击者还能够控制特权 FPGA 逻辑，例如 AWS F1 Shell。我们假设任何片外存储器（包括 HBM）都可能受到损害，因为对手可以对片外总线执行物理攻击，或者通过 HBM 的 Shell 逻辑拦截流量。我们假设 FPGA 的物理封装、供应链和制造商是可信的。当我们使用主机程序传输数据时，我们假设主机 CPU 是不受信任的，并且不依赖于 CPU TEE 提供的任何安全机制。通过从 TCB 中移除主机 CPU，我们就不易受到最近困扰 CPU TEE 的攻击 [28、30、58、61、65、71、80、83、91×93]。

旁道攻击很大程度上是应用程序特定逻辑的函数。因此，我们并不声称能够防御所有可能的旁道攻击。相反，ShEF 的可定制性使我们能够为开发人员提供成熟的工具，以减轻常见的 FPGA 旁路攻击，例如受控通道 [100] 和功耗分析 [79, 102] 攻击（参见第 5.2 节）。我们希望开源社区能够利用 SheEF 的灵活性来贡献额外的安全机制。

我们不考虑拒绝服务 (DoS) 攻击，因为 CSP 对硬件具有物理控制权，并且可以简单地关闭其电源。当 FPGA 实例不可用时，CSP 会被激励防止因收入损失而遭受 DoS 攻击。我们不考虑针对 CSP 的攻击，因为 Shell 已经可以防止恶意 FPGA 用户的攻击。我们不考虑隐蔽渠道；我们假设用于生成加速器的工具流程是可信的并且在安全的环境中运行。

SHEF WORKFLOW AND SECURITY MODEL

ShEF 是一个端到端框架，使远程用户能够为云 FPGA 中的加速器设计定制 TEE。 ShEF 围绕云 FPGA 中的现有机制（即 Xilinx UltraScale+ 和 Intel Stratix 10）进行设计，不需要更改硬件。也就是说，ShEF 确实需要 FPGA 制造商和 CSP 双方的合作来实现第 2.1 节中描述的 TEE 要求。本节概述了 ShEF 及其组成部分，以及各方的责任。第 4 节描述了这些组件如何启用必需的 TEE 构建块。

ShEF框架中的四个关键方如图2所示。制造商负责制造物理FPGA芯片。云服务提供商 (CSP) 拥有物理数据中心，其中包含包含 FPGA 的服务器并将其提供给客户。 SheEF 将“客户”的概念分为两​​个独立的实体。 IP 供应商创建实际的加速器设计并将其分发给数据所有者（例如，在公共市场上 [4]）。然后，数据所有者从 CSP 租用 FPGA 实例，对加速器进行编程，并使用它来处理敏感数据。数据所有者应仅从受信任的 IP 供应商处采购加速器设计。当然，IP供应商和数据所有者可以是同一实体。数据所有者不必信任 CSP，但必须信任制造商和 IP 供应商。

现在，我们按照图 2 中的 SheEF 框架中的步骤回顾各方的角色以及如何委托信任。

Device Manufacturing (the Manufacturer).

SheEF 的安全基础始于制造商。制造商必须为每个 FPGA 设备提供两个密钥：AES 设备密钥和非对称公共/私有设备密钥对（例如 RSA 或 ECDSA）。制造商必须在生产过程中使用现有 FPGA 安全机制 1 将 AES 设备密钥刻录到电子熔丝或 BBRAM 中（并可选择使用 PUF 对其进行加密）。然后，制造商将非对称私有设备密钥嵌入到 FPGA SPB 固件中，然后使用 AES 设备密钥对固件进行加密 2 。制造商还必须通过受信任的证书颁发机构注册并发布公共设备密钥。

Accelerator Development (the IP Vendor).

IP供应商被信任在安全环境（例如安全工作站3）中开发加速器IP。在开发过程中，IP供应商将加速器的I/O端口连接到开源ShEF Shield模块而不是Shell接口。该扩展板提供可配置的运行时安全 I/O 和隔离执行（参见第 5 节）。由于 Shield 是参数化的 RTL 逻辑，公开与 Shell 相同的接口，因此 IP 供应商可以轻松地模拟其设计并将其与 Shield 集成。 IP 供应商可以使用单独的 Shield 模块保护多个加速器模块，从而实现多个隔离的执行环境 [57]。

然后，IP 供应商为加速器提供对称比特流加密密钥和非对称屏蔽加密密钥。比特流加密密钥用于比特流机密性，屏蔽加密密钥用于保护数据所有者和 FPGA 之间传输的数据（两者均在下面进行说明）。 IP 供应商将私有 Shield 加密密钥嵌入到每个相应的 Shield 模块中，并将整个设计编译为部分比特流。最后，IP供应商利用比特流加密密钥对部分比特流进行加密并分发加密的部分比特流4。 IP 供应商为所有用户创建一个加速器比特流；认证过程为每个数据所有者提供唯一的密钥。

Deployment (the Data Owner).

一旦数据所有者准备好使用加速器处理敏感数据，她就会从 CSP 5 获取云 FPGA 实例。然后，数据所有者指示 CSP 的 FPGA 驱动程序将加速器编程到 FPGA 上。 FPGA 驱动程序首先重置 FPGA，从而启动安全启动过程 6 。 SPB 首先使用 BootROM 代码从磁盘加载 SPB 固件，并使用其嵌入式 AES 设备密钥对其进行解密。 SPB 固件将 SheEF 安全内核从外部存储引导到专用安全内核处理器上，该处理器从其自己的私有片上存储器 7 执行。安全内核处理器可以是 FPGA 中保留的强化 CPU，也可以是包含软 CPU 的静态比特流（例如 MicroBlaze 或 Nios II）[76]。 SPB 固件对安全内核进行哈希处理，并使用其哈希值和私有设备密钥生成唯一的非对称密钥证明密钥对和相应的证书。因此，证明密钥以加密方式绑定到 FPGA 设备和特定的安全内核二进制文件。安全内核本身不包含机密信息，无法直接访问设备密钥，防止攻击者通过非法安全内核泄露设备密钥。安全内核只能访问通过安全通道（例如片上共享内存）从 SPB 固件接收的证明密钥。

SheEF 安全内核有三项主要工作。首先，它与数据所有者和 IP 供应商 8 执行远程证明（第 4 节）。通过此过程，数据所有者收到加密证明，表明 FPGA 设备、安全内核和加速器部分比特流是真实的，分别将制造商和 IP 供应商作为证书颁发机构。其次，它协调对 FPGA 结构的所有访问。 CSP 使用安全内核首先将 Shell 启动到其保留的静态逻辑区域。然后，安全内核通过在证明期间建立的安全通道从 IP 供应商安全地接收加速器的比特流加密密钥，并解密加速器并将其加载到 FPGA 上，通过部分重新配置将其连接到 Shell 接口 9 。由于Security Kernel是开源的，不包含任何秘密，CSP可以完全控制和审计Shell加载过程。同样，安全内核哈希包含在证明报告中（第 4 节）； IP 供应商在发送比特流加密密钥之前审核哈希值。最后，内核不断检查现有的硬件监视器。因此，它可以检测后门活动（例如 JTAG 和编程端口）[24, 76]，确保经过身份验证的加速器比特流在使用前不被修改，并防止任何物理攻击。虽然安全内核依赖主机 CPU 与 IP 供应商通信，但该通道经过身份验证和加密。

作为远程证明过程的一部分，数据所有者为每个 Shield 模块生成对称数据加密密钥（第 4 节）。数据加密密钥用于加密敏感的输入数据。数据所有者接收 IP 供应商的公共屏蔽加密密钥 10 ，并根据 IP 供应商的公共屏蔽加密密钥对数据加密密钥进行加密以生成加载密钥。随后使用加载密钥将数据加密密钥安全地提供到每个 ShEF Shield 模块中。

最后，数据所有者准备利用加速器，使用不可信主机CPU上的（不可信）ShEF主机程序来代理到加速器11的所有通信。主机程序将Load Key和加密数据转发到FPGA。 ShEF Shield 使用私有 Shield 加密密钥来解密加载密钥并检索数据加密密钥，从而在运行时保护用户数据。当输出准备就绪时，Shield 将使用数据加密密钥加密的结果通过主机程序传输回数据所有者。与安全内核的情况一样，通过 CPU 的所有通信都经过加密和验证。

SECURELY ENABLING TEE BUILDING BLOCKS

我们现在提出一个安全论点来演示 ShEF 如何启用所有 TEE 构建块（第 2.1 节）。

Hardware Root-of-Trust

虽然当前的 FPGA 不提供对必需的私有非对称密钥的硬件支持，但 ShEF 能够通过两个制造商提供的密钥构建信任根。 AES 设备密钥是真正的信任根，受到当前 FPGA 中现有关键任务安全机制的保护。私有设备密钥提供证明所需的非对称加密。尽管它嵌入在固件中，但它是使用 AES 设备密钥加密的，因此具有相同级别的信任。

Secure Boot

ShEF 的安全启动过程是作为当前 FPGA 启动机制的扩展而构建的，该机制首先在 SPB 上执行 BootROM 代码。 BootROM 使用 AES 设备密钥解密 SPB 固件，并将引导过程交给它。我们相信这一步是安全的，因为它已部署在众多关键任务 FPGA 应用中。

SPB 固件初始化后，其主要工作是引导对专用处理器上运行的安全内核的信任。为此，它从启动介质中读取安全内核并对其进行哈希处理以获得 H (SecKrnl)。 SPB 固件使用私有设备密钥 DeviceKeypriv 对哈希进行签名。它使用结果值作为密钥生成器的种子，以生成唯一的非对称证明密钥对 AttestKeypriv,pub，该密钥对以加密方式绑定到设备和安全内核二进制文件。它还通过计算 σSecKrnl = SignDeviceKey (H (SecKrnl), AttestKeypub) 在安全内核上生成证书和生成的证明密钥。然后，SPB 固件将安全内核加载到处理器上，并将证明密钥对和 σSecKrnl 放入安全内核的私有内存中。安全启动发生在加载任何其他软件之前，确保任何不受信任的软件都无法篡改或监视安全内核。如果安全内核处理器是软 CPU，则其部分比特流与安全内核一起进行哈希处理，并且比特流由 SPB 固件加载。

Remote Attestation

一旦安全内核启动，它就会等待远程证明请求。远程证明通过数据所有者、IP 供应商和安全内核之间的一系列消息交换来执行，如图 3 所示。通过远程证明，(a) 数据所有者生成用于保护敏感数据的临时数据加密密钥， (b) IP 供应商验证 FPGA 器件和比特流的真实性，以及 © 安全内核接收加载所需的比特流密钥加速器。数据所有者可以完全控制使用哪个 IP 供应商来为每个 FPGA 实例进行远程证明。

数据所有者初始化与可信IP供应商服务器1的标准TLS/SSL连接。 IP 供应商首先生成随机数 n，以及非对称验证密钥对 VerifKeypriv,pub。 IP供应商将n和VerifKeypub发送到安全内核2。

同时3，安全内核读取并散列适当的加密加速器比特流，获得H(EncBitstrKey(加速器))。使用 VerifKeypub 和 AttestKeypriv，安全内核执行密钥交换以与 IP 供应商生成共享的对称会话密钥，从而允许安全内核和 IP 供应商发送加密消息。为了防止任何中间人攻击，安全内核还使用AttestKeypriv对SessionKey进行签名，以获得新的证书σSessionKey。然后，安全内核生成证明报告α，其中包含n、H（EncBitstrKey（加速器））、AttestKeypub、H（SecKrnl）和σSecKrnl。安全内核使用AttestKeypriv对该报告进行签名以获得σα，并最终将α、σα和σSessionKey发送回IP Vendor 4 。

IP 供应商从通过制造商的证书颁发机构收到的 DeviceKeypub 开始对证明报告进行身份验证 5 。 IP供应商检查σSecKrnl是否由相应的DeviceKeypriv签名，证明合法的FPGA生成了证明报告。为了确保安全内核（和安全内核处理器，如果适用）有效，IP 供应商会查阅 ShEF 安全内核（和安全内核处理器）哈希值的公共列表。接下来，IP Vendor 使用 AttestKeypub 对证明报告进行身份验证，以确保 α 是使用 AttestKeypriv 进行签名的。 IP 供应商将签名的随机数与 n 进行匹配，以防止重放攻击，并将签名的比特流哈希与 H (EncBitstrKey (加速器)) 进行匹配，以确认正确的比特流已加载到安全内核的内存中。最后，IP 供应商首先使用 AttestKeypub 和 VerifKeypriv 生成与安全内核相同的 SessionKey，并验证 σSessionKey 是否由 AttestKeypriv 签名，从而建立到安全内核的安全通道。

使用会话密钥，IP供应商将BitstrKey安全地传输至安全内核6。安全内核解密加速器比特流并将其加载到 FPGA 上，确保包含敏感 IP 和屏蔽密钥的明文比特流仅在安全的片上存储器中进行处理。

Secure Storage and I/O

ShEF 通过 SheEF Shield 创建安全边界，对所有外部数据进行加密和身份验证，从而为数据所有者提供安全存储和 I/O。回想一下，IP 供应商在加速器中的每个 Shield 模块中配置了一个私有 Shield 加密密钥。作为远程证明会话的一部分，IP 供应商向数据所有者提供公共屏蔽加密密钥（例如，通过证书颁发机构）7。数据所有者生成至少一个数据加密密钥（例如，每个屏蔽模块一个）并根据公共屏蔽加密密钥对它们进行加密以获得加载密钥8。然后，数据所有者使用适当的数据加密密钥对安全位置中的敏感输入数据进行加密。加载密钥随后被发送到 FPGA 扩展板，FPGA 扩展板对其进行解密以获取数据加密钥匙。正如我们在第 5 节中讨论的那样，Shield 使用它来确保所有敏感数据在存储和 I/O 期间都受到保护。

Isolated Execution

Shield 和安全内核确保隔离执行。安全内核持续运行并监控 FPGA 编程和调试端口，以防止在执行期间篡改加速器逻辑。

SHEF SHIELD: SUPPORT FOR FLEXIBLE SECURITY

Shield 是一个高度可配置的 RTL 模块，通过插入加速器和 Shell 之间的端口来提供隔离执行以及安全 I/O 和存储。 Shield还实现了FPGA TEE必要的定制。 IP 供应商配置 Shield 以满足其加速器的内存访问模式以及性能和安全要求。

Shield Overview

图 4 显示了 Shield 如何适应由主机 CPU 和 FPGA 加速器组成的典型云 FPGA 部署。主机程序通过标准设备驱动程序协调执行。它首先将加载密钥加载到 FPGA 上，扩展板将其解密为数据加密密钥并存储在临时密钥存储中。然后，主机程序通过 CSP 的 Shell 接口在数据所有者和 Shield 之间代理加密的命令和数据。主机程序不受信任，不会观察到任何未加密的数据。

CSP 的 Shell 逻辑为主机程序和加速器提供两个主要接口。由 Shell 控制的 AXI4-Lite 接口向主机公开命令和少量数据的内存映射寄存器。加速器和主机分别驱动 AXI4 和 DMA 接口，通过 Shell 访问 FPGA 设备内存。虽然我们专注于保护设备内存，但 Shell 通常为内存和 PCIe 提供通用 AXI4 接口 [3]。因此，Shield 还可以通过相同的 AXI4 接口支持其他接口，例如 PCIe。

Shield 提供了一个包装器模块，可以透明地保护这些接口。主机程序像以前一样通过 AXI4-Lite 访问寄存器，加速器通过相同的 AXI4 协议访问设备内存。 Shield 透明地解密和加密主机程序、加速器和设备内存之间的 I/O，如图 4 所示。因此，IP 供应商可以在设计时以即插即用的方式简单地合并和配置 Shield。提供经过身份验证的加密的加密模块是 Shield 的核心。我们使用 AES-CTR + HMAC 模块作为默认值，并在第 6.2.4 节中提供可配置的替代方案。

Register interface

注册接口使用数据所有者的数据加密密钥提供经过身份验证的加密。主机程序内存映射加速器可访问的寄存器，并通过指针读取/写入加密的数据和命令。对于来自主机程序的写入，Shield 在将数据存储到加速器的明文寄存器之前对数据进行解密和验证。类似地，当主机程序读取映射地址时，相应的明文寄存器在发送到Shell之前会被加密和标记。 Shield提供如图4所示的寄存器文件；用户可以选择使用自己的寄存器文件与 Shield，只需解密/验证 AXI4-Lite 接口即可。此外，由于 AXI4-Lite 寄存器地址可能会泄露敏感信息，因此 Shield 提供了通过所有寄存器的公共地址对地址和数据进行加密的附加选项。在这种情况下，扩展板将解密并代理数据到/来自适当的明文寄存器。

A Flexible Memory Interface

Why Flexibility Is Necessary

如图 4 所示，Shield 公开了与 Shell 相同的一组 AXI4 接口。虽然接口是通用的，但加速器在使用设备内存时遵循不同的范例。一些加速器从内存中流入大块数据，在片上缓冲区中执行随机访问，并将结果流出到单独的内存区域。例如，深度神经网络 (DNN) 以大块权重形式进行流式传输。在图形处理等应用中，加速器使用非顺序数据相关内存访问。即使单个加速器也可以在内存区域中表现出不同的范式，例如，在 DNN 中，用于权重的大流读取和用于激活的较小读取/写入。

加速器的多样性（就内存区域的读/写次数以及每次突发中传输的数据量而言）对 Shield 具有性能和安全性影响。首先，经过身份验证的加密（Shield 的核心安全机制）需要在可变的块大小上执行。较小的块需要更多的读取请求，完整性标签的计算和存储开销较高，而过大的块会传输不必要的数据字节。正确调整每个加速器内存区域的块粒度非常重要。

其次，读取和写入同一块内存的加速器会产生额外的漏洞。通过块及其地址计算 MAC 可防止直接修改内存内容的欺骗攻击和将内存内容从一个地址复制到另一个地址的拼接攻击 [37]。然而，它并不排除重放攻击，即返回旧值进行读取，因为相应的 MAC 标签是有效的。为了防止重放攻击，安全处理器采用 Merkle 树验证方案 [85]，其中 MAC 被组织在树中。由于 SRAM 在 CPU 中很珍贵，因此只有根节点始终保留在片上，而叶节点在访问其相应地址时会进行验证。

Designing for Flexibility

Shield 的内存接口旨在允许 IP 供应商配置其功能和性能，从而实现针对每个加速器定制的定制 TEE。存储器接口由一个或多个引擎组组成。每个突发请求都由 Shield 中的突发解码器进行转换，该解码器查阅 IP 供应商指定的内存区域的映射，并将每个地址范围映射到其中一个引擎集。每个引擎组都包括加密和身份验证引擎以及片上缓冲区和计数器。

IP 供应商可以单独配置每个内存区域的引擎集，以针对目标应用程序的不同需求和威胁模型进行优化。我们回顾一下当前 Shield 实现中的配置选项：

Cryptographic engines

每个引擎集包含可配置的加密 (AES) 和身份验证 (HMAC/PMAC) 引擎。 AES 引擎包含 S-box 的内部 256 字节查找表。在设计时，每个引擎 S-box 最多可以复制 16 次，通过并行查找减少 AES 延迟，但代价是更高的资源消耗。用户还可以在比特流编译期间配置 AES 密钥大小（128 或 256 位）。由于引擎公开了一个简单的有效/就绪接口，IP 供应商可以简单地替换新的加密引擎。我们在第 6.2.4 节中通过用 PMAC 引擎代替 HMAC 来演示这种灵活性，以实现并行 MAC 计算。因此，IP 供应商可以实例化每个引擎的多个实例以增加并行性，甚至使用他们自己的设计。

Chunk size.

IP供应商表示每个存储器区域的块大小Cmem，其指定每个经过验证的加密块的粒度。每个块都与一个 12 字节初始化向量 (IV) 相关联，每个连续块的初始化向量加 1，以确保没有两个密文块重用相同的 IV。每个块都通过存储在 DRAM 中的 16 字节 MAC 标签以加密后 MAC 模式进行身份验证。通过对流模式使用较大的 Cmem 值，IP 供应商可以更好地分摊 MAC 标签开销。 Cmem 可以是任意大小，从一个字节到整个 FPGA 内存。

On-chip buffers

每个引擎组可选地包括一个缓冲区，使用 Block RAM 或 UltraRAM 实现，从而减少小内存区域内随机访问的开销。它存储解密和验证的明文数据及其地址范围，可以将其视为行大小为 Cmem 的缓存。如果突发请求命中缓冲区，引擎将处理所有传输，而无需访问 DRAM。对于未命中，引擎集仅生成突发请求以从 DRAM 读取整个 Cmem 字节块和 16 字节 MAC 标签。引擎组解密并验证并行返回密文并填充缓冲区行。如果缓冲区需要逐出修改的行，则引擎集会加密该行并通过密文计算 MAC 标签，然后对 DRAM 执行必要的写入。对于写入，引擎集可以首先以与读取相同的方式填充缓冲区行。或者，如果相应的块仅写入一次而不读取（例如，流式写入），则IP供应商可以简单地将片上缓冲区清零，从而避免不必要的读取。

Advanced integrity verification

如果加速器多次读取和写入同一块，则需要额外的机制来防止重放攻击。 Shield 支持优化的 Bonsai Merkle Trees [77]，它通过计数器而不是数据块创建 Merkle Trees。

Merkle 树对于需要从 DRAM 访问每个树节点的 FPGA 设计来说非常昂贵，这与可以从多层缓存中受益的 CPU 不同。我们观察到 Merkle 树在 CPU TEE 中使用，因为 (a) CPU 中的片上存储很少，(b) 安全处理器必须在数 GB 内存上保护相对较小的缓存行大小的块 (64B)。然而，加速器不会面临同样的问题，因为 (a) 现代 FPGA 通过 UltraRAM [19] 等新技术提供更多的片上存储器，以及 (b) 加速器通常在较小的地址区域上运行，并且可以利用大型 Cmem大块。因此，ShEF 提供了一种更简单、更高效的替代方案，它利用 FPGA 的多余片上 RAM 仅在所需的地址区域（即多次读写块的区域）存储计数器。

具体地，除了上述加密认证机制之外，还为这些地址区域配置片上计数器模块。每次将块 i 写入 DRAM 时，引擎组都会将片上计数器值 ctri 加 1。每次从 DRAM 读取块 i 时，都会生成一个标签 MAC(i, ciphertexti, ctri )，并根据片外标签进行验证。在这种情况下，只需要一次额外的 DRAM 访问，从而消除了与 Merkle 树相关的过多片外访问。由于 IP 供应商可以根据每个特定工作负载定制 Cmem、计数器大小和内存区域大小，因此可以最大限度地减少多余的存储开销。

Side Channels

Shield 的灵活性还可以帮助减轻第 2.4 节中讨论的许多侧信道攻击。对于受控通道攻击，IP 供应商可以通过增加 Cmem 作为有效对策来显着减少数据相关内存访问的数量 [44, 100]，通过权衡带宽和存储效率来提高安全性。 ShEF还提供了两种针对远程功率分析的有效对策。首先，ShEF 通过比特流加密隐藏了加速器的微架构，当前的功率分析攻击需要大量的知识 [79, 102]。其次，ShEF 提供了一个脚本来生成隐藏敏感功率信号的主动逻辑栅栏 [62]。

然而，某些类别的侧信道攻击（例如定时侧信道攻击）依赖于应用程序，并且需要应用程序知识来缓解[90]。虽然我们确保 Shield 加密引擎的时序不依赖于任何机密信息，但如果需要时序不干扰，我们仍依赖 IP 供应商集成特定于应用程序的技术。我们在 5.1 节中讨论了如何保护寄存器接口免受地址元数据攻击。可以简单地添加针对地址元数据攻击的进一步安全机制，例如 ORAM [84]由于其通用接口，在 Shield 引擎之上采用开源模块（例如，[43]）。

IMPLEMENTATION AND EVALUATION

我们在 Xilinx UltraScale+ FPGA 上实现并评估了 ShEF。由于 ShEF 仅依赖于 AES 密钥存储和 SPB，因此它也可以在英特尔 FPGA 上实现。由于我们不允许在 AWS 上部署安全启动流程，因此我们首先在本地 UltraScale+ Ultra96 FPGA 板上实现了端到端工作流程 [18]。然后，我们在 AWS F1 实例上部署了带有加速器的各种 Shield 配置，以评估性能（假设正确启动和证明）。

在这两种情况下，我们都在 Vivado 2019.2 中将 Shield 作为可移植 RTL 代码实现。 Shield 通过 SheEF 运行时库与主机程序连接，该库链接到提供 FPGA 驱动程序和库的 Xilinx 运行时 (XRT)。因此，如第 6.2.4 节所述，ShEF 支持使用 RTL 和 OpenCL 和 SDAccel 等框架开发的加速器。 XRT 和主机程序不在 TCB 中。

End-to-End Ultra96 Implementation

Shield Evaluation on AWS F1

FPGA Resources Overheads

Throughput Microbenchmarks

End-to-End Design Example

Enabling SDP

Configuring Shield Performance

Customized Engines for Various Workloads

Convolution

Digit Recognition

Affine Transformation

DNNWeaver

Bitcoin

RELATED WORK

CPU Enclaves

存在多种类型的安全处理器和 CPU enclave [17、29、33、34、41、42、67、74、75、85×87]，其中最著名的是 Intel SGX 和 ARM TrustZone。 Keystone [64] 是 RISC-V enclave 的最新框架，可解决 CPU 特定的内存管理挑战，例如自分页和动态调整大小，但不提供硬件支持的身份验证加密。 Keystone 和其他基于 CPU 的 enclave 依赖 FPGA 中不存在的 ISA 扩展和硬件机制，例如 RISC-V PMP 和 SGX 指令。 SheEF 解决正交问题。也就是说，ShEF 是一个端到端框架，可在面对云 FPGA 特有的挑战时保护任意自定义逻辑。 SheEF 的灵活性使用户能够快速利用安全处理方面的进步，加速 CPU 飞地之外的应用程序，并快速解决安全处理器中出现的众多漏洞 [30,61,91]。

Accelerator Enclaves

Graviton [94] 修改了 GPU 外围硬件以防止恶意设备驱动程序直接访问敏感资源，但将 DRAM 视为可信内存。 HIX [54] 将驱动程序从操作系统中分离出来，并在受信任的 CPU 飞地内运行，本质上是在 CPU 和 GPU 上创建一个异构的受信任环境，但需要对 CPU 和 PCIe 根联合体进行更改。 HETEE [105] 提议制造一个防篡改加速器盒（即 GPU），服务器机架可以通过专用 FPGA 中的集中式安全控制器访问该加速器盒。然而，它没有考虑云 FPGA 中出现的独特挑战（第 2.4 节），并且需要专门的防篡改底盘。 Telekine [51] 在 ML 训练的背景下解决了 GPU enclave 中的一种新颖的侧通道问题。相比之下，ShEF 假设了一个更强大的威胁模型，既不信任片外内存（包括 HBM），也不依赖 CPU enclave。 ShEF 不需要额外的硬件或 FPGA 修改。边界控制 [73] 沙箱化不受信任的加速器，允许访问系统内存，假设使用与 ShEF 类似的技术（例如缓存和审核内存访问）的受信任 CPU。 SheEF 解决了保护加速器免受不安全系统软件和 Shell 侵害的相反问题。

FPGA Security

FPGA 已用于加速加密原语 [38, 70]。人们对 FPGA 上的通用安全计算也越来越感兴趣。 PFC [99] 使用代理重新加密向云 FPGA 上由制造商预编程的加速器提供加密的 I/O。 Cipherbase [25] 使用 FPGA 加速加密数据库操作。 Eguro 和 Venkatesan [36] 使用可信第三方对要加载到远程 FPGA 上的比特流进行签名和加密。 CPU enclave 已在 FPGA 中进行了模拟 [63,64,67]。商用 FPGA 通过嵌入式密钥对比特流进行加密，防止对手窥探或修改用户设计 [96]，但需要可信的第三方。考夫林等人。通过使用 FPGA 硬件中的自配置密钥来消除第三方[35]，扩展了此过程，并演示了远程认证协议。 MeetGo [72] 和 AMBASSY [52] 讨论了引导远程认证嵌入式私有分别是密钥和 ARM TrustZone 处理器。然而，这些工作并没有解决 2.4 节中描述的关键挑战，例如云或 Shell 内的远程证明，并且要求用户实现隔离执行以及安全存储和 I/O。最后，Trimberger 等人。 [88]讨论了云FPGA的安全问题，包括如何检测恶意用户逻辑并防止篡改用户逻辑。马哈茂德等人。 [68] 和 Elnaggar 等人。 [39]提出了多租户 FPGA 中的攻击方法。

CONCLUSION

随着计算转向云加速器，对敏感数据的安全和加速计算的需求非常迫切。我们通过 SheEF 满足了这一需求，ShEF 是一个由安全启动和可配置的远程证明流程以及保证运行时隔离执行的 Shield 逻辑组成的框架。我们利用 FPGA 的可重新配置性，让开发人员能够打造整体、定制的可信执行环境 (TEE)，以满足他们的安全和性能要求。我们在当前的 FPGA 硬件上制作了 SheEF 原型。我们在本地 FPGA 上演示了安全启动和远程认证，启用了安全存储应用程序，并在 AWS F1 上使用多个加速器评估了 Shield。