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 şifresi konusunda, protokol istemcisinin bir sonraki sürümlerinde bir öneri sunacağız. Şifrenin zorunlu olarak uygulanıp uygulanmayacağından 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" değerlerini 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ıtlamayı ve doğrulamayı doğru bir şekilde, spesifikasyona uygun olarak ve en önemlisi geçersiz bir ifadenin doğrulamadan geçemeyecek şekilde uygulamak.

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:

• ​Kötü biçimlendirilmiş girdi işleme
• Olağandışı uzun veya kısa girdi işleme
• Büyük ağaç derinliği veya özyineleme seviyesi durumunda davranış
• Güvenli olmayan Scala türleri ve yapıları 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 depolaması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ığı, isteğe bağlı şifre ile kullanılır.
• Mnemonikten bir tohum türetir ve BIP39'un PBKDF2 tabanlı türetme mantığını kullanır.
• Bu tohumu diske AES-GCM ile şifreler, rastgele bir nonce kullanır ve şifreyi PBKDF2-HMAC-SHA256 ile 128000 yinelemesi ile türetilen bir anahtar kullanarak rastgele bir tuz ile şifreler.

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

​Mevcut bir hesabı bir BIP39 şifre ifadesinden 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:

• Şifrenin uzunluğu üzerinde kontrol eksikliği: Şifre, cüzdanın diskte depolanan gizli bilgilerine erişmek için yeterli olduğundan, teorik olarak şifrenin en az mnemonik kadar entropiye sahip olması ve pratikte kırılması zor olması gerekir. Bu nedenle, en az 16 karakterlik bir şifre uzunluğu zorunluluğu getirilmesini öneriyoruz.
• Gizli değerlerin (şifre, tohum ve türetilmiş özel anahtarlar) cüzdan yazılımı çalıştırıldıktan sonra bellekte kalma olasılığı, 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şikliklere dikkat ettik.

​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, yetkili parametrelerden zayıf bir çözüm hala oluşturulabilir. Bu nedenle, validate() fonksiyonu, n ve k değerlerinin hedeflenen değerlere eşit olduğunu doğrulamak için ek doğrulama içerebilir.
• k ve n değerlerinin pozitif değerler olduğunu doğrulamak, çünkü şu anda negatif olanlar (Int olarak) assert ifadelerini geçebilir.