【论文阅读】——secureTF: A Secure TensorFlow Framework_scone: secure linux containers with intel sgx-优快云博客

secureTF是一个安全的TensorFlow框架，设计用于在不受信任的云环境中提供端到端安全性。它扩展了Intel SGX的安全特性，保护了输入数据、机器学习模型和应用代码。通过使用SCONE框架，secureTF能够在不修改原始TensorFlow应用的情况下运行，同时支持训练和分类。系统通过CAS组件进行远程验证和密钥管理，确保弹性与容错。在性能评估中，secureTF显示了合理性能开销，适用于实际部署。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

secureTF: A Secure TensorFlow Framework

作者：Do Le Quoc, Franz Gregor, Sergei Arnautov，Roland Kunkel，Pramod Bhatotia，Christof Fetzer
来源：Middleware

比较好的引用文章：
SCONE: SCONE: Secure Linux Containers with Intel SGX.
CAS: Trust Management as a Service: Enabling Trusted Execution in the Face of Byzantine Stakeholders.
TensorSCONE:TensorSCONE: A Secure TensorFlow Framework using Intel SGX

有状态应用：A stateful app is a program that saves client data from the activities of one session for use in the next session. The data that is saved is called the application’s state.
有状态计算：A stateful computation is a function that takes some state and returns a value along with a new state.

现在在利用云服务之前，用户通过TLS来传递相关加密密钥和enclave配置给CAS，每次创建新的容器之后CAS做了远程验证之后通过TLS来传递相应的密钥和文件。执行结果通过TLS传递

文章目录

Abstract

如今的在线服务中，数据驱动的智能应用越来越普遍。这些应用程序通常托管在不受信任的云计算基础架构中。由于这些软件应用的机器学习(ML)算法依赖的数据集可能有隐私和敏感信息，可能会造成严重的安全隐患。
为了应付这个挑战，我们设计了secureTF:应用在不受信任云架构上的基于TensorFlow分布式ML安全架构。SecureTF是支持未经修改的TensorFlow应用程序的通用平台，同时为输入数据、ML模型和应用程序代码提供端到端安全性。SecureTF是基于TEE提供的安全属性从头开始创建的。然而，它扩展了由单节点TEE提供的易失性存储器区域(或安全enclave)的trust，来保护支持在云中运行的未修改的ML应用程序所需的分布式基础架构。
本文报告了我们在生产用例中的系统设计选择和系统部署方面的经验。最后，我们根据我们商业平台的局限性总结了经验教训，并讨论了未来工作的开放研究问题

1 Introduction

当使用第三方不可信云架构部署自己依赖隐私数据的计算时候，对用户会有严重的安全危害。攻击者可以威胁计算的完整性和私密性。由于数据存储在数据所有者的控制之外，第三方云平台提供了额外的攻击载体。客户目前在核实第三方运营商是否能够以声明的安全来处理数据方面的支持有限，即使用意是好的。
现有的保护ML应用程序的安全技术对于性能，准确率有这很大限制，甚至只能做分类任务。因此，我们要设计一个支持现有APP的同时可以保证性能、准确率，并且可以做训练分类的安全ML框架，此外，我们的工作力求对输入数据、ML模型、应用代码提供端到端的保护。

TEE可以实现相应的设计目标，考虑到云服务安全威胁的重要性，最近利用TEE在不受信任的基础设施中应用程序的shielded execution激增。shielded execution旨在使用硬件保护的安全内存区或enclave为应用程序提供强大的机密性和完整性。
TEE不支持扩展到云上分布式有状态应用，搭建提供（透明度、准确性和性能）三种设计属性的支持训练和分类安全ML框架需要解决由SGX带来的一些挑战。
由传统的单节点SGX架构带来的挑战：
1、SGX是用来设计单个节点上的安全计算，我们需要把SGX的安全性拓展到分布式TF架构上
2、其次，我们需要支持公有云服务中的虚拟平台提供的实用功能，以支持弹性和容错计算，即根据工作负载进行扩容/缩容，以及处理故障/迁移。
为了支持这些重要需求，我们需要确保在容器中运行的新工作节点保持数据、ML模型和应用程序代码的完整性和机密性。然而，传统的使用IAS的远程证明对于支持弹性和容错计算是不现实的。我们需要重新设计该机制，通过配置和认证服务来确保弹性可信建立？
3、传统的TEE不支持从网络中读写数据，只支持在enclave区中进行计算，对于涉及多个机器的有状态ML计算不提供安全保护

做的贡献：
1、在没有损害准确率的情况下，设计并实现了基于TF的secureTF端到端系统，允许不修改现有TF APP的情况下进行安全执行APP
2、对于SGX在不可信分布式云计算环境下的劣势做了改进
3、基于微基准和生产用例的secureTF做了广泛评估，评估表明，secureTF实现了合理的性能开销，同时以较低的TCB提供了强大的安全性

