零知识证明在年龄验证中的局限

这篇博文介绍了来自 Brave 研究团队的 Sofia Celi、Kyle Den Hartog 和 Hamed Haddadi 正在进行的学术研究。

在监管政策和内容审核范围不断扩大的推动下，年龄验证日益被视为访问在线服务的前提条件。零知识证明常被作为一种技术解决方案提出，承诺能提供保护隐私的年龄或资格证明。然而，其实践部署暴露了概念上和实际上的局限性。基于中心化权威机构的凭证系统存在排斥风险、创造了新的控制点，并威胁用户隐私。同时，许多零知识证明提案仍然脆弱，引发了关于可靠性、可组合性和长期可持续性的担忧。除了加密保证之外，内容分类、撤销和互操作性等持续存在的挑战表明，仅靠零知识证明无法解决年龄验证或身份验证更广泛的社会技术问题。

在此，我们通过强调现有系统的缺陷、中心化凭证框架的意外后果以及误用证明带来的风险来审视这些局限。我们的目的并非否定零知识证明作为一项有价值的工具，而是将其置于更广泛的架构背景中：一个真正优先考虑用户隐私、自主权和网络开放性的背景。

背景

近期来自主要技术平台的提案强调将数字可验证凭证（通常辅以零知识证明）作为例如在线年龄检查和访问控制的基础。这些框架设想用户从指定的发行者那里获得加密签名的证明（例如年龄、居住地或国籍），然后将其呈现给服务以证明其资格。类似的加密模型也在学术和工业环境中被研究，特别是在基于区块链的身份系统中。具体而言，存在以下提案：

zk-TLS：诸如 TLSNotary、DiStefano、Janus、Town crier、DECO（及其他）等系统，允许用户提交 TLS 会话记录，并在之后证明其与未经修改的网络服务（例如，账户余额）交互的事实，从而为智能合约构建基于网络的预言机。
zk-授权：像 zkLogin 和 zkCreds 这样的工具，允许用户在不泄露令牌本身的情况下，证明来自 OAuth 或 OpenID 提供商的 JSON Web 令牌的属性。
zk-编译：证明可执行文件或字节码（例如，ELF、WASM）对应于已知的源代码和编译器工具链，支持来源追踪和可审计性。
zk-优化：像 Otti 这样的系统允许证明一个私有的优化过程（例如大学录取）是根据承诺的策略和输入进行计算的，而不泄露输入信息。
zk-中间盒：给定对网络协议流（例如 DNS）的承诺，发送者可以证明流量满足策略要求，而无需泄露其内容。

尽管取得了这些进展，基于凭证的系统（即使是使用零知识证明）在理论和部署上仍然存在局限。在以下部分，我们将审视这些局限性，重点关注排斥和中心化的风险、当前零知识证明构造的某些脆弱性，以及分类、撤销和互操作性方面未解决的社会技术挑战。

局限

如前所述，尽管取得了进展，但基于凭证的系统在理论和部署上仍然存在局限。它们的缺点不仅限于实现细节，还反映了加密、安全和隐私保证与身份和访问控制的社会技术现实之间的深层矛盾。为了理解这些挑战，区分以下几类局限性是有用的：

安全脆弱性：零知识证明在已部署系统中的使用仍然很脆弱。文献中许多被称为“零知识”的协议可能无法满足严格的形式定义：它们可能实际上并未提供零知识（从而无法保护隐私），或者可能缺乏可靠性（从而可被伪造）。即使满足了定义，通常也缺乏可组合性保证，在复杂的系统部署中带来风险。需要通过严格验证的安全性证明和形式化验证技术，进行更多研究以确保生产环境中使用的零知识证明能达到其声称的特性。实现也并非易事：即使在经过良好审计的系统中也发现了细微的漏洞，如果优化本身没有被仔细分析，它们可能会悄无声息地破坏核心保证。

隐私保障不足：除非仔细且正确地应用，否则零知识证明无法保证有意义的隐私。例如，证明用户的年龄在 20-21 岁之间，可能会无意中透露用户确实是 21 岁。同样，使用更广泛的“层级”（例如 20-25、25-30、30-40）仍然可能将内容关联到受约束的年龄范围，从而破坏预期的隐私保障。在实践中，即使是语义上“私密”的范围证明，也可能根据其构造或解释方式泄露大量信息。

这反过来又产生了新的风险：当证明与其他上下文信号（如使用凭证的网站、凭证发行者的身份（例如特定政府）或用户的位置）结合时，生成的元组（凭证来源、年龄范围、地理元数据）可以唯一地识别个人。实际上，这可能比当前网络暴露的信息更具识别性，从而在隐私保护验证的幌子下实现普遍的用户画像和跨站点关联。

此外，当在一段时间序列中颁发多个证明时，隐私损失会随时间累积。例如，用户首先证明自己的年龄在 20 到 22 岁之间，两个月后又证明自己超过 21 岁，实际上就披露了其确切出生日期的狭窄区间。这种时间性泄漏凸显了系统需要通过变化来管理隐私，而不仅仅是在孤立的证明中，而是在重复交互中。向用户提供基于属性的披露序列所带来的累积隐私损失的透明度，并建立跨会话不可链接性的基本保证，对于此类系统的安全部署至关重要。

此外，如果没有应用适当的范围约束，零知识证明系统可能会退化为一种客户端扫描的形式，即对 TLS 记录、JWT 令牌或数字凭证等内容进行任意证明。此类证明可能会破坏底层协议或数据结构的安全性或隐私保证。因此，必须能够验证并可进行外部审计，以确保所证明的陈述不会导致间接去匿名化或政策规避。

