ZKS:zkSNARK合約「輸入假名」漏洞致眾多混幣項目爆雷_NAR

編者按：本文來自安比實驗室，作者：p0n1，Odaily星球日報經授權轉載。大量零知識證明項目由于錯誤地使用了某個zkSNARKs合約庫，引入「輸入假名(InputAliasing)」漏洞，可導致偽造證明、雙花、重放等攻擊行為發生，且攻擊成本極低。眾多以太坊社區開源項目受影響，其中包括三大最常用的zkSNARKs零知開發庫snarkjs、ethsnarks、ZoKrates，以及近期大熱的三個混幣應用hopper、Heiswap、Miximus。這是一場由Solidity語言之父Chris兩年前隨手貼的一段代碼而引發的血案。雙花漏洞：最初暴露的問題

semaphore是一個使用零知識證明技術的匿名信號系統，該項目由著名開發者barryWhiteHat此前的混幣項目演化而來。俄羅斯開發者poma最先指出該項目可能存在雙花漏洞。問題出在第83行代碼，請仔細看。該函數需要調用者構造一個零知識證明，證明自己可從合約中提走錢。為了防止「雙花」發生，該函數還讀取「廢棄列表」，檢查該證明的一個指定元素是否被標記過。如果該證明在廢棄列表中，則合約判定校驗不通過，調用者無法提走錢。開發者認為，這樣一來相同的證明就無法被重復提交獲利，認為此舉可以有效防范雙花或重放攻擊。然而事與愿違，這里忽視了一個致命問題。攻擊者可根據已成功提交的證明，利用「輸入假名」漏洞，對原輸入稍加修改便能迅速「偽造證明」，順利通過合約第82行的零知識證明校驗，并繞過第83行的防雙花檢查。該問題最早可追溯到2017年，由ChristianReitwiessner大神，也就是Solidity語言的發明者，提供的zkSNARKs合約密碼學實現示例。其后，幾乎以太坊上所有使用zkSNARKs技術的合約，都照用了該實現。因此都可能遭受以下流程的攻擊。混幣應用：該安全問題的重災區

Sui聯合創始人：Sui已支持Groth16 zkSNARK算法:11月19日消息，Sui Network聯合創始人Kostas Kryptos發推稱，Sui歡迎零知識證明，用戶現已可以其交易事務中附加Groth16 ZKP證明，由于我們的后端結合了Arkworks和BLST，因此這樣做可以提升2倍的驗證性能速度。”與此同時，Kostas分享的Sui Github界面顯示關于Groth16的模塊已于今日提交。

注：Groth16是zkSNARK的典型算法，系Groth在2016年發表的一篇論文中提出，目前該算法在ZCash，Filecoin，Coda等多個項目中均有應用。[2022/11/19 13:24:11]

零知識證明技術在以太坊上最早和最廣泛的應用場景是混幣合約，或匿名轉賬、隱私交易。由于以太坊本身不支持匿名交易，而社區對于隱私保護的呼聲越來越強烈，因此涌現出不少熱門項目。這里以混幣合約的應用場景為例，介紹「輸入假名」漏洞對零知項目的安全威脅。混幣合約或匿名轉賬涉及兩個要點：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次？

哥倫比亞足球巨星James Rodríguez與ZKSpace合作推出NFT:金色財經消息，哥倫比亞足球巨星James Rodríguez宣布與ZKSpace合作推出紀念版NFT系列《Zurda》，據介紹，該系列NFT共計1500份，其中包含Rodríguez跨越三大洲的杰出職業生涯的關鍵亮點。（news.bitcoin）[2022/6/2 3:58:38]

上面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次，而且攻擊成本非常低！還有更多受影響的項目

算法匯率協議Increment宣布將基于zkSync 2.0構建:2月24消息，算法匯率協議 Increment 宣布將基于 zkSync 2.0 構建。Increment 團隊表示 zkSync 2.0 是最適合該協議的基礎設施，同時未來也會考慮進行多鏈部署。目前 Increment 協議已進入測試網發布和審計準備階段。[2022/2/24 10:12:46]

存在問題的遠遠不止semaphore一個。其他很多以太坊混幣項目以及zkSNARKs項目都存在同樣的允許「輸入假名」的問題。這當中，影響最大的要數幾個大名鼎鼎的zkSNARKs庫或框架項目，包括snarkjs、ethsnarks、ZoKrates等。許多應用項目會直接引用或參考他們的代碼進行開發，從而埋下安全隱患。因此，上述三個項目迅速進行了安全修復更新。另外，多個利用了zkSNARKs技術的知名混幣項目，如hopper、Heiswap、Miximus也立刻進行了同步修復。這些項目在社區熱度都十分高，其中Heiswap更是被人們稱為「Vitalik最喜愛的項目」。「輸入假名」漏洞的解決方案

事實上，所有使用了該zkSNARKs密碼學合約庫的項目都應該立即開展自查，評估是否受影響。那么應該如何修復這個問題？所幸的是，修復很簡單。僅需在驗證函數中添加對輸入參數大小的校驗，強制要求input值小于上面提到的q值。即嚴禁「輸入假名」，杜絕使用多個數表示同一個點。暴露的深層問題值得反思

火幣已正式上線BNT、FRONT、ZKS和LUNA品種USDT本位永續合約:據火幣合約官方消息，火幣BNT、FRONT、ZKS和LUNA品種USDT本位永續合約已于新加坡時間2月23日14點正式上線，用戶現可在平臺進行劃轉、交易等操作。

據悉，火幣USDT本位永續合約在每個新品種上線前，平臺均會提前配置一定額度風險準備金，以最大可能保護用戶權益。此次4個品種上線前，火幣合約已向其USDT本位永續合約風險準備金余額中注入了80萬USDT，各品種對應20萬USDT。

據了解，此次4個新幣上線后，火幣USDT本位永續合約已覆蓋BTC、ETH等主流幣，以及LINK、UNI、AAVE等熱門DeFi在內的69大主流品種，支持用戶在Web端、API端和APP端操作，最高125x倍數。[2021/2/23 17:43:28]

該「輸入假名」導致的安全漏洞值得社區認真反思。我們再回顧一下整個故事。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/

MatterLabs已在以太坊主網部署Layer2擴展工具zkSync:據官方消息，以太坊擴容項目MatterLabs宣布已在以太坊主網部署其Layer2擴展工具zkSync。MatterLabs團隊表示，zkSync將極大解決以太坊上的交易成本（Gas）費，平均交易費用旨在長期保持在的小于0.01美元的低位，并逐步實現最高達2000TPS的吞吐量。目前，zkSync已經實現「可擴展的支付功能」，后續將依次實現「智能合約部署」、「隱私」和「加密抗審查」等功能，最終實現為數十億人提供可擴展的、保護隱私的、公平的且無許可的加密基礎設施。（Medium）[2020/6/19]

Tags：ZKSARKNARINTzksync幣圖標SPARK幣Extra Ordinary CoinSplinterlands

DYDX