Yazar: Beosin güvenlik araştırma uzmanları Saya & Bryce

1. Sıfır bilgi kanıtı nedir

Sıfır Bilgi Kanıtı (ZKP), bir beyanın gerçekliğini, beyanla ilgili herhangi bir spesifik bilgiyi açıklamadan kanıtlamak için kullanılabilecek bir kriptografik kavramdır. Sıfır bilgi kanıtında, kanıtlayıcı, doğrulayıcıya belirli bir ifadenin doğru olduğunu kanıtlayabilir ve doğrulayıcı yalnızca tek bir sonuç alır: kanıtın belirli ayrıntılarını bilmeden, ya ifadeyi doğru olarak kabul edin ya da reddedin.

Bu kavram basit bir örnekle açıklanabilir. Diyelim ki iki kişi var; biri kanıtlayıcı, diğeri doğrulayıcı. Kanıtlayıcı, doğrulayıcıya, şifrenin kendisini açıklamadan, gizli bir şifreyi bildiğini kanıtlamak ister. Geleneksel yöntemde, kanıtlayıcı doğrulayıcıya parolanın ne olduğunu söyleyebilir, ancak sıfır bilgi kanıtında kanıtlayıcı, doğrulayıcıya parolanın kendisini açıklamadan parolanın doğruluğunu bildiğini kanıtlamak için özel bir protokol kullanabilir.

Şu anda yaygın sıfır bilgi kanıtı sistem algoritmaları arasında zk-SNARK'lar, zk-STARK'lar, BulletProof'lar vb. yer almaktadır.

2. ZKP'nin blockchain'de uygulanması

Blockchain teknolojisinde ZKP'nin gizliliği iyileştirme, ölçeklenebilirliği ve güvenliği artırma vb. gibi çeşitli uygulamaları vardır. ZKP'nin blockchain'deki bazı önemli uygulamaları şunlardır:

1 Gizlilik Koruması:

Blockchain halka açıktır, yani herkes zincirdeki tüm işlemleri görebilir. Ancak bazen kullanıcılar işlem bilgilerini gizli tutmak isteyebilirler. ZKP, kullanıcıların toplam fonlarını açıklamaya gerek kalmadan ticaret için yeterli fona sahip olduklarını kanıtlamalarına olanak tanır. Bu, kullanıcı gizliliğinin korunmasını büyük ölçüde artırır. Örneğin Zcash, sıfır bilgi kanıt teknolojisini kullanan ve kullanıcıların göndereni, alıcıyı ve işlem tutarını gizlemesine olanak tanıyan bir kripto para birimidir.

2 Hesaplamalı sıkıştırma ve blockchain genişletme:

Blockchain'in ölçeklenebilirliği özellikle büyük ölçekli uygulamalarda zorlu bir iştir. ZKP, düğümler üzerindeki yükü azaltmak ve tüm sistemin ölçeklenebilirliğini artırmak için kullanılabilir. İşlemlerin geçerliliğini doğrulamak için ZKP'yi kullanarak, düğümlerin tüm işlem geçmişini görüntülemesine gerek kalmaz, böylece depolama ve işleme yükü azalır.Şu anda en yaygın olarak kullanılan ZK Rollup, Ethereum'u ve diğer alanları geliştirmek için tasarlanmış bir ölçeklenebilirlik çözümüdür. Blockchain ağlarının verimi ve verimliliği. Yüksek performanslı merkezi olmayan uygulama (DApps) genişletme çözümleri sağlamak için Rollup ve ZKP teknolojilerinin avantajlarını birleştirir. Geleneksel Ethereum ağında, her işlemin doğrulanması ve blok zincirine kaydedilmesi gerekir; bu da işlem süreçlerinde gecikmelere ve yüksek maliyetlere neden olur. ZK Rollup, çok sayıda işlemi tek bir blokta toplar ve sıkıştırır ve ZKP, işlemlerin doğruluğunu ve güvenliğini sağlamak için toplu işlemlerin geçerliliğini kanıtlamak için kullanılır.

