使用部分盲签名打击欺诈

我们花了大量时间思考最好的方法来保护使用我们服务的人的隐私，同时也打击我们平台上的欺诈行为。我们为各种目的处理客户端应用程序报告的数千种不同类型的事件，包括调查崩溃、评估性能以及监控产品和广告指标。这些活动帮助我们了解我们的应用程序，并改善使用它们的人的体验。我们希望在报告足够的信息以准确监控我们的服务和最大限度地减少数据收集之间取得谨慎的平衡。

今天在@Scale 2019上，我们分享了我们正在进行的研究，目的是探索一种新的方法，通过使用盲签名等加密技术，以更高的匿名性报告事件，同时仍然打击欺诈。我们相信，如果浏览器制造商和应用程序开发人员共同努力，定义一套利用这些技术的新API，打击欺诈将需要从使用这些浏览器和应用程序的人那里收集更少的信息。在这篇文章中，我们将讨论私人防欺诈报告的挑战，并建议使用匿名日志记录和盲签名的可能的全行业解决方案。

我们提供第三方用来报告事件的API。这些事件是人们在Facebook上采取的操作(例如，点击)。当实体试图伪装成合法的事件时就会发生欺诈，即使它不合法-比如当机器人进行自动点击时，这些点击看起来就像是真人做出的一样。我们如何确定哪些事件是合法的，哪些是欺诈性的？

到目前为止，大多数公司都是通过从设备上收集难以伪造的信号来解决这个问题，比如加速度计读数、电池电量和其他高熵信号。必须伪造这些值的欺诈者将很难接近真实世界的信号，并且可能会作为统计异常脱颖而出。但这些难以伪造的设备信号也很难让人们保持知晓和了解。正因为如此，这类信息的收集可能会引发隐私问题，即使它被用来打击欺诈。

为了缓解潜在的担忧，我们考虑到了数据最小化；我们可以收集的最少的信息是什么，同时又能够防止大规模的欺诈？如果我们从“我们可以发送哪些额外的参数”的角度来处理这个问题？那么绝对最小值将是除了“这是一个真实的事件”之外不添加任何额外信息的参数。但是我们怎么才能让这些东西变得不可伪造呢？

数字签名(基于公钥/私钥加密)在这里提供了一个很好的解决方案，因为它们很难伪造。在任何产品交互中，用户可能会访问多个接触点。我们称之为用户之旅。接触点可能来自不同的域，甚至可能来自不同的设备。操作沿着用户旅程的每个接触点的实体可以使用其自己的私钥来签署一些数据。

沿途的每个签名都应该是随机数的有效签名。这可以通过查询每个实体的公钥来验证。

数字签名非常有效，但是它们仍然不能完全最小化这些参数传递的信息量。问题是链接性。这N个实体中的每一个都可以将转换报告链接到其自己的内部日志，并排列哪个签名请求对应于该报告。那么，我们如何才能使转换报告与签名请求断开链接呢？

这就是盲签名的用武之地。它们降低了伪造参数的能力，而不会增加数据可能与个人联系起来的可能性。我们不是要求每个实体临时签署一次，而是要求它签署其他内容：

盲签名的最大特点是，这个非盲签名是原始数据的有效签名，在盲签名之前，签名者根本没有看到原始数据。

稍后，我们可以向该实体发送两个它以前从未见过的值，即随机数和签名，并且它可以验证签名是否有效。由于大多数实体都会收到许多不同的签名请求，因此此过程使他们更难将此签名请求与之前收到的请求联系起来。盲签名有助于模糊个人，因为特定个人的请求可能是数千个请求中的任何一个。

如果我们向N个参与方中的每一个发送相同的blinded_nonce，他们可能会彼此共享数据，并将N个签名请求中的每一个链接起来。为了防止这种行为，我们可以为用户旅程的每一步使用不同的blinding_factor。这样，即使所有N个实体将它们的数据汇集在一起，它们也不能将它们链接起来，因为每个实体都会收到不同的blinded_nonce值。

这种方法实现了我们的目标，即在有效性证书之外传递绝对最少数量的额外信息。简单地说：

即使它们都共享了所有内部数据，它们也无法链接签名请求，因为每个签名请求都签署了不同的值。

最好的解决方案，也是在防止欺诈方面做得最多的解决方案，是让浏览器或操作系统促进这种签名收集。

浏览器或操作系统可以为随机数生成一个完全随机的值，该值在发送最终报告之前从不离开设备。

浏览器或操作系统可以为盲因数生成N个完全随机的值，每个接触点一个唯一值。这些值都不需要离开设备。

实际的签名请求可能发生在带外，直接从内部浏览器代码到盲签名端点，超出应用程序(甚至浏览器扩展)代码的范围，从而使恶意软件更难观察和收集签名。

浏览器或操作系统可以向其发送最终转换报告的时间添加随机变化，以进一步将其匿名化。

让浏览器或操作系统促进这一点的价值在于，代码可以完全开源，并且可以由安全和隐私社区仔细审查。这意味着私有数据(如用于BLING_FACTOR的值)永远不需要离开设备并访问任何服务器。最后，将此逻辑放在正常应用程序代码的范围之外会使篡改变得更加困难。

