Güvenlik Denetimi (Jean Philippe Aumasson tarafından)

Ergo'nun belirli (en kritik) kod parçalarının güvenlik denetimini başarıyla geçtiğini duyurmak istiyoruz. Bu sefer denetim Jean-Philippe Aumasson (aka veorq, https://aumasson.jp/) tarafından yapıldı.

Aşağıda detaylı rapor bulunmaktadır. Kritik bir sorun bulunmamıştır. Bulunan sorunlarla ilgili yorumlar:

1. Cüzdan parolası ile ilgili, protokol istemcisinin bir sonraki sürümlerinde bir öneri sunacağız. Parolanın zorunlu olarak uygulanıp uygulanmayacağı konusunda emin değiliz, ancak bu konuda daha fazla danışma yapacağız.
2. "n" ve "k" parametrelerini değiştirmek yalnızca yeni bir ağ başlatıldığında mantıklıdır. Bu parametrelerin madencilik düğümünde değiştirilmesi, diğer düğümler için üretilen blokların geçersiz olmasına neden olacaktır. Protokol istemcisindeki bu parametrelerin değiştirilmesi, başka bir çatala gitmek anlamına gelir (dürüst protokol katılımcılarından gelen bloklar reddedilecektir). Bu nedenle, belki de ekstra kontrol gerekmiyor, çünkü yeni ağlar başlatan insanlar "n" ve "k"'yı doğru bir şekilde ayarlayacaklardır.
3. Şu anda Ergo düğümü (bilgimiz dahilindeki diğer blockchain protokol istemcileri ve cüzdanlar ile birlikte, kullandığımız kriptografik kütüphaneler de dahil) yerel olarak çalışan yan kanal saldırılarına karşı koruma sağlamamaktadır (örneğin, zamanlama saldırıları veya kötü amaçlı yazılımlar veya virüsler tarafından bellek denetimi). Bu nedenle, cüzdanları çalıştırdığınız makineleri koruyun!

==========================================================================================================

% Ergo güvenlik değerlendirmesi % Jean-Philippe Aumasson % 07/Aralık/19

Özet

Ergo, Ergo Platformlarının birkaç bileşeninin güvenlik değerlendirmesini gerçekleştirmemiz için bize başvurdu:

• Sigma protokolü kanıtlarının oluşturulması ve doğrulanması
• Cüzdanın gizli bilgilerin güvenli depolanması
• İş Kanıtı doğrulaması

​Bu kısa rapor, değerlendirmemizi özetlemekte ve bulgularımızı ve azaltma önerilerimizi tanımlamaktadır.

Sigma protokolü kanıtları

​Ergo protokolü, sigma ifadelerini destekleyen bir betik dili olan ErgoScript'e dayanır ve bu ifadeler, etkileşimsiz bilgi kanıtları aracılığıyla kanıtlanabilir ve doğrulanabilir.

Bu kanıtlar, yaprakları ayrık-logaritma probleminin bilgi kanıtları olan AND, OR ve eşik koşullarından oluşan bir ağaç olarak tanımlanan ifadelerdir.

Sigma ifadesinin kanıtı, Fiat-Shamir dönüşümü sayesinde etkileşimsiz hale getirilir.

Bu mantık, ErgoScript belgesinde belirtilmiştir ve özel kanıtlama ve doğrulama rutinleri Ek A'da tanımlanmıştır.

​Uygulama zorlukları şunlardır:

• Kanıtların güvenli ve verimli bir şekilde kodlanmasını tanımlamak ve her zaman geçerli girişi işleme konusunda başarılı olan ve her zaman geçersiz girişi işleme konusunda nazikçe başarısız olan serileştirme ve serileştirmeyi uygulamak.
• Kanıtlama ve doğrulama işlevlerini doğru bir şekilde uygulamak, spesifikasyona uygun olarak ve en önemlisi geçersiz bir ifadenin doğrulamadan geçemeyecek şekilde uygulanmasını sağlamak.

