查看原文
其他

为下一代可信计算设计更好的数据中心(arxiv)


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

1

简介
现在的云端已经从CPU集中式的设计(即CPU、内存、外设在同一个硬件上)转变为领域特异式(Domain-specific)的设计,比如部署专门处理特定工作(如储存、AI、渲染等)的加速器。这些加速器一般在数据中心内有独立节点,被多个租户共享且并行运行。但这样会有一些安全问题,比如云服务提供商或者某些租户是恶意的,它们会篡改某些节点,以及窃取用户数据。一种解决办法是引入加速器TEE(例如GPU TEE),但大多数设计(如CRONUSHIX)是在bus上的隔离,不适用于数据中心的场景(即节点在一个clusterrack上连接)。HETEE提出了在数据中心一个rack上的隔离方法,但是这不适用于多个rack的场景,简单地移植HETEE也不能很好地解决这个问题。由此,本文建立一种多rackTEE系统。从局部上来说,在CPU和加速器上部署TEE,然后使用TEE保护交互的数据;从全局上来说,建立一个安全控制器(包括验证、隔离、安全信道等机制)来隔离非TEE节点。同时,建立一个全局保护机制,以阻止非TEE节点攻击者利用。
2

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

可能的设计思路

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

具体设计

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节点上的资源通过DMAMMIO传输数据的问题。对于DMA,它主要用于两个计算资源之间的大规模数据交互(DMA不需要CPU插手,所以快,适合做这个)。而本文就需要在数据从app(在enclave里)经由一个不安全的网络载入到设备时,确保数据安全。最简单办法是让app加密数据,但是对开发者不友好,并且也有安全问题。本文的想法是构造一个enclave中的tiny DMA driver来监视DMA事件,并协助数据加密和传输。而对于MMIO,本文发现设备的MMIO地址在启动时是固定的,那么本文还是配置一个tiny driver,监测(例如产生page fault)与协助对这个MMIO地址的数据加密和传输。来源:COMPASS Lab
END

往期推荐


横向联邦学习下隐私保护安全聚合:问题,方法,与展望
同态加密开源框架整理
国际信息安全顶级会议ACM CCS2022论文合集整理(上)
国际信息安全顶级会议ACM CCS2022论文合集整理(下)
欢迎投稿邮箱:pet@openmpc.com参与更多讨论,请添加小编微信加入交流群

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存