3 Kimlik Doğrulama:

Sıfır bilgi kanıtları, hassas kişisel bilgileri ifşa etmeden bir kullanıcının kimliğini doğrulamak için kullanılabilir. Örneğin bir kişi, kesin yaşını veya diğer tanımlayıcı bilgileri açıklamadan, belirli bir yaş şartını karşıladığını veya belirli bir sertifikaya sahip olduğunu ağa kanıtlamak için sıfır bilgi kanıtlarını kullanabilir.

4 Merkezi Olmayan Depolama:

Sunucu, kullanıcılara verilerinin güvenli bir şekilde saklandığını ve veri içeriğinin sızdırılmadığını kanıtlayabilir.

Genel olarak, **blockchain'in sıfır bilgi kanıtı, gizliliğin korunması, bilgi işlem sıkıştırma ve genişletme, kimlik doğrulama, merkezi olmayan depolama vb. alanlarda geniş uygulamalara sahiptir. Blockchain teknolojisi için daha fazla işlev ve seçenek sunar ve blockchain'in farklı alanlarda geliştirilmesini ve uygulanmasını teşvik eder. **

3. ZKP uygulamalarında çift harcama saldırısı

zk-SNARK (Sıfır Bilgi Özlü Etkileşimsiz Bilgi Argümanı), gerçek bilgiyi açığa vurmadan bir ifadenin gerçekliğini kanıtlayabilen sıfır bilgi kanıtına dayalı bir teknolojidir. Gizliliği ve güvenliği korurken çok kısa sürede kanıt oluşturabilen ve doğrulayabilen çok etkili bir sıfır bilgi kanıt teknolojisidir ve bu nedenle yaygın olarak kullanılmaktadır. Ancak uygulamaların yaygınlaşmasıyla birlikte güvenliği de giderek daha fazla ilgi görmeye başladı. Genel güvenlik açığını kısa bir süre önce keşfettik: doğrulama işlevindeki parametre girişinin değer aralığı ZKP projesinde doğru şekilde doğrulanmazsa, bir saldırgan doğrulamayı geçmek için birden fazla girdiyi taklit edebilir ve bu da çift harcama saldırısına neden olabilir. Bu saldırının etkisi oldukça geniş olup, aralarında groth16, plonk vb.nin de bulunduğu birden fazla zk-SNARK algoritmasını içermektedir ve bu güvenlik açığı, solidity ve js gibi birçok geliştirme dilinde mevcuttur. Bu güvenlik açığı ilk olarak poma tarafından sıfır bilgi kanıtı projesi Semaphore'da keşfedildi ve aşağıdaki şekilde gösterildiği gibi başarıyla uygulanan iki işlem örneği verildi:

Bu güvenlik açığının spesifik saldırı ilkesi, Ethereum'da zk-SNARK kanıtını oluşturmak ve doğrulamak istiyorsanız, aralığı belirlemek için p değerinin kullanıldığı F_p-aritmetik sonlu alan eliptik eğri devresini kullanmanız gerektiğidir. Eliptik eğrinin sonlu alanı, yani devrenin giriş değeri aralığı [0,1,…,p-1]. Farklı eğrilerin farklı p değerleri vardır:

EIP-196'da tanımlanan BN254 eğrisi (ALT_BN128 eğrisi olarak da bilinir):

p = 21888242871839275222246405745257275088548364400416034343698204186575808495617

circom2 iki yeni asal sayıyı, BLS12-381 eğrilerini tanıtıyor:

p = 52435875175126190479447740508185965837690552500527637822603658699938581184513

ve plink2:

18446744069414584321

