zkPass 技术概述 v2.0

注意：由于 Medium 的排版限制，请 点击这里 查看完整版本。

概述

本博客从技术角度描述了 zkPass oracle 协议。它展示了基础的加密组成部分并指定了构建 zkPass 协议所需的构建模块。

zkPass 协议被精心设计为一个私有数据 oracle，利用 Vector Oblivious Linear Evaluation (VOLE) 创建有效的承诺，通常称为基于 VOLE 的零知识证明 (VOLE-ZK)。具体而言，除了使用 SoftSpokenOT 进行 Oblivious Transfer (OT) 之外，zkPass 协议的安全完整性与 VOLE-in-the-Head (VOLEitH) 技术的鲁棒性紧密相关。

zkPass 在 混合模式 下运行，该模式结合了 Proxy 和 MPC模式，使协议能够适应各种网络条件和服务器限制，而不会影响性能或安全性。这种设计确保了数据共享场景的灵活性，适应既支持直接客户端请求的服务器，也符合更严格的安全政策的服务器。

概述

虽然 传输层安全性 (TLS) 提供对私有数据的安全访问，但它不允许用户向第三方证明数据来源于特定网站。现有解决方案要么施加不必要的信任假设，要么要求服务器修改，有效地将用户的数据锁定在其来源。zkPass 协议通过将 TLS 扩展为 三方 TLS (3P-TLS) 来解决此问题，以防止作弊并保护隐私，使安全的数据共享无需数据持有者的协助或许可。

zkPass 协议涉及三个实体：证明者 (P)、验证者 (V) 和数据源 (TLS 服务器作为 S)。与传统方法不同，P 使用其访问Token直接定位并从 S 提取其数据。P 随后生成为 V 检查的零知识证明 (ZKP)。该过程确保 V 加不知 P 的个人数据。

为了实现这一架构，我们整合了 3P-TLS、MPC 和 非交互式零知识 (NIZK) 技术。

我们在两种模式下设计和实现了 zkPass 协议：

1. 代理模式：在这种模式下，P 通过 V 与 S 通信，充当代理。
2. MPC模式：在这种模式下，P 和 V 都作为客户端与 S 通信。

这两种模式共同形成 混合模式，使 zkPass 在各种场景中有效运行。通常，zkPass 协议在代理模式下高效运行。然而，一小部分 TLS 服务器不支持该模式，意味着它们会阻止来自不同 IP 地址的同一帐户请求。在这种情况下，我们的协议切换到 MPC 模式下运行。

代理模式

在代理模式下，我们建议让 V 充当 P 和 S 之间的代理。在这种设置下，P 通过 V 与 S 通信，这允许 V 记录交通以便后续验证。修改后的协议流程旨在保持安全性，同时提高效率。

流程和安全属性

协议流程如下：

1. 三方握手：P、V 和 S 参与 3P-TLS 握手。该握手建立加密参数，确保各方之间的相互身份验证。
2. 证明者的密钥共享承诺：握手后，P 承诺其密钥共享 Kp。此承诺防止 P 在协议后期修改其密钥共享。P 必须在学习完整会话密钥 K 之前承诺其密钥共享 Kp。此承诺将 P 绑定至其密钥共享，确保其无法操纵会话以生成虚假证明。
3. 验证者暴露密钥共享：V 向 P 揭示其密钥共享 Kv。有了两个密钥共享，P 计算出完整的会话密钥 K = K p + K v。
4. 会话持续：P 使用会话密钥 K 继续与 S 的 TLS 会话。V 作为代理，记录 P 和 S 之间的所有流量。
5. 证明生成：会话结束后，P 向 V 证明有关记录会话的某些陈述。

为了在三方握手过程中验证服务器身份，V 检查服务器对新 nonce 的签名，遵循标准的 TLS 程序。由于假设 TLS 是安全的，验证者的完整性和隐私得以维持，因为恶意的 V 无法危害 P 与 S 之间 TLS 会话的完整性和隐私。确保证明者完整性要求某些网络假设。V 必须在整个会话期间保持与 S 的可靠连接，并确保 P 无法篡改 V 与 S 交换的消息，比如通过 BGP 劫持执行的消息。由于实质上执行 BGP 等攻击的难度大，而这些攻击又已通过 ICP 和 CSP 进行缓解，这些网络假设通常是可接受的，并可在实际场景中视为可以忽略的。

