Penulis: Pakar riset keamanan Beosin Saya & Bryce

1. Apa yang dimaksud dengan bukti tanpa pengetahuan

Zero-Knowledge Proof (ZKP) merupakan konsep kriptografi yang dapat digunakan untuk membuktikan keaslian suatu pernyataan tanpa mengungkapkan informasi spesifik apa pun tentang pernyataan tersebut. Dalam pembuktian tanpa pengetahuan, pembukti dapat membuktikan kepada pemverifikasi bahwa suatu pernyataan tertentu benar, dan pemverifikasi hanya mendapatkan satu hasil: menerima pernyataan itu benar atau menolaknya, tanpa mengetahui rincian spesifik dari pembuktiannya.

Konsep ini dapat dijelaskan dengan contoh sederhana. Misalkan ada dua orang, yang satu sebagai pembukti dan yang satu lagi sebagai verifikator. Prover ingin membuktikan kepada verifikator bahwa ia mengetahui password rahasia tanpa mengungkapkan password itu sendiri. Dengan cara tradisional, pembuktian mungkin memberi tahu pemverifikasi apa kata sandinya, tetapi dalam pembuktian tanpa pengetahuan, pembuktian dapat menggunakan protokol khusus untuk membuktikan kepada pemverifikasi bahwa dia mengetahui kebenaran kata sandi tanpa mengungkapkan kata sandi itu sendiri.

Saat ini, algoritme sistem pembuktian tanpa pengetahuan yang umum mencakup zk-SNARKs, zk-STARKs, BulletProofs, dll.

2. Penerapan ZKP di blockchain

Dalam teknologi blockchain, ZKP memiliki beragam aplikasi, seperti meningkatkan privasi, meningkatkan skalabilitas dan keamanan, dll. Berikut adalah beberapa aplikasi utama ZKP di blockchain:

1 Perlindungan Privasi:

Blockchain bersifat publik, artinya siapa pun dapat melihat semua transaksi di rantai tersebut. Namun terkadang, pengguna mungkin ingin merahasiakan informasi transaksinya. ZKP memungkinkan pengguna untuk membuktikan bahwa mereka memiliki cukup dana untuk berdagang tanpa harus mengungkapkan total dana mereka. Ini sangat meningkatkan perlindungan privasi pengguna. Misalnya, Zcash adalah mata uang kripto yang menggunakan teknologi zero-knowledge proof, yang memungkinkan pengguna menyembunyikan pengirim, penerima, dan jumlah transaksi.

2 Kompresi komputasi dan perluasan blockchain:

Skalabilitas Blockchain merupakan sebuah tantangan, terutama dalam aplikasi skala besar. ZKP dapat digunakan untuk mengurangi beban pada node dan meningkatkan skalabilitas seluruh sistem. Dengan menggunakan ZKP untuk memverifikasi validitas transaksi, node tidak perlu melihat riwayat transaksi secara lengkap, sehingga mengurangi beban penyimpanan dan pemrosesan. ZK Rollup, yang saat ini paling banyak digunakan, adalah solusi skalabilitas yang dirancang untuk meningkatkan Ethereum dan area lainnya. Throughput dan efisiensi jaringan blockchain. Ini menggabungkan keunggulan teknologi Rollup dan ZKP untuk menyediakan solusi perluasan aplikasi terdesentralisasi (DApps) berkinerja tinggi. Di jaringan Ethereum tradisional, setiap transaksi perlu diverifikasi dan dicatat di blockchain, yang mengakibatkan penundaan dan biaya tinggi dalam pemrosesan transaksi. ZK Rollup mengelompokkan dan memampatkan sejumlah besar transaksi ke dalam satu blok, dan ZKP digunakan untuk membuktikan validitas transaksi batch untuk memastikan kebenaran dan keamanan transaksi.

3 Otentikasi:

Bukti tanpa pengetahuan dapat digunakan untuk memverifikasi identitas pengguna tanpa mengungkapkan informasi pribadi yang sensitif. Misalnya, seseorang dapat menggunakan bukti tanpa pengetahuan untuk membuktikan kepada jaringan bahwa mereka memenuhi persyaratan usia tertentu atau memiliki sertifikasi tertentu tanpa mengungkapkan usia sebenarnya atau informasi identitas lainnya.

4 Penyimpanan Terdesentralisasi:

Server dapat membuktikan kepada pengguna bahwa data mereka disimpan dengan aman dan tidak ada konten data yang bocor.

Secara umum, **bukti tanpa pengetahuan blockchain memiliki aplikasi luas dalam perlindungan privasi, kompresi dan perluasan komputasi, verifikasi identitas, penyimpanan terdesentralisasi, dll. Ini memberikan lebih banyak fungsi dan pilihan untuk teknologi blockchain dan mempromosikan pengembangan dan penerapan blockchain di berbagai bidang. **

3. Serangan pembelanjaan ganda pada aplikasi ZKP