Bu iki yönü, sigmastate-interpreter deposundaki kod ve ErgoScript belgesi temelinde gözden geçirdik ve amaçlanan davranışı (Ek A'da) uygulanan gerçek davranışla dikkatlice karşılaştırdık.

​Özellikle SigSerializer, Interpreter ve ProverInterpreter özellikleri ve nesneleri üzerinden kodu gözden geçirdik.

​Aşağıdaki sınıflardan hatalar aradık:

• Bozuk girdi işleme konusunda güvensiz
• Olağandışı uzun veya kısa girdi işleme konusunda güvensiz
• Büyük ağaç derinliği veya özyineleme seviyesi durumunda davranış
• Scala türleri ve yapılarının güvensiz kullanımı
• Uygun olmayan değişken türleri
• Tam sayı taşmaları
• Yarış koşulları
• Mantık hataları

​Kapsamlı incelemeye rağmen, herhangi bir güvenlik sorunu tespit edemedik.

Protokolün mantığı ve iç yapıları yine de oldukça karmaşık olup, en yüksek riskin kanıtların ayrıştırılması ve doğrulanmasında olduğunu düşünüyoruz. Ancak, bu tür sorunları istismar etmek için bir saldırganın, bir şekilde kendisine fayda sağlayan, ancak doğrulamadan geçmesi gereken anlamlı bir betik oluşturması gerekecektir.

Yazılım güvenliği açısından, Scala belirli hata sınıflarını ortadan kaldırır, ancak Scala kodu hala Scala'nın belirli davranışları veya ele alınmamış hatalar nedeniyle hatalardan muzdarip olabilir.

Cüzdan

Ergo'nun cüzdan işlevselliği, kullanıcılarının diskte bir gizli bilgi saklamasına ve bunu geri almasına olanak tanır, cüzdan ilk kullanıldığında yeni bir tohum ile başlatılır.

​Bu mantık esasen ErgoWalletActor içinde tanımlanmıştır ve gizli bilgilerin depolanmasıyla ilgili önemli bir bileşen JsonSecretStorage dir.

​Bir cüzdan ilk kez oluşturulduğunda, InitWallet komutu aşağıdakileri yapar:

• Başlangıç entropisi olarak settings.walletSettings.seedStrengthBits rastgele bitler üretir. Varsayılan olarak, 160 bit üretilir.
• Üretilen rastgele bitlerden bir BIP39 oluşturur, bu da entropi bitlerinin bir kodlaması olarak görülebilir. Standart BIP39 mantığı kullanılır, isteğe bağlı parolayla.
• Mnemonikten bir tohum türetir, BIP39'un PBKDF2 tabanlı türetme mantığını kullanarak.
• Bu tohumu diske AES-GCM ile şifreler, rastgele bir nonce kullanarak ve paroladan türetilen bir anahtar kullanarak PBKDF2-HMAC-SHA256 ile 128000 yinelemesi ile, rastgele bir tuz kullanarak.

Zaten oluşturulmuş bir cüzdanı açmak için, bir kullanıcı parolayı sağlar ve cüzdan saklanan verileri çözmeye çalışır.

​Mevcut bir hesabı bir BIP39 parolası ile geri yüklemek için, başlatma ile benzer bir işlem gerçekleştirilir, ancak cüzdan rastgele bir mnemonik seçmek yerine mnemonikten tohumu türetecektir.

​Burada tanımladığımız iki risk şunlardır:

• Parolanın uzunluğu üzerinde kontrollerin olmaması: çünkü parola, cüzdanın diskte saklanan gizli bilgisine erişmek için yeterlidir, parolanın teorik olarak mnemonik kadar en az entropiye sahip olması ve pratikte kırılması zor olması gerekir. Bu nedenle, en az 16 karakterlik bir parola uzunluğu zorunluluğu getirilmesini öneriyoruz.
• Gizli değerlerin (parola, tohum ve türetilmiş özel anahtarlar) cüzdan yazılımı çalıştırıldıktan sonra bellekte kalma olasılığı yüksektir, bu da Scala gibi çöp toplayıcı dillerin içsel bir sınırlamasıdır.

Aynı bellek adres alanını paylaşan başka bir işlem veya kullanıcı, gizli bilgileri geri kazanabilir ve bu bilgiler çökme dökümlerinde de görünebilir. Bildiğimiz kadarıyla, saf Scala'da etkili bir azaltma yoktur.

​

PoW doğrulaması

​Önceki Autolykos PoW güvenliğini gözden geçirdikten sonra, en son doğrulama mantığına odaklanan bir başka gözden geçirme turu gerçekleştirdik ve özellikle eb0f85a commitindeki değişiklikleri inceledik.

​Ana ilgili dosya AutolykosPowScheme dir ve diğer önemli işlemler örneğin HeadersProcessor ve ModifierValidator içinde uygulanmıştır.

​Uygulanan doğrulama mantığının Autolykos spesifikasyonlarında belirtilenle tutarlı olduğunu ve blok başlığı doğrulama mantığına düzgün bir şekilde entegre edildiğini kontrol ettik.

​Aşağıdaki noktaların ele alınması gerektiğine inanıyoruz:

• k ve n için daha sıkı doğrulama: sınıf k<=32 (çözümdeki eleman sayısı) ve n<31 (toplam eleman sayısının log2'si) zorunlu kılmasına rağmen, yetkilendirilmiş parametrelerden zayıf bir çözüm hala oluşturulabilir. Bu nedenle, validate() fonksiyonu, n ve k'nın hedeflenen değerlere eşit olduğunu ek bir doğrulama yapabilir.
• k ve n'nin pozitif değerler olduğunu doğrulamak, çünkü şu anda negatif olanlar (Int olarak) assert ifadelerini geçebilir.