为下一代可信计算设计更好的数据中心（Arxiv）

IoT 1年前 (2022) admin

368 0 0

本文是一篇暂时挂在Arxiv的工作，全名《Empowering Data Centers for Next Generation Trusted Computing》，作者是Aritra Dhar等人，来自ETH和华为的苏黎世研究中心。本文实现了类似于HETEE的设计，即面向大规模数据中心的，基于硬件的Accelerator TEE，但相比于HETEE，本文考虑的设计规模（以rack计数）更大，性能负担更低。

一、简介

现在的云端已经从CPU集中式的设计（即CPU、内存、外设在同一个硬件上）转变为领域特异式（Domain-specific）的设计，比如部署专门处理特定工作（如储存、AI、渲染等）的加速器。这些加速器一般在数据中心内有独立节点，被多个租户共享且并行运行。但这样会有一些安全问题，比如云服务提供商或者某些租户是恶意的，它们会篡改某些节点，以及窃取用户数据。一种解决办法是引入加速器TEE（例如GPU TEE），但大多数设计（如CRONUS，HIX）是在bus上的隔离，不适用于数据中心的场景（即节点在一个cluster或rack上连接）。HETEE提出了在数据中心一个rack上的隔离方法，但是这不适用于多个rack的场景，简单地移植HETEE也不能很好地解决这个问题。

由此，本文建立一种多rack的TEE系统。从局部上来说，在CPU和加速器上部署TEE，然后使用TEE保护交互的数据；从全局上来说，建立一个安全控制器（包括验证、隔离、安全信道等机制）来隔离非TEE节点。同时，建立一个全局保护机制，以阻止非TEE节点攻击者利用。

二、攻击模型

本文假设在enclave中的CPU和设备固件（如设备驱动）是可信的，但是enclave互相不信任。由于本系统存在TEE和非TEE节点，本文相信TEE节点里的硬件（包括硬件的信任根，它用于远程验证和保护秘钥），以及在验证TEE节点中的可信固件（如可信hypervisor和ATF）完整性后相信这部分TCB。本文考虑攻击者会控制Host OS和Hypervisor，控制任意节点或者插入恶意节点。本文不信任PCIe link的加密和验证机制（因为攻击者可能会控制主板的BIOS），本文也考虑物理攻击者，它会窥测bus和操作network traffic。

本文不考虑Iago攻击，侧信道攻击，基于硬件的木马，DOS。

三、可能的设计思路

在讲解本文设计前，先讲一些针对数据中心的设计思路

中心化的安全控制器+全部是非TEE节点（HETEE就是这种例子）。这种设计把全部的节点连接到一个安全控制器上，让这个控制器管理资源隔离，提供安全信道。但是，这种设计需要监视所有节点上的决策（例如分享资源和与远程用户交互），负担很大；此外，这种设计一般是针对一个rack的，如果扩展到多个rack上，就需要多个安全控制器之间的合理交互。
中心化的安全控制器+CPU TEE+加速器节点。这种设计把加速器节点与安全控制器相连，然后根据CPU TEE的需求分配独立的加速器。安全控制器需要监测并阻止租户访问非法的设备，以及为想直接访问加速器的租户提供安全信道。但是这种设计还是需要监视所有节点上的决策。
半中心化的安全控制器+TEE和非TEE节点。这种设计允许TEE节点在内部实现租户的隔离（而不是通过安全监视器），但是非TEE的节点仍然需要安全监视器监视（不然会被攻击者利用），因此安全监视器仍然需要掌握全局资源分配，并且处理用户和非TEE节点之间的通信。
没有安全控制器+全部是TEE节点。这种分布式设计需要节点间验证，以及节点和用户之间的验证与通信。缺点是现在的数据中心不一定把所有的设备（包括加速器）都配置了TEE。
本文设计（Hybrid设计）。本文借助了分布式TEE的优点，即让TEE节点自我管理访问控制，而不用经由安全控制器（即使在多rack场景中）。至于对非TEE节点的通信，则需要安全控制器来保护。这样，安全控制器就对非TEE节点的通信过滤（把它与TEE节点间的通信隔离），以及提供安全信道。这看起来更像是专门为非TEE节点提供保护。而对于多rack的场景，由于本设计不需为TEE节点提供保护了，那性能开销也小了一些。

四、具体设计

4.1 非TEE节点和安全监视器

安全监视器内部包含硬件信任根，用于验证和隔离。这个设备的主要作用就是“为非TEE节点提供TEE的特性”。即确保非TEE节点被分配给特定用户，不让它被其他人（包括云服务供应商）使用。但是相比于TEE来说，非TEE的节点和用户交流的数据不需要加密，只用确保隔离（确保一个transaction的始末来自于同一个job）；但是TEE和非TEE内存之间的交互需要加密，这还是需要用户提供一个秘钥。为了保护这些节点，安群监视器需要物理链接这些非TEE节点，维护与隔离这些节点上的输入和输出buffer（以确保明文数据的隔离）。

当云服务供应商请求一个非TEE节点时，安全监视器先看哪个节点空闲（没有job），然后发送验证报告给自己和节点，如果成功就请用户提供一个秘钥，并且记录该秘钥、对应用户和对应节点（即这个节点）。当数据交互时，如果发现该非TEE节点要和TEE节点交互，安全监视器就加密buffer中的数据并传输；如果只是非TEE节点间的交互，安全监视器就确保隔离，即下一个节点不能是属于其他job的；如果该非TEE节点要交互一个其他rack的节点，安全监视器就把秘钥和相关的job记录，通过安全信道发送给其他rack的安全监视器。最后，job执行完毕，安全监视器初始化和释放节点，清空job记录。

4.2 TEE节点

TEE节点虽然不需要安全控制器保护，但是其内部隔离还是要讲一讲。首先它们需要一些设备上的TEE源语来实现使用该节点的租户间隔离和资源隔离，以及需要硬件信任根来实现远程验证。以上工作基本被做掉了，那么本文主要考虑TEE节点上的资源通过DMA和MMIO传输数据的问题。

对于DMA，它主要用于两个计算资源之间的大规模数据交互（DMA不需要CPU插手，所以快，适合做这个）。而本文就需要在数据从app（在enclave里）经由一个不安全的网络载入到设备时，确保数据安全。最简单办法是让app加密数据，但是对开发者不友好，并且也有安全问题。本文的想法是构造一个enclave中的tiny DMA driver来监视DMA事件，并协助数据加密和传输。

而对于MMIO，本文发现设备的MMIO地址在启动时是固定的，那么本文还是配置一个tiny driver，监测（例如产生page fault）与协助对这个MMIO地址的数据加密和传输。