zkPass 协议的代理模式通过简化通信流程并消除握手阶段后对密集加密计算的需求，提高了效率和性能。由于会话期间无需复杂的加密操作，因此协议变得更快、更高效，因为减少了加密工作量。虽然这种方法更通用，但对代理引入了额外的信任假设，并不仅仅需要一种对客户负担得起的 ZK 解决方案，还需要额外的魔法手段绕过数据源的 WAF。

VOLEitH 协议

VOLEitH 是授权 TLS 的最合适且负担得起的 ZKP 协议。我们使用 SoftSpokenOT[ROY22] 、VOLE-ZK[YSWW21] 和 Fiat-Shamir 变换[FS87] 实现了该协议。

VOLE

为了构建 zkPass 协议，我们引入 VOLEitH 创建交互式论证系统。此系统随后通过 Fiat-Shamir 变换变成非交互式，并在随机 Oracle 模型 (ROM) 中证明其安全性。zkPass 使用在有限域 F₂ᵏ 上的 VOLE 相关性，作为一种线性同态承诺方案。长度为的 VOLE 相关性由随机全局密钥 Δ ∈ F₂ᵏ 、一组随机位 uᵢ ∈ F₂ᵏ​、随机 VOLE 标签 uᵢ ∈ F₂ᵏ​​ 和 VOLE 密钥 qᵢ ∈ F₂ᵏ​​ 定义如下：

qi​=ui​⋅Δ+vi​, for i=0,…,ℓ−1.

其中，uᵢ 和 vᵢ​ 仅在 P 知晓，而 qᵢ 和 Δ 应该提供给 V。VOLE 相关性可以被视为一种通过线性同态承诺方案承诺 P 到随机位 uᵢ 的方法。此方案具有隐藏性，因为随机值 vᵢ​ 掩盖了 V 的值 qᵢ 中的 uᵢ。它也是绑定的，因为打开不同的值 u^ 将要求 P 想出一个新的标记 q′ᵢ = u′ᵢ ∗ Δ + v′ᵢ​。然而，为了成功做到这一点，P 需要猜测 ∆ = (v′ᵢ − vᵢ)/(u′ᵢ − uᵢ)，这只能以 2⁻ᵏ 的概率发生。

VOLE 相关性可以通过安全两方协议创建，但在 zkPass 协议中，由于我们希望获得可公开验证的 ZKP，因此我们使用 VOLEitH 技术[BBD+23]。在这里，P 首先生成其值 uᵢ、vᵢ，并使用一种特殊类型的 VOLE 承诺进行承诺。该承诺设置为 V 后续可以向 P 发送随机密钥 ∆，然后，P 可以发送一个开放，允许 V 学习其 qᵢ 值，以便该方程对 ∆ 成立，并且没有其他信息。重要的是，∆ 仅在 ZKP 主要步骤执行后才提供给 P，因为一旦知道 ∆，同态承诺的绑定属性将完整破坏。

VOLEitH 承诺

我们 VOLEitH 方法的主要构建模块是通过从长度加倍的 PRGs 树中推导出 N 个伪随机种子的向量承诺技术。这也被称为 GGM 构造，它从 PRG[GGM84, KPTZ13, BW13, BGI14] 构建出一个可打孔的 PRF。我们将此建模为一种几乎全部向量承诺方案，其中 P 通过发送一个哈希值来承诺 N 个种子，随后只需 O(logN) 通信便可打开 N − 1 个种子。为了打开所有但一个的种子，例如排除索引 sd ⱼ，P 获取从根到叶 j 的路径中所有节点的兄弟节点（不包括根节点），并将这些值与承诺 com ⱼ​ 一起发送给 V。V 然后可以使用兄弟节点重建每个 sd ⱼ​ 的值（其中 i ≠ j），并且也拥有足够的信息来计算哈希值 h 并检查最初的承诺。

接下来，我们开始将向量承诺转换为 VOLE，以获取我们想要的 VOLE 承诺，P 首先承诺 τ 所有但一个的向量承诺。在发送向量承诺后，下一步是将每个向量承诺转换为长度为 l 的小域 VOLE 相关性，在 F₂ᵏ 中。这涉及到首先通过 PRG 扩展每个种子 sd₀, . . . , sd_N−1（在向量承诺中承诺），以获得 NNN 个字符串 r₀, . . . , r_N−1 ∈ {0,1}ˡ，并在 F₂ᵏ 中计算：

