Giriş

Temmuz 2021'de, Nym, ünlü güvenlik uzmanı Jean-Philippe Aumasson tarafından bir güvenlik denetiminden geçti. Amaç, kriptografi, kod güvenliği ve protokol güvenliğine odaklanarak Nym kod tabanındaki olası açıkları ve hataları belirlemekti. Denetimin amacı, sistemin bütünlüğünü ve sağlamlığını güvence altına almak olup, mimarisi ve uygulanışıyla ilgili temel unsurları kapsamaktaydı. Denetimin tamamına buradan ulaşabilirsiniz.

Denetim Özeti

Denetim 2021 yazında gerçekleşti. Denetim kapsamı, Nym projesinin birden fazla deposunu içeriyordu:

• Nym Ana Deposu: nymtech/nym, mixnode, gateway ve validator servislerini içerir.
• Sphinx Mixnet Paket Formatı: nymtech/sphinx, mixnode’lar tarafından kullanılır.
• Coconut Eşikli Kör İmza Protokolü: nymtech/coconut, kimlik bilgisi verme işlemlerinde kullanılır.

Denetim, geliştirme alanındaki en güncel kodun incelenmesini içeriyordu. Hızla gelişen proje yapısı nedeniyle bu alan düzenli olarak güncellenmekteydi. Nym ekibi, JP Aumasson’a kod tabanına tam erişim, detaylı proje dokümantasyonu, araştırma makaleleri ve destekleyici belgeler sağladı.

Denetimin Odak Noktaları

Denetim üç ana başlığa odaklandı: kod güvenliği, kriptografi, ve protokol tasarımı. Denetçiler, güvenlik açıklarını belirlemek amacıyla Nym’in kod tabanını detaylı şekilde inceledi; güvensiz kodlama kalıpları ve hatalı hata yönetimi gibi yaygın sorunlara odaklandılar. Bellek güvenliğine özel önem verildi ve tamsayı taşmaları gibi tuzaklardan kaçınılmaya özen gösterildi.

Kriptografik denetim, Nym tarafından kullanılan AES-128-CTR, BLAKE2b, ChaCha, Ed25519 gibi temel yapıtaşlarını kapsayan geniş bir yelpazeyi içeriyordu. Amaç, bu algoritmaların doğru şekilde uygulanmasını sağlamak ve yan kanal saldırılarına, parametrelerin hatalı kullanımına ve rastgelelik üretimindeki zayıflıklara karşı dayanıklılığını doğrulamaktı.

Bireysel bileşenlerin incelenmesinin yanı sıra, denetim aynı zamanda Nym'in temel işlevselliğini tanımlayan protokolleri de inceledi. Bu, gizlilik veya güvenliği tehlikeye atabilecek herhangi bir zayıflığı belirlemek amacıyla Sphinx paket formatı ve Coconut eşik kör imza protokolünün incelenmesini içeriyordu. Denetim, kullanıcı anonimliğini tehdit eden olası bilgi sızıntılarına, ayrıca MAC doğrulama atlamaları, küçük alt grup saldırıları ve BLS12-381 aritmetiği ile sıfır bilgi kanıtları gibi kriptografik işlemlerdeki hatalar gibi güvenlik açıklarına odaklandı.

Bulguların Genel Değerlendirmesi

Denetim sırasında dokuz güvenlik açığı tespit edildi. Hiçbiri kritik olarak değerlendirilmedi, ikisi yüksek, biri orta, ve altısı düşük olarak derecelendirildi. Ayrıca, Nym ağına daha fazla güçlendirme önerileri sunan 17 gözlem yapıldı. Aşağıda, tespit edilen tüm güvenlik açıklarını gidermek için uygulanan düzeltmelerin bir özeti sunulmaktadır.

S-SPHX-01: Anahtarların Eksik Doğrulamaları (Düşük)

nymtech/sphinx'teki özel ve genel anahtarların yetersiz doğrulamasıyla ilgili tespit edilen sorun, x25519 kütüphanesine geçilerek çözülmüştür. Bu kütüphane, tasarımı sayesinde anahtar geçerliliğini doğrudan uygular. x25519 uygulaması, özel anahtarların doğru şekilde "clamp" edilmesini sağlar, yani geçerli bir skalar alt kümesine otomatik olarak sınırlandırılır ve geçersiz özel anahtarların kullanılma riski ortadan kaldırılır. Ayrıca, x25519 açıkça genel anahtarları doğrulamasa da, Montgomery merdiveni uygulaması, belirli geçersiz eğri noktalarının kullanılmasını engeller. Bu, sonsuzdaki noktalar veya başka hatalı genel anahtarlar gibi sorunları önler. Ayrıca, anahtar değişim süreci, gerekirse sıfır olan bir paylaşılan gizlinin tespit edilip reddedilmesini sağlar. x25519'in kullanılmasıyla, anahtar doğrulama önemli ölçüde iyileştirilmiş ve sistemde geçersiz veya yanlış formatlanmış anahtarların kullanılma riski azaltılmıştır. Bu, denetimdeki anahtar doğrulama konusundaki endişeleri etkili bir şekilde çözmüştür.

