【TEE论文】Trust Beyond Border: Lightweight, Verifiable User Isolation for Protecting In-Enclave Service-CSDN博客

本文链接：https://blog.csdn.net/qq_43543209/article/details/135769754

Trust Beyond Border: Lightweight, Verifiable User Isolation for Protecting In-Enclave Service（2021 IEEE Transactions on Dependable and Secure Computing CCF-A）

摘要

现实世界的微服务用户执行的任务很小，无法支持为每个用户创建单独飞地的资源和延迟，无法在单个飞地允许不同用户的任务。本文开发一种方法，实现飞地内用户隔离，以保护分时服务。

配置安全区的时候限制安全区内线程的权限
在用户切换时对安全区数据执行完整性检查和清理
性能目标：轻量级（1%开销）、可验证（3200行代码）

问题和动机

动机

创建、维护、销毁enclave和远程执行证明会产生成本，为每个用户保留一个飞地没有必要也不现实。
为每个用户保留一个 enclave 不太可能扩展到（数百万用户）。在用户请求到来时创建一个 enclave，并在服务完成后销毁它，将导致每个请求的数百毫秒延迟。
每个用户的请求仍然需要通过远程证明来验证 enclave 并建立安全通道，这可能需要几秒钟才能与证明服务进行通信
当关键数据和关键指令不受保护时，对远程证明的中间人攻击仍然有效。

现有工作的问题

多用户共享一个安全区存在风险，软件故障隔离（Ryoan、Occlum、CHANCEL）引入大量性能、内存开销，以及难以验证的大TCB

本文设计

Liveries，enclave 托管一项服务，该服务一次为一组用户提供服务，每个用户间歇性地发出一批任务，一个用户的任务批处理完成后，才会清理 enclave 状态以服务于一个用户。

挑战

恶意用户破坏了服务程序并获得了对整个飞地的控制权
服务的状态在其操作期间会发生变化，因此应确保飞地运行时状态的正确性。

解决策略：

构建 enclave 时静态限制 in-enclave 程序的权限，又在运行时动态控制其操作（通过 Enclave Security Configurator （ESC）在 SGX 上实施）
ESC 在 enclave 创建期间最大限度地减少了 enclave 内服务的特权
ESC 确保安全关键指令的执行受到限制，每一个只能在一个 sblock 中运行，一个原子代码块，一旦调用，它将运行完成或被回滚，以防止滥用指令
SM用于检查和清理用户服务运行时状态
SM 旨在检查服务期间的敏感数据的完整性，并在运行其他用户的任务批处理之前删除用户数据。

本文贡献：

轻量级隔离，不依赖软件故障隔离，利用安全配置限制 enclave 代码的权限和运行时控制；用户之间分时共享 enclave
安全分析和验证：小型TCB使形式化验证成为可能，使用模块化软件验证工具链 SMACK 和模型检查工具 Spin进行 sblocks 验证
实现：在 SGX1 和 SGX2 平台上对设计进行了原型设计

威胁模型

总结攻击者控制飞地后可以利用的攻击媒介，提供轻量级方案保护用户免受以下攻击：

针对远程证明的中间人攻击：损坏的飞地可以帮助在飞地外运行的恶意程序生成由QE认证和签名的“合法”加密报告，从而软件模拟SGX环境，窃取后续用户的所有数据。原因：失去对关键数据（在飞地外生成私钥和公钥）和关键指令（滥用 EREPORT 指令以生成不受信任数据的报告）的控制
窥探并发运行的任务或暴露先前用户的数据：内存读写攻击来获取同时运行的其他用户数据或先前用户残留数据（会话密钥、中间结果等）
篡改 Enclave 数据使后续用户受害：篡改enclave，干扰后续用户请求的服务或数据

假设一个强大的对手：

完全了解 enclave 服务的源代码和二进制代码以及 enclave 的内存布局
任意内存读取和写入
操作 enclave 的控制流
对手无法规避 TEE 的硬件保护
不考虑侧信道攻击（例如，推测执行攻击）和基于电压操纵的故障攻击
拒绝服务攻击超出了范围

Liveries设计

概述

专为顺序服务模型而设计，enclave 为一组用户提供服务，但一次处理来自同一用户的任务。

每个用户都需要对 enclave 运行远程证明，并在首次与 enclave 交互时交换会话密钥
顺序服务模型以“无状态”和“短生存期”为特征，与软件故障隔离（SFI）相比，有助于简化用户隔离，带来诸如低性能/内存开销和极小的 TCB 等好处

使用安全区安全配置器（ESC）构建安全区，以对其进行“硬编码”，保护关键程序组件和数据（例如，会话密钥），并限制关键指令（例如，可能更改安全区安全设置的指令）的使用。从而限制了攻击者通过劫持线程的控制流可以实现的目标。使用安全监视器（SM）对服务在其运行期间上传的关键数据的完整性执行运行时检查，并在下一个任务进入之前清理用户留下的敏感内容。
在这里插入图片描述

限制指令执行

重要性，要确保关键指令不会被对手带入安全区：

