SoK:安全多方计算通用框架

SoK:安全多方计算通用框架

写在前面

有段时间没有为知友们带来安全会议的演讲视频翻译了,主要原因是我发现这类文章阅读量并不是很高。业余时间我自己反思了一下,可能是因为知乎到底还是一个问答类社区,文字类型的描述可能更适合知友们快速感知到安全会议演讲视频的内容。为此,在接下来的安全演讲视频文章中,我做了如下几个改变:

  1. 不在知乎上传视频,而是根据视频主讲人的幻灯片展示情况,将对应的演讲稿发出。
  2. 演讲视频还是会上传,不过会上传到B站这个专门播放视频的地方。这样,如果有翻译错误,或者有更好的建议,知友或者B站的朋友可以通过弹幕、评论的形式更快地反馈。
  3. 演讲视频的中文字幕、时间轴文件(ass格式)、相应的截图等,我会公开在我的GitHub下面,方便知友们下载。

希望这种方式可以让知友们各取所需。如果知友们还想了解哪些演讲视频,也可以通过知乎评论、GitHub、B站等方式给我留言。我会尽可能满足大家的要求。

演讲视频简介

本次为大家带来的是2019年5月23日刚刚召开的安全顶级会议Security and Privacy 2019的一个演讲视频《SoK:安全多方计算通用框架》,对应的论文是《SoK: General Purpose Frameworks for Secure Multi-Party Computation》。

这里需要介绍一个背景知识:如果一篇论文的开头是“SoK”,则代表这篇论文是一篇综述论文。SoK的全称是“Systematization of Knowledge Papers,Security and Privacy的官方网站(ieee-security.org/TC/SP)给出了一个很详尽的解释:

Following the success of the previous years' conferences, we are also soliciting papers focused on systematization of knowledge (SoK). The goal of this call is to encourage work that evaluates, systematizes, and contextualizes existing knowledge. These papers can provide a high value to our community but may not be accepted because of a lack of novel research contributions. Suitable papers include survey papers that provide useful perspectives on major research areas, papers that support or challenge long-held beliefs with compelling evidence, or papers that provide an extensive and realistic evaluation of competing approaches to solving specific problems. Submissions are encouraged to analyze the current research landscape: identify areas that have enjoyed much research attention, point out open areas with unsolved challenges, and present a prioritization that can guide researchers to make progress on solving important challenges.Submissions must be distinguished by a checkbox on the submission form. In addition, the paper title must have the prefix "SoK:". They will be reviewed by the full PC and held to the same standards as traditional research papers, except instead of emphasizing novel research contributions the emphasis will be on value to the community. Accepted papers will be presented at the symposium and included in the proceedings.

简单来说,SoK论文的目标是系统化、结构化地评估已有知识体系的论文。这类论文虽然工作量很大,但由于缺乏必要的创新性贡献,所以一般不会被会议所接收。但是,随着相应知识的不断提出和完善,这类论文会对他人进一步的研究带来非常大的帮助。所以,越来越多的会议开始接收SoK论文了。SoK论文的最大特点是:这类论文的题目必须以“SoK”开头。

《SoK: General Purpose Frameworks for Secure Multi-Party Computation》这篇论文非常详尽的分析了现有的安全多方计算通用框架,从各种维度评估了各个框架的优缺点,在不同场景下给出了使用建议。特别地,作者成功构建了所有的通用框架,并把构建环境打包在Docker中。我个人用了一下Docker,样例程序都可以跑通,作者也针对各个框架给出了进一步的文档和注释。这篇文章特别适合准备研究安全多方计算协议,或者准备在实际中使用安全多方计算的研究人员。

演讲视频信息

中文字幕视频

感谢知乎工程师们的辛勤工作,知乎现在可以上传60分钟的视频了。为了文章的完整性,我把视频也同步发布在知乎专栏上面。

https://www.zhihu.com/video/1134055356077580288

演讲视频字幕

(主讲人)非常感谢主持人的介绍。我是Marcela Hastings。这是一篇SoK论文。我将讲解我们的调研结果。我们考察的工具是安全多方计算。这是一个密码学工具,允许互不信任的参与方根据自己的输入计算任意一个函数,计算过程不泄露除输出结果以外的任何信息。

安全多方计算实际应用中最著名的实例是丹麦甜菜拍卖系统。在这个场景中,售卖方是丹麦种田菜的农民,而购买方只有一个,即丹麦唯一的一个甜菜加工公司。售卖方为甜菜出价,表示他们希望按照这个价格售卖甜菜,购买方希望得知市场出清价(即保证供求关系平衡的售卖价格)。但售卖方不希望泄露自己的具体出价。如果常年泄露出价,则其它人就会得知自己的甜菜种植能力和做生意的能力了。因此,他们使用安全多方计算协议,在不泄露售卖方出价的条件下计算市场出清价。