S-COCO-01: Hash-to-scalar Bağımlı Dağılım (Düşük)

BLS12-381 alanında bir skalar türetmek için kullanılan hash işlemi, daha önce bir hash fonksiyonu çıktısını doğrudan bir skalar alan öğesine eşlemek suretiyle yapılmaktaydı. Ancak bu yaklaşım, modüler indirgeme işlemi (mod p) nedeniyle bias (sapma) oluşturuyordu. Bu durum, hash çıktısı alanın asal modülüyle tam olarak hizalanmadığında, dağılmanın düzgün olmamasına yol açabiliyordu. Bu sorunu çözmek için, mevcut hash-to-scalar fonksiyonunu, bls12_381 crate'inden hash_to_field fonksiyonu ile değiştirdik. Bu fonksiyon, standartlaşmış hash-to-field spesifikasyonunu takip eder ve hash çıktılarının alan öğelerine düzgün ve tarafsız bir şekilde eşlenmesini sağlar. Ayrıca, Coconut protokolünün yerine geçen zk-Nym protokolü de, kriptografik işlemlerinde tutarlılık ve doğruluk sağlamak için bu fonksiyonu kullanmaktadır.

S-COCO-02: keygen-cli Anahtar Dosyalarının İzinleri (Düşük)

Denetçiler, keygen-cli anahtar dosyalarının varsayılan izinlere sahip olduğunu ancak daha iyi güvenlik için daha kısıtlayıcı izinlere sahip olmaları gerektiğini belirtti. Bu sorun herhangi bir değişiklik gerektirmemiştir çünkü keygen-cli yalnızca Coconut uygulamamızın ilk aşamalarında kullanıldı. Artık ana Nym deposunun bir parçası değildir ve aktif olarak kullanılmamaktadır. Bu araç geçerliliğini yitirdiğinden, dosya izinleri ile ilgili daha fazla işlem yapılması gerekmemektedir.

S-CRYP-01: Potansiyel Akış Şifreleme IV Yeniden Kullanımı (Yüksek)

Bu sorun, bir başlatma vektörü (IV) kullanarak veriyi şifreleyen bir fonksiyonla ilgilidir. Eğer IV sağlanmazsa, fonksiyon sıfır IV kullanmayı varsayar, bu da IV yeniden kullanımına yol açabilir. Bu sorun, kayıt aşamasında AES-GCM-SIV protokolünün eklenmesiyle çözülmüştür. Gerileme saldırılarını önlemek amacıyla, istemci ve geçit arasındaki iletişimde eski AES-128-CTR anahtarının kullanılma seçeneği kaldırılmıştır. Hem istemci hem de geçit güncellenmiş olduğu sürece, her zaman rastgele ve sıfır olmayan bir IV (başlatma vektörü) üretilecektir.

S-PROT-01: Potansiyel Çift Harcama Sorunu (Yüksek)

Denetçiler, incelenen Coconut sürümünde çift harcama tespiti mekanizmasının eksik olduğunu fark etti. Bu durum, birden fazla geçidin aynı anda bir kimliği hatalı bir şekilde kullanılmamış olarak doğrulamasına yol açabilirdi. Ancak, Coconut bant genişliği sözleşmesi daha sonra, kimlik kullanımını zincir üzerinde durum kaydederek izlemeyi sağlayacak şekilde güncellendi ve bu sorun çözüldü. Ayrıca, Coconut protokolü yerini zk-nyms protokolüne bıraktı ve bu yeni protokol, yerleşik çift harcama tespiti işlevselliği sunuyor.

S-NYM-01: Bilinen Güvenlik Açıkları İçeren Bağımlılıklar (Orta)

Denetçiler, Nym projesindeki birkaç bileşenin, bilinen güvenlik açıklarına sahip eski bağımlılık sürümlerine dayandığını tespit etti. Örneğin, Sphinx deposu, güvenli olmayan bir generic-array crate sürümünü kullanıyordu, Nym’in ana deposu eski bir tokio sürümüne dayanıyordu ve Nym istemcisi, bazıları Nym bağlamında potansiyel olarak sömürülebilir bilinen güvenlik sorunlarına sahip birkaç crate içeriyordu. Denetçilerin önerisi doğrultusunda, bağımlılıklar düzenli olarak güncellenmiştir. Şimdi, bağımlılıkları aktif olarak Dependabot ile yönetiyoruz, bu araç sürekli olarak eski veya güvenlik açığı içeren paketleri izler ve otomatik olarak tespit eder. Depomuzda uygulanan Dependabot düzeltmelerini sürekli olarak takip edebilirsiniz.

S-NYM-02: Şifre Çözme Hatasının Yönetilmemesi (Düşük)