u=∑i=0N−1ri,v=∑i=0N−1i∗ri

其中 i 被编码为 F₂ᵏ 的一个元素。

为了了解这如何用于获得 VOLE 相关性，考虑一个 V 在稍后了解所有的种子 sdᵢ ​（对于所有 i ≠ j ，对于某个索引 j∈ {0, . . . , N − 1} 作为 F₂ᵏ 中的元素）。V 可以计算：

q=∑i=0N−1(j−i)∗ri=j∗∗u−v

对每个向量承诺进行此操作后，P 将拥有 l 个小且独立的 VOLE 相关性。将它们称为 uᵢ， Vᵢ ​，对于 i = 0,…,τ−1，现在我们将 Vᵢ ​ 视为 {0, 1}^l∗k 中的矩阵。最终，V 将学习到 (Δᵢ,Qᵢ) ，使得：

Qi=Vi+(δ0∗ui...δk−1∗ui)

其中 δ_0, …, δ_{k−1} 是 ∆ 的位分解。

在这之后，P 还必须发送校正值，以便将 VOLE 修正为相同的 u 值。最后，我们进行 VOLE 一致性检查，以确保所有 u 值以正确的方式得到了修正。

VOLEitH 证明系统

VOLE-ZK 是 VOLE-混合模型中的交互式 ZKP。它是基于线-点零知识范式[DIO21]。对于 zkPass 协议，我们使用 QuickSilver 协议来证明布尔电路的满足。由于 QuickSilver 是一个交互式证明系统，这里将它描述为在两个参与方 P 和 V 之间执行的协议。最终我们将其转换为 NIZK。

在最后一步，我们有 VOLE 承诺，P 首先从 Fiat-Shamir 变换中获取 χ_i ​，然后 P 针对电路中的所有输入和门计算 ∑ u ᵢ ∗ χ ᵢ 和 ∑vᵢ ∗ χ ᵢ，随后从 Fiat-Shamir 获取 Δ，打开所有向量承诺和 ∑uᵢ​ ∗ χ ᵢ​ 、 ∑vᵢ​ ∗ χ ᵢ，给 V，V 重建 GGM 树以获取 VOLE 实例并计算 ∑ q ᵢ​ ∗ χ ᵢ ，然后检查：

∑qi∗χi=∑ui∗χi∗Δ+∑vi∗χi

如果方程成立，则电路得到了满足。

此时，我们已成功完成所有协议实现。

为什么选择 VOLEitH

像 SNARKs 这样的 ZK 系统不太适合于授权 TLS 数据，因为它们涉及密集的加密计算，例如大规模指数运算和复杂配对操作。这些操作需要大量计算资源和内存，导致生成证明的时间耗时，往往对客户端而言是不可承受的。此外，SNARKs 通常需要可信的设置阶段，这引入了潜在的安全风险。虽然它们可能对非常小的数据尺寸是可以接受的，但对于 TLS 通信中常见的典型数据尺寸来说，它们效率低下，不切实际。

相比之下，VOLE-ZK 的效率要高得多。它们自然处理线性计算，实现快速而低开销，这使得它们更适合授权 TLS 数据。它们避免了对可信设置的要求，不需要大内存或广泛的计算来生成证明，从而使其对客户端负担得起。然而，VOLE-ZK 证明是交互的，要求验证者持续在线，可能会引入合谋的风险。

为了克服这些挑战，zkPass 协议采用 VOLEitH 技术，将 VOLE-ZK 协议转换为非交互式形式。这确保了在浏览器和设备中快速和高效的证明生成，并解决了传统 SNARKs 和 VOLE-ZK 的局限性。因此，zkPass 结合了 VOLE-ZK 证明的效率与非交互式的便利性，为授权 TLS 数据提供了一个实用和安全的解决方案。

MPC模式

在 MPC 模式下，我们使用结合 ZKP 和 MPC 技术的混合方法实现了该协议，以支持 3P-TLS。

P 和 V 作为单一客户端共同工作，以与 S 建立安全通信。它们通过基于椭圆曲线 Diffie-Hellman (ECDH) 协议的一系列阶段实现这一点，增强了 MPC 和 OT 技术。

三方握手

协议的第一阶段是 P、V 和 S 之间的三方握手，他们共同生成预主密钥。P 和 V 每个使用 Oblivious Linear Evaluation (OLE) 基于乘法到加法 (MtA) 或加法到乘法 (AtM) 方案接收这个密钥的一部分，这些方案支持加法同态。预主密钥被分割，P 和 V 每个获得一半，而 S 保留完整的密钥。

