EUDI钱包中零知识证明的实施

<img align="right" height="50" src="https://raw.githubusercontent.com/eu-digital-identity-wallet/eudi-srv-web-issuing-eudiw-py/34015dc3c6f52529a99e673df1d4fa69d50f7ff5/app/static/ic-logo.svg"/>&lt;br/>

EUDI钱包中ZKP实现的规范

摘要

本文档规定了EUDI钱包中零知识证明（ZKP）实现的技术规范和要求。

GitHub讨论

版本控制

1 引言和概述

本文档提供了现有零知识证明（ZKP）系统的技术概述，这些系统可以作为潜在的候选者，纳入未来的EUDI钱包中ZKP实现的技术规范。目前，没有现有的ZKP方法被认为完全合适或足够成熟，可以直接集成到EUDI钱包中。因此，本文档的目标是从技术角度检查当前的ZKP技术，评估它们在EUDI钱包ARF中的适用性，并识别现有的差距或限制。

关于使用ZKP的ARF的高级需求（HLR）在ARF的附件2的主题53下呈现。

2 可用的零知识证明方案

根据ETSI TR 119 476 [ETSI_119476] 和 [Topic_G] 的分类，我们讨论两种ZKP方案：多消息签名方案和算术电路证明。

2.1 多消息签名方案

从高层次的角度来看，基于多消息签名的解决方案实现如下。最初，PID提供者或证明提供者构建一个证明，该证明可以用消息列表的形式表示。然后，它使用多消息签名算法，并对该组消息生成一个（短）签名。现在，钱包单元可以选择性地隐藏任何消息，并生成一个ZKP，以证明“钱包单元拥有一组消息，这些消息与公开的消息一起可以验证PID提供者或证明提供者的签名”。

2.1.1 BBS+

BBS+是一种数字签名协议，用于签署一组消息。它最初由Boneh、Boyen、Shacham在[BBS2004]中设想（由此得名），由[Cam2016]接触并重新审视。目前正在由IRTF密码学论坛研究组[Loo2025]基于[Tes2023]中提出的改进进行标准化，以及由ISO/IEC在“ISO/IEC PWI 24843隐私保护的基于属性的凭证”中进行标准化。本节其余部分中BBS+的描述基于[Tes2023]。

2.1.1.1 颁发

PID或证明提供者将PID或证明转换为消息列表（例如，使用[Kal2022]等技术）。然后，使用[Tes2023]中描述的BBS+签名方案对该消息列表进行签名，该方案依赖于配对友好的椭圆曲线。然后将生成的签名证明传输到钱包单元。

2.1.1.2 演示

钱包单元可以生成一个证明的演示文稿，其中仅包括颁发期间生成的消息列表中的一个子集。然后，它使用[Tes2023]中描述的方案创建一个零知识证明（ZKP），证明公开的消息确实是提供者签名的原始消息列表的一部分。

2.1.1.3 性能

据报道，BBS+证明的生成和验证时间不到2毫秒。BBS+证明的大小为272+32*i字节，其中i是隐藏消息的数量。

2.1.1.4 讨论

BBS+实现了高性能，其构建块经过了充分的研究。然而，基于配对的密码学算法和配对友好的椭圆曲线未标准化，并且不受现有硬件安全模块（HSM）、安全元件或SIM卡的支持。 同样，将[ISO/IEC 18013-5]或[SD-JWT VC]中指定的证明格式转换为消息列表的算法也缺失。最后，标准化下的BBS+方法不考虑将证明绑定到用户钱包单元控制的公钥。

2.1.2 无配对BBS方案

最近的努力（BBS# [Des2025] 和 SAAC [Api2025]）提出了BBS的无配对变体。这些方案利用了一种称为密钥验证匿名凭证（KVAC）的结构，这是一种特殊的匿名凭证，其中提供者和依赖方是同一实体（即，它们共享一个私钥）。KVAC非常高效，不依赖于配对，并且在Signal消息传递系统中被广泛采用[Cha2020]。KVAC的主要构建块是消息认证码（MAC）。这两种方法都建立在[Bar2016]中提出的解决方案之上，该解决方案使用BBS签名的无配对变体 [BBS2004] 为消息列表创建一个MAC，然后允许用户公开这些消息的子集，同时证明它知道完整消息列表的有效MAC；可以使用提供者的密钥来验证此证明。 此外，BBS# 提出了一种来自ECDSA签名的设备绑定解决方案，该解决方案依赖于ECDSA签名和公钥的重新随机化。此外，[BBT2025]中定义了BBS#的信任模型，该模型涵盖了吊销和有效性证明。