Semaphore daha sonra güvenlik açığını doğruladı ve düzeltti ve ZoKrates ve snarkjs gibi zk kütüphaneleri de aynı anda acil onarımlar yaptı. Ancak Beosin güvenlik araştırmacıları şu anda bu soruna birleşik bir çözüm olmadığını buldu. Örneğin, Semaphore protokolü eşleştirmeye kısıtlamalar yazıyor kütüphane.Geçerli veri aralığı dış iş mantığında açıkça doğrulanmaz; circom ve Tornado.Cash tarafından oluşturulan sözleşme kodu, doğrulama işlevinde SNARK_SCALAR_FIELD'ı açıkça doğrular.Bu kafa karıştırıcı ve tutarsız bir çözümdür. Birçok yeni zk DApp proje tarafı için sorun ve güvenlik riskleri olduğundan, bu sorunu çözmek için standartlaştırılmış bir yol kullanmayı umuyoruz.

4. ERC-1922'de çift harcama saldırısı

Şu anda Ethereum, zk-SNARK'ı doğrulamak için Doğrulama sözleşmesi standart arayüzünü tanıtan zk ile ilgili bir standart EIP-1922'ye sahiptir. Özel kod aşağıdaki gibidir:

pragma sağlamlığı ^0.5.6;/// @title EIP-XXXX zk-SNARK Doğrulayıcı Standardı/// @dev Bkz. /// Not: Bu arayüz için ERC-165 tanımlayıcısı 0xXXXXXXXX'tir./// ⚠️ YAPILACAKLAR: Arayüzü hesapla identifierinterface ERC1922 /* ERC165'tir */ { /// @notice Eliptik eğri /// eşleştirme fonksiyonları aracılığıyla Kanıtın argümanlarını kontrol eder. /// @dev /// Kanıt tüm kontrolleri geçerse (yani Kanıt /// geçerliyse) doğru döndürmelidir ZORUNLU. /// Kanıt tüm kontrolleri geçemezse (yani /// Kanıt geçersizse) false döndürmelidir ZORUNLU. /// @param kanıtı A zk-SNARK. /// @param girişleri Proof'a eşlik eden genel girişler. /// @param doğrulamaKeyId Kanıtın karşılık geldiği Doğrulama Anahtarı için benzersiz bir tanımlayıcı (bu doğrulayıcı /// sözleşme tarafından bilinir). /// @return result Doğrulama hesaplamasının sonucu. Doğru /// Kanıt geçerliyse; aksi takdirde yanlış. fonksiyon doğrulama(uint256[] çağrı verisi kanıtı, uint256[] çağrı verisi girişleri, bytes32 doğrulamaKeyId) harici dönüşler (bool sonucu);}

