近期，创新工场南京人工智能研究院执行院长冯霁做客雷锋网(公众号：雷锋网)AI金融评论公开课，以“浅析联邦学习中的安全性问题”为题，详尽地讲解了联邦学习的特点、联邦学习的应用和安全防御对策等内容。
以下为冯霁演讲全文内容与精选问答：
今天跟大家简单的汇报，我们对联邦学习中安全性问题的思考。
在介绍联邦学习之前，先简单介绍一下创新工场。
创新工场，是由李开复博士在2009年创办的创投机构，经过10余年的发展，在国内外都颇具影响力。
创新工场的特色之一是设立了创新工场人工智能工程院，开创了独特的VC+AI模式。创新工场人工智能工程院最近针对人工智能系统的安全性和隐私保护方向，做了一点自己的思考，今天和大家做一个简要的技术上的分享。
人工智能系统的安全性问题
这一波（2015年后）人工智能的兴起，使得人工智能逐渐从低风险的应用，比如判断一封邮件是否是垃圾邮件，转向了高风险应用，比如自动驾驶、无人机、还有重度依赖人工智能技术的金融投资、投顾等领域。
一旦这些人工智能系统出现了偏差甚至错误，它所带来的损失不仅仅是巨额的财产，还有可能是生命。
但是，一个核心的问题是，人工智能领域涉及到的安全问题，和传统的软件工程安全问题，是否存在本质的不同？我们能否继续使用传统的攻防工具，对人工智能系统进行安全分析？
这就需要谈到软件1.0和软件2.0的概念。
我们认为在这一轮的人工智能兴起之后，整个软件工程也产生了一个范式的转变。
在传统的软件工程中，工程师会搭建一个系统，构建一个基于规则的程序，输入数据后，计算机会给出确定性的输出。这是软件1.0时代的特征。
而随着这一波人工智能的兴起，诞生了一个新的软件工程开发范式，程序是由数据驱动的方式，利用人工智能算法自动产生的，这从软件工程角度来看，是一个相当本质的改变，有人称之为软件2.0时代。
因此，在软件工程1.0时代的一系列安全分析，漏洞分析的手段，到了软件2.0时代不再适用。软件工程范式的改变，带来了全新的安全问题。
目前针对人工智能系统的攻击，可以分成两大类。一类是测试阶段攻击，一类是训练阶段攻击。
测试阶段攻击
训练阶段攻击发生在AI模型训练之前，测试阶段攻击针对是已训练好的AI模型。我们先看测试阶段攻击。
测试阶段的攻击，大家见的最多的一类，也对抗样本。
左边的这张图拍的是大熊猫的照片，当攻击者知道这个图像分类模型的所有参数后，就可以根据模型的参数，精心设计出干扰“噪声”（中间的图）。
把噪声叠加在左图，形成右图。虽然我们用肉眼看到的右图和左图一模一样，但图像分类模型会把右图的熊猫错认为另一种生物。这个过程就是所谓的对抗样本攻击。
对抗样本不仅仅可用于电脑储存的数字图像，还可以应用在真实的物理环境中。
比如对交通的路牌做微小的改动，就可能让自动驾驶汽车在行驶过程中因为不能正确识别，而做出错误的行动。再比如用3D打印技术设计出一只乌龟，在乌龟的纹理上做对抗样本的叠加，模型会认为这是一个其他物种。
对抗样本并不神秘，学术界认为它攻击原理的本质就是由于我们的输入样本在一个非常高维的空间中。而通过机器学习模型学习出来的决策边界，在高维空间中是高度非线性的。
对抗样本在这些高度非线性的角色边界附近产生了一个扰动，扰动就会让模型从分类一误判为分类二（如上图）。但它们在视觉上很难区分。
刚才讲的对抗样本，从另一个角度来看，是白盒攻击。意思是攻击者需要提前知道AI模型的所有参数信息。
黑盒攻击，是另一种测试阶段攻击，攻击者对指定模型的参数未知，只知道模型的输入输出，这种情况下依旧想产生特定的对抗样本，很明显黑盒攻击的难度更大。
怎样才能让黑盒攻击，做到和白盒攻击一样的效果呢？对此，目前常见的攻击思路有两大方向：
黑盒攻击的第一大方向，是利用对抗样本的普适性。
虽然准备攻击的对象的模型和参数不知道，但是我们可以找一个已知的模型，比如说VGG，或者ResNet（残差网络），来做一个对抗样本。
我们的核心假设是如果这个对抗样本能哄骗已知的模型，也就能哄骗云端（黑盒）的分类器， 2016年有人做过一个的工作，用不同的神经网络架构产生相应的对抗样本，去哄骗其他的结构。实验的结果证明了，这个假设是合理的。
怎样加强这种对抗样本的普适性？
首先是在训练替代模型时，对数据进行增广，其次是利用集成方法，如果它能成功的攻击多个已知的白盒的模型的集成，那么攻击一个黑盒的API，成功率就会高一些。
黑盒攻击的第二个方向，是基于查询的逆向猜测，目前有一些云服务，返回时显示的不仅仅是一个标签，还包括了某一个类别的概率的分布的向量。
这个分布向量包含了关于模型本身非常多的知识。我们可以让这个模型标注足够多的样本，然后训练一个本地模型，模拟云端模型的行为。由于本地模型是白盒的，利用现有白盒攻击算法，针对本地模型产生对抗样本，再由于普适性，该样本对云端黑盒模型往往同样有效。
这件事情的关键，是训练一个本地的模型，该模型能够模仿黑盒模型的行为。有点像吸星大法。学术界Hinton等人提出的知识蒸馏，以及更早的周志华教授提出的二次学习，本质都是在干这件事情。
我们也可以用遗传算法，改变输入样本的像素的值，每次改变一点点，就访问一下云端的API。用这种方式，我们就能慢慢地收到一个可以哄骗云端的对抗样本。
训练阶段攻击
刚刚讲的，是测试阶段攻击。下面讲，训练阶段攻击。
训练阶段攻击，发生在模型产生之前。比如说经典的训练阶段攻击是数据下毒，目标是改动尽可能少的训练数据，使得训练后的模型，在干净测试集上表现尽可能差。
最近我们和南大周志华教授合作，提出了一个新的范式，我们叫毒化训练（参见Learning to Confuse: Generating Training Time Adversarial Data with Auto-Encoder，In NeurIPS 19）要求对每个样本尽可能小的扰动（注意数据下毒是尽可能少的样本进行编辑），使得训练后的模型，在干净测试集上表现尽可能差。
毒化训练，从流程来看就是这样，针对一个训练集，需要用一个函数在训练集上做某种程度上的扰动。
然后任意一个模型，在毒化后的训练集上做完训练后，它在面临一个干净的测试样本的时候，每次的预测都是错误。
那么这里的关键就是如何得到下毒的函数g，在Deep Confuse这篇文章中，我们用了一类特殊自编码器。自编码器是非常经典的，从输入到同输入空间中的映射。去噪自编码器，能做到噪音样本经过编码和解码这两个步骤，把原始有噪音的样本去噪。
这个算法把去噪自编码器逆向使用，让自编码器学习出如何增加毒化噪声（而不是降噪）。
这里就涉及到了算法的第二个核心思想：
我们需要同时训练一个假想的分类器和一个我们想要的加噪自编码器。通过记录假想分类器在训练过程中更新的轨迹，反向的更新毒化噪声器的参数。
举例来说，我们观察一个人学习的过程，然后根据这个人学习书本的轨迹，修改书本的知识。我最终希望他学完这本书后，每学一步都是错的，每一步我们都稍微修改了一点点。通过劫持一个正常分类器的学习轨迹，我们教会了加噪自编码器如何下毒。
效果是明显的，如上图所示，abc中的三张图，第一行都是原图，第二行都是毒化后的图片，从视觉上看，我们很难看出不同。
但是对于分类器来说，在毒化后的数据集上训练的分类器，面临干净样本的时候，正确率降低到了完全不可用，正常图像数据基本都不能正确的被识别。
毒化样本也存在普适性，我们针对于不同的网络架构（VGG、ResNet、Dense）做了一些实验。
这三个不同的网络架构，在相同的毒化训练集上，预测准确度都会有一个非常明显的下降。
当然，毒化训练，不是只能干坏事，它也能做好事。
毒化训练，可以用来保护公司的知识产权。比如医院，如果想去发布一些训练集，但又担心第三方用发布后的数据进行商业活动。作为数据的发布方，可以将想要发布的训练集毒化，让第三方不能随意对这些数据进行商业运作。
下面讲联邦学习。
联邦学习，我的理解是，他本质上是下一代分布式机器学习系统。它本质上是一个分布式的架构，在这种分布式的架构下，它具备传统分布式平台不具备的隐私保护的功能。
联邦学习有三个显著特点。
第一个特点是刚才提到的隐私保护。由于训练数据不会出本地，联邦学习满足欧盟的GDPR法案（通用数据保护条例）等各类隐私。
第二个特点是端部定制。
联邦学习在边缘计算中前景巨大。
根据联邦学习算法的特点，我们如果在边缘计算的过程中，比如说我们在可穿戴的医疗设备中，这个模型不仅保护了本地数据，跟云端的大模型相比，它还自适应的去满足基于本地数据的个性化需求。每个人对医疗设备的需求是不一样的，我们可以根据不同数据的输入分布，做一个端部的定制化。这非常具有商业价值。
第三个特点是大家熟悉的协同合作，在不同机构之间，比如一家电商网站和一家银行之间的合作。在联盟学习没有推出之前，这件事情可能在技术上不可行，而在联邦学习推出之后，这件事情可以做到。
联邦学习的应用可分成四大类。
第一，是基于政府的联邦学习应用。这类应用主要是因为法律法规或者政策性的要求，催生的AI服务。
第二类，是基于企业的联邦学习应用。部分大型机构内部之间的数据不能进行直接的交换。
第三类，消费端的联邦学习应用，更多的是针对于边缘计算或者定制化。
2C端，更多和边跟边缘计算有关；而2B端，更强调联邦学习的协同能力。
当然也可以做把2B、2C混合着做，统称混合型联邦学习应用。
在联邦学习的分布式场景下，安全的问题更加需要研究，因为攻击者攻击的可能更多。
比如攻击者所了解的先验知识会更多，要么是知道某一方的数据，要么知道某一方的模型。不需要知道所有方的数据和模型，攻击者就能做出攻击。
攻击者的目的也更为多样，他可能只针对于某一方进行攻击，也可能把整个联邦后的结果都进行攻击。不管如何，被攻击者所面临的场景矩阵都会更加复杂。
针对联邦学习的攻击的方式可以分为三类。
第一类是黑/白盒攻击，攻击者获得模型参数（白盒），或者通过API进行访问（黑盒）。黑/白盒攻击具有普适性，和联邦学习关系较小。刚才提到的各类黑盒白盒攻击，在联邦学习场景下依旧适用。
第二类是信道攻击。
如果攻击者侵入了训练过程中的通信系统，他只能够监听到本地的小模型跟中央的Server之间的梯度更新的信号，我们能不能做一些事情？
上图基于对抗生成网络，如果你有相应的梯度更新的方向，这篇工作告诉我们，目前技术上能够高保真的还原出对应的样本。怎么防御呢？
目前，我们已经有了的防御方案，比如对梯度参数信息进行同态加密，能够以非常高的概率防御这一类的信道攻击。
最后一类是数据攻击，也就是刚才提到的毒化训练，数据下毒。
联邦学习场景下，毒化训练的核心问题是，仅仅毒化个别数据库（而不是所有数据），是否可以依旧破坏模型的准确度？
例如如果我们只得到了30%的数据，毒化训练的算法有没有效，需要实验验证。
在多方联邦学习场景下，我们用CIFAR10的数据来分别毒化不同比例的本地数据库，观测毒化的效果。
如上图显示，不管是两方学习、三方学习还是四方学习，不管我们攻击了一方、两方、三方还是把所有数据都攻击，性能都会降低。
当然你攻击的联邦学习的参与方越多，攻击的成功率和攻击的显著性就会越高。
安全防御，是一件非常困难的事情。
做一个坏人很容易，做好人却很难。坏人，只需要攻击一个点，攻击成功了，攻击的算法就有效。如果做防御，你需要对所有潜在的攻击都做保护。
我简单介绍三类不同的防御思路。
第一类就是刚才提到的，基于信道的攻击。用同态加密或者多方安全计算，能够解决信道攻击。
第二种思路，即鲁棒性机器学习。其实在深度学习之前，学术界就有非常大量的鲁棒性机器学习研究。
第三种思路是对抗训练和联邦对抗训练。
对抗训练是鲁棒性机器学习的一个分支。对于每一个样本点，在围绕这个样本点的附近，都能够有一个非常好的性能。通过这种方式来避开在高维空间决策边界中样本的一些扰动。在联盟学习场景下，我们仍然需要开发一些新的、可以规模化的对抗训练算法。
目前对抗训练是一个非常好的技术，但是它在面临海量训练集的任务的时候，很难形成规模化。这是我们从算法上设计更好实现安全防御的三种对策。
时间有限，今天就和大家介绍这么多，谢谢。
互动问答精选
Q1: 为什么说毒化后的样本，可以防止成为不好的用途？
冯霁：当你把要发布的数据进行某种程度上的毒化，第三方因为不知道你如何毒化的，所以他就没有办法拿你的数据做你不想让他去做的一些场景和商业落地行为。
Q2: 为什么四方学习的原始数据，准确度比两方的低很多。
冯霁：下毒的训练集越少，没有毒的训练集越多，下毒的能力就越少。
最极端的例子是，如果你有100万个样本，你只改了一个样本，训练之后，你对模型的操控的能力跟操控的幅度就会更小。
Q3: 最近有银行和医疗公司泄露数据的情况发生，联邦学习现在的成熟度，足够应对这些情况吗？
冯霁：泄露数据的原因比较多，联邦学习是能够从算法上和技术上防止数据的泄漏。
如果因为业务方本身或者其他原因导致的数据泄露，那么这就不是一个技术问题，也就不是联邦学习所能够解决的领域和范畴了。
Q4：原始数据是指毒化前的数，如何应对非iid场景下的毒化攻击。
冯霁：在iid场景下进行毒化攻击，都很难。毒化攻击这件事情本身和这个样本是不是iid没有多大关系。
只能说，如果样本是iid的话，对于一些分类任务它是能更好毒化的。
Q5: 联邦学习和区块链有什么不一样？
冯霁：不太一样。
联邦学习更多的是一个分布式的机器学习平台，而区块链更多的是在做一个去中心化的、可靠且不受干扰的信任机制。
Q6: 无人车怎样防范错误的识别图像？
冯霁：有人专门做过实验，检验目前商用的无人车是否能识别毒化后的数据或者图片。
当我们把路牌的进行处理会发现，目前现有的、比较成熟的无人车视觉系统都会做出相应的误判。
无人车公司需要在这一类高风险模型的训练过程中利用到对抗训练，增强模型的鲁棒性。
Q7: 联邦学习会导致隐私泄露吗？
冯霁：联邦学习是一个保护隐私的、分布式的机器学习平台。在这个框架下，我们可泄露的东西非常少。
当参数被加过密，信道在通信的过程中，也是监听无效的。我觉得唯一需要注意的是刚才提到的毒化训练。
联邦学习的数据不仅仅要不能出狱，同时在不出狱的同时，你还要保证别人也不能看到。
如果你的数据在不出狱的前提下，能够被第三方进行某种程度的修改，那么这也能给这个系统带来隐患。
Q8: 如何平衡联邦学习的效率和安全？
冯霁：这其实是一个商业问题。
我们希望在未来，能够在可异性和隐私保护之间寻求一个平衡点。
这个平衡点，我们认为跟产品本身有关。
有的产品是受到法律强制性约束的，它基本上是是没有可平衡余地的。
对于不受法律严格约束的应用场景，我们认为应该把这个选择的权利交给用户。
用户想要一个更强的隐私保护，效益就会差一些；用户希望效率更高，那么隐私的保护可能就会弱一些。这个选择的权利不应该只让产品经理决定，而更应该交给用户。（雷锋网）
雷锋网
雷锋网原创文章，未经授权禁止转载。详情见转载须知。