zk-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) adalah teknologi berbasis bukti tanpa pengetahuan yang dapat membuktikan keaslian suatu pernyataan tanpa mengungkapkan informasi sebenarnya. Ini adalah teknologi bukti tanpa pengetahuan yang sangat efisien yang dapat menghasilkan dan memverifikasi bukti dalam waktu yang sangat singkat sekaligus melindungi privasi dan keamanan, sehingga digunakan secara luas. Namun, seiring dengan berkembangnya aplikasi, keamanannya semakin menarik perhatian. Kami menemukan kerentanan umumnya belum lama ini: jika rentang nilai input parameter dalam fungsi verifikasi tidak diverifikasi dengan benar dalam proyek ZKP, penyerang dapat memalsukan beberapa input agar lolos verifikasi, sehingga menyebabkan serangan pembelanjaan ganda. Dampak serangan ini sangat luas, melibatkan beberapa algoritma zk-SNARK termasuk: groth16, plonk, dll., dan kerentanan ini ada di banyak bahasa pengembangan seperti solidity dan js. Kerentanan ini pertama kali ditemukan oleh poma pada proyek zero-knowledge proof Semaphore, dan diberikan dua contoh transaksi yang berhasil diimplementasikan, seperti yang ditunjukkan pada gambar di bawah ini:

Prinsip serangan spesifik dari kerentanan ini adalah jika Anda ingin membuat dan memverifikasi bukti zk-SNARK di Ethereum, Anda perlu menggunakan rangkaian kurva elips bidang hingga aritmatika F_p, di mana nilai p digunakan untuk menentukan rentang dari bidang berhingga kurva elips, sehingga rangkaian Rentang nilai inputnya adalah [0,1,…,p-1]. Kurva yang berbeda memiliki nilai p yang berbeda:

Kurva BN254 yang ditentukan dalam EIP-196 (juga dikenal sebagai kurva ALT_BN128):

p = 21888242871839275222246405745257275088548364400416034343698204186575808495617

circom2 memperkenalkan dua bilangan prima baru, kurva BLS12-381:

p = 52435875175126190479447740508185965837690552500527637822603658699938581184513

dan plink2:

18446744069414584321

Semaphore kemudian mengkonfirmasi dan memperbaiki kerentanan tersebut, dan perpustakaan zk seperti ZoKrates dan snarkjs juga melakukan perbaikan darurat secara bersamaan. Namun, peneliti keamanan Beosin menemukan bahwa saat ini tidak ada solusi terpadu untuk masalah ini. Misalnya, protokol Semaphore menuliskan batasan pada pemasangan perpustakaan. Rentang data yang valid tidak diverifikasi secara eksplisit dalam logika bisnis luar; kode kontrak yang dihasilkan oleh circom dan Tornado.Cash secara eksplisit memverifikasi SNARK_SCALAR_FIELD dalam fungsi verifikasi. Ini adalah solusi yang membingungkan dan tidak konsisten. Ini dapat menyebabkan masalah dan risiko keamanan bagi banyak pihak proyek zk DApp baru, jadi kami berharap dapat menggunakan cara standar untuk menyelesaikan masalah ini.

4. Serangan pembelanjaan ganda di ERC-1922

Saat ini, Ethereum memiliki standar terkait zk EIP-1922, yang memperkenalkan antarmuka standar kontrak Verifikasi untuk memverifikasi zk-SNARK. Kode spesifiknya adalah sebagai berikut:

soliditas pragma ^0.5.6;/// @title EIP-XXXX zk-SNARK Verifier Standard/// @dev Lihat /// Catatan: pengidentifikasi ERC-165 untuk antarmuka ini adalah 0xXXXXXXXX./// ⚠️ TODO: Hitung antarmuka identifierinterface ERC1922 /* is ERC165 */ { /// @notice Memeriksa argumen Bukti, melalui kurva elips /// fungsi berpasangan. /// @dev /// HARUS mengembalikan nilai true jika Proof lolos semua pemeriksaan (yaitu Proof /// valid). /// HARUS mengembalikan false jika Bukti tidak lulus semua pemeriksaan (yaitu jika /// Bukti tidak valid). /// @param bukti zk-SNARK. /// @param inputs Input publik yang menyertai Bukti. /// @param verifikasiKeyId Pengidentifikasi unik (dikenal oleh pemverifikasi ini /// kontrak) untuk Kunci Verifikasi yang sesuai dengan Bukti. /// @return result Hasil perhitungan verifikasi. Benar /// jika Bukti valid; salah sebaliknya. fungsi verifikasi(uint256[] bukti panggilan data, uint256[] input data panggilan, bytes32 verifikasiKeyId) pengembalian eksternal (hasil bool);}

