首页>>资讯>>产业

zkPass — zkTLS 预言机协议的技术概述

2024-10-29 15:38:09 25

zkPass 是一种预言机协议,它基于 zkTLS(零知识传输层安全)构建,结合了 3P-TLS(三方位传输层安全)和混合零知识证明技术。该协议允许用户在不暴露敏感个人信息的情况下,对各种类型的数据进行验证并在区块链上证明其有效性。这些数据类型包括但不限于合法身份、财务记录、医疗保健信息、社交互动、游戏数据、现实世界资产、工作经验、教育背景以及技能认证。通过本地执行零知识证明计算,zkPass 确保了敏感数据的安全性,使其不会泄露给第三方。


zkPass 的应用范围广泛,不仅适用于人工智能(AI)、去中心化个人身份识别(DePIN)、去中心化标识符(DID)、贷款等金融场景,还延伸至非金融领域。对于任何需要确保数据真实性和隐私保护的应用,zkPass 都能提供有效的解决方案。通过使用 zkPass,用户能够在不泄露敏感个人信息的前提下,控制自己的数据,从而避免因信息泄露可能导致的不可预见的法律风险或其他问题。


zkPass 通过重新定义证明者(个人)、验证者(业务)以及数据源(TLS 服务器)之间的关系,重构了数据验证流程。与传统方法不同,zkPass 让证明者直接从数据源获取数据,然后在本地生成零知识证明供验证者检查。这样做的好处在于,验证者无法接触用户的个人信息,从而提高了数据的安全性和隐私性。

24.png

符号与定义


P:证明者(个人)

V:验证者(业务)

S:TLS 服务器

Q: P 发起的查询

R:S 回复的数据

enc_key:TLS 中加密数据的密钥

mac_key:TLS 中的 MAC 密钥

t:摘要


解决方案概述


在传统的数据验证模型中,证明者(通常是个人或实体)需要将其敏感信息提交给验证者(通常是某个机构或服务提供商)。验证者随后会与数据源(通常是数据库或服务)合作来验证这些信息的真实性。对于证明者而言,存在着个人信息过度暴露的风险。数据源尽管是可信的数据提供者,但却无法提供个性化的验证服务。验证者掌握了大量客户的私人数据,并且拥有完全的访问权限,这增加了数据泄露的可能性。


为了应对上述挑战,我们提出了一个新的框架来重新定义证明者、验证者以及数据源之间的关系。在这个新的模型中,证明者位于验证者和数据源之间,而不是像传统模型那样处于被动地位。具体而言:


证明者:使用其持有的访问令牌直接从数据源处获取其所需的数据。一旦数据被获取,证明者就在其本地设备上生成一个零知识证明(ZKP),这个证明可以向验证者展示其数据的真实性而不暴露实际的信息内容。

数据源:作为数据的提供者,继续保持其数据的准确性和可靠性,但不再参与到验证的具体过程中。

验证者:只负责检查证明者提供的 ZKP 是否有效,而不需要知道证明者实际的个人信息。


为了实施这一新的验证模型,我们利用了3P-TLS、MPC 和 IZK 技术。


3P-TLS 和 MPC

24.png

3P-TLS 协议是一种创新的安全通信协议,它在传统的TLS协议基础上增加了多方计算(MPC)和盲传输(Oblivious Transfer, OT),旨在提供更强大的安全保障机制,特别是在防止欺骗方面。以下是3P-TLS协议的详细说明:


第一阶段:三方握手

在这一阶段,协议涉及三个主要参与者:可信数据源(S)、证明者/用户(P)和zkPass节点(V)。这三个实体合作生成会话密钥。Paillier加密算法被用于分割预主密钥,其中P和V各自获得一半,而S则保留完整的预主密钥。为了防止客户端伪造虚假网站,客户端在与服务器交换初始消息后会请求服务器返回证书。密钥交换还包括服务器的公钥签名,该签名由服务器证书对应的私钥签署。这允许客户端内部的V验证证书及其签名,从而建立对数据源的信任。


第二阶段:密钥交换和MPC

在此阶段,P和V通过MPC计算出两个重要的密钥:用于数据保护的加密密钥(enc_key)和用于数据完整性的消息认证代码密钥(mac_key)。值得注意的是,V仅拥有mac_key的一部分,而不是完整的mac_key,这样就保证了V无法访问用户的隐私信息。相反,P持有mac_key的一部分,这赋予了其对特定身份信息的访问权限,但没有篡改的能力。通过mac_key验证消息的真实性,可以检测到任何篡改行为。


第三阶段:标准TLS和零知识证明准备

第三阶段开始遵循标准TLS协议处理应用程序数据。然后,在步骤10至12中,P和V之间交换必要的密钥信息,为随后涉及零知识证明(zkProof)的阶段做准备。


ZKP — Hybrid ZK

24.png

zkPass 协议的最后一步是生成零知识证明,该证明随后由区块链上的智能合约进行验证。为了达到这一目的,zkPass 采用了混合零知识证明方法,该方法结合了交互式零知识(IZK)和非交互式零知识(NIZK)协议的优点。


交互式零知识证明 (IZK)


