Meta 如何实现大规模无身份信息认证？
我们在 Meta 公司不断研发新的隐私增强技术（privacy-enhancing technologies，PET），核心原则之一是数据简约化——仅收集我们服务所需的最少量数据。我们一直在寻找方法来增强用户隐私性，以保护我们所有产品的用户数据。
以前，我们研究过用后置的处理数据方法，去除身份信息或汇总多用户数据，从而简约化数据。然而，这是一种被动的数据简约化方法，以 Meta 公司的规模，可能会非常耗费资源。当我们寻找扩展性更高的解决方案时，我们发现，可以利用“无身份信息认证（de-identified authentication）”的方法来主动消除身份信息。这样一来，我们从信息源头就可以去除身份信息。
在所有客户端 - 服务器交互中，身份认证对防止端点被爬取、被垃圾邮件塞满或被分布式拒绝服务攻击（DDOS）很有帮助。业内最为广泛采用的身份认证方式，是通过用户 ID 进行身份认证，服务器在提供服务或接收客户端流量之前验证客户端身份。
但我们希望通过去除用户身份信息来提高隐私标准，同时仍能保证身份认证，以保护用户数据和我们的服务。因此，我们利用工业界和学术界多年来合作设计的匿名凭据，创建了称为“匿名凭据服务（Anonymous Credential Service，ACS）”的核心服务。匿名凭据服务是一种高可用的多租户服务，它允许客户端以无身份信息的方式进行身份认证。这增强了隐私和安全性，同时还具有计算意识。匿名凭据服务是我们隐私增强技术产品组合的最新成员之一，目前正在 Meta 公司多个大流量的用例中使用。
在较高抽象层面上，匿名凭据将认证分为两个阶段，来支持无身份信息认证：颁发令牌和无身份信息认证。在颁发令牌阶段，客户端通过一个认证过的通道联系服务器，向服务器发送一个令牌（token）。服务器给令牌签名并将其发回客户端。然后，在无身份信息认证（或称令牌赎回）阶段，客户端使用匿名通道提交数据，并用此令牌的变异形式取代用户 ID 进行身份认证。
我们大幅简化了协议中的细微差别，签名令牌（令牌发行阶段）和赎回令牌（无身份信息认证阶段）两个阶段的数据不再能够直接关联起来，因此服务器在第二阶段对客户端进行身份认证时，无需知道令牌属于哪个特定客户端，从而保护了用户隐私。
让我们深入了解一下匿名凭据协议。匿名凭据基于 VOPRF（可验证不经意伪随机函数，它使客户端能够获知自定义输入的可验证伪随机函数评估）和盲签名（一种数字签名，可以防止签名者知道发送者的消息内容）创建。除了前面提到的颁发令牌阶段和无身份信息认证阶段之外，完整的工作流程还有一个设置阶段。
在设置阶段，客户端获取服务器的公钥和其他公共参数。接下来是颁布令牌阶段，客户端创建一个随机令牌并选择一个致盲因子，对令牌进行盲签名，并将盲签后的令牌发送到服务器。反过来，服务器对令牌签名并将其发回客户端。然后客户端对服务器返回的签过名的盲令牌执行非盲操作。客户端还计算 shared_secret，它本质上是原始令牌和服务器签名的函数。
请注意，直到此时，服务器都没有见过原始令牌的值。之后，在无身份信息认证阶段，客户端转发原始令牌、相关业务数据，以及带有 shared_secret 的业务数据的 HMAC（Hash message authentication codes，散列过的消息认证代码）。
然后，服务器可以通过检查这个 HMAC，来验证客户端发送的 shared_secret 与本地计算的 shared_secret 是否相同。如果此检查通过，则服务器将请求视为合法，并处理业务数据。有关该协议的详情，请参阅论文《大规模无身份信息认证遥测（De-identified authenticated telemetry at scale）》。
匿名凭据服务使客户端能够以无身份信息方式进行身份认证。通过匿名凭据服务去除身份认证中的用户 ID，我们可以在满足数据收集简约化目标的同时保护用户隐私。为了服务于生产用例，我们必须创建一个健壮的架构，增强面对现实世界各种问题的适应能力。
WhatsApp 上的无身份信息遥测（De-Identified Telemetry，DIT）是当前利用匿名凭据服务的一个用例。以前，我们用安全存储和数据删除策略，确保日志数据不会关联具体用户。但我们希望我们的隐私保护措施更进一步，将匿名凭据服务与 WhatsApp 系统集成，以便对某些 WhatsApp 客户端日志启用无身份信息认证。
大规模部署后，无身份信息遥测使 WhatsApp 在验证日志请求时无需收集身份信息，就能报告性能指标（对确保为每个用户提供快速、无崩溃的应用程序很重要）。整个 WhatsApp 家族都在使用匿名凭据服务，这个庞大的用例需要匿名凭据服务每秒处理数十万个请求。
我们要强调的另一个用例是联合学习，这是一种训练全局机器学习模型的技术，私有敏感数据仅保存在本地客户端设备上（不需要上传到服务器）。在这种模式中，设备与服务器共享模型更新而不是原始敏感数据，服务器计算聚合模型的更新来优化全局模型。
这是使用匿名凭据服务进一步保护用户隐私的一种潜在方法。我们不希望恶意行为者发送欺诈性的模型更新数据，但我们希望确保合法用户能够帮助改进全局模型。通过利用匿名凭据服务，我们可以确保合法客户端以无身份信息认证的方式发送客户端模型的更新信息。
现在让我们深入了解匿名凭据服务架构。
匿名凭据服务是一个 C++ 服务，基于 Meta 公司的容器编排框架 Twine 开发。在全球范围对流量进行负载均衡，每个区域都根据需求动态伸缩。匿名凭据服务为颁发令牌和赎回令牌提供 Thrift API。
有一项重要需求是，在不同用例间构建围栏，隔离匿名凭据服务的令牌。为什么呢？因为我们是多租户的，服务于各种用例。不同用例可能有不同的身份认证机制（例如，脸书用户与 Instagram 用户）。应当禁止不同的用例赎回颁发给特定用例的令牌。
为了解决这个问题，我们要求每个 API 请求都声明自己的用例名称，我们使用针对具体用例的密钥来隔离用例。我们把密钥存储在 Meta 公司的“钥匙串（keychain ）”服务中，并通过 Meta 公司的异步作业基础设施定期更换安全密钥。此外，我们还有另一项工作是，在密钥轮换后，发布更新的匿名凭据服务公钥，让客户端可以获取更新后的密钥。
在扩展匿名凭据服务的过程中，我们学到了维持服务可靠性和效率的三个关键经验：防止运行匿名凭据服务的成本随着流量的增加而线性增长、避免人为的流量高峰、在不需要专家知识的情况下，推进各个用例接入服务。
随着接入服务的用例越来越多，我们注意到，对新接入的用例，必须按其流量 1:1 的比例添加主机和更多的服务器容量。鉴于最近全球服务器供应链紧张，我们研究了如何简化匿名凭据服务，使其更实用，同时仍能保持我们的高隐私标准。
我们决定允许用例在合理的阈值内重用凭据。在匿名凭据服务服务器上，我们添加了一个重用凭据计数器（由 Meta 公司的分布式键值存储 ZippyDB 提供支持）。该计数器将计算特定匿名凭据服务令牌被赎回的次数，如果赎回次数超过阈值，则请求失败。针对敏感的用例，还有赎回限制（即不重用令牌）。通过允许重用凭据，可以减少为特定用例颁发令牌的数量，从而节省服务器容量。
我们在扩展时遇到的另一个问题和流量尖峰有关。我们通过观察服务仪表盘，注意到匿名凭据服务的服务器在短时间内收到大量请求。这将导致服务器一时不堪重负，部分请求会失败。
我们发现，这些引起流量尖峰的请求都来自一个大型用例。在与相关的客户团队交谈后，我们了解到，他们把数据缓存在移动客户端上，然后每晚在同一时间，这些移动客户端分别把自己的数据批量发送到服务端。
尽管理论上这是个好主意，但这种模型实际上是在对我们的服务器进行分布式拒绝服务攻击（DDOS），因为突然有众多客户端同时发送了许多请求。为了解决这个特定用例的问题，我们通过添加抖动来分散请求，让它们错开发送时间。为了更普遍地解决这个问题，保护我们服务器的健康，我们与 Meta 公司流量团队合作，添加了一个全局限速器，如果匿名凭据服务流量超过某个速率阈值，限速器将选择性地丢弃这些超额流量。
我们在扩展匿名凭据服务时遇到的最后一个挑战是在工程方面。最初，我们有一个小团队，致力于推广匿名凭据服务，然后发现接入新的用例很困难。当时，接入新用例通常需要我们中的一个人与合作伙伴团队密切合作，解释匿名凭据服务的关键概念，并在我们的服务器上手动配置新的匿名凭据服务用例。
我们通过给接入匿名凭据服务的新用例创建平滑的接入体验来减轻这种合作成本。我们用 React 构建了一个自助接入匿名凭据服务的站点入口。现在，来自 Meta 公司的工程师们，可以使用该站点作为匿名凭据服务的一站式商店。
此外，我们为 Android 和 iOS 创建了匿名凭据服务客户端 SDK，以提供高质量的加密原语和协议实现。客户端可以调用高级方法，例如直接获取匿名凭据服务令牌（fetch-acs-token），不需要自己一步一步构建令牌。这些方法通过调用匿名凭据服务的 API、去盲化令牌和执行所有其他相关操作，来处理整个令牌交换协议。我们还改进了维基上的接入文档，投入资源开发了 codegen 工具。这进一步减少了客户的编码量，更容易与我们集成，让他们无需专家级的密码学知识即可使用我们的协议。
无身份信息化是保护数据和隐私的重要工具。共享和保护数据需要信任和责任感。展望未来，我们希望将匿名凭据服务进一步集成到 Meta 公司的数据基础架构中，并在身份认证用例之外的产品中用它进一步保护数据隐私。
我们希望我们的工作能够激发整个行业研发更多的隐私增强技术。
查看英文原文：
https://www.infoq.cn/link?target=https%3A%2F%2Fengineering.fb.com%2F2022%2F03%2F30%2Fsecurity%2Fde-identified-authentication-at-scale%2F
点击底部阅读原文 访问 InfoQ 官网，获取更多精彩内容！
点个在看少个 bug 👇
相关内容
微信扫码咨询专知VIP会员