全同态加密和可信执行环境的完整性保护

阵列13（2022）100118TFHE-rs：一个使用全同态加密和可信执行环境的Lars Brennaa，*，Isak Sunde Singhb，Håvard Dagenborg Johansen c，Dag Johansen ca挪威北极大学：挪威特罗姆瑟大学，特罗姆瑟，挪威bUiT -挪威北极大学|UiT Arctic University of Norway：UiT Norges arktiske universitet，Norwayc挪威北极大学：挪威北极大学，挪威A B S T R A C T全同态加密（FHE）和可信EX加密环境（TEE）是互补的方法，可以保护在公共云上远程运行的计算。然而，EXFHE方案在设计上是可延展的，并且缺乏完整性保护，这使得它们容易受到完整性破坏，其中对手可以修改数据并破坏输出。本文描述了如何通过将FHE与基于硬件的安全飞地技术相结合来保证远程计算的机密性和完整性。我们提供了一个软件库，用于在英特尔SGX TEE中执行FHE，该软件库采用内存安全编程语言Rust编写，以增强软件的内部安全性并减少其攻击面。我们评估一个用我们的库编写的示例应用程序。我们证明，我们可以可行地结合这些概念，并提供更强的安全guarantees与最小的开发工作。1. 介绍将数据和计算服务外包给公共云提供商需要能够实施严格的数据机密性和完整性法规的安全机制。这对于处理敏感数据的应用程序和组织尤为重要。 两种用于保护数据处理活动的正交方法正被积极吹捧为潜在的游戏规则改变者：同态加密（HE）和基于硬件的TEE。他承诺计算加密的值，而不透露其内容。2009年之后，该领域的研究有所增加，当时Craig Gentry [1]在他的博士论文中描述了实现FHE的第一种技术，这是在构思了近30年之后[2]。FHE使许多类型的计算能够外包，这些计算以前由于保密性限制而必须在内部进行，包括健康数据处理，财务处理和基因组研究。虽然FHE方案可以提供机密性，但它们不能提供完整性，因为所有HE方案在设计上都是可延展的。从理论上讲，恶意修改的结果与正确的结果是无法区分的。如果处理数据的远程服务的机密性不受信任，那么它的完整性也不应受信任。对使用FHE加密的数据执行的实际计算也将是可见的，这在某些情况下可能是不可接受的，因为操作本身可能是秘密。因此，FHE仅部分解决了将具有完整性约束的计算外包给公共云服务的问题。虽然数据完整性问题尚未解决，但FHE的实际用途有限。可信的EX可信环境（TEE）与HE有着相似的目标，它们保护托管在远程和不可信机器上的程序和数据的完整性和机密性。可信的EX虚拟设备（TEE）通过将正在运行的进程与操作系统以及通过各种硬件设施的其他同时运行的进程隔离来实现这一点。然而，已有证据表明，现有的TEE（如Intel Software Guard EX tensions（SGX））易受几种类型的旁道攻击的影响，其中攻击者可以获取安全设备中的代码和数据信息[3尽管文献中的大多数注意力都集中在SGX，一些攻击针对支持同时多线程（SMT）的所有处理器[7]。因此，不能依赖在内部揭示秘密的硬件技术来在公共云设置中提供高度有保证的机密性有一些方法可以解决这个问题，例如使用不经意RAM（ORAM）[8]这样的不经意原语，它模糊了访问模式，以防止信息通过侧通道泄漏。然而，不经意的方法确实会给计算带来显著的每次开销。在本文中，我们调查这些概念之间的交集* 通讯作者。电子邮件地址：lars. uit.no，lars. gmail.com（L。Brenna）。https://doi.org/10.1016/j.array.2021.100118接收日期：2021年2月25日;接受日期：2021年12月2日2021年12月28日网上发售2590-0056/© 2021由Elsevier Inc.发布这是CC BY许可下的开放获取文章（http://creativecommons.org/licenses/by/4.0/）。可在ScienceDirect上获得目录列表阵列期刊主页：www.sciencedirect.com/journal/arrayL. Brenna等人阵列13（2022）1001182×⊗×⊗×⊗××× ∈++++在规定的安全背景下，并提出了一种混合的方法，结合FHE的保密性与完整性的TEE的优势。我们使用内存安全编程语言Rust [9]来实现。使用Rust可以减轻大量危险和常见的安全相关错误，包括内存损坏错误、缓冲区溢出、未初始化内存、数据竞争、指向未分配内存的解引用指针（例如， 空指针解引用），以及解引用指针导致访问冲突[10 我们评估通过在新交所内外实施FHE计划，我们的混合方法的性能。通过比较相对性能差异，我们证明了混合方法在性能方面是可行的，同时保留了比单独使用FHE或SGX更强大的安全性和安全性保证。据我们所知，我们的方法是第一个工作，结合TEE与FHE，以涵盖完整性弱点的FHE。2. 背景所有的HE系统在设计上都是可延展的，因为攻击者可以将密文转换为不同的密文，然后将其解密为相关的明文。例如，考虑以下同态加密方案：Ek（x）<$Ek（y）=Ek（x，y）（1）E k（x）是用密钥k对明文x进行的加密，是明文之间的某种二进制运算，是在密文空间中运算的提升版本。注意，提升的运算符不一定涉及与运算符相同的运算，这意味着它可能具有更高的复杂性。假设攻击者知道x和y以及它们的距离Ek（x）和Ek（y），并且存在某个对（x，y）使得xy/{x，y}。然后，攻击者可以计算Ek（x）Ek（y）以获得密文C，其对应于x y的加密，其预先被假设为不同于x和y。正因为如此，攻击者已经获得了一个密文，它对应于一个他们知道的明文x y，但他们以前没有观察到的密文。虽然可延展加密方案在选择明文攻击（IND-CPA）下的标准不可分辨性下是安全的，但它们在自适应选择密文攻击（IND-CCA 2）下的不可分辨性下不是安全的[13]，与不可延展加密系统相反[14]。此外，已经表明，一些IND-CPA加密方案在加密自己的解密密钥时变得不安全[15]，通常称为循环安全。如.HE方案将其解密密钥作为自举过程的一部分进行加密，具有循环安全特性。TEE是一种隔离的计算环境，保证保护其中加载的代码和数据。已经提出了TEE [16[20]这是一种比较。初始化和形式化的描述TEEs通过建立在分离内核的概念，首先由Rushby[21]描述，并定义四个主要的安全策略。TEE应该保证执行代码的真实性，包括运行时状态的完整性，例如CPU寄存器。它应该保证持久化到辅助存储器的代码、数据和运行时状态的机密性，例如通过加密。TEE应该有可能提供远程证明，为第三方证明可信度。TEE内的内容更新应安全完成。TEE应该能抵抗所有针对主存的攻击。通过后门安全漏洞进行的攻击应该是不可能的。因此，TEE应该是安全的，即使操作系统是分离的，也不能访问或修改它。这些条件保证任务可以发送给第三方并执行敏感任务外包，因为他们提供了TEE。存在几种已知的方法，用于对手物理攻击硬件组件以提取信息。这包括功率监视（或功率调整）攻击，如Plundervolt [22]，声学密码分析攻击[23]，电磁攻击和光学攻击。基于软件的侧信道攻击包括基于页面错误的攻击[3]，基于缓存的攻击[4]和基于接口的攻击[5]，所有这些攻击都针对机密性。TEE制造商还必须能够提供可靠的软件和开发工具。对于英特尔SGX，除了片上硬件机制外，还提供了各种软件系统和软件开发工具包（SDK）。截至2021年2月，英特尔SGX LinuX SDK包含约36万个源代码行（SLoC）。3. TFHE-rs库在本文中，我们提出了一种混合方法，将FHE的机密性优势与TEE的完整性优势相结合，并开发了一个Rust库作为概念验证。TFHE-rs库将HE与在TEE内执行的代码相结合，以提供机密性和完整性。通过在TEE内处理密文，对手不能修改甚至不能读取密文，消除了可延展性的问题，从而提供更强的安全性。对于我们的TEE，我们使用英特尔SGX，对于同态运算，我们使用圆环上的快速全同态加密（TFHE）方案，该方案首先由Chillotti等人描述[24]第10段。TFHE是一种基于对称格的FHE方案，其工作原理是表示系数在T、实数集模1或R/ Z上的多项式。Chillotti等人。[24]还提供了一个适应库实现[25]，我们在本文中将其称为TFHE-c。TFHE-c库的一个主要优点是它被设计为基于位进行计算。相比之下，其他方案，如近似数字的同态加密算法（HEAAN）（也称为Cheon-Kim-Kim-Song（CKKS））[26]和Brakerski-Gentry-Vaikun tanathan（BGV）[27]，使用近似数字，因为明文空间在复数内。BGV方案比其他方案更适合用于整数运算。该方案适用于构建电路，但更复杂在使用中，并要求开发人员有相当多的知识，其内部工作，以建立一个有效的HE程序。BGV的实现也可以在HElib中找到1所有这些方案都建立在关于有错误学习（LWE）问题或其环变体，环错误学习（RLWE）我们的TFHE-rs库实施深受现有TFHE库[25]2的启发，关键部分在英特尔SGX的TEE中运行，以确保完整性。执行这项要求的具体Rust而不是C 以确保内存安全。此外，TFHE-rs完全是在Rust的安全子集中编写的，如果在我们的代码库中使用unsafe关键字，将无法编译。这是由一个crate诊断属性forbid（unsafe_code）强制执行的，它也可以防止在我们的crate中覆盖该属性。然而，我们的一些外部依赖需要使用Rust的不安全部分来与低级操作交互，例如通过汇编指令提供随机性。3.1. 数据结构在TFHE-c库中，许多结构的字段严格指向另一个结构类型。在C和C语言中，这与数组指针没有区别，除非查看初始化位置。像这样的动态分配数组在在TEE内，不需要对该方的信任这使得数据-1 https://github.com/homenc/HElib。2我们完全基于此commithttps://github.com/tfhe/tfhe/commit/ 76 db 530 cf736 a25115 ea 0 b 0 ccdb 9267 b401 bb 9a 7中的代码构建。L. Brenna等人阵列13（2022）1001183++Rust std：vec：Vec类型的功能，并且与原始库的实现相比是明确的C语言中的指针域结构没有具体说明他们拥有它们所引用的数据，或者指针是否引用在初始化过程中提供给它的例如，在struct Data {val：Vec i32>}与struct Data { val：mut [i32]}（生命周期注释）为简洁起见，省略了一些段落）。这种区分对于Rust是必要的，因为它跟踪所有权。在TFHE-rs中，我们选择了前者，因为它比后者更易于管理，而且似乎TFHE库也选择了这种解决方案，基于它们的使用情况。浮点和浮点数据类型在Rust中有直接的等价物，因此可以直接转换TFHE源代码有一些结构，其中字段是指向动态分配数组中的值的指针，同一结构中的不同字段也引用该数组，即自我参照结构当在内存中移动一个值时，自引用结构中的引用值将失效。这使得它们本质上是危险的，因此被Rust中的类型系统作为一种解决方案，我们选择删除这些字段并直接访问值，但会损失一些可读性。TFHE库也有一些空指针的出现，通过快速傅立叶变换（FFT）实现来专门化。这些指针的使用在某种程度上相当于Rust的 tr a i t 系 统 ， 它 允 许 多 个 实 现 ， 同 时 提 供 一 个稳定的接口。由于我们不打算允许FFT的多种实现，因此可以避免这种抽象。3.2. 参数集TFHE-rs支持创建不同安全级别的密钥。选择基于LWE的加密方案的参数是复杂的，因为选择具有不兼容值的参数集可能导致不安全或缓慢的系统。我们的实现目前支持TFHE-c中定义的两个参数集，其估计安全级别为80位和128位，称为位安全性[28]。然而，密钥大小与安全级别不成正比，如AES中，128位的安全级别等同于128位的密钥大小。在TFHE中，128位的安全级别相当于~ 24 MB的引导密钥[29]。我们库中的默认参数集是128位安全版本，因为密码学家建议128位安全性在理论上直到2090年都是安全的[28]。3.3. 序列化所有可能需要传输的数据结构都是可序列化和可重复的，使用Rust包Serde。3Serde设计seri-实现两种特性之一的任何数据结构都可以被序列化或非序列化为所支持的数十种不同序列化格式之一。这与TFHE列表不同，在the列表中，数据的序列化只能通过用于读取和写入文件和流的特定函数完成。这些函数有些限制，不允许开发人员指定串行化格式。在TFHE-rs中，宏允许自动导出实现，例如（第3行突出显示导出宏）：3https://crates.io/crates/serde或其主页https://serde.rs/实现这些traits允许库实现的用户选择最适合用例的序列化格式。 由于密文非常大，并且包含许多整数，因此二进制格式可能最适合。3.4. SGX整合我们选择使用FortaniXSDK通常允许对SGX和SDK进行低级控制，而FortaniX Rust EDP旨在提供一种简单的方式来编写专业的gram作为平台编译目标。Fortani X的项目被RUST认可为受支持的目标平台，目前拥有官方的TIER 2状态。52级支持手段代码保证在平台上构建，并且是语言持续构建测试系统的一部分因此，不使用多个进程或依赖于操作系统功能的常规Rust程序应该可以在X的盒子。这些保证使我们能够轻松地将FHE库集成到在SGX飞地内运行的程序中，这也是我们选择使用FortaniX Rust EDP与SGX合作的主要原因。我们的示例程序使用我们的TFHE-rs实现和FortaniX Rust EDP，除了指定程序所需的堆栈和堆大小外，不需要特殊处理。没有特殊处理意味着我们移植库的用户可以轻松地在云中使用FHE和SGX的混合解决方案。4. 评价我们使用微基准测试并通过实现经典的姚氏百万富翁问题[ 30 ]来评估TFHE-rs的性能因为我们的主要目标是在保持性能的同时减轻FHE方案中的完整性弱点，所以我们的实验集中在我们的混合方法引起的计算开销。作为基线，我们使用的TFHE-lib实现Chillotti等人。[25]第10段。TFHE-lib提供了几种不同的FFT处理器，包括FFTW，它声称是最快的免费FFT实现。6TFHE-rs使用RustFFT crate，目前不使用任何Single指令，多数据（SIMD）指令，只有纯Rust，因此不能使用FFTW。为了排除使用FFTW带来的潜在无关性能益处，TFHE-lib与Nayuki项目7此外，Chillotti等人。[29]提供了两个基准：一个在内部使用拉格朗日半复表示，另一个没有。我们使用后一个基准，因为我们的实现不使用拉格朗日表示。4.1. 微基准每个微基准重复50次以获得平均值，4https://github.com/fortaniX/rust-sgx或其主页https://edp.fortaniX.com/5https://forge.rust-lang.org/release/platform-support.html。6 http://www.fftw.org/。7https://www.nayuki.io/page/fast-fourier-transform-in-X 86-汇编。L. Brenna等人阵列13（2022）1001184±×微基准测试总结。标准偏差这些测量是在没有SGX参与的情况下完成的。我们的测量结果总结在表1中。4.1.1. 加密解密速度加密过程由于随机数的产生和分配而较慢，而解密过程仅由简单的算术组成。这意味着解密的吞吐量也是加密的两倍。4.1.2. 密钥生成密钥生成过程生成用于在TFHE方案中加密和解密数据的秘密对称密钥，以及在引导过程期间所需的引导密钥和密钥切换密钥。为了简洁起见，我们将这些密钥统称为引导密钥，因为这是唯一使用它们的进程密钥生成平均值为527。67μ s24岁269μ s生成密钥。因为这过程严重依赖于随机数生成，它受到用于生成数字的时间4.2. 自举自举过程将LWE样本作为输入，连同在消息空间中编码的输出消息和自举密钥。如图1所示，单个自举过程的平均执行时间为1。1937年代，显著高于原始论文的实现，在类似硬件上花费约53 ms [29]，并且改进工作导致约13 ms [25]。然而，TFHE提供了我们在TFHE-rs中没有实现的一些优化。首先，它使用拉格朗日半复表示，这减少了近三分之一的自举过程中所需的乘法的数量。它还减少了所需的外部产品的数量，在自举过程中执行的昂贵操作。其次，原始实现使用基于SIMD指令集（如AVX）的FFT处理器，可提供较大的加速比。图中观察到的异常值与解密和加密过程中的异常值类似，可能与使用CPU的其他进程的交互有关。由于大多数样品都落在一个几乎相同的点上，因此可以合理地假设大多数结果都在这个范围内。此外，此过程是确定性的，并且使用相同的输入进行基准测试，因此我们假设离群值可以Fig. 1. 估 计 的 自 举 PDF 的 详 细 视 图 。 平 均 估 计 值 为 1.1937s ， 中 位 数 为1.1969s，具有std。偏差为13.234 ms。图二. 在我们的实现中，使用和不使用基于FFT的多项式乘法的自举操作的执行时间。Naïve红色区域标记多项式乘法的Naïve实现，而FFT蓝色区域标记优化版本。可以忽略，平均值可以用作估计值。4.2.1. 优化和非优化实现之间的比较图2显示了时间复杂度为O n2的n阶多项式乘法过程与基于FFT的实现之间的性能差异。 我们观察到，基于FFT的实现提供了执行时间减少74. 百分之四百零八需要注意的一点是，在FFT优化的实现中，从128位参数集更改为80位参数集会使自举操作快约2倍此结果表明，加密中使用的参数集对性能有很大影响。使用C编写的FFT实现执行TFHE-c库的基准测试，而614号47 ms用于单个引导操作。与我们的实现相比，这只快了~ 2，考虑到我们的目标不是实现快速实现，而是实现内存安全，易于使用，并且易于与SGX集成，这并不太糟糕。最后，我们还执行了TFHE库的基准测试，包括所有优化。我们使用他们的spqlios FFT处理器和FMA指令集扩展，并实现了14。771 ms.这个数字与他们的发现相似，但不应该直接与我们的比较，因为它实现了几个优化。4.3. 姚明Andrew Yao介绍了一种安全多方计算（SMPC）（计算 执行 通过多 缔约方 与 私人投入）1982年，姚明的百万富翁问题被称为姚明的问题很简单，考虑两个百万富翁，爱丽丝和鲍勃，希望找出他们中的哪一个更富有，同时保持其实际财富的私密性。本质上，这个问题的目标是计算以下内容：a ≤ b，其中a代表爱丽丝的财富，b代表鲍勃的财富，同时对计算方保持私有。姚明的百万富翁问题是一个在实践中看起来简单的问题，在很难解决的情况下。因此，这是很好的证明，一个特定的系统可以解决SMPC领域的问题。这个问题有几种解决方案，技术范围从不经意传输方法[31]，私有集合与HE相交[32]到FHE。4.3.1. 社会主义百万富翁问题在这个姚氏百万富翁问题的修改表1时间（μs）吞吐量（KiB s-1）加密1 .一、654 50七十三。916解密0。797 62一百四十八79密钥生成527号67L. Brenna等人阵列13（2022）1001185==≤他们互相透露自己的真实财富[33]。从本质上讲，它旨在计算以下内容：a b，其中a和b分别代表双方的财富，并且是私人的。4.3.2. 百万富翁问题为了增加我们实验中的计算负荷，我们考虑 姚百万富翁问题与社会主义百万富翁问题的融合问题。在这个问题中，我们的目标是找出双方财富的总排序，同时保持他们的实际财富的私人。也就是说，当a代表A方的财富 ，b 代表B 方的财 富，并且两者 都是私人的， 我们想弄清楚这三种情况中哪一种是正确的：• A比B富有• B比A富有• A和B拥有同等的财富我们通过使用TFHE方案加密值来解决这个问题。从技术上讲，这需要双方使用多密钥设置共同计算加密数据多密钥HE是可能的，如参考文献[34]所示，这方便地将我们使用的TFHE方案转变为多密钥TFHE方案。使用多密钥TFHE方案，双方将对各自的财富量进行编码和加密，将其发送到计算节点，在计算节点处，将其部分评估密钥组合，然后计算比较。4.3.3. 融合百万富翁问题我们首先生成两个值的二进制分解。为此，我们使用两个32位有符号整数。对于每个值，我们将它们按大端顺序分解为字节，然后将它们分解为单个位。我们使用big-endian来实现处理big-endian值的电路。然后，每个位都使用我们的TFHE实现单独加密。这导致两对32个密文表示两个值的加密在多密钥设置中，双方在完成密钥交换协议后分别执行这些操作。请注意，我们的TFHE方案的实现不支持多密钥设置，因为我们基于一个也不支持它的实现。然而，支持它只需要添加一个密钥组合步骤，该步骤随参与方的数量线性缩放在此之后，设置阶段完成。然后我们执行COM-等效于计算a b的奇偶电路和等效于a的等式电路 b.两者都对加密位列表（两对32位）进行计算，产生加密结果。这两个电路是独立的，因此并行评估，虽然我们的实现顺序执行它们。4.4. TFHE-rs（含和不含SGX）接下来，我们评估和比较TFHE-rs在使用和不使用SGX的情况下的性能我们重复每个实验25次，只对相关部分计时。运行80位安全性，TFHE-rs与SGX的算术平均值为90。504 s和0. 60286 s，而FHE仅在116完成。08s，标准差为2。3548秒。这些结果表明，TFHE-rs使用SGX大约快28%。已知有与SGX内存加密和分页相关的开销。然而，我们通过SGX飞地如何处理内存来解释TFHE-rs的两个版本之间的性能改进。为此，我们使用128位安全参数集，这是一个使用最多的内存，在图3中示出了释放的分配速率，而在图3b和c中示出了释放的分配速率。从图中我们可以看到，该程序持续消耗大约100 MiB的内存，并且具有大约每秒100 000次从内存分析中可以看出，程序会执行一个签名，大量的分配和处置。Linux x上的常规Rust代码依赖于标准的libc malloc 9分配器。然而，我们的SGX实现所基于的For-tani XRust EDP平台使用dlmalloc 10分配器。 这个分配器强调最小化内存使用和碎片，当程序定期分配和释放内存时会发生的事情，就像我们的虽然TFHE-rs中的每个分配都相对较小，大约只有几个kibibytes，与用于数值处理的向量相关，并且从未超过1 MiB，但我们想看看不同的分配器是否可以实现28%的执行时间加速。因此，我们修改了TFHE-rs以使用dlmalloc分配器，并重复了测试。使用修改的TFHE-rs，我们获得了93的平均值。556 s，标准差为1。4932 s的程序与80位的安全性和平均160。61和3。9251 s。该结果仅比具有SGX的TFHE-rs慢大约综合结果如图所示。 四、从图中可以看出，使用128位安全性会显著影响性能。混合程序执行大约72. 5%，而只使用dlmalloc进行分配的FHE是71。比80位安全的慢7%。如上所述，这是因为TFHE方案中的密文随着安全性的增加而在大小上大幅增长，从而增加了所需的计算。至于有和没有新交所的时间差，只有3%的时间差是很低的。因此，用户将受益于使用SGX版本，该版本涵盖了FHE的完整性弱点。为什么SGX版本比只使用FHE的程序更快还不清楚。然而，如图4所示，针对仅FHE版本测量的标准偏差更高，这意味着性能可能比它们看起来更相似。另一个原因可能是因为CPU的自动频率缩放。 然而，关闭它也会产生同样的结果。我们没有看到其他行为，包括系统调用，可以解释性能差异。系统调用主要由内存分配调用组成，这些调用由安全区内存管理器处理。我们的程序是单线程的;它不使用任何SIMD指令，也不包括在测量的执行时间的随机性。如果我们要推测，性能提升可能是SGX SDK优化了一些通常无法优化的情况的结果，因为操作系统和进程交互的复杂性。5. 相关工作Drucker和Gueron [35]指出，大多数安全的云数据库解决方案倾向于通过使用TEE或HE来提供数据的机密性和完整性。他们表明，结合TEE和使用HE是可行的，并且不需要依赖于TEE用于保密目的。他们将他们的工作与CryptDB [36]和MrCrypt [37]进行比较，两者都使用部分同态加密（PHE），但缺乏代码和数据的完整性安全性Drucker和Gueron结合了PHE方案Paillier [38]和SGX，其中SGX提供了代码和数据的完整性Paillier加密系统确保数据是私有的，并提供机密性，即使在飞地内。这种组合使系统可以减少对英特尔的信任，因为Paillier密码系统在允许一些计算的同时保证了加密数据的机密性。在他们的实验中，LinuxX的内存分析器。8观察到的内存使用情况随时间的变化是9 https://www.gnu.org/software/libc/manual/html_node/The-GNU-Allocat或.html。8https://github.com/koute/memory-profiler。10http://gee.cs.oswego.edu/dl/html/malloc.html。L. Brenna等人阵列13（2022）1001186××图3. 具有默认系统分配器的FHE的内存使用特性。见图4。我们的百万富翁问题的100倍。进行25次EX实验，并且相应的标准偏差由垂直误差条表示。1左右。7与未在SGX中运行PHE相比，性能下降。正如预期的那样，EXSAFETY [39]结合PHE和SGX来安全地处理基因组数据，以识别疾病的遗传风险因素。这些数据是非常敏感的，并且在如何处理和存储这些数据上通常有严格的规定。与现有的安全计算技术相比，8加速。TEEFHE [40]是通过在SGX内执行自举步骤来组合FHE与SGX的示例。他们使用在简单加密算术库（SEAL）中实现的BGV [27]方案，并修改该库以在SGX中运行。它们将工作分布在多个节点上，其中一些节点在不可信的协议中使用同态运算来处理密文。当节点需要引导过程时，它们将其传输到具有在SGX内运行的SEAL库的节点SGX安全区执行加密和解密，保护数据和代码的完整性和机密性，因为它们不考虑边信道攻击。解密和加密密文可以去除编码的噪声并刷新密文，有效地执行与自举操作相同的操作，但成本较低。当不可信计算服务器对加密数据执行计算时，它们在攻击的情况下不保持数据完整性。大量的工作存在，解决保密性与侧信道攻击和云托管计算有关的问题。Chen等人[41]提出了一种软件框架，可以检测特权攻击者（例如恶意或病毒感染的操作系统）的侧信道攻击。可以使用ORAM [8]等技术来保护利用访问模式信息泄漏的某些类型的侧信道攻击。ORAM可以被看作是一个编译器，它将程序的内存访问转换成一个程序，其中内存访问的分布不同于（独立于）原始程序，同时保留程序的语义。Path ORAM [42]改进了常规ORAM，具有较低的空间开销，在某些情况下，与早期工作相比，性能逐渐提高。Circuit ORAM [43]进一步改进了这些技术，并给出了一个复杂度接近理论下限的实现。ZeroTrace [44]是一个不经意的原语的例子。塞-在SGX中使用块级存储器控制器来隐藏访问模式，从而增强了针对访问模式侧信道攻击的安全性。路径ORAM和电路ORAM都被实现，并且在某些情况下，在飞地代码和ORAM服务器之间的带宽成本中仅给出对数开销。ZeroTrace减轻了SGX的相当大的弱点，因为它通过将程序转换为不经意的表示来防止共享资源和页面错误相关的攻击。另一示例 SGX中的不经意存储器原语是ObliX [45]，一个不经意搜索索引。作者介绍了一种他们称之为双重遗忘技术的东西，因为它确保了对外部服务器的访问以及L. Brenna等人阵列13（2022）1001187××++=ORAM客户端的内部内存是不经意的。ORAM客户端是一个通过不经意技术访问外部资源（ORAM服务器）的程序。这些双重遗忘技术确保了即使对手观察到访问客户端记忆，它不能学习任何关于数据的信息。ObliX另外设计了比早期工作更有效的不经意算法，并实现了一个联系人号码发现服务，类似于Signal它们使用与Signal不同的技术，但实现了~ 9到~ 10的加速比。140快，同时加强安全性，通过利用 双重遗忘技术CacheOut [6]攻击利用了这样一个事实，即刷新和覆盖的硬件缓存仍然可以恢复。CacheOut甚至可以选择性地选择部分数据以相对较高的效率泄漏，而不像以前的攻击，攻击者只能观察CPU飞地当前正在访问的泄漏数据。这次攻击需要硬件修复，再次证明SGX安全区不能完全保护安全区中数据和代码的机密性，需要采取其他保护措施。SGAX e [47]利用CacheOut攻击以损害en-clave存储器的机密性和完整性。该攻击提取安全区使用的秘密证明密钥来证明它们是真实的，这意味着恶意攻击者（如恶意云供应商）可以将假安全区传递为真实安全区，从而欺骗客户端。 这种攻击危及许多安全保障这是我们的混合TEE和FHE解决方案所需要的，但最重要的是，它损害了我们系统工作所需的完整性保证负载值注入（LVI）攻击[48]建立在Meltdown[49]将攻击者的数据注入这种可扩展性违反了SGX应该提供的数据完整性保证，因为它为受害者的代码在攻击者的数据上执行打开了可能性此外，它可能会通过注入以受害者代码不期望的格式结构化的数据而导致软件崩溃。修补LVI需要大量的软件补丁，估计对SGX飞地的影响在2-19倍之间。6. 总结发言本文介绍并评估了用于执行FHE的TFHE-rs库，特别是用纯内存安全Rust编写的TFHE [29]方案。它通过使用FortaniX Rust EDP作为单个依赖嵌入SGX。我们的TFHE-rs实现基于一个用C和C混合编写的现有库[25]。除了创建SGX安全区所需的最低配置外，没有用户要求的配置。TFHE-rs提供预制电路，使用户可以轻松创建通用电路，并提供内置的串行化和串行化支持，以便轻松传输到安全区和从安全区传输。我们评估了具有和不具有SGX飞地的TFHE-rs的性能特性，发现性能开销可以忽略不计。评估表明，使用带有SGX的TFHE-rs比没有SGX的TFHE-rs版本快3%。这一结果与我们的假设不一致，即TFHE-rs与SGX应该更慢。根据我们的经验，我们推测特定的内存管理 实施方式 特别影响 性能 的LinuX上的默认系统分配器（libcFortaniX Rust EDP在SGX设置中使用的dlmalloc分配器。 因此，一个与我们类似的系统应该强调低内存使用率，并尝试不同的分配器，以确保它们保持在SGX施加的内存限制内。然而，测量的标准偏差确实解释了大部分的性能差异，并且基准测试本身需要足够长的时间才能使这种差异归因于我们实验设置中的环境因素（即，由于系统负载）。总的来说，这是一个积极的结果，因为我们的混合解决方案更安全，更快。因此，我们得出结论，在SGX中使用FHE操作，用内存安全语言Rust编写，是可行的，并且提供了几个额外的安全保证，前提是开发人员确保合理的内存使用。竞合利益作者声明，他们没有已知的可能影响本文所报告工作确认这项工作的部分资金来自挪威研究理事会的资助编号263248和275516。引用[1] 金特里角全同态加密方案，博士。论文斯坦福大学; 2009年。https://crypto.stanford.edu/craig/网站。[2] RivestRL，Adleman L，Dertouzos ML.关于数据库和隐私同态，安全计算的基础中国科学院出版社，1978年.第169- 179页。[3] 徐毅，崔伟，裴纳多.受控通道攻击：不可信操作系统的确定性侧通道。In：2015 IEEE Symposium on Security and隐私; 2015. 第640- 656页。https://doi.org/10.1109/SP.2015.45网站。[4] Brasser F，Müller U，Dmitrienko A，Kostiainen K，Capkun S，Sadeghi A-R.软件盛大曝光：SGX缓存攻击是实用的。在：第11届USENIX攻击性技术研讨会（WOOT 17），USENIX协会，温哥华，BC; 2017年。https：//www.useniX.org/conference/woot17/workshop-program/presentation/brasser.[5] 王军，程勇，李勤，蒋勇.针对英特尔SGX的基于接口的侧通道攻击。CoRRabs/1811.05378 2018。http://arxiv.org/abs/1811.05378网站。arXiv：1811.05378。[6] [10]范夏克S，明金M，邝A，根金D，亚罗姆Y.高速缓存溢出：通过高速缓存驱逐在英特尔CPU上泄漏数据. 2020年。https://cacheoutattack.com/网站。[7] 珀西瓦尔角为了娱乐和利益而丢失缓存 2009年[8] 戈德赖希岛Towards a theory of software protection and simulation by obliviousRAM，in：Proceedings of the nineteenth annual ACM Symposium on the theory of计算的 STOC '8 7 ， AC M ， 纽 约 州 纽 约 市 ， 美 国 ， 19 8 7 ： 18 2 -9 4 。https://doi.org/10.1145/28395.28416。 http://doi.acm.org/10.1145/28395.28416。[9] MatsakisND，Klock FS. Rust语言 ACM SIGAda-Ada Lett 2014;34：103-4.[10] van der V，Veen N，dutt Sharma L，Cavallaro H Bos.记忆错误：过去、现在和未来。In：Balzarotti D，Stolfo SJ，Cova M，editors.研究攻击、入侵和防御。柏林，海德堡：施普林格柏林海德堡;2012. p. 86比106[11] 米勒M.软件脆弱性缓解领域的趋势、挑战和战略转变. URL. 2019.PjbGojjnBZQ？t 848，https://youtu.be/。[12] 沈毅，陈毅，陈克，田宏，严松.是孤立，还是分享？那是一个问题英特尔SGX，收录于：第九届亚太系统研讨会论文集。URL.在：APSys '18，计算机械协会，纽约州纽约市，美国; 2018年。https://doi.org/10.1145/3265723.3265727。https://doi.org/10.1145/3265723.3265727.[13] Das A，Dutta S，Adhikari A.再访对选择密文验证攻击的不可破解性：全貌. In：Susilo W，Reyhanitabar R，editors. 可证明的安全性。Berlin，Heidelberg：Springer Berlin Heidelberg; 2013.p. 104比20[14] 杜立夫D，杜沃克C，Naor M.非延展性密码学30.第30章.https://doi.org/10.1145/103418.103474网站。[15] [10]张文辉，张文辉，张文辉.加密灵活性及其与圆形加密