2 Background and ThreatModel

2.1 Machine Learningusing TensorFlow

ML通过构建概率模型来提取数据集中的有用样式
TF可以用在异构分布式系统上，定义一个包含节点的有向图来代表在输入数据的操作。TF使用流模型来计算，定义完有向图之后可以分割到不同的节点上，来在不同的设备上执行。
TF Lite是设计来移动和嵌入式设备使用的削减版本TF，不可以做训练，只能做forward pass

2.2 Intel SGX andShielded Execution

enclave memory存储在enclave page Cache中，EPC是一个由MEE保存的专用内存区。
基于sgx的shielded execution用于应用的私密和完整性，我们的工作基于SCONE shielded execution框架，在这个框架中，APP是基于SCONE libc的C lib，在该框架中，应用程序的地址空间被限制在Enclave内存中，与不可信内存的交互通过系统调用接口执行。具体地说，SCONE运行时提供了一种异步系统调用机制，在该机制中，enclave之外的线程异步地执行系统调用。SCONE提供了与Docker的集成，以无缝部署容器镜像

2.3 Threat Model

云计算架构存在复杂的虚拟堆栈，在这种环境下，攻击者可以控制整个系统栈，能够实施物理攻击。
网络不可信，攻击者可以丢弃、注入、重发、更改packet。在这种情况下，我们的目标是保护数据和代码的完整私密新鲜。
在enclave 内存上提供Pesos进行防护回滚攻击。
不防御side-channel攻击，不考虑Dos攻击。假设CPU安全，攻击者不能物理上提取CPU中的数据和密钥

3 Design

3.1 System Overview

在这里插入图片描述
框架使用SGX来实现分布式ML计算安全，不仅保护执行，还保护数据和模型。
用户使用SGX提供的远程验证来验证计算和输入是正确的，没有被修改，在验证框架正确运行之后，来传输用于加密的Key和证书，计算结束之后结果返回
上述过程都是通过transport Layer Security（TLS）来传输的

设计目标：
私密性：包括模型和代码的所有数据，不能被未授权的人拿到
完整性：未授权的人对数据进行修改必须能够被监测到
透明：在不修改的前提下，可以运行现有的TF APP；对于为支持的架构提供相同的接口
性能：尽可能的在添加安全功能的情况下造成比较小的代价
准确率：在不损害准确率的情况下实现安全

3.2 Design Challenges

1、代码修改：对于SGX中运行的APP，需要对原来的软件进行大量修改
2、EPC大小的限制：对于训练过程这种内存密集的过程来说SGX提供的EPC大小太小了
3、分布式系统上建立信任：SGX是为了单个机器设计的
4、弹性、容错计算支持：当工作负载增加时候，框架分配新的容器去处理新的请求。但是常用的ISA在创建新容器时候做远程验证时候有较大的代价
5、状态计算(网络和文件系统的安全)：ML应用是有状态计算，SGX只支持Enclave中的安全，对于有状态计算并不支持

3.3 System Design

在这里插入图片描述
主要包含四个组成部分：CAS、安全的机器学习容器，包括TensorFlow参数服务器和TensorFlow工作器、网络盾牌和文件系统盾牌、适配TensorFlow库

3.3.1 System Components

克服Challenge1，使用SCONE框架，SCONE框架支持软件不做任何修改在SGX中运行
CAS组件去处理Challenge3、4,该组件在框架的分布式体系结构中扮演着重要的角色，它在传输运行secure ML容器所需的密钥和配置之前，透明地自动执行secure ML容器的远程证明。CAS运行在enclave中，步骤如下：当secure ML容器运行，在CAS做完远程验证之后其从CAS中接收必要的密钥和配置，之后在enclave中使用适配TF库来运行ML计算。
网络盾牌和文件系统盾牌来解决Challenge5，容器与CAS的交流都使用网络盾牌构件

3.3.2 Configuration and Remote Attestation Service

在传输用于加密解密的密钥之前要进行远程验证，CAS配置审计服务去防止数据回滚攻击

3.3.3 Secure Machine Learning Containers

在这里插入图片描述
使用SCONE的secure TF架构如图所示。
使用TF lite来解决Challenge2，使用Docker来方便部署。
该容器包含两个组成：secureTF控制器来为保护TensorFlow库提供必要运行环境；secureTF TensorFlow Library来允许TF APP不做修改进行部署

secureTF Controller基于SCONE Runtime，包括：网络盾牌，文件系统盾牌，用户级线程

