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数据集上的多层感知器
- 将模型加载到MEASURE_AREA中，而要处理的输入数据则加载到TMP_AREA中，测量了用户切换时完整性检查和退出清理带来的开销。
- MNIST 数据集上的 CNN
- enclave 二进制文件中有多少个 ENCLU 和 WRGSBASE 小工具？如果有的话，删除它们的开销是多少？
- 构建了自己的小工具查找工具，以查找流行的飞地二进制文件中 ENCLU 和 WRGSBASE 小工具的出现；收集了 10 个流行的开源 SGX 项目以及 SGX-nbench [49] 和 lmbench [50]，使用默认配置编译
- 对于英特尔-SGX-SSL 中唯一的 ENCLU 小工具，我们确认只需使用内联汇编添加 NOP 指令而不影响功能，然后重新编译代码即可删除该小工具。引入可以忽略不计的性能开销。
与基于SFI方案的比较
- SFI 需要检测 enclave 代码以检查内存引用和控制流指令，这会产生较大的性能和内存开销，以及用于验证 SFI 合规性的大型 TCB
- 本文简化了顺序服务模型下的用户隔离，带来了诸如低性能/内存开销（平均 1%）和极小的 TCB（3200 个 LoC）等优势。
- 下述实验表示：在大多数情况下，SFI方法 Occlum 和 WAMR 比基线慢得多（平均分别约为 5.21× 和 1.51× 减速）。
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达，可以在下面评论区评论
