文章阅读页通栏

零知识证明 - 区块链应用中的风险

来源: 星想法 作者:Star Li
最近翻到一篇19年底360安全发布的一篇有关零知识证明安全的文章。这篇文章是Zhiniang Peng在PacSec2019大会发言的总结。文章框架性地介绍零知识证明zk-SNARK的......
最近翻到一篇19年底360安全发布的一篇有关零知识证明安全的文章。这篇文章是Zhiniang Peng在PacSec2019大会发言的总结。文章框架性地介绍零知识证明zk-SNARK的知识,并给出了一些安全提示和思考。

原文链接如下:
http://blogs.360.cn/post/Security-Risks-in-Zero-Knowledge-Proof-Cryptocurrencies.html

对整个PPT的内容感兴趣的小伙伴,可以直接查看原文链接。我摘录一些比较精彩的点,分享一下。

1. zk-SNARK总体流程

文章开头讲了讲 NIZK/zk-SNARK的基本概念,给出了zk-SNARK的工作流程图:


在这个流程图上,清晰的给出了“电路”,“R1CS”以及“QAP”的关系。一个NP问题,先拍平(Flatten)构成电路(若干个乘法门/加法门构成)。在电路的基础上,构造约束,也就是R1CS。有了一个个的约束,就可以把NP问题,抽象成QAP问题。有了QAP问题的描述,Groth16的算法就可以初始化,生成以及验证证明了。

整个流程从工程的角度,又可以“切分”成几个大块:

设计阶段(Design) - NP问题,也就是业务的设计。
翻译QAP(Translation) - 抽象并转化成QAP问题。
初始参数生成(Setup) - 生成可信参数,也就是传说中的CRS(Common Reference String)。
构造证明 - 提供私有/公开信息,生成证明。
验证 - 采用公开信息,验证证明。

2. zk-SNARK的工具链

文章中也比较细心地给出了目前zk-SNARK开发的各种高级语言以及相互的依赖关系。

大家可以看出,目前,R1CS->QAP的这条链上,相对其他来说是最健壮的。如果开始入门的小伙伴,可以从Zokrates/libsnark/Bellman入手:

零知识证明 - libsnark源代码分析
零知识证明 - bellman源码分析
零知识证明 - 深入理解ZoKrates

3. 应用风险总结

开发实现的风险

零知识证明的开发(所有的软件开发)常见的安全风险:内存污染,逻辑上的漏洞。加密的东西,没有时间的挑战都感觉有隐患。新的加密的实现存在新的风险。

文章举例,Zcash中的Faerie Gold攻击。在Zcash生成commitment的时候,发送方有意采用同样的随机数(rho)发送多笔交易。接受者只能消费其中的一笔交易。

去年7月份,暴露出来另外一个双花的Bug:

零知识证明 - zkSNARK应用的Nullifier Hash攻击

初始设置的风险

zk-SNARK一直被诟病,就是因为需要Trusted Setup。这个初始设置涉及到人为因素,虽然可以采用MPC多方计算加强安全性,但是始终不是绝对安全。

信息泄露

虽然ZCash提供了隐私交易,但事实上截止2019年9月份,整个Zcash的交易中只有5%的交易是隐私交易:

并且,从进行隐私交易的交易地址,金额,交易时间以及用户习惯,也可以推断出一些有用信息。

密码学本身安全问题

Groth16发表在2016年,2017年就大规模应用。没有得到充分的时间验证。Zcash之前有些零知识证明相关的漏洞,都是很晚才公布。文章列举了一些之前公布的漏洞,感兴趣的小伙伴可以看看。

其他问题

文章给出了自己的一些安全思考,并列举了一些其他问题。

文章最后给出了如何使用ZKP构造协议来进行数据的交易。对这部分感兴趣的小伙伴,可以自己查看原文。

感谢360安全的Zhiniang Peng,分享零知识证明和相关安全问题。大会发言用的完整版PPT,也分享给我了。需要原始完整PPT的小伙伴,可以留言。

关键词: 零知识证明  区块链应用  
0/300