**文件系统盾牌：**保护文件的私密和完整性，每当应用程序要写入文件时，盾牌要么加密和验证，要么简单地验证或按原样传递文件。选择取决于用户定义的路径前缀，这些前缀是enclave配置的一部分。盾牌将文件分成很多片，然后单独处理，对于这些处理中的密钥，是enclave启动时候CAS传递过来的配置参数，与SGX的密钥不同。

**网络盾牌：**TLS密钥由网络盾牌进行防护

**用户级线程：**Enclave的切换开销非常大，所以需要避免，许多系统调用需要线程退出用户空间并进入内核空间进行处理。为了尽可能避免线程转移出enclave，控制器实现了用户空间线程化。当OS分配线程给enclave时候，按照规划去执行APP，这些应用程序线程被映射到SGX线程控制结构。
当应用程序线程阻塞时，控制器再次运行以将OS线程分配给不同的应用程序线程，而不是将控制传递回操作系统。通过这种方式，减少了昂贵的enclave过渡的代价，当没有应用程序线程准备好执行时，操作系统要么后退并在enclave内等待，要么在enclave外等待，具体取决于enclave转换所需的时间
控制器不需要更多的操作系统线程，用于实现完整的CPU利用率，这通常是在传统操作系统下运行的应用程序的情况

3.3.4 secureTF TensorFlow Library

ML有两步：训练、分类
训练过程：使用标准TF在CPU上的SGX运行训练确实降低了性能，但是随着分布训练的水平扩展，性能也会相应增加

分类过程：
使用TF Lite在SCONE中进行推理过程，SCONE的C库是兼容的

4 lmplementation

TrustZone不支持远程验证，AMD`TEE不支持完整性保护

4.1 Training Process

TF用户使用Python API来定义和训练有向图，在SCONE中使用Python会增加额外的开销，因为SGX不支持在运行过程中添加dlopen，SCONE支持添加，但是会对安全有影响，我们使用文件系统盾牌来防御该方面的攻击

该框架不仅支持Python也支持C++，但是python中的一些package由于SCONE不支持fork不可用，我们可以使用Python来导出参数和有向图，之后由C++来使用，在训练过程使用标准版的TF

4.2 Classification/Inference Process

在该过程我们还提供了一个轻量版本的TF Lite SCONE框架，使用musl 来编译TF、TF Lite，musl兼用glibc但是在更少代码时候更安全，TF使用ICF来编译后者链接，但是musl不支持，我们移除ICF选项

TF中默认使用回溯，但是musl中没有这个库（glibc有），我们使用musl重新编译该库，或者设置不回溯

适配TF库之后，就很容易使用SCONE框架进行编译

4.3Configuration andRemote AttestationService

CAS使用SCONE框架和Rust来编写，这样更安全，使用SQLite来进行存储key、证书和其他的配置，SQLite同样运行在enclave中，为了更加保证CAS的安全，CAS没有任何参数可以控制行为

5 Evaluation

基于微基准和宏基准进行测试现实世界中的部署

5.1 Experimental Setup

采用Cifar-10、MNIST数据集做测试

在测试之前，通过过载运行需要交换EPC pages的IO操作来预热机器；
对于分类和训练，分别在有文件系统盾牌和没有文件系统盾牌的情况下运行；
对框架在两种sgx模式下运行(HW、SIM),利用SIM对SGX的开销做评估。

5.2 Micro-benchmark:Remote Attestation andKeys Management

在框架中，我们需要安全的传输整数和密钥来在工作节点通信时加密解密数据，为了实现该目标，我们利用CAS组件，来验证在Enclave内运行的TF进程，
在secureTF中，我们需要安全地传输证书和密钥来加密/解密输入数据、模型和工作节点之间的通信(在分布式培训过程中)。为了实现安全目标，在透明地提供密钥和证书以加密/解密输入数据、模型和TLS通信之前，我们利用CAS组件来验证在Enclaves内运行的TensorFlow进程

5.3 Macrobenchmark:Classifying Process

第一个实验，分析了模型在SIM、HW模式下的运行延迟，并与musl、glibc、Graphene做了对比(Graphene将LibOS移入Enclave，并仿真地提供系统调用、线程、事件处理、Forking等功能（最终会转换到Host OS的系统调用），但是也会导致TCB太大（主要是库比较大），效率低等,但是Graphene与SCONE相同，可以让用于直接运行app不需要做修改)。
结果如图：SIM模式下的模型比native版本只有5%左右的代价增长，这意味着使用模型中的libc带来轻量化的overhead，因为模型在enclave中处理系统调用，不需要退出kernel

glibc为了性能，musl为了模型大小。与Graphene相比，我们并没有添加整个LibOS中的库进入enclave，我们使用的是SCONE libc，因此会有更小的size，我们使用3.3中介绍过的机制来执行system call

在这里插入图片描述