• 元宇宙：本站分享元宇宙相关资讯，资讯仅代表作者观点与平台立场无关,仅供参考.

几分钟搞懂全同态加密FHE：运行模式与应用场景

  • 2024年8月12日 20:31

原文标题：FullyHomomorphicEncryption:IntroductionandUse-Cases

原文作者：NicolasGama和SandraGuasch，SandBoxAQ

编译：Faust，极客web3

这篇博客是对全同态加密（FHE）的系统性介绍，但我们并不在此深入的探讨数学细节，而主要从基础的机制设计角度来解释这项技术，让读者初步理解FHE的基本运行逻辑，并介绍FHE的几个主要应用模式。

上图展示了线上投票的三种加密/解密方案，其中E()表示加密操作，而D()表示解密操作；

左侧图中，一个受信任的中间人在公布投票结果前，会对各个投票数据进行混淆和解密，我们必须假设该中间人不会泄露隐私，且投票统计结果是正确无误的；

在中间的图中，使用了TEE，TEE能保证数据完整性和隐私保护；

而在最右侧的图中，使用了同态加密技术：加密后的投票数据可以被公开加总求和，然后再解密得到结果，算出最终的投票数

FHE（全同态加密）是紧凑型加密方案，输出结果?(?)的密文数据大小，以及解密该结果所需的工作量，仅取决于输入数据?对应的原始明文，并不依赖于所采用的计算过程，这与那些非紧凑型的加密系统截然不同，后者往往简单地把?与函数?的源码连接起来，然后让接收者自己解密?并输入到?中来完成计算任务。

在现实中，FHE外包模式通常被视作TEE等安全执行环境的替代方案，FHE的安全性基于密码学算法，而不依赖于硬件等实体设备。因此，FHE完全不受被动侧信道攻击或云端服务器被攻击的影响。想象一下，当某人需要外包出去一些计算任务，但数据非常敏感，他可能不愿意使用搭建在AWS上的虚拟机（VM），因为这类基于云端的服务器背后往往存在更高级的控制人。他也可能对SGX或TEE这类东西犹豫不决，因为运行TEE的主机可以监控该计算任务在执行时产生的功耗或运行时间等，可能通过这些数据来推断出一些信息。

然而，如果使用FHE，将计算任务外包出去的人就可以安心——因为在FHE的系统中要破解私密信息，就必须破解其用到的密码学算法，但这在目前几乎无法做到。

但是，虽然密码学算法可以防止攻击者在不知道密钥的情况下破解?对应的明文，但另一方面，通用延展性则允许攻击者对输出结果?(?)进行修改，这相当于一种主动侧信道攻击：攻击者可以对执行加密算法的硬件进行针对性的攻击，影响输出结果。这听起来似乎很可怕，但在FHE的设计中，这类恶意攻击可以通过在计算流程中制造冗余来进行规避。

简要总结的话，FHE通常会用到几组密钥，包含以下几部分：

解密密钥（DecryptionKey）：这是整个FHE加密系统中的主密钥，所有其他类型的密钥都可以根据主密钥来导出。解密密钥通常在用户本地生成，从不传输给外界，只有持有者本人能用它来解密FHE密文。这意味着密文即使在传输中被他人截获，也无法被解密，除非他们拥有解密密钥。

加密密钥（EncryptionKey）：在FHE的公钥模式下，加密密钥是用来将明文转换为密文的密钥。当生成初始密文的人不是解密密钥/主密钥的持有者时，就会使用加密密钥来进行加密。该密钥通常中等大小，由一些随机的零加密组成。由于FHE支持仿射函数（affinefunctions），足以用于加密任何消息。

在公钥加密模式中，加密密钥通常是公开的，任何人都可以用它来加密数据，但只有解密密钥的持有者才能针对性的解密。

计算密钥（EvaluationKey）：计算密钥是用来对密文?进行同态运算的专用密钥，使得FHE系统可以在不对密文?进行解密的情况下，对密文进行同态运算。计算密钥可以像公钥一样被公开发布，即使他人获知了计算密钥，也无法破解出密文?，而只能对密文进行同态运算得到一个输出结果。

此外，当使用计算密钥进行运算时，密文的结构保持不变，对密文?进行同态运算得到的结果会被重新加密为新的密文，这确保了计算过程中的隐私性，即使计算过程是公开的也不会泄露机密数据。