为了确保真实性，防止客户端冒充虚假网站，在客户端和服务器交换问候后，服务器提供其证书。在密钥交换阶段，服务器还用其证书中的私钥对公钥进行签名。这允许客户端中的 V 验证证书和签名，确认服务器的身份并在数据源中建立信任。

协议的第二阶段是密钥派生，P 和 V 一起使用 Garbled Circuit (GC) 从预主密钥生成两个会话密钥：用于数据保护的加密密钥 (enc_key) 和用于数据完整性的消息认证码密钥 (mac_key)。值得注意的是，V 只持有 mac_key 的一部分，而无权访问 enc_key，从而确保 V 无法查看 P 的私密信息。P 也持有 mac_key 的一部分，虽然能接触到与身份相关的数据，但无法篡改它。任何篡改都可以通过使用 mac_key 验证消息的真实性来检测。

zkPass 中的 MPC 算法在多个领域进行了显著优化，包括通信时间、用于 Garbler 和 Evaluator 的哈希函数、OT 操作和内存复制。这些改进提高了效率，超过三倍。还引入了一种新的 AES128 证明方法，减少了 300 倍的块数，使 Garbler/Evaluator 执行速度提高了十倍。zkPass 使用 Silent OT，最小化了 OT 生成期间的离线网络通信。对于 GC，zkPass 实现了“三分之二构成一个整体”（Three Halves Make a Whole）和堆叠 GC，这减少了加密表的大小，从而导致更少的通信和更快的执行。总体而言，这些优化大大减少了整个 MPC 过程的运行时间，使 zkPass 更加高效。

ZKP

在 zkPass 协议的最后阶段，客户端创建一个 ZKP 以供公开验证。在 3P-TLS 阶段后，证明者获取完整的数据，使用 VOLEitH 过程生成证明。由于这一步骤与代理模式中使用的过程类似，此处不再详细说明。

为什么不优先考虑 MPC 模式

MPC 模式的性能开销是显著的，主要是由于 GC 中的真值表 (TT)。应用数据的每个块都必须通过 TT 加密，这极大地增加了计算和带宽需求。对于单个 TLS 会话，存在固定成本 20MB，加上每 1KB 的额外出站数据 8MB 和每 1KB 的额外入站数据 32KB。对于典型的 1KB 请求和 100KB 响应，证明者需要上传约 32MB，这使得这种方法在常规使用中不切实际。

此外，MPC 模式并不一定比代理模式更安全，因为它仍然依赖于“可信的公证人”，与代理类似。恶意的公证人可能会缓存会话数据并与泄露的客户端合谋。由于服务器的解密密钥对隐私保持隐蔽，因此外部验证是不可能的，这意味着合谋或操控可能不被察觉。虽然 MPC 模式减少了一些信任假设，但并没有完全消除它们，因此它本身并不更安全。

鉴于这些问题，尽管 MPC 模式提供了一些加密上的优势，并可能对小请求有用，但其高性能开销和有限的安全收益使其不比设计良好且去中心化的代理更好。对于日常使用，资源需求和不切实际性限制了其在现实世界中的应用。因此，我们仅将此模式作为 TLS 服务器在来自不同 IP 地址时阻止来自同一帐户的请求的备用方案。

总结

zkPass 协议通过结合先进的加密技术，实现安全、高效和保密的数据共享，从而脱颖而出。通过将 TLS 扩展为三方协议，并结合 VOLEitH 以实现非交互式零知识 (NIZK) 证明，zkPass 有效地解决了安全性和性能挑战。

其 混合模式 能在 代理模式 和 MPC模式 之间无缝切换，使协议能够适应各种网络环境和服务器策略，而不会影响效率或安全性。代理模式确保以最小的加密开销实现高性能，而当某些服务器阻止来自多个 IP 地址的请求时，MPC 模式则介入，保持隐私和安全性。使用 VOLEitH 进一步提高了效率，避免了传统加密系统如 SNARKs 的高计算和内存需求。

优化的加密计算和通信流程使 zkPass 高度可扩展，确保该协议在不牺牲安全性或速度的情况下保持适用于现实世界应用的实用性。

zkPass 链接：

官方网站 | Twitter | Discord | Medium | Github | Portal

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