EREPORT将为证明和密钥交换而生成的公钥与SGX安全区状态的测量绑定在一起，并可能被恶意安全区程序滥用，将证明报告链接到由对手控制的密钥，以进行中间人攻击
EGETKEY 从特定于处理器的密钥层次结构中返回一个 128 位密钥，如果安全区受到安全区程序的保护，则该密钥可用于隐藏安全区内的密钥

ESC 首先从 enclave 中的所有代码（service、SM 和 SGX SDK）中找到关键指令，然后为每个指令构建一个保护块。sblock 是一组带有进入和退出指令的指令，通过sblock的原子性保护关键指令以授权的方式使用。例如，EREPORT 只能将授权的公钥作为输入;EGETKEY获取的密钥在解密后会立即被删除，以避免暴露给sblock之外的指令

设计采用了一种独特的策略：ESC 在块的开头设置一个标志，在块的末尾检查该标志，如果正确则重置（检查和清除寄存器）;否则，SBLOCK 将终止整个 enclave 服务。

sblock：表示为三元组（C,entry,exit），其中C是指令块，entry是块的唯一入口点指令，并且exit是唯一的出口点指令
在这里插入图片描述

ESC 禁用了 enclave 中的多线程，并强制执行例外策略（P2）以确保线程只能通过 ERESUME 重新进入 enclave，因此执行将从中断发生的地方恢复，并且所有 enclave 状态完好无损。
在这里插入图片描述

SGX1上启用Liveries

安全区安全配置器（ESC）

ESC 旨在根据一组安全策略在创建其 enclave 之前配置对 enclave 服务的保护。这些配置旨在限制对手的能力，即使他控制了整个飞地，并且在飞地的生命周期内无法更改。

通过配置强制实施的策略包括内存保护（P0）、顺序服务模型（P1和P2）、使用 sblocks进行指令保护（P3）和数据保护（P4），以及 SM 保护（P5)。

P0：在所有常规 enclave 页面上强制执行 X 策略，完成并验证给 SGX1 平台上的 enclave 用户，页面属性是 enclave 测量的一部分，并且在 enclave 初始化后无法更改
P1：单线程 Enclave，在 SGX1 平台上将 TCSNUM 设置为 1来禁用多线程（SGX2 上支持多线程）
P2：安全异常处理，对 sblock 原子性的另一个威胁是异常，它可能由安全区内部和外部的事件触发，在 sblock 运行时发生异常，则其所有上下文（内存和寄存器内容）将由 AEX 保存到正在运行的线程（SSA）的状态保存区域。
- 异常处理：将 EENTER 的条目设置为 SM ，指令执行触发时，它首先检查标志（通过从 SSA 检索 GS 寄存器），如果设置（sblock 被中断），它会立即退出 enclave。这确保了在 sblock 操作期间，enclave 只能通过 ERESUME 进入，而其他情况下的异常处理将照常进行。
- 在所有 sblock 链中都包含了在离开链之前清理 SSA 的指令，因为如果发生异常，该区域中的内容将始终存在。
P3：关键指令保护，使用 sblock 链保护 EGETKEY 和 EREPORT 等关键指令
- 在二进制代码级别上，这些指令都被编译成ENCLU；ENCLU根据寄存器EAX中设置的参数调用不同的SGX非特权叶函数（EGETKEY、EREPORT等）。应该对所有其他出现的 ENCLU 进行适当的保护，以确保其输入参数没有被更改以运行不同的指令
- 下图的sblock链足够，因为大多数构建在 ENCLU 之上的指令不会对从 ENCLU 开始到标志检查结束的代码块造成任何控制流更改。唯一的例外是 EEXIT，它将线程移动到 enclave 之外。为了防止攻击者滥用其底层 ENCLU，ESC 只需在 EEXIT 之后立即添加一个 ud2 指令，如果该指令正确运行并导致 EEXIT 发生，则永远不会使用 ud2，因为当前线程离开了 enclave;如果攻击者在块外更改 EAX 并跳转到 ENCLU 以创建 EGETKEY 或其他，则将运行 ud2 并终止 enclave。
P4：保护关键数据，利用 EGETKEY 从 SGX 硬件派生密钥并使用密钥加密关键数据（会话密钥、公钥/私钥对）
- 构建了一个派生密钥的 sblock 链，解密密钥下的秘密数据，对密钥执行所需的操作，然后删除派生的密钥和密钥
- 如图a，如果编译器可能会将一些密钥泄漏到堆栈中，则需要在退出 sblock 链之前清理所有寄存器和堆栈。利用 sblock 链的原子性，确保对手只能观察链执行前后的状态，因此不会损害数据的机密性。
- 如图b，通过将 EGETKEY 和 EREPORT 链接在一起，可以生成加密报告以与新用户远程认证时保护公钥的完整性。该链首先运行 EGETKEY 来检索密钥以解封公钥，然后删除派生密钥，然后将公钥传递给 EREPORT 以将其绑定到报告。在这个过程中，链的原子性确保了在报告中使用正确的公钥，从而防御中间人攻击。
P5：安全监视器的不可绕过性，SM 的代码受页面权限保护，其数据使用受保护的 EGETKEY 进行密封。将 enclave 的条目（保存在 TCS 中，并且在 enclave 生命周期内不可变）设置为指向 SM，因此每次使用 EENTER 通过 ECALL 将新任务传递到安全区时，都会调用它。SM，将用户数据的完整性检查、内存清理和解密整合到一个 sblock 链中，以确保其原子执行

