编者按：本文来自安比实验室，作者：p0n1，Odaily星球日报经授权转载。大量零知识证明项目由于错误地使用了某个zkSNARKs合约库，引入「输入假名(InputAliasing)」漏洞，可导致伪造证明、双花、重放等攻击行为发生，且攻击成本极低。众多以太坊社区开源项目受影响，其中包括三大最常用的zkSNARKs零知开发库snarkjs、ethsnarks、ZoKrates，以及近期大热的三个混币应用hopper、Heiswap、Miximus。这是一场由Solidity语言之父Chris两年前随手贴的一段代码而引发的血案。双花漏洞：最初暴露的问题
semaphore是一个使用零知识证明技术的匿名信号系统，该项目由著名开发者barryWhiteHat此前的混币项目演化而来。俄罗斯开发者poma最先指出该项目可能存在双花漏洞。问题出在第83行代码，请仔细看。该函数需要调用者构造一个零知识证明，证明自己可从合约中提走钱。为了防止「双花」发生，该函数还读取「废弃列表」，检查该证明的一个指定元素是否被标记过。如果该证明在废弃列表中，则合约判定校验不通过，调用者无法提走钱。开发者认为，这样一来相同的证明就无法被重复提交获利，认为此举可以有效防范双花或重放攻击。然而事与愿违，这里忽视了一个致命问题。攻击者可根据已成功提交的证明，利用「输入假名」漏洞，对原输入稍加修改便能迅速「伪造证明」，顺利通过合约第82行的零知识证明校验，并绕过第83行的防双花检查。该问题最早可追溯到2017年，由ChristianReitwiessner大神，也就是Solidity语言的发明者，提供的zkSNARKs合约密码学实现示例。其后，几乎以太坊上所有使用zkSNARKs技术的合约，都照用了该实现。因此都可能遭受以下流程的攻击。混币应用：该安全问题的重灾区
零知识证明技术在以太坊上最早和最广泛的应用场景是混币合约，或匿名转账、隐私交易。由于以太坊本身不支持匿名交易，而社区对于隐私保护的呼声越来越强烈，因此涌现出不少热门项目。这里以混币合约的应用场景为例，介绍「输入假名」漏洞对零知项目的安全威胁。混币合约或匿名转账涉及两个要点：1.证明自己有一笔钱2.证明这笔钱没有花过为了方便理解，这里简单描述一下流程：1.A要花一笔钱。2.A要证明自己拥有这笔钱。A出示一个zkproof，证明自己知道一个hash(HashA)的preimage，且这个hash在以root为标志的tree的叶子上，且证明这个preimage的另一种hash是HashB。其中HashA是witness，HashB是publicstatement。由于A无需暴露HashA，所以是匿名的。3.合约校验zkproof，并检查HashB是否在废弃列表中。若不在，则意味着这笔钱未花过，可以花。4.如果可以花，合约需要把HashB放入废弃列表中，标明以HashB为代表的钱已经被花过，不能再次花了。上面代码中的第82行verifyProof(a,b,c,input)用来证明这笔钱的合法性，input是publicstatement，即公共参数。第83行通过require(nullifiers_set]==false)校验这笔钱是否被花过。很多zkSNARKs合约尤其是混币合约，核心逻辑都与第82行和83行类似，因此都存在同样的安全问题，可利用「输入假名」漏洞进行攻击。漏洞解析：一笔钱如何匿名地重复花5次？
上面verifyProof(a,b,c,input)函数的作用是根据传入的数值在椭圆曲线上进行计算校验，核心用到了名为scalar_mul()的函数，实现了椭圆曲线上的标量乘法。我们知道以太坊内置了多个预编译合约，进行椭圆曲线上的密码学运算，降低zkSNARKs验证在链上的Gas消耗。函数scalar_mul()的实现则调用了以太坊预编译7号合约，根据EIP196实现了椭圆曲线alt_bn128上的标量乘法。下图为黄皮书中对该操作的定义，我们常称之为ECMUL或ecc_mul。密码学中，椭圆曲线的{x,y}的值域是一个基于modp的有限域，这个有限域称之为Zp或Fp。也就是说，一个椭圆曲线上的一个点{x,y}中的x,y是Fp中的值。一条椭圆曲线上的某些点构成一个较大的循环群，这些点的个数称之为群的阶，记为q。基于椭圆曲线的加密就在这个循环群中进行。如果这个循环群的阶数为质数，那么加密就可以在modq的有限域中进行，该有限域记作Fq。一般选取较大的循环群作为加密计算的基础。在循环群中，任意选定一个非无穷远点作为生成元G，其他所有的点都可以通过G+G+....产生出来。这个群里的元素个数为q，也即一共有q个点，那么我们可以用0,1,2,3,....q-1来编号每一个点。在这里第0个点是无穷远点，点1就是刚才提到的那个G，也叫做基点。点2就是G+G，点3就是G+G+G。于是当要表示一个点的时候，我们有两种方式。第一种是给出这个点的坐标{x,y}，这里x,y属于Fp。第二种方式是用n*G的方式给出，由于G是公开的，于是只要给出n就行了。n属于Fq。看一下scalar_mul(G1Pointpoint,uints)函数签名，以point为生成元，计算point+point+.....+point，一共n个point相加。这属于使用上面第二种方法表示循环群中的一个点。在Solidity智能合约实现中需要使用uint256类型来编码Fq，但uint256类型的最大值是大于q值，那么会出现这样一种情况：在uint256中有多个数经过mod运算之后都会对应到同一个Fq中的值。比如s和s+q表示的其实是同一个点，即第s个点。这是因为在循环群中点q其实等价于点0。同理，s+2q等均对应到点s。我们把可以输入多个大整数会对应到同一个Fq中的值这一现象称作「输入假名」，即这些数互为假名。以太坊7号合约实现的椭圆曲线是y^2=ax^3+bx+c。p和q分别如下。这里的q值即上文中提到的群的阶数。那么在uint256类型范围内，共有uint256_max/q个，算下来也就是最多会有5个整数代表同一个点。这意味着什么呢？让我们回顾上面调用scalar_mul(G1Pointpoint,uints)的verifyProof(a,b,c,input)函数，input数组里的每个元素实际就是s。对于每个s，在uint256数据类型范围内，会最多存在其他4个值，传入后计算结果与原值一致。因此，当用户向合约出示零知识证明进行提现后，合约会把input放入作废列表。用户还可以使用另外4个值再次进行证明提交。而这4个值之前并没有被列入「废弃列表」，因此“伪造”的证明可以顺利通过校验，利用5个「输入假名」一笔钱可以被重复花5次，而且攻击成本非常低！还有更多受影响的项目
FTX今年在巴哈马的房产上花费了7400万美元:金色财经报道，根据获得的政府文件，并由两名FTX前员工证实，在2022年期间，FTX地产控股公司在巴哈马的房地产上总共花费了74,230,193美元。其中大部分资金，即67,440,193.99美元，用于新普罗维登斯的豪华公寓度假村Albany Bahamas周边的实体。
此外，该文件还指出，\"在2021年底，山姆-班克曼-弗里德直接以200万购买了凯布尔海滩一号的一套公寓\"。作为参考，巴哈马元与美元挂钩并保持平价。One Cable Beach是另一个海边的豪华公寓楼。（the block）[2022/11/13 12:57:12]
存在问题的远远不止semaphore一个。其他很多以太坊混币项目以及zkSNARKs项目都存在同样的允许「输入假名」的问题。这当中，影响最大的要数几个大名鼎鼎的zkSNARKs库或框架项目，包括snarkjs、ethsnarks、ZoKrates等。许多应用项目会直接引用或参考他们的代码进行开发，从而埋下安全隐患。因此，上述三个项目迅速进行了安全修复更新。另外，多个利用了zkSNARKs技术的知名混币项目，如hopper、Heiswap、Miximus也立刻进行了同步修复。这些项目在社区热度都十分高，其中Heiswap更是被人们称为「Vitalik最喜爱的项目」。「输入假名」漏洞的解决方案
事实上，所有使用了该zkSNARKs密码学合约库的项目都应该立即开展自查，评估是否受影响。那么应该如何修复这个问题？所幸的是，修复很简单。仅需在验证函数中添加对输入参数大小的校验，强制要求input值小于上面提到的q值。即严禁「输入假名」，杜绝使用多个数表示同一个点。暴露的深层问题值得反思
该「输入假名」导致的安全漏洞值得社区认真反思。我们再回顾一下整个故事。2017年Christian在Gist网站贴出了自己的zkSNARKs合约计算实现。作为计算库，我们可以认为他的实现并没有安全问题，没有违反任何密码学常识，完美地完成了在合约中进行证明验证的工作。事实上，作为Solidity语言的发明者，Christian在这里当然不会犯任何低级错误。而两年后的今天，这段代码却引发了如此的安全风波。两年多的时间内，可能有无数同行和专家看过或使用过这段只有两百多行的代码，却没有发现任何问题。核心问题出在哪里？可能出在底层库的实现者和库的使用者双方间对于程序接口的理解出现了偏差。换句话说：底层库的实现者对于应用开发者的不当使用方式欠缺考虑；而上层应用开发者没有在使用中没有深入理解底层实现原理和注意事项，进行了错误的安全假设。所幸的是，目前常见的zkSNARKs合约库都火速进行了更新，从底层库层面杜绝「输入假名」。安比实验室认为，底层库的更新诚然能够很大程度上消除掉后续使用者的安全隐患，但若该问题的严重性没有得到广泛地宣传和传播，依旧会有开发者不幸使用到错误版本的代码，或者是根据错误的教程进行开发，从而埋下安全隐患。「输入假名」漏洞不禁让我们回想起此前频繁曝出的「整数溢出」漏洞。二者相似之处颇多：都是源于大量开发者的错误假设；都与Solidity里的uint256类型有关；波及面都十分广；网络上也都流传着很多存在隐患的教程代码或者库合约。但显然「输入假名」漏洞显然更难检测，潜伏时间更长，需要的背景知识更多。安比实验室认为，随着zkSNARKs、零知识证明应用、隐私技术的兴起，社区会涌现出更多的新应用，而背后暗藏的更多安全威胁可能会进一步暴露出来。希望这波新技术浪潮中，社区能充分吸收以往的惨痛教训，重视安全问题。参考文献https://github.com/https://github.com/https://gist.github.com/https://github.com/https://github.com/
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。