2.1.2.1 颁发

PID或证明提供者将PID或证明转换为消息列表。然后，它使用其密钥和一个随机数e生成MAC A。最后，它将（A,e）传输到钱包单元。

2.1.2.2 演示

钱包单元随机化A并获得新的A'。此外，使用其证明、随机数和e，它生成一个新数字B'。B' 具有等于 A' 提升为提供者密钥的属性。在提供者和依赖方是同一实体的设置中，依赖方只需检查后一个等式是否成立。但是，在一般情况下，依赖方无权访问提供者的私钥。因此，提出了两种方法：

• 依赖方要求提供者验证B' 等于 A' 提升为其密钥。因为这两个数字都是随机的，所以提供者无法将它们链接回用户。
• 钱包单元要求提供者验证 B' 等于 A'。这可以批量完成，也可以更早地完成。为了保持不可链接性，钱包单元“盲化”这两个数字，并且提供者基于盲化值生成证明。这是使用遗忘证明颁发 [Orr2024] 实现的。

此外，BBS# 定义了在WSCD的帮助下进行公钥随机化的算法，以及证明拥有相应私钥的算法，该私钥安全地存储在WSCD中。

2.1.2.3 性能

[Des2025] 报告说，BBS# 的证明生成和验证时间在高端移动设备中不到2.5毫秒。类似地，报告说BBS# 演示证明的大小为416+U*32字节，其中U表示隐藏消息的数量。

2.1.2.4 讨论

BBS# 和 SAAC 提供了高性能，但在依赖方或钱包单元和提供者之间引入了额外的通信。这种额外的交互在数量上与证明的批量颁发相当。值得注意的是，这两种方案都避免使用基于配对的密码学，但是，它们仍然需要标准化。此外，在这两种方法中，提供者端所需的操作目前不受现有硬件安全模块（HSM）的支持。最后，BBS# 支持将证明绑定到钱包单元控制并安全地存储在相关WSCD中的公钥 。

2.1.3 带有ECDSA所有权证明的BBS

最近的ZKP方案能够证明拥有与ECDSA数字签名相对应的密钥，以及对关联公钥的承诺。这些方案可以使用Sigma协议 [Cel2024] 或 zkSNARK [Woo2025] 构建。此外，诸如 [Cha2020] 之类的构造可以生成一个证明，证明承诺的公钥确实包含在证明中。 通过将这些证明机制与BBS签名集成，可以将证明绑定到存储在WSCD中的密钥。

2.1.3.1 颁发

PID或证明提供者遵循2.1.1.1节中描述的相同步骤，但在已签名消息列表中包含ECDSA公钥。

2.1.3.2 演示

钱包单元执行2.1.1.2节中描述的步骤，确保隐藏消息列表中包含的公钥。然后，它执行以下附加步骤：

• 创建公钥的承诺
• 生成一个证明，证明承诺的公钥与证明中包含的（隐藏）公钥相同（例如，使用[Cha2020]）
• 使用设备的WSCD生成一个新的nonce的ECDSA数字签名
• 生成一个证明，证明可以使用承诺的公钥验证签名（例如，使用[Cel2024]或[Woo2025]）。

2.1.3.3 性能

这种方法引入了一些与证明相关的额外开销。 [Cel2024] 报告说，在具有8 GB内存的Macbook M1中，证明大小大于160kB，证明生成和验证时间分别超过610ms和450ms。[Woo2025] 报告说，在AMD Ryzen Threadripper 5995WX 1.8GHz CPU，256 GBs RAM服务器中，证明生成时间为1.6msec，证明验证时间为1.7msec。类似地，[Woo2025] 报告说证明大小等于406字节。此外，较旧的实现报告 [Cha2020] 的性能在三星Fold智能手机中约为1秒，证明大小超过100kb。

2.1.3.4 讨论

这些方法的组合实现了使用带有配对的BBS签名签名的证明的所有权 （因此需要支持配对密码学和配对友好曲线） 。这种组合似乎仍在进行中：其可行性、性能 以及安全性需要进一步研究。最后，这些方案仍需要标准化。

2.2 算术电路证明（可编程ZKP）