安全监控SM

SM 在创建 ECALL 时调用，ECALL 首先确定是否在 enclave 内触发了异常。这是通过监视 SSA 来确定的。SM 首先执行完整性检查，以确保服务的关键系统参数未被篡改，并执行出口清理以“重置”服务状态并删除所有退出用户的数据。这些操作一旦成功，就会解密新用户的数据。所有这些操作都受到 sblock 链的保护，以确保原子执行。

完整性检查。完整性检查通过计算 MEASURE_AREA 的哈希度量值并将其与预期值（用 RUNTIME_HASH 表示）进行比较来进行。如果检查失败，则服务将终止。否则，任务数据将被解密并移交给服务器。

在初始化 enclave 之前，如果预先确定了所有服务参数，则 RUNTIME_HASH 的生成和保护非常简单。可以简单地计算其参数的RUNTIME_HASH，并在构建 enclave 时将其保留在只读页面上。

服务参数在安全区运行时上传，并可能由服务提供商更新。机器学习推理即服务，其中神经网络参数可以在 enclave 初始化后加载，并且可以在以后由服务提供商更改。发生这种情况时，只能在运行时生成RUNTIME_HASH，并且需要防止未经授权的修改。

退出清理。退出清理的目的是重置服务状态并清理以前用户的数据。

原子执行保护。SM 使用 sblock 链来保证其操作的原子性：只有在完整性检查通过并清理完所有内存状态后，才会解密新用户的数据或新的服务参数;此外，所有关键数据（例如派生密钥和RUNTIME_HASH）都将被删除或加密。

SGX2的多线程

在并发运行线程的监视下，sblock 的执行已无法再保证所涉及数据的机密性。

SGX2 引入了一组新的叶函数，具有以下功能：（1）动态创建页面并将其添加到已初始化的 enclave;（2）更新EPC页面的权限;（3）更改EPC页面的类型。

保护关键数据（P4）。利用 SGX2 功能，我们能够在运行涉及敏感数据的 sblock 链时强制将 enclave 降级为单线程，然后恢复多线程模式，从而保护数据机密性。这是通过动态调整 TCS（线程控制结构）页数来完成的。

关键指令保护（P3）。使用 GS 来托管 sblock 的标志。GS 在 AEX 上保存到内存中，并在 ERESUME 上恢复。在多线程设置中，重要的是，在线程通过 AEX 离开 enclave 后，内存不能被另一个线程更改。

分析和评估

安全分析

与软件故障隔离（SFI）相比，TCB 要小得多，它不包括大部分 SGX SDK 库代码，并且只引入了一个小的软件堆栈（软件 TCB 总共包含大约 3,200 个 LoC）

两个用于保护关键数据的 sblock 链（强制执行P4).这增加了大约 300 行 C 代码（LoC），用于 AES 实现和使用 EGETKEY 进行解封/密封。
用于生成 ECDH 密钥对的 sblock 链，大约 1,100 LoC
两个 sblock 链，用于在远程认证协议中创建 enclave 报告和生成 MSG3，大约 1,000 个 LoC
一个用于计算RUNTIME_HASH的 sblock 链和一个用于使用 RUNTIME_HASH 进行完整性检查的 sblock 链，引入了大约 500 个 LoC
三个 sblock 链，用于保护 SGX2 机器上的 EREPORT 和 EACCEPT 指令，大约 200 个 LoC

性能分析

与创建和销毁 enclave 以及为每个服务请求执行远程证明的基线相比，设计带来的性能提升有多大？
- 即使不考虑远程证明的时间，我们的方法仍然快几个数量级：例如，当堆大小为 1 MB 时，我们的方法要快 827×。当堆大小较大时，性能提升会变小（256 MB 堆为 52×），这可能是由页面交换引起的。

在这里插入图片描述

SM（即完整性检查和出口清理）对实际案例研究带来的开销是多少？
- 将模型加载到MEASURE_AREA中，而要处理的输入数据则加载到TMP_AREA中，测量了用户切换时完整性检查和退出清理带来的开销。
  - MNIST数据集上的多层感知器
  - MNIST 数据集上的变体自动编码器
  - MNIST 数据集上的 CNN
enclave 二进制文件中有多少个 ENCLU 和 WRGSBASE 小工具？如果有的话，删除它们的开销是多少？
- 构建了自己的小工具查找工具，以查找流行的飞地二进制文件中 ENCLU 和 WRGSBASE 小工具的出现；收集了 10 个流行的开源 SGX 项目以及 SGX-nbench [49] 和 lmbench [50]，使用默认配置编译
- 对于英特尔-SGX-SSL 中唯一的 ENCLU 小工具，我们确认只需使用内联汇编添加 NOP 指令而不影响功能，然后重新编译代码即可删除该小工具。引入可以忽略不计的性能开销。