Bunlar arasında sıfır bilgi kanıtı kanıtı ve giriş değişken türleri uint256['dır. Bu değişken türü şu anda ZKP algoritmasında en yaygın kullanılan eliptik eğri işlemidir. Ancak ilgili güvenlik koruması bu arayüze eklenmemiştir, bu nedenle çift -harcama saldırıları da mevcuttur. Büyük güvenlik tehlikesi.

5.ERC-7520 Çözümü

Yukarıdaki konulara dayanarak Beosin, bu güvenlik riskini önlemek için EIP-7520'yi önerdi. Spesifik olarak, Ethereum ekosisteminde zk teknolojisini kullanan tüm DApp projelerinin, birleşik ve güvenli standartları kullanmak için bu arayüzü uyumlu doğrulayıcı sözleşmesinde uygulaması gerekir. Yöntem geçerli aralığı gerçekleştirir tüm girişlerde doğrulama Özel arayüz aşağıdaki gibidir:

pragma sağlamlığı ^0.5.6;/// @title EIP-XXXX zk-SNARK genel girişler Doğrulayıcı Standardı/// Not: Bu arayüz için ERC-165 tanımlayıcısı 0xXXXXXXXX'tir./// ⚠️ YAPILACAKLAR: Arayüz tanımlayıcı arayüzünü hesaplayın EIP7520 /* ERC165 ve ERC1922 */ { /// @notice Girişlerin argümanlarının skaler alan içinde olup olmadığını kontrol eder /// @dev /// Girişler aralık kontrolünü geçerse doğru döndürmelidir ZORUNLU (yani Girişler /// geçerlidir). /// Girişler aralık kontrolünü geçemezse (örneğin, /// Girişler geçersizse) false döndürmelidir ZORUNLU. /// @param girişleri Proof'a eşlik eden genel girişler. /// @param p Eğriye eşlik eden genel giriş. function validPublicInput(uint256[] girişler，uint256 p) harici dönüşler (bool sonucu);}

VerifyPublicInput işlevi bu standardın temelini oluşturur. İlgili parametrelerin özel anlamları aşağıdaki gibidir:

• girişler: uint256[] türü olarak tanımlanır; ZKP projesindeki doğrulama işlevinde yer alan genel sinyal parametrelerini temsil eder *p: uint256 tipi olarak tanımlanan bu değer, algoritmada kullanılan eliptik eğrinin p değerine karşılık gelir.

Aşağıda, proje taraflarına yönelik riskleri belirtmek amacıyla bu saldırının farklı tezahürlerini hedefleyerek EIP-7520 arayüzünün uygulanmasına ve uygulanmamasına ilişkin iki durum karşılaştırılacaktır:

1 Doğrulama için bu eip arayüzünün validPublicInput'unu çağırmadan doğrudan doğrulama sözleşme kodunu kullandığımızı varsayalım.Özel kod aşağıdaki gibidir:

fonksiyon doğrulama(uint[] hafıza girişi, Proof hafıza kanıtı) dahili görünüm döndürür (uint) { VerifyingKey hafızası vk = validingKey(); require(input.length + 1 == vk.IC.length,"doğrulayıcı-kötü-giriş"); // Doğrusal kombinasyonu hesaplayın vk_x Pairing.G1Point belleği vk_x = Pairing.G1Point(0, 0); for (uint i = 0; i < giriş.uzunluk; i++) vk_x = Pairing.addition(vk_x, Pairing.scalar_mul(vk.IC[i + 1], input) [i] )); vk_x = Eşleştirme.addition(vk_x, vk.IC) [0] ); if (!Pairing.pairingProd4( Pairing.negate(kanıt.A), kanıt.B, vk.alfa1, vk.beta2, vk_x, vk.gamma2, kanıt.C, vk.delta2 )) return 1; 0 değerini döndür;}

Doğrulamanın geçtiğini kanıtlayan orijinal deney sonuçlarının ekran görüntüsü:

Aynı zamanda, aşağıdaki dört sertifika sahte olabilir ve doğrulamayı geçerek çift harcama saldırısına neden olabilir:

Sahte delillerden biri kullanılarak yapılan doğrulama sonuçları aşağıda gösterilmiştir:

2 Bu eIP'deki validPublicInput arayüzü çağrılırsa, yukarıdaki sahte kanıt doğrulanamayacaktır. Sözleşme kodunun bir kısmı aşağıdaki gibidir. Geri kalan ayrıntılar için lütfen Referans Uygulamaya bakın:

function doğrulamax(uint[] bellek girişleri, Proof bellek kanıtı, bytes32 doğrulamaKeyId,uint256 p) genel dönüşler (uint){ require(verifyPublicInput(inputs,p),"verifier-over-snark-scalar-field"); require(verify(girişler, kanıt, doğrulamaKeyId),"doğrulama başarısız"); return true;}function validPublicInput(uint256[] girişler，uint256 p) dahili görünüm döndürür (bool) { for (uint i = 0; i < input.length; i++) { require(input < p,"verifier-gte-snark) -skaler-alan"); } doğruyu döndür;}

Deney sonuçları aşağıdaki şekilde gösterilmektedir:

Özetle, bu arayüzün genel sinyal değer aralığının geçerliliğini doğrulamak için kullanılmaması durumunda çift harcama saldırıları riskinin olabileceği tespit edilebilir. **