在 IZK 部分,zkPass 依赖于基于虚拟输出提取器 (VOLE) 的协议,称为 VOLE-ZK 23。此协议确保数据来自正确的数据源并且防止客户端篡改数据。在“提交并证明”的框架下,证明者 (P) 和验证者 (V) 创建一系列的 VOLE 实例,这些实例满足线性关系“m = k + w * delta”。P 使用“m”作为承诺,并持有“w”作为见证,而 V 持有“k”和“delta”。通过比较所有承诺的总和与“m”和“w”的总和,V 可以批量验证这些承诺的一致性。


五项主要约束


在 VOLE-ZK 23 协议中,存在五个主要约束,以确保数据正确性和完整性:


Dec(enc_key,Q') = Q:确保客户端使用正确的加密密钥来加密发送到数据源的查询。

Q = Query(token):确保查询是由用户访问令牌生成的,这通常存储在 cookie 中。

Dec(enc_key,R') = R:确保响应由客户端使用正确的加密密钥解密。

验证(mac_key_pv,MAC,R)= 1:确保响应没有被篡改,通过 MAC 进行验证。

b = 断言(R):确保响应中的数据符合预定条件。


优化


为了提高协议的效率,zkPass 引入了几种优化措施,包括减少网络开销、最小化承诺的数量,并在可能的情况下重用 VOLE 参数。这些改进减少了网络流量,简化了电路的复杂度,并提高了协议的整体性能。


非交互式零知识证明 (NIZK)


从 IZK 转换到 NIZK 的目的是允许用户向任何一方展示证明,而无需直接互动。zkPass 在这一阶段采用了 SNARK 框架,特别是 Circom,来创建简洁的非交互式知识论证。一旦客户端通过 IZK 验证,节点会对结果签名,客户端则将签名的结果插入到 Merkle 树中,并更新 SBT(选择性区块链树)合约的根。当需要验证结果时,客户端只需提供零知识证明即可。


这种方法不仅提供了安全性,还保护了用户的隐私,并且支持可扩展性。通过结合 IZK 和 NIZK 技术,zkPass 实现了一种平衡隐私保护与验证效率的解决方案。


SBT

24.png

上图展示了我们如何构建zkSBT(零知识自我主权身份令牌)。我们遵循ERC998标准——这是一种可组合的非同质化代币(NFT)标准,并以此为基础构建NFT。具体而言,tSBT(信任自我主权身份令牌)和dSBT(数据自我主权身份令牌)本质上就是NFT。tSBT代表诸如法律身份、社交网络和财务信息等类别;而dSBT则存储用户从可信来源如政府网站或银行账户获得的实际凭证。我们对dSBT进行了定制,使其能够存储额外的信息,即所谓的“声明”。


声明分为两种类型:主声明与查询声明。主声明是在用户通过安全多方计算(MPC)从数据源(例如政府网站上的国家、年龄、性别等信息)获取其私人数据后创建的。根据这些数据构建声明树,每个树节点代表其子节点的哈希值。为了增加安全性,在构建声明树的过程中加入了从私钥和声明ID派生的随机数的babyjub签名,从而防止穷举攻击。最终,声明树的根哈希被保存在dSBT中,且必须由智能合约生成相应的零知识(ZK)证明以验证树的正确性。


相比之下,查询声明用于证明特定条件的满足而不暴露实际数据。例如,为了证明用户年龄超过18岁,只需提供一个证明,表明代表用户年龄的叶子节点存在于声明树中并且该叶子的值大于18。用户可以将此证明直接传递给验证者,验证者可以运行链上函数来确认证明的有效性。


这种设计确保了用户的实际私人数据不会被相关方看到,只有选择性的数据查询结果会被透露给指定的验证者。


安全性


首先,我们需要明确协议中可能存在的威胁:


从客户端角度看,主要担忧在于使用虚假数据绕过验证。而节点可能试图未经授权访问客户的私人数据。


就后者而言,根据协议的设计,节点实际上无法达到这一目的。


针对前者,在协议假定的所有参与者都是半诚实的前提下,只要各方按规则行事,就能维持系统的安全性和准确性。


然而,当涉及到恶意客户端与恶意节点之间的互动时,问题变得复杂。为了解决这一问题,我们在区块链中引入了一个类似RPC端点的安全网关。该网关确保客户端在网络层面的匿名性,并通过TLS协议引入随机性,进一步模糊客户端的身份。


在去中心化网络中,我们引入了“渔夫”这一角色,其职责是随机向节点分配任务,以检测并揭示任何潜在的恶意行为。因为节点无法区分真实客户端与渔夫,所以任何恶意行为都可能导致节点损失质押资产,而渔夫则会得到奖励。因此,从事恶意行为并不符合节点的利益。


如果客户端或渔夫需要解决争议,可以求助于仲裁员,仲裁员作为任务执行的中介。仲裁员可以缓存所有通信记录,并要求节点披露其VOLE(虚拟在线提取)参数。这使得仲裁员能够重新执行整个验证流程,确定责任方,并完成仲裁过程。整个过程自动化程度高,几乎无需人工介入。


上述描述概述了zkSBT的构建方式及其安全机制,涵盖了不同类型的声明生成与验证流程,以及如何防范潜在的对手攻击,从而保障系统的安全性和隐私性。

声明:本网站所有相关资料如有侵权请联系站长删除,资料仅供用户学习及研究之用,不构成任何投资建议!