早上很多朋友@我，安比實驗室發(fā)表了一篇文章zkSNARK的“輸入假名”的攻擊。迅速看了看，很贊。這個攻擊原理其實比較簡單，但是，不深入理解zkSNARK以及使用場景的朋友確實很難發(fā)現(xiàn)和理解。本文講講我對這個攻擊的分析和理解。
源于三天前
這種攻擊方式一直潛伏著，沒被發(fā)現(xiàn)。直到三天前：
俄羅斯開發(fā)者poma，在項目semaphore提交了一個issue，公開了這個攻擊方法。poma同時也在kovan測試網(wǎng)絡驗證了這種攻擊方式。
先從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對應的hash信息。Note代表可以花的錢，Nullifier表示某筆錢已經(jīng)消費。Note和Nullifier一一對應，一個Note只存在一個Nullifier。通過zkSNARK生成證明，證明Note和Nullifier的正確性以及存在某種聯(lián)系。在鏈上，為了防止雙花，在執(zhí)行某個交易時，必須確定某個Note是否已經(jīng)消費。確定的方法就是記錄下Nullifier對應的hash信息。
verifyProof的計算
verifyProof的函數(shù)實現(xiàn)在snarkjs項目的templates/verifier_groth.sol（以Groth16為例）。verifyProof只是個簡單的wrapper，具體計算的實現(xiàn)時verify函數(shù)。
verify就是驗證Groth16的驗證等式是否成立，再看Groth16的驗證等式：
其中橙色部分就是input，藍色部分就是vk.IC。scalar_mul是橢圓曲線的“標量乘法”計算。vk.IC是橢圓曲線上的一個點（假設為P），input是個標量（假設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即可。雖然邏輯上在花費同一筆錢，但是，智能合約卻認為是花費不同的費用。智能合約認為一個Note只能對應一個Nullfier，事實上，在這樣的情況下，一個Note對應了多個Nullfier。
如何修復？
修復的方式有好多種，目前最簡單的修復方式是在verify函數(shù)加限制：
限制input不能超過q。
總結(jié)：
三天前，俄羅斯開發(fā)者poma公開了zkSNARK應用模型下的一種攻擊方式。攻擊不需要重新生成證明信息，只需要修改Statement中Nullfier對應的hash數(shù)據(jù)。原理是，橢圓曲線是個循環(huán)群，scalarMul計算在輸入的標量加上橢圓曲線的階的情況下，結(jié)果相等。
下載文檔