Koddaki sorun, nym/common/nymsphinx/acknowledgments/identifier.rs dosyasındaki recover_identifier fonksiyonunda tespit edilmiştir. Burada, geçersiz parametreler gibi şifre çözme hataları doğru bir şekilde yönetilmemekteydi. Bu da panik veya diğer güvensiz durumlara yol açabilirdi. Benzer bir sorun, nym/common/nymsphinx/src/receiver.rs dosyasındaki recover_plaintext fonksiyonunda da bulunuyordu. Şifre çözme hatalarının yönetilmemesi, sistemin kararsız veya güvensiz bir duruma girmesine yol açabilirdi. Fonksiyonlar dikkatlice incelendiğinde, recover_identifier örneğinin bir sorun oluşturmadığı sonucuna varıldı. Yanlış parametrelerin sağlanması imkansızdır, çünkü her şey AckEncryptionAlgorithm (bağlantı) ile parametrize edilmiştir, bu da geçersiz değerlerin derleme aşamasında yakalanacağı anlamına gelir. İkinci örnek olan recover_plaintext artık mevcut değildir. Ancak, bunun yerine geçen kod olan recover_plaintext_from_regular_packet, teorik olarak bazı parametrelerin olağan dışı değerlere değiştirilmesi durumunda hata verebilir. Bu durumu, doğru hata yönetimi ekleyerek çözdük ve sistemin istikrarlı kalmasını sağladık, hatta kenar durumlarında bile.

S-NYM-03: Fragman ID'lerinin Üretilmesinde Panik (Düşük)

Yeni fragman ID'leri üretmek için kullanılan kod, rastgele bir i32 değeri seçer ve mutlak değerini alır. Ancak bu yaklaşım, rastgele seçilen değer i32::MIN olduğunda panik oluşmasına yol açabilir, çünkü mutlak değeri i32 sınırları içinde temsil edilemez. Bu durum, 2-complement kodlamasının sınırlamaları nedeniyle 'overflow ile negatif alma girişimi' hatasına yol açar. Bu sorunla ilgili ciddiyet derecesinin çok düşük olduğunu kabul ediyoruz, çünkü bu durumu karşılamanın olasılığı yaklaşık 4 milyarda 1'dir. Ancak, bu durumu çözmek için denetçilerin önerdiği düzeltmeyi uyguladık ve potansiyel paniklerin ve beklenmeyen çöküşlerin önlenmesini sağladık, özellikle milyonlarca kullanıcının binlerce fragman ID'si üretmesi durumunda.

S-NYM-04: Mnemonic Sıfırlanmadı (Düşük)

Tespit edilen sorun, nymd servisine bağlanmak için kullanılan BIP39 mnemoniklerinin kullanım sonrası sıfırlanmadığını gösteriyordu, bu da mnemoniklerin bellekte birden fazla kopyasının kalmasına neden oluyordu. Bu durum, mnemonic'lerin ham kriptografik anahtarlardan daha kolay tespit edilebilmesi nedeniyle, sızıntı riskini artırıyordu. Bu sorunu çözmek için birkaç önlem uyguladık. Rust bileşenlerinde, mnemonic içeren belleğin kapsam dışına çıktığı anda güvenli bir şekilde silinmesini sağlamak için zeroize crate'ini entegre ettik. JavaScript, çöp toplayıcılı bir dil olduğu ve doğrudan bellek yönetimi sağlamadığı için, JavaScript çalışma zamanında sızıntıyı azaltmak için farklı bir yaklaşım benimsedik. Özellikle, sistemin mnemonic Rust katmanına iletilmeden önce JavaScript çalışma zamanının sonlandırılacak şekilde değiştirildi. Bu, JavaScript bellek içindeki tüm mnemonic örneklerinin çalışma zamanı kapandığında silinmesini sağlar. Mnemonic, Rust katmanına mümkün olan en erken aşamada iletilir, bu da JavaScript'teki maruziyeti azaltır. Rust içinde, zeroize, mnemonic artık gerekli olmadığında tüm örneklerinin güvenli bir şekilde silinmesini sağlar. Bu değişikliklerle, mnemonic'lerin bellekteki varlığını önemli ölçüde azalttık ve sızıntı riskini en aza indirdik, böylece hassas verilerin güvenli bir şekilde yönetilmesini ve silinmesini sağladık.

Son Sözler

Bu denetim süreci boyunca gösterdiği uzmanlık ve özveri için JP Aumasson'a teşekkür ederiz. Ayrıca denetimin planlama ve yürütme aşamalarında gösterilen iş birliği ve profesyonellik için de minnettarız. Güvenliğe olan bağlılığımız en yüksek önceliğimiz olmaya devam ediyor ve ekosistemimizde en yüksek standartları korumak için güvenlik uzmanlarıyla olan iş birliklerimizi sürdürmeyi dört gözle bekliyoruz.