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

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

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

數據：zkSync Era 鏈上獨立地址數突破 100 萬:6月30日消息，據 Dune 數據顯示，zkSync Era 鏈上獨立地址數已突破 100 萬，現為 1,086,771 個，鏈上橋接 TVL 總額達到 562,299 枚 ETH。據歐科云鏈 OKLink 多鏈瀏覽器數據顯示，當前 zkSync Era 鏈上地址總數為 2,846,469 個，總交易量約 423 萬筆。[2023/6/30 22:10:55]

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

BitKeep Swap已支持zkSync Era:5月19日消息，多鏈錢包 BitKeep 發推稱，BitKeep Swap 現已支持 zkSync Era 上 token 單鏈、多鏈兌換，并提供 K 線行情查詢。BitKeep 表示會持續升級跨鏈服務，豐富跨鏈交易幣對，并正在配置 zkSync Era 借 Gas 交易功能，之后用戶可以在沒有 ETH 的情況下直接進行鏈上交易。[2023/5/19 15:14:01]

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

穩定幣跨鏈交易協議Meson新增支持zkSync Era:3月29日消息，穩定幣跨鏈交易協議Meson新增支持zkSync Era，用戶可將其他支持的鏈上的USDT、USDC和BUSD交易為zkSync Era上的USDC。[2023/3/29 13:33:13]

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

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

跨鏈橋Hop Protocol將部署至zkSync 2.0:12月8日消息，以太坊Layer 2擴容方案zkSync在推特上宣布，跨鏈橋Hop Protocol將在zkSync 2.0主網進入Full Launch Alpha時部署至其主網，允許用戶跨Rollup和Layer1進行交易和轉移資金。

此前10月份消息，zkSync 2.0主網第一階段Baby Alpha已上線，并且預計將在明年初進入第三階段Full Launch Alpha，并向全部用戶開放。[2022/12/8 21:30:46]

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

在zkSync上部署Uniswap V3的提案獲得通過:金色財經報道，據相關頁面信息顯示，在zkSync上部署Uniswap V3的提案已結束。超4000萬票贊成，預計將在4-6周內完成部署。

根據提案，盡早部署Uniswap將“鞏固Uniswap作為第一大DEX和思想領袖的地位”。它應該有助于Uniswap建立先發優勢。更重要的是，Uniswap DAO 治理將留在以太坊L1上。zkSync將使用L1<>L2通信橋來支持任意消息傳遞以進行治理。[2022/10/14 14:27:08]

Tags：ZKSINTNARARKzks幣這幾天怎么這么火Endpoint Cex Fan TokenManariumDARK幣

BNB價格