这并不能解决所有案件，一些攻击者会不遗余力地危害人们的账户。但如果是浏览器或操作系统促成了这一点，欺诈者就很难干预这一逻辑。这将有助于防范窃取cookie、在个人设备上安装恶意应用程序或浏览器扩展等攻击。

让我们把自己放在攻击者的位置上，并试图生成一份令人信服的报告。我们可以为随机数生成任何我们想要的值，但是在没有访问N个私钥的情况下，我们不能生成N个签名。

攻击者尝试的第一件事将是重放攻击，或者获取一组有效的报告参数并反复重新发送它们。这是相当容易预防的。我们只是维护过去收到的所有报告的记录，并确保每个报告都有唯一的nonce值。如果我们在这里使用足够的位，应该会有很少的冲突。可以忽略随机数的任何重复值。

攻击者可能尝试的下一件事是创建假帐户或危害真实用户的帐户，然后使用它们来生成尽可能多的签名集。这也是相当容易缓解的。如果触点表示在用户界面的特定部分上的点击，则每次点击该触点应该只给出一个签名。如果实体在一次单击时请求多个签名，或者在根本没有单击的情况下请求签名，则这些签名请求应该被拒绝。

这有效地限制了攻击者可以获得签名的最大速率。如果接触点观察到不规则的行为(例如，一个人的帐户进行了异常大量的点击)，它就可以对该帐户进行速率限制，在一段时间内拒绝所有签名请求。

假设我们已经实现了上面列出的所有缓解措施，攻击者可能会继续尝试寻找保护最弱的接触点，在那里它可以生成最大数量的签名。可能有一个接触点没有实现适当的节流或速率限制。该提案的一个使用案例可能是广告，这可能是欺诈的更高价值目标。例如，我们可以调用第一个接触点A，并假设它代表对网站上显示的广告的点击。那么我们还可以假设接触点B代表广告商网站上的购买事件，但也可以假设该广告商没有对其盲签名端点实施适当的节流或速率限制。

考虑到从接触点B获得签名是多么容易，攻击者只需要让虚假或被泄露的帐户点击Facebook上的任何广告，获得有效签名，然后从接触点B生成签名，如果他们从Facebook收到的签名不仅仅是一次广告点击，那么我们就可以更好地识别弱点了，怎么办？我们能让这些签名以某种方式表明广告指向的目的地吗？

我们可以使用部分盲签名来做到这一点。有一条共享信息在创建签名时和最终报告中都可用。这条信息就是接触点的顺序。

让我们稍微调整一下建议，以确保用户从接触点A到B的旅行报告具有仅针对此排序进行验证的签名。实现部分盲签名的最简单方法是生成多个公钥-私钥对。管理多个密钥在操作上可能很困难。还有其他方法可以在不使用多个密钥的情况下执行部分盲签名，但是它们涉及更高级的密码技术，例如基于曲线的配对，这在平台上缺乏通用实现。我们很乐意与社区合作，使其更实用，但在此之前，为了简单起见，我们可以使用多个密钥。

继续我们前面的广告示例，让我们假设用户之旅涉及到一个人点击广告，这会将他们带到广告商站点上的目的地页面，在那里他们可能会购买产品。几个广告商可以投放广告，这可以将用户重定向到不同的网站。使用部分盲签名，Facebook将为每个目的地URL生成一个公钥-私钥对。例如，如果点击广告将某人带到网站amazingtoasters.com上的页面，我们将使用该目的地网站的公私密钥对来生成第一个签名(代表点击Facebook上的广告的签名)。之后，如果进行了购买，浏览器会向Facebook发送一份报告，其中包含Facebook的URL特定签名和广告商的签名。当我们验证报告时，我们可以获取与amazingtoasters.com相关联的相应公钥，并使用该公钥进行验证。该过程隐式地将目的地URL绑定到盲签名。

提案的这一微小更新大大增加了欺诈的难度。在我们的广告示例中，如果攻击者使用虚假或泄露的帐户点击随机提供的广告，他们将获得仅对通向特定接触点的用户行程有效的签名。能够以加密方式将元数据绑定到盲签名适用于涉及多个接触点的广泛问题。这将防止攻击者大规模利用最薄弱的链接接触点。他们首先必须让他们的虚假或被泄露的账户获得指向该网站的广告。由于攻击者无法控制向他们提供哪些广告，这使得他们的事情变得更加困难。我们也可以选择不向可疑用户投放广告，或者只投放指向安全可靠目的地的广告。

通过这项早期研究，我们清楚地认识到，我们不能单独完成这项工作。该提案要求浏览器和操作系统制造商与应用程序创建者和网站所有者合作打击欺诈。我们相信，这种方法不仅比目前的方法更有效地威慑欺诈，而且还提供了数据最小化的优势。

我们正在寻求学术界和企业界的意见，以继续改进和完善这项提案。我们邀请您向W3C提交意见和意见，帮助我们推进这项工作。请让我们知道：我们没有考虑到什么？我们还能提供更好的反欺诈担保吗？我们如何以更简单的方式实现部分盲签名？我们如何才能使网站所有者尽可能容易地实现盲签名端点？我们很想听听你的想法。

有几个人对这项工作做出了重大贡献。我们要感谢安德鲁·诺克斯、凯文·刘维、佩曼·莫哈塞尔、斯科特·伦弗罗和埃里克·陶本内克。