这些解决方案基于以算术电路形式表达的程序。该电路接收一个秘密输入，称为见证，可以是例如一个证明，以及一个公共声明。该电路执行计算，如果某些条件成立，则输出true（例如，“该证明包括一个值> 18的age属性”）。然后，钱包单元可以生成一个ZKP，以证明“钱包单元知道一个见证（例如，证明），当将该见证作为输入提供给使用提供的声明的某个电路时，该电路输出true”。

2.2.1 来自ECDSA的匿名凭证

[Fri2024] 中介绍了基于ECDSA的匿名凭证。 此方法建立在Ligero协议[Ame2017]之上。

2.2.1.1 设置

此解决方案不需要可信设置阶段。 但是，用于在钱包单元中执行密码学计算的算术电路必须经过仔细设计、实现和分发。

2.2.1.2 颁发

PID提供者或证明提供者不知道此方案的使用； 因此，无需对现有的颁发流程进行更改。

2.2.1.3 演示

为了生成用于演示证明的零知识证明，钱包单元首先将证明编码为适当的算术电路的私有输入（即，见证），该电路表示所需的语句。 该电路还定义了任何公共输入，例如提供者的公钥。 然后，钱包单元使用见证和公共输入在电路上运行zkSNARK证明器算法，从而生成一个简洁的证明。 任何第三方都可以使用公开的输入验证此证明。

2.2.1.4 性能

据报道，[Fri2024] 中的解决方案可在Pixel 6 pro手机中在1.2秒内生成一个证明，证明 [ISO/IEC 18013-5] 证明有效，并且包含age_over_18属性。 相应的验证时间为0.6秒。 证明的大小约为400KB。

2.2.1.5 讨论

在本文档中讨论的解决方案中ECDSA方法引入的匿名凭证具有最高的计算和通信开销。 此外，该方案的几个组成部分尚未标准化。 此解决方案还需要为每种类型的证明语句设计和部署单独的算术电路（例如，取决于证明的格式或结构）

另一方面，此解决方案不需要对凭证颁发过程进行任何更改，并且可以与 [ISO/IEC 18013-5] 或 [SD-JWT VC] 中指定的证明格式一起使用。 同样，它支持证明绑定到钱包单元控制并安全地存储在相关WSCD中的公钥.

2.2.2 Crescent

Crescent在 [Paq2024] 中介绍，并建立在Groth16 [Gro2016] zkSNARK之上

2.2.1.1 设置

此解决方案需要在受信任的设置期间为特定的算术电路生成证明密钥和验证密钥，这些密钥应分别分发给钱包单元和依赖方。 此过程需要一次性生成结构化参考字符串（SRS），之后必须安全地丢弃这些字符串，以防止泄露。 该设置是特定于电路的，这意味着必须为每个唯一的语句或电路执行新的设置。 此外，用于在钱包单元中执行密码学计算的算术电路必须经过仔细设计、实现和分发。

2.2.2.2 颁发

PID提供者或证明提供者不知道此方案的使用，因此无需对现有的颁发过程进行更改。

2.2.2.3 演示

在Crescent中，证明生成过程分为两个阶段：离线阶段和在线阶段。 在仅执行一次的离线阶段，钱包单元将证明编码为预定义的算术电路的见证。 使用此见证，钱包单元计算Groth16证明。 在在线阶段，钱包单元重新随机化证明，以确保同一证明的多个演示文稿之间不可链接。 然后，可以将此重新随机化的证明安全地与依赖方共享，依赖方使用相应的验证密钥和已公开的公共输入对其进行验证。

2.2.2.4 性能

当在具有6个内核的3.60GHz的Intel Xeon W-2133 CPU中使用时，据报道Crescent可以在29.2毫秒内实现在线证明生成，并在11.7毫秒内实现证明验证。 当使用设备绑定时，这些数字分别增加到315毫秒和184毫秒。 离线证明生成需要19秒。 设置参数的大小为580MB，证明的大小为1019字节。

2.2.2.5 讨论

Crescent比来自ECDSA解决方案的匿名凭证具有更好的性能，但是受信任的设置参数会产生大量的存储开销。 此外，此解决方案的一些组成部分尚未标准化。 强调的是，Crescent依赖于Groth16，而Groth16依赖于基于配对的密码学。

与来自ECDSA的匿名凭证类似，Crescent不需要对凭证颁发过程进行任何更改，并且可以与 [ISO/IEC 18013-5] 或 [SD-JWT VC] 中指定的证明格式一起使用。 Crescent还支持证明绑定到钱包单元控制并安全地存储在相关WSCD中的公钥.

3 参考文献

• 原文链接： github.com/eu-digital-id...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～