在上述几种密钥的持有者中，解密密钥/主密钥持有者是最敏感的，他要确保整个同态操作的执行链条/流程有效无误，最终的密文是安全的，然后解密得到明文结果。如果在FHE的操作链条中引入恶意操作，解密密钥有可能会在解密时被泄露。但幸运的是，同态操作可以公开进行并被任何人所验证。

FHE的具体场景/模式

在本节中，我们将描述一些FHE中的常见场景/模式，并讨论每种模式的优缺点。

外包模式（OutsourcingMode）

TwoPartyComputingMode（两方计算模式）

AggregationMode（聚合模式）

Client-ServerMode（客户端-服务器模式）

关于同态加密的其他细节

同态加密如何确保外部计算结果是有效的？

在多方合作的场景中使用FHE是更容易的，因为每个参与者都有动机诚实地遵循协议规定。例如，FHE可以在位于两个不同国家但属于同一公司/组织内的两个法人实体之间进行加密计算并统计一些数据：诸如GDPR之类的法规允许你对外发布某些统计数据，但会禁止将所有个人数据集中存储在同一物理地点。

在这种情况下，使用FHE是可行的，所有参与者都有动机诚实地遵循协议规定。而在参与方并非彼此合作的场景中，确保计算任务已被正确执行的最简单方法，是引入冗余（类似于多签/共识）。例如，在前面提到的外包和聚合场景中，同态计算用到的函数公式是完全公开的，并且可以是确定性的，只要两个或更多独立实体得出完全相同的输出密文，那么整个计算过程就是正确的，结果也是可信的。冗余程度越高，最终结果的可信度就越高，但这需要在效率方面进行权衡。

此外，当承包计算任务的计算方通过对输入和输出密文进行数字签名来担保FHE结果有效时，每个人都可以重跑相同的FHE计算流程，并检查计算方给出的证明是否有效。任何计算方的欺骗行为都可以被检测出来并被惩罚，并可以与一个公开可验证的证书相关联，该证书会揭露欺骗行为和欺骗者——我们称这种模型为强隐蔽安全模型。

至于完全同态签名，是另一种验证计算正确性的方法，无需第三方验证者，但通常需要更多的软硬件资源来参与。

FHE如何确保最终接收者只解密最终结果而非中间变量？

最简单的方法是确保解密密钥持有者无法访问FHE计算流程中产生的中间密文。在双方计算场景或客户端-服务器场景中，Alice对输入结果进行加密，Bob对密文进行计算并将加密的输出结果传输回Alice，显然Alice只能解密最终结果，无法访问中间变量。

在基于云端服务器的场景，例如线上投票系统中，许多参与者会在AWS等公共的云端服务器上发送加密后的投票数据，这里会用到一种手段：解密密钥通常不会交给单个接收者，而是以秘密共享的方式分配给不同的人或机构（类似于MPC）。在这种情况下，只有通过执行多方计算并让持有解密密钥的成员之间在线通信，才能对特定密文进行解密。如果其中某些人拒绝配合其他人，则无法进行解密。这样就可以通过设置相应的阈值来提高系统的整体安全性。

同态加密的构建模块

同态加密有三种类型：部分同态加密（PHE）、分级同态加密（LHE）和完全同态加密（FHE）。部分同态加密只允许我们对某些计算任务进行同态加密（例如求和、线性函数、双线性函数），而分级同态加密和完全同态加密可以支持任意的计算任务。

对于LHE来说，系统用到/产生的参数依赖于要执行的函数计算?()，并随着该函数计算复杂性的增加而增长，这反过来导致密文和密钥的大小也跟着增加，会消耗更多的存储和通讯资源。而FHE方案允许我们在给定的一组参数下（也就是给定的密钥和密文大小下），计算任何可以表示为二进制逻辑门电路的函数。也就是说，与LHE不同，即使需要计算的任务变得越来越复杂，FHE方案涉及的参数（以及密钥和密文）也不会变大。

因此，FHE是唯一一种能保证同态计算的内存消耗和运行耗时都与原始明文/任务成正比的模式。但是，FHE有一个技术上的问题：随着计算的持续进行，密文中包含的噪声（垃圾数据）会越来越多。为了避免噪声过多导致解密结果出错，FHE方案会定期执行一种代价较高的操作，称为自举（bootstrapping），它可以将噪声减少到可控水平。日后我们将对此进行更多的介绍和科普，大家敬请期待！

原文链接：https://cryptographycaffe.sandboxaq.com/posts/fhe-01/

元宇宙最新

元宇宙热门

Copyright © 2021.Company 元宇宙YITB.COM All rights reserved.元宇宙YITB.COM