中心化与包容性风险：许多数字凭证系统依赖于一小部分公认的发行者，例如政府、电信提供商或身份验证公司。政府颁发的凭证（例如驾照、身份证、护照）通常被认为是“高保证的”，并带有内置的撤销机制。然而，这些撤销功能可能会引入“电话回家”问题：每次验证凭证时，都可能联系发行者，使其能够跟踪凭证的使用地点和频率。即使依赖方可以自由信任任何发行者，实际上他们通常只接受一小部分“高保证”凭证。这使得一两个发行者能够了解每次凭证展示的情况及其元数据。例如，如果一个网站每次访问都要求提供新的凭证，即使不存储，发行者仍然可以通过验证检查了解用户返回的频率。

排斥是另一个主要问题。如果依赖方只接受有限的一组凭证，例如正式身份证、居留许可或机构隶属关系，那么没有这些凭证的人将被锁定在服务之外。如今，估计全球有 8.5 亿人缺乏正式身份证明。在这样的系统中，依赖一小部分高保证凭证有加剧数字鸿沟的风险。此外，如果访问服务或在线发布权利取决于凭证的实时有效性，少数发行者实际上就获得了把关权。撤销可能出于良性的原因（例如，未付罚款导致驾照被暂停），也可能出于更令人担忧的原因（例如审查，即发行者不同意凭证持有者发布的内容）。当前强制使用数字凭证的法规往往未能解决这些中心化和排斥风险。如果没有保障措施，凭证发行者可能成为谁可以参与数字生态系统关键方面的强大控制点。

解析与语义不匹配：当前基于零知识证明的系统的一个核心且常被忽视的局限性是低级数据（例如原始字节流）与证明本应在其上操作的结构化数据之间的语义鸿沟。大多数系统隐含地假设输入已经是格式良好的，例如，JSON 对象遵循其语法或凭证符合标准语法。

然而，如果没有正确解析的形式化保证，这种假设可能被利用。格式错误或对手精心制作的输入可能被证明方和验证方以不同方式解释，从而破坏可靠性。例如，如果一个系统假设 JSON 键不能包含转义字符，那么违反此假设的攻击者可能会破坏证明系统的安全性。

一些方法试图通过揭示部分数据以供直接检查来缓解这个问题。但这削弱了零知识证明旨在提供的隐私保障。挑战不仅在于检查某个值（例如年龄）是否出现在数据中：还必须确保数据符合语法（例如是有效的 JSON），并且该值位于文档结构中的正确位置。一个可靠的证明必须确定，例如，年龄值确实绑定到顶层的“年龄”字段，而不是隐藏在嵌套字段中或通过结构歧义引入。

其他生态系统限制。还存在几个进一步的挑战：

缺乏协议标准化：跨司法管辖区或供应商没有广泛采用的零知识证明协议栈，阻碍了互操作性。
互操作性担忧：即使兼容的方案在编码、支持的谓词和证明格式方面也存在差异，导致生态系统碎片化。
撤销挑战：隐私保护的撤销机制尚不成熟，并且难以与不可链接性保证集成。
信任模糊性：即使使用零知识证明，验证方也必须知道是否信任发行者，这重新引入了中心化的信任依赖。
用户体验差：要求用户配置选择性披露或谓词证明会带来认知和用户体验负担。

上述担忧并非意在否定零知识证明的价值，它仍然是隐私保护系统设计中一个强大而必不可少的工具。相反，它们强调了在没有严格的正式验证、全面的安全分析、以用户为中心的界面设计以及深思熟虑地融入更广泛的系统架构和社会的情况下，“即开即用”地部署零知识证明所带来的风险。

一个构想

除了上述技术限制外，确实存在一种潜力，即让人们更多地控制和了解零知识证明的创建过程。与其让系统在后台静默生成证明，不如允许用户查看甚至调整正在被证明的陈述。

例如，与其被动地批准数字身份证“显示我的年龄”，用户可以确切检查正在揭示的内容，并在证明生成前确认或编辑它。更先进的系统可以让用户决定包含哪些特定的数据字段。如果进行了任何更改，系统可以生成额外的证明，表明修改后的数据仍然以保留原意的方式匹配原始信息。

在实践中，这意味着如果一个凭证显示某人是 27 岁，用户可以选择只透露他们“超过 25 岁”。然后，系统在不透露实际数字的情况下，证明这一说法与真实数据一致。

这种模式既促进了隐私，也促进了用户自主权。人们可以更清楚地了解正在被证明的内容，并且可以在信息共享之前对其进行过滤或清理。通过依赖独立的工具、已验证的软件或第三方检查来确保转换正确完成，也可以增强对该过程的信任。

总而言之…

零知识证明为隐私保护的数字身份和年龄验证迈出了重要一步，但它们远非万能的解决方案。正如我们的分析所示，当前的提案面临着持续的局限性：加密定义和实现的脆弱性、实践中隐私保障不足、凭证框架中的排斥和中心化风险、解析中的语义模糊性，以及互操作性、撤销和可用性方面未解决的挑战。

这些局限性强调，不能简单地“插入”零知识证明来解决在线信任和访问控制的社会技术问题。相反，它们必须嵌入到更广泛的架构中，这些架构明确地保障用户自主权，最小化中心控制点，并考虑到排斥、审查和用户画像的现实生活情况。实现这一目标不仅需要加密研究的进展，还需要谨慎的系统设计、包容性的政策框架和透明的用户界面。

简而言之，零知识证明不应被视为一个完整的解决方案，而应被视为更大隐私保护技术生态系统中的一个组成部分。只有当与严格的验证、负责任的治理和有意义的用户控制相结合时，它们才能兑现其承诺：在不牺牲网络开放性的前提下加强在线信任。