另一个例子是波士顿妇女劳动委员会与企业的合作项目。此项目研究员工性别是否会影响到其实际的工资。公司不希望、从法律角度也不能够对外泄露自己雇员的收入或金融类信息。但通过安全多方计算,他们可以在不给出具体数据的条件下计算相应的统计分析结果。

所有这些例子都告诉我们安全多方计算已经足够高效,可以在实际场景中得到应用了。然而,我们之前看到的所有实际应用实例中,项目方都需要组织一个密码学专家团队,针对特定用例实现专用MPC引擎。如果想让MPC得到更广泛的应用,我们需要让不懂密码学的外行也能使用这一工具。虽然二十世纪八十年代,密码学家就提出了MPC算法,但一直以来MPC协议的效率都很低,无法在实际中使用,直到2004年“公平参与”编译器的提出改变了这一现状。

“公平参与”是第一个通用MPC框架,可以通过MPC执行任意函数的计算。在接下来的10年,这一框架掀起了学者们针对MPC协议性能优化的浪潮。直至现在,无论从算法角度还是从实现层面,MPC协议得到了巨大的优化。在过去十年间,学者们提出了很多端到端MPC框架。在本工作中,我们重点考察通用端到端MPC框架。

端到端框架的架构如幻灯片所示。框架一般实现了两个阶段的功能:编译器、执行器。这是因为大多数MPC算法只支持有限的算子,如模质数下的加法和乘法。开发者很难应用这些有限的算子实现所需的计算函数。因此,我们重点考察包含一个编译器的框架。编译器的输入是用高级语言描述的函数。编译器会把函数编译成算法可执行的协议。接下来,执行器会具体执行编译好的协议。协议会在多个参与方上同时执行。每个参与方都以编译器的输出结果和自己的秘密值作为输入,计算得到函数输出结果。当然了,不同框架的架构各不相同,但是它们基本都是这样的结构。

在本综述中,我们想回答这样一些问题:目前都有哪些框架?谁在使用这些框架?这些框架是否可以实现实际的计算过程?这些框架是否可以支持所需函数的计算?这些框架是否可以在实际中使用?

为了回答这些问题,我们调查了9个端到端框架和2个电路编译器。我们记录了这些框架的不同特性,包括框架所实现的协议、框架所支持的数据类型和运算操作、以及其它一些实现的具体细节。我们通过多种可用性标准对这些协议进行评价。为了收集这些数据,我们在每个框架上实现3个样例程序。我们把每个框架的完整构建环境及其对应的样例程序都放在了开源的代码仓库中。结合这些框架的使用经验,我们为各个框架补充了相应的文档。构建代码仓库的总时间约为750人小时。此仓库是开源的。我们仍然在积极地维护这一仓库,非常希望大家能看看这个代码仓库。

现在,我想简单介绍一下完成这些工作后我们所得到的一些结论。总的来说,几乎所有的框架做得都不错。各种框架在不同的安全模型下实现了不同的协议。根据具体用例的不同,框架也提供了一些协议和安全模型的选项。我们可以在几乎所有的框架上实现我们的样例程序。这意味着对于绝大多数场景来说,框架的高层语言具有较好的可表达性。总的来说,大多数框架都是开源的、可编译的、可用的。然而,我们发现了两个重要的改进方向。第一个方向是:框架的工程局限性较高。例如,框架的系统构建环境过于复杂。第二个方向是:框架的可用性较差。其根本原因主要在于框架缺失相应的文档。

在具体讲解这些问题之前,我想先从宏观层面介绍我们的发现。我们考察了9个框架。最下方是2个电路编译器。大家可以从表格中看到框架支持的参与方数量、支持的安全模型。我们有两种安全模型。在半诚实模型中,攻击者会正确执行协议,但是攻击者会尝试得到其它参与方的输入。在恶意模型中,攻击者不会遵从约定执行协议,以错误的协议执行结果中推断信息。

我们还对不同的协议进行了简单的分类,这里需要简单解释一下。第一类协议是乱码电路协议,最初由姚期智于二十世纪八十年代提出。自姚期智提出此协议以来,学者们持续不断地对协议进行改进。理论密码学家从不同角度对乱码电路进行了优化。从实际中我们发现,几乎所有的框架都实现了半诚实两方协议,一个参与方对电路加密后将结果发送给另一个参与方,另一个参与方根据输入对电路求值。在乱码电路中,需要把函数表示为布尔电路的形式。

第二类协议包含很多不同的协议。我们称这类协议为基于电路的多方计算协议。