Di antara mereka, jenis variabel bukti bukti nol dan input adalah uint256[].Jenis variabel ini saat ini merupakan operasi kurva elips yang paling umum digunakan dalam algoritma ZKP. Namun, perlindungan keamanan yang sesuai tidak ditambahkan ke antarmuka ini, jadi gandakan -Serangan pembelanjaan juga ada.Bahaya keamanan yang besar.

5.Solusi ERC-7520

Berdasarkan masalah di atas, Beosin mengusulkan EIP-7520 untuk mencegah risiko keamanan semacam ini. Secara khusus, semua proyek DApp yang menggunakan teknologi zk di ekosistem Ethereum harus mengimplementasikan antarmuka ini dalam kontrak verifikator yang sesuai untuk menggunakan standar yang terpadu dan aman. verifikasi rentang yang valid pada semua input. Antarmuka spesifiknya adalah sebagai berikut:

pragma soliditas ^0.5.6;/// @title EIP-XXXX zk-SNARK public inputs Verifier Standard/// Catatan: pengidentifikasi ERC-165 untuk antarmuka ini adalah 0xXXXXXXXX./// ⚠️ TODO: Hitung pengidentifikasi antarmukainterface EIP7520 /* is ERC165 & ERC1922 */ { /// @notice Memeriksa argumen Input berada dalam bidang skalar /// @dev /// HARUS mengembalikan nilai true jika Input lolos pemeriksaan rentang (yaitu Input /// valid). /// HARUS mengembalikan false jika Input tidak lolos pemeriksaan rentang (yaitu jika /// Input tidak valid). /// @param inputs Input publik yang menyertai Bukti. /// @param p Input publik yang menyertai kurva. function verifikasiPublicInput(uint256[] inputs,uint256 p) pengembalian eksternal (hasil bool)；}

Fungsi verifikasiPublicInput adalah inti dari standar ini. Arti spesifik dari parameter yang terlibat adalah sebagai berikut:

• input: didefinisikan sebagai tipe uint256[], mewakili parameter sinyal publik yang terlibat dalam fungsi verifikasi di proyek ZKP
• p: Didefinisikan sebagai tipe uint256, nilai ini sesuai dengan nilai p dari kurva elips yang digunakan dalam algoritma

Berikut ini akan membandingkan dua situasi penerapan dan tidak penerapan antarmuka EIP-7520, yang bertujuan pada manifestasi berbeda dari serangan ini, untuk menunjukkan risiko bagi pihak proyek:

1 Asumsikan kita langsung menggunakan kode kontrak verifikasi untuk verifikasi tanpa memanggil verifikasiPublicInput antarmuka eip ini.Kode spesifiknya adalah sebagai berikut:

fungsi verifikasi(uint[] masukan memori, bukti bukti memori) tampilan internal kembali (uint) { VerifyingKey memory vk = verifikasiKey(); require(input.length + 1 == vk.IC.length,"verifier-bad-input"); // Hitung kombinasi linier memori vk_x Pairing.G1Point vk_x = Pairing.G1Point(0, 0); for (uint i = 0; i < input.length; i++) vk_x = Memasangkan.tambahan(vk_x, Memasangkan.scalar_mul(vk.IC[i + 1], masukan [i] )); vk_x = Memasangkan.tambahan(vk_x, vk.IC [0] ); if (!Pairing.pairingProd4( Pairing.negate(proof.A), proof.B, vk.alfa1, vk.beta2, vk_x, vk.gamma2, proof.C, vk.delta2 )) mengembalikan 1; kembali 0;}

Tangkapan layar hasil eksperimen asli yang membuktikan bahwa verifikasi lolos:

Pada saat yang sama, empat sertifikat berikut dapat dipalsukan dan juga dapat lolos verifikasi, sehingga menyebabkan serangan pembelanjaan ganda:

Dengan menggunakan salah satu bukti palsu, maka hasil verifikasinya seperti dibawah ini:

2 Jika antarmuka verifikasiPublicInput di eip ini dipanggil, bukti palsu di atas akan gagal diverifikasi. Bagian dari kode kontrak adalah sebagai berikut. Untuk detail selanjutnya, silakan merujuk ke Implementasi Referensi:

fungsi verifikasix(uint[] masukan memori, bukti bukti memori, bytes32 verifikasiKeyId,uint256 p) pengembalian publik (uint){ require(verifyPublicInput(inputs,p),"verifier-over-snark-scalar-field"); memerlukan(verifikasi(input,bukti,verifikasiKeyId),"verifikasi gagal"); return true;}fungsi verifikasiPublicInput(uint256[] inputs，uint256 p) tampilan internal mengembalikan (bool) { for (uint i = 0; i < input.length; i++) { require(input < p,"verifier-gte-snark -bidang skalar"); } kembalikan benar;}

Hasil percobaan ditunjukkan pada gambar di bawah ini:

Singkatnya, dapat ditemukan bahwa jika antarmuka ini tidak digunakan untuk memverifikasi validitas rentang nilai sinyal publik, mungkin terdapat risiko serangan pembelanjaan ganda. **