早上很多朋友@我，安比實驗室發(fā)表了一篇文章zkSNARK的“輸入假名”的攻擊。迅速看了看，很贊。這個攻擊原理其實比較簡單，但是，不深入理解zkSNARK以及使用場景的朋友確實很難發(fā)現(xiàn)和理解。本文講講我對這個攻擊的分析和理解。

源于三天前

這種攻擊方式一直潛伏著，沒被發(fā)現(xiàn)。直到三天前：

俄羅斯開發(fā)者poma，在項目semaphore提交了一個issue，公開了這個攻擊方法。poma同時也在kovan測試網(wǎng)絡(luò)驗證了這種攻擊方式。

先從semaphore項目的代碼開始：

話說，semaphore是個很有意思的項目，它提供了一套方法能讓用戶不暴露自己身份的情況下廣播消息。暫不深入介紹這個項目的內(nèi)容，直接看函數(shù)。broadcastSignal函數(shù)提交了證明，某個用戶發(fā)送某個消息（signal）。只有具體的某個broadcaster（server）才會調(diào)用這個函數(shù)。

signal - 廣播的消息內(nèi)容

a/b/c以及input - 是zkSNARK的證明以及公開信息（statement信息）

函數(shù)實現(xiàn)（第82行），調(diào)用verifyProof函數(shù)驗證證明以及statement信息是否是合理的證明。第83行，查看nullifier_hash是否被用過。

什么是Nullifier？

熟悉ZCash的朋友，估計對Nullifier比較熟悉。

為了保護交易的隱私，在鏈上只存儲Note和Nullifier對應(yīng)的hash信息。Note代表可以花的錢，Nullifier表示某筆錢已經(jīng)消費。Note和Nullifier一一對應(yīng)，一個Note只存在一個Nullifier。通過zkSNARK生成證明，證明Note和Nullifier的正確性以及存在某種聯(lián)系。在鏈上，為了防止雙花，在執(zhí)行某個交易時，必須確定某個Note是否已經(jīng)消費。確定的方法就是記錄下Nullifier對應(yīng)的hash信息。

verifyProof的計算

verifyProof的函數(shù)實現(xiàn)在snarkjs項目的templates/verifier_groth.sol（以Groth16為例）。verifyProof只是個簡單的wrapper，具體計算的實現(xiàn)時verify函數(shù)。

verify就是驗證Groth16的驗證等式是否成立，再看Groth16的驗證等式：

其中橙色部分就是input，藍(lán)色部分就是vk.IC。scalar_mul是橢圓曲線的“標(biāo)量乘法”計算。vk.IC是橢圓曲線上的一個點（假設(shè)為P），input是個標(biāo)量（假設(shè)x）。scalar_mul（P， x） 表示為xP。如果橢圓曲線的階為q的話，下面的等式成立：

（x+q）P = xP + qP = xP

也就是說，x+p和x作為input的話，scalar_mul的計算結(jié)果相等。也就是說，Groth16的等式依然成立。

如何攻擊？

在智能合約中，輸入input是用uint表示。以太坊上一般采用bn254的曲線，q為：

21888242871839275222246405745257275088548364400416034343698204186575808495617。雖然這個q比較大，但是，uint的最大值還是比q大不少。

攻擊方法就形成了：

在一個用戶提交了證明以及公開的input信息后，攻擊者修改input中的nullifier_hash即可。雖然邏輯上在花費同一筆錢，但是，智能合約卻認(rèn)為是花費不同的費用。智能合約認(rèn)為一個Note只能對應(yīng)一個Nullfier，事實上，在這樣的情況下，一個Note對應(yīng)了多個Nullfier。

如何修復(fù)？

修復(fù)的方式有好多種，目前最簡單的修復(fù)方式是在verify函數(shù)加限制：

限制input不能超過q。

總結(jié)：

三天前，俄羅斯開發(fā)者poma公開了zkSNARK應(yīng)用模型下的一種攻擊方式。攻擊不需要重新生成證明信息，只需要修改Statement中Nullfier對應(yīng)的hash數(shù)據(jù)。原理是，橢圓曲線是個循環(huán)群，scalarMul計算在輸入的標(biāo)量加上橢圓曲線的階的情況下，結(jié)果相等。