这些协议拥有两个共同的特性。第一个特性是,需要把函数表示为代数电路或者布尔电路的形式。第二个特性是,数据需要用线性秘密分享的形式表示。线性秘密分享意味着协议支持任意数量的参与方。参与方协同工作,依次对门电路求值,将秘密分享输入转换为秘密分享输出。然而,在基于电路的多方计算模型下,不同协议将输入转换为输出的方式不太相同,可以基于信息论安全模型下转换,也可以基于密码安全模型下转换。

我们认为这两类协议可以涵盖大多数框架的基础协议。在理论层面,大多数理论密码学家用非常有限的运算操作定义MPC协议,涉及的运算操作只包含模整数下的加法和乘法,或者逐比特与预算和异或运算。这两类运算操作都是图灵完备的,任何函数都可以用这两种运算操作表示。然而,在实际中我们需要为代数模型下的除法、比较等公共函数定义更优的子协议,这样我们就不用把所有函数都表示为基本运算操作,从而提高函数表达的效率。

我们发现有3个框架实现了特定的子协议。我们称这类协议为混合协议。在最下方,大家可以看到2个电路编译器。

当选择适当的框架时,人们需要着重考虑的是:高层语言对协议的抽象能力。不同框架都实现了协议的抽象。我们对这些高层语言展开了考察。我们测试的其中一个样例程序是内积运算。内积运算是指逐位计算乘积,再对各个结果求和。

Frigate是一个电路编译器,它的高层语言是非常传统的C语言风格抽象。大家可以看一下幻灯片上给出的内积运算代码实现。初始化结果变量,在向量上构建循环语句,循环中依次取出向量中的每一个元素,计算各个元素的乘积,最后对乘积求和。实现过程非常直观、通俗易懂。然而,如果你熟悉MPC,你可能会知道在线性秘密分享模型中,我们可以通过一轮交互并行处理所有的乘法运算。如果你希望得到优化后的协议,你可能就需要使用PICCO等框架了。

PICCO会对内积运算的乘法进行了并行优化,它们实现了一个针对内积运算的自定义算子。所以PICCO是一个混合协议框架。大家可以看到,可以用这个非常简单的自定义算子求两个任意长向量的内积结果。即使你不熟悉密码学,也可以很方便地直接使用自定义算子,你也不需要关注底层到底做了什么。

然而,如果你是一个密码学家,你想实现一个比内积更复杂的函数,你可能会希望对生成的电路做更深度的控制和修改。这种情况下,你可能会使用ABY这样的框架。ABY是一个端到端框架,在C语言上实现了一个函数库。大家可以看到,我们用一个share类管理秘密数据。我们随后放置一个乘法门,ABY会帮助我们实现乘法的并行优化。我们需要一个乘法门对整个向量逐位计算乘法。随后,我们把向量展开,对所有乘法运算结果求和。这可以给我们更大的自由,实现我们想实现的函数。但如果你对密码背景不熟悉,你可能就不想具备这些自定义的能力。这就是我们考察的前后端高层语言的范围。

我们下一个想讨论的内容是这些框架的一些限制。正如我前面提到的,软件工程是这些框架中最主要的问题。大家一定要记住,大多数框架都是在学术研究场景下开发的。因此,这些框架在工程落地时会有很多的限制。在我讲解下面内容的过程中,大家要把这一点牢记于心。

最主要的痛点是构建系统。系统的整个构建过程非常复杂。你需要从源代码层面编译特定版本的OpenSSL库,这就要花费很长的时间,或者你需要建立一个自定义的证书认证机构,从而建立秘密通信信道。光编译每一个框架平均就要花费我们1-2周的时间。这个过程苦不堪言。但是大家很幸运,我们已经把编译好的环境放在了Docker仓库里,所以大家不需要再重复一遍此项工作了。

在系统构建之上,要使用这些软件框架项目,我们还需要很多的软件开发工作。正确实现密码学协议已经很困难了,但在这之上,开发者还需要实现很多支持系统,例如分布式通信、用安全语言实现与其它通信系统的交互。这方面的结论虽然比较细节,但仍然令人沮丧。例如,在ObliVM中,我们无法编写一个返回结果超过32比特的计算函数。我们可以通过进一步的代码开发来解决这个问题。由于框架都是在学术层面上开发的,框架在实现层面上都不太完美。

另一个比较严重的问题是可用性,尤其是文档比较匮乏。如幻灯片所示,我们定义了5类文档,一半框架都缺失了至少3类文档。我这里不详细介绍每一类文档的细节,而是想给大家展示几个例子,从而证明语言文档的缺失极大地影响框架的可用性。

语言文档指的是描述如何使用高层语言的文档。CBMC-GC是一个电路编译器,可以将代码编译成乱码电路。大多数人都熟悉C语言。假设我们要实现这样一个简单的程序:把两个数直接相乘。这个代码感觉上是正确的。然而,我们会得到一个编译错误:我们忘记返回一个值。

实际上,在CBMC-GC中,计算过程中的所有秘密输入的变量名都需要以input开头。这根本不算是一个问题,但是并没有文档说明这一点,我们有必要告诉大家。

另一个例子来自于ObliVM,这是一个将类Java语言作为高层语言的端到端框架。与前面相同,我们的程序是计算两个数的乘积,但我们碰上了解析错误。

事实上,Alice和Bob是此高层语言中的保留关键词。因此,我们不能把这两个词作为变量名。

Wisteria是开发编程语言的人所撰写的端到端框架。此框架使用函数式语言来描述计算函数。此框架包含了一个详尽的语言指南,告诉大家如何使用函数式语言编写计算函数。然而,语言文档没有考虑到解析器的限制要求。开发者需要在代码中放置很多的括号,编译器才能编译通过。

EMP-toolkit是一个我们非常喜欢使用的框架。这是一个基于乱码电路的框架。然而,我们发现平均600行代码才会有1行注释,并且没有单独的代码解释文档。这些问题都会导致框架难以使用。

然而,有一些框架的文档工作做得很好,我真挚地感谢这些框架的作者。对于那些维护一个较大开源项目框架的开发者,我想给出两个重要的建议。

第一个建议是,即使针对不同方面的很简单的文档,也会大幅提高框架的可用性。不同类型的文档指的是,可能有一个文档解释框架的架构,另一个文档是带注释的样例程序,演示一些高层语言的特性。

第二个建议是在线资源,例如提供一个邮件列表或在GitHub上开启问题追踪。这是一个持续生成、持续更新框架文档的好方法。问题追踪就像一个在线问答平台,这样你就不用通过邮件重复回答相同的问题了。问题追踪也是用户之间相互交流的平台,他们可以互相回答遇到的问题。如果你不再想维护你的框架,用户仍然可以相互讨论,解答相应的问题。

即使有这些工程和可用性方面的问题,MPC框架的实现情况还是非常乐观的。我们可以在框架上实现很多样例程序。总体来说,实现过程还是很顺利的。社区也发现了框架可用性的问题。IARPA HECTOR项目正在赞助下一代MPC框架的实现。在赞助中,它们专门提出了可用性评价标准。

我们强烈建议后续的开发者们可以与编程语言研究者合作。大多数框架都是由密码学家实现的,因此前后端语言的设计可能不是很规范。编译器经验充分的开发人员介入,会对语言设计有更好的帮助。

插播一条广告,我们仍然在积极维护我们的代码仓库,我们随时准备接受新框架、已有框架的提交请求。如果你在维护其中一些框架,或者想在学术项目中使用这些框架,建议看看此代码仓库。

最后一条广告,我们在寻找MPC的落地项目,如果你是潜在合作方,如果你有一个有趣的项目,请稍后与我们联系。

非常感谢。

(主持人)非常感谢。如果有问题的话,请用麦克风提问。

(提问者)你好,首先非常感谢你们所做的工作。社区迫切需要你们所做的工作,这个工作非常令人激动。我知道你们完成了这一概览性的工作。你们也得到了一些好的结论,一些不好的结论。但你们没有给出类似这样的结论:这是正确的框架,社区应该在这个框架的基础上继续构建,或者类似的结论。这样的结论可能会非常重要,因为如果没有这样的结论,最后的情况可能就是:哦不,这里有12个标准,我们要尝试构建一个标准,然后我们就得到了第13个标准。你能给出类似这样的结论吗?

(演讲人)当然可以。在论文中,我们明确给出了建议,推荐使用哪些框架。如果你在为某个特定场景寻求建议,我这里可以给出4个不同场景下的推荐。对于乱码电路框架来说,Obliv-C是一个不错的通用框架。如果你一些密码学专业知识,EMP-toolkit会更适合你。SCALE-MAMBA最适合多参与方场景,或者说这是一个混合协议框架。因此,这是最好的线性秘密分享协议框架。此框架的适用性很广泛,更新仍然很活跃。如果你有特定的安全需求,你可能会对Sharemind感兴趣,这是唯一一个付费开发者维护的框架,而且开发者是学术领域的研究人员。这就是我给出的推荐建议。

(主持人)谢谢,我绝对也会开发一个将Alice和Bob作为保留关键词的编程语言,这太酷了。再次感谢你的精彩演讲。

编辑于 2019-10-04

文章被以下专栏收录