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

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

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

LayerZero宣布上線zkSync Era主網:4月27日消息，全鏈互操作性協議LayerZero宣布上線zkSync Era主網。[2023/4/27 14:31:23]

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

Ankr將發布zkSync RPC，允許開發者訪問zkSync測試網和主網:2月17日消息，Web3 基礎設施提供商 Ankr 宣布啟動開發者 RPC 連接到 zkSync，并將很快發布 zkSync RPC，允許開發者使用 Ankr 的公共、高級和企業 RPC 端點訪問 zkSync 測試網和主網，開發者可以使用標準 EVM 方法進行請求調用，并接收與其自己運行 zkSync 節點所獲得的結果相同的信息返回。

Ankr 的 zkSync RPC 將把錢包、命令行界面或 DApp 與 zkSync L2 區塊鏈連接，充當信使或區塊鏈路由器，在 zkSync 節點、DApp 和終端用戶之間中繼鏈上信息。zkSync RPC 端點是開發者直接與 zkSync 鏈接口的網關，無需通過 DecOps 即可建立自己的 zkSync 節點。[2023/2/17 12:13:51]

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

zkSync 2.0 主網項目注冊現已開放:金色財經消息，以太坊Layer2擴容解決方案zkSync宣布，zkSync2.0項目注冊現已開放。注冊項目在主網的部署時間將在Proof Merging和Baby Alpha里程碑之后宣布。此外，主網將按既定計劃在52天后上線。[2022/9/7 13:12:55]

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

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

以太坊二層解決方案zkSync將于7月14日在主網上線:官方消息，以太坊二層解決方案zkSync最新版本完成了由ABDK進行的代碼審計，將于7月14日在主網上線，該版本將支持交易、NFT，且代幣上線zkSyns無需經過審查，此外zkSync還將上線新的事件系統。[2021/7/2 0:21:16]

該「輸入假名」導致的安全漏洞值得社區認真反思。我們再回顧一下整個故事。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在測試網中被意外觸發安全開關Exodus Mode，可證明其安全機制有效:據官方消息，Matter Labs 表示昨日在以太坊測試網（Ropsten）上有用戶觸發了擴容方案 zkSync 1.0 的“Exodus Mode”（出埃及記模式），這并不是計劃內的操作，但是也證明了 zkSync 1.0 的安全機制是有效的。該模式的觸發是由于 Matter Labs 在測試一個新的系統，最終導致了系統認為 zkSync 的操作節點已下線了或者是惡意的，也就導致了該模式可以被觸發。Matter Labs 表示，Exodus Mode 是 zkSync 可以與以太坊主鏈安全性一致的保證，在觸發該模式后，用戶可以重構狀態數據并從 zkSync 網絡中提現資產。[2021/4/24 20:53:50]

Tags：ZKSSYNKSYzkSyncZKS價格DSYNC價格zksync幣合法嗎zksync幣總量

世界幣