5月17日， RSAC密码学沙龙先进技术以“应用多方计算”为主题，主要包含三个子议题:1、《安全快速的迭代评估方法》及其在安全PageRank算法中的应用；2、《基于函数表示编译的安全计算范式》；3、《基于多方计算的不经意TLS协议》。其中《安全快速的迭代评估方法》的演讲者是比利时鲁汶大学的imec研究小组COSIC的Daniele Cozzo博士（COSIC是比利时微电子研究中心IMEC在比利时鲁汶大学的一个专注于计算机安全和密码学的研究团队）；《基于函数表示编译的安全计算范式》的演讲者是imec研究小组COSIC的顶级演讲者Nigel P. Smart教授；《基于多方计算的不经意TLS协议》的演讲者是丹麦的奥胡斯大学的Damiano Abram博士。
下面绿盟科技将针对以上三个主题进行分别介绍。
1、安全快速的迭代评估方法及其在安全PageRank算法的应用，该主题主要针对欺诈检测场景的分析方法进行介绍。
- 收集网络中一段时间（1~2个月）内的重传数据
- 建立关联图，并从图中提取特征：包括强连通组件、最短路径、PageRank值
- 用PageRank值衡量在互联网中网页的重要程度
- 该方法可用于衡量交易网络中各种银行账户的可信程度
- 使用Molloy & al. (FCrypto2016)启发式算法：高的信誉值意味着低的欺诈概率
为保护客户隐私，在欺诈检测算法中使用多种隐私增强技术：
- 同态加密
- Sangers & al. (FCrypto 2019)方法
- 安全假设：被动安全，多数参与方诚实遵循协议
- 不支持外包：银行数量多，但计算服务少
- 安全多方计算
- 线性秘密分享算法（固定迭代次数以及提前终止的power method）
- 基于google矩阵的第二特征值
得出如下结论：
对于安全方式执行的一般不动点问题：
2、基于函数表示编译的安全计算范式
该主题从传统的（非加密模式）函数编译过程出发，首先将人类可读的函数表示编译成机器码或字节码，然后在实体机或虚拟机上执行，编译和执行两个阶段都必须做到高效运行。
对比实际和理想的加密函数编译过程，指出MPC协议通常需要配置相关的随机源，以及一般为特定任务开发的专用协议。
一个经典的小工具可以是并行执行多次乘法的一种方式，以避免多次通信。编译过程会考虑这些信标和小工具，所以理论也应该考虑到这些信标和小工具。
在任何运行敏感数据的函数中，有两个关键操作：
- 去敏感，即将敏感变量转化为不敏感变量
- 分类，划分敏感和非敏感变量
以上是信息流安全中的经典操作（BLP模型等）。MPC函数编译器充分利用这两个操作来满足性能要求。以基于MPC的LSSS中的典型整数比较为例，其指出这个过程只是统计上安全，因为这里将“<”编译到协议理解的操作中会引入安全问题。
考虑以下编译路径：
- 基于敏感输入变量x,y,z，执行函数F(x,y,z)
- 将敏感变量x,y,z变为不敏感变量
- 在干净的环境中，计算F(x,y,z)
- 输出结果
以上是一个有效的编译（功能正确），但是根本不安全。
为建模、量化这种安全损失，文中提出了一种适合于安全计算范式的函数表示模型。
捕获我们已知的MPC协议中使用的所有函数表示。一个函数被表示为M-Circuit：
- 二进制/算数电路的概述
- M-Circuit可以访问小工具或随机信标
- 每个M-Circuit属于一类（会详细说明它可以访问的小工具或信标）
从M-Circuit电路开始，它使用一个有趣的工具F，这个工具计算出真正想要的函数。
编译时获取M-Circuit中的M，并将其转换为M-Circuit中的M’：
- M和M’在功能上等价（他们计算相同的函数）
- 他们可以在不同的类
以底层协议支持的M-Circuit类中M-Circuit结束。
- 对编译步骤中的每个M-Circuit，我们可以定义一个执行跟踪
- 如果这两个trace完全不可区分，那么编译步骤就是完全安全的
- 如果这两个trace从统计上不可区分，那么编译步骤在统计上是安全的
- 如果这两个trace是可区分的，那么编译步骤就是不安全的
这可获知：
- 在理论论文中完成的二进制电路或运算电路的完美编译
- 对Beaver随机信标的完美编译
- 统计安全编译示例如前面的“<”示例
- 不安全的早期编译
从MPC到零知识证明ZK：
- –这种M-Circuit模型捕捉了实际MPC协议中发生的情况
- –我们可以通过MPC-in-the-Head从MPC协议中构建ZK协议
- –我们是否可以在MPC-in-the-Head协议中使用相同的编译/函数表示？
在MPC-in-the-Head中：
- 验证方模拟n个MPC方
- 挑战者（在交互式版本中）向证明者提出挑战，要求其公开一些各方观点
- 由验证者检查打开视图的一致性
- 正确性：由于底层MPC协议的正确性
- 稳健性：需要猜测验证者的挑战
- 零知识：由于基础MPC协议的被动安全性
第一步：在验证者头脑中执行MPC协议，记录所有发送/接收通信。将这些通信的承诺发送给验证人。
第二步：验证者选择一个（或多个）玩家，验证者显示此玩家（或多个玩家）的状态，验证者可以对其他玩家做他想做的事，验证者取消该玩家发送/接收的数据，
第三步：验证者检查视图是否一致，解除承诺是否正确
在本文中，我们展示了如何扩展标准MPC-in-the-Head协议来处理我们的M-Circuit结构，如使用不同的随机信标和小工具。
我们还介绍了一些适用于MPC-in-the-Head的特殊小工具，这样在构建MPC-in-the-Head协议时，我们可以重复使用所有关于MPC编译策略的工作：编译策略的安全性分析和处理分类数据的高效方法。
通过该分享我们可得知：
定义安全计算协议时：
- 不要使用二进制电路/运算电路的范式，我们没有生活在石器时代
- 对于安全来说，函数表示和协议一样重要
- 对于性能，函数表示可能比协议更重要
构建安全计算系统时：
- 考虑系统使用的函数的表示方式
- 如何将抽象表示编译成系统需要的表示？
寻找安全计算研究的主题：
- 怎么（自动）证明编译过程是安全的？
- 哪些工具/资源可以用来加速特定的有用的计算？
- 我们如何自动地从一个类编译到另一个类？从而将适合于一个协议的函数表示转换成适合另一个协议的函数表示？
3、经过多方计算的不经意TLS协议
该篇介绍了如下内容：
- 多方计算Multiparty Computation (MPC)
- 秘密分享（Secret-Sharing）
- 客户端提供数据的多方计算（Client-Supplied Data in MPC）
- 不经意TLS（Oblivious TLS）协议,其中记录层负责多方计算中的加解密，握手层负责多方计算中的密钥的交换，如下图：
- 多方计算中的Diffie-Hellman 加密（EC Diffie-Hellman in MPC）
- 性能估算：在局域网以两方做时延，握手时间约为1s，AES-GCM为3MB/s（仅在线阶段，基于查询表）
通过以上介绍，不经意TLS：TLS端点的多方执行，可用于：
- 任意数量的参与方
- 多方服务器和多方客户端
- MPC中的EC Diffie-Hellman
- MPC中的AES-GCM
- 创新的MPC-friendly AEAD
- EsDSA阈值
安全多方计算（包括秘密共享、不经意传输、混淆电路、隐私集合求交、隐私信息检索等关键计算协议）作为数据流通共享、打破数据孤岛的关键技术之一，有助于实现多方数据“可用不可见”。近年来在政务、金融、医疗、运营商、交通等多个场景应用落地，取得了良好的效果。然而目前MPC技术包含复杂的密码学操作，计算开销较大。同时，针对特定问题和场景，还需要设计专用协议。此外，该技术的落地还受到带宽、时延等因素制约。因此，提升计算效率、降低方案复杂度、拓展落地场景将是多方计算的应用发展方向。
版权声明
本站“技术博客”所有内容的版权持有者为绿盟科技集团股份有限公司（“绿盟科技”）。作为分享技术资讯的平台，绿盟科技期待与广大用户互动交流，并欢迎在标明出处（绿盟科技-技术博客）及网址的情形下，全文转发。
上述情形之外的任何使用形式，均需提前向绿盟科技（010-68438880-5462）申请版权授权。如擅自使用，绿盟科技保留追责权利。同时，如因擅自使用博客内容引发法律纠纷，由使用者自行承担全部法律责任，与绿盟科技无关。