Güvenli Saklamanın Ötesinde, 2. Bölüm: Cüzdan Kriptografisini Güvenli Biçimde Uygulamak

Beyond Secure Storage yazısının 1 numaralı bölümü, bir ödeme sisteminin kendi imzalama yeteneğinin kötüye kullanılmasını incelemişti. Bu ikinci bölüm, yetkisiz imza elde etmenin farklı bir yolunu inceliyor: saldırganın özel anahtarı elde edip bağımsız olarak imza atmasına olanak tanıyan kriptografik uygulama kusurları. Soru şu: Bir saldırgan, anahtarın koruma altındaki kopyasını okumadan anahtarı yeniden oluşturabilir mi?

1 numaralı bölüm, anahtar oluşturma, saklama ve imzalama için güvenlik gereksinimlerini ortaya koyuyor. 2 ve 3 numaralı bölümler, dört anahtar oluşturma ve iki imzalama olayını inceleyerek uygulama hatalarını ve sonuçlarını açıklıyor. 4 numaralı bölüm, bu olaylardan tasarım ve uygulama ilkeleri çıkarıyor, ardından gerekli özelliklerin nasıl doğrulanacağını açıklıyor.

1. Anahtar Yaşam Döngüsü Boyunca Güvenlik Özellikleri

Bir anahtar oluşturulmalı, saklanmalı ve imzalama için kullanılmalıdır. Şemanın gösterdiği gibi, her aşamanın farklı bir güvenlik gereksinimi vardır.

BIP-39 anımsatıcı ifadelerini ve BIP-32 anahtar türetimini kullanan hiyerarşik deterministik bir cüzdanda, kriptografik açıdan güvenli rastgele veriler bir anımsatıcı ifadeye kodlanır ve bir tohuma dönüştürülür. Bu tohum, özel anahtarların, açık anahtarların ve cüzdan adreslerinin türetilmesinde kullanılır [1, 2].

Tohumlar ve özel anahtarlar oluşturulduktan sonra şifreleme veya donanım yoluyla yalıtılarak korunmalıdır. İmzalama işleminde ise özel anahtar kullanılarak herkesin doğrulayabileceği bir imza üretilir. Kullanılan yönteme bağlı olarak, güvenli biçimde üretilmiş rastgele bir nonce ya da gizli materyalden deterministik olarak türetilmiş bir nonce da gerekebilir.

Bu aşamalardaki güvenlik gereksinimleri farklıdır:

1. Oluşturma sırasında öngörülemezlik. Saldırgan, cüzdanı kontrol eden gizli değeri tahmin edememeli veya olası değerlerini uygulanabilir bir çabayla tek tek deneyememelidir.
2. Saklama sırasında gizlilik. Yetkisiz taraflar; yazılım, fiziksel arayüzler, yedekler, günlükler veya uzak hizmetler üzerinden gizli materyali okuyamamalıdır.
3. Kullanım sırasında bilgi sızmaması. Herkesin görebildiği çok sayıda imzadan sonra bile imzalama işlemi, gizli değerin yeniden oluşturulmasına yetecek kadar bilgi açığa çıkarmamalıdır.

Donanım cüzdanları, güvenli öğeler ve güvenilir yürütme ortamları (TEE'ler) gizliliği güçlendirebilir. Ancak bunların varlığı tek başına diğer iki özelliği sağlamaz. Öngörülebilir bir anahtar, güvenli depolamaya konulduktan sonra da öngörülebilir kalır; imzaların açığa çıkardığı matematiksel bilgiler, özel anahtarın baytları ana sistemden yalıtılmış olsa bile erişilebilir olmaya devam eder. Dolayısıyla saldırgan, saklanan kopyayı okumadan etkilenen bir anahtarı elde edebilir ve anahtarın kontrol ettiği varlıklara erişebilir.

Sonraki iki bölüm, uygulamaların bu gereksinimleri nasıl ihlal ettiğini inceliyor: oluşturma kusurları anahtarları öngörülebilir kılabilirken, imzalama kusurları anahtarların açık imzalardan elde edilmesine yol açabilir. Bu olaylar, 4 numaralı bölümdeki uygulama ilkelerine ve doğrulama hedeflerine temel oluşturuyor.

2. Kusurlu Anahtar Oluşturma: Öngörülebilir Özel Anahtarlar

Anahtar oluşturma süreci, her adımda öngörülemezliği korumalıdır. Entropi kaynağı kriptografik kullanıma uygun olmalı, durumunun olası değerleri pratikte tek tek denenememeli ve rastgele baytların bir tohuma veya özel anahtara dönüştürülmesi amaçlanan belirsizliği korumalıdır. 128 bitlik bir güvenlik hedefi, uygulama kusurları nedeniyle uygulanabilir bir aramaya indirgenemeyecek bir gizli değer uzayı gerektirir.

Tablo, oluşturma sürecinin bu özelliği dört şekilde nasıl kaybedebileceğini özetliyor: zayıf bir kütüphane üreteci, hatalı bir rastgele sayı üreteci (RNG) bağlantısı, bilgi kaybına yol açan bir girdi dönüşümü ve sınırlı başlangıç durumuna sahip bir üreteç. Etki rakamları farklı dönemleri kapsayan raporlardan alınmıştır; aynı tarihte ölçülmüş toplamlar değildir.

2,1 Ill Bloom: Bir Cüzdan Bağımlılığında Zayıf Rastgelelik

Ill Bloom olayında bazı yazılım cüzdanları, crypto-js kütüphanesinin güvenlik açığı içeren sürümlerini kullanarak BIP-39 kurtarma ifadeleri oluşturdu. Kütüphanedeki CryptoJS.lib.WordArray.random(), kriptografik açıdan güvenli bir kaynaktan entropi almak yerine Math.random() ile başlatılan özel bir Multiply-With-Carry (MWC) üreteci kullanıyordu. Bu işlevi güvenlik açısından kritik bir entropi kaynağı olarak kullanan cüzdanlar, sonraki anımsatıcı ifade ve anahtar türetme adımları ilgili standartlara doğru biçimde uysa bile üretecin zayıflıklarını devraldı [3].

Güvenlik açığı içeren crypto-js v3.1.9-1 uygulaması [4] şu karakteristik mantığı içerir:

  random: function (nBytes) {
      var words = [];

      var r = (function (m_w) {
          var m_w = m_w;
          var m_z = 0x3ade68b1;
          var mask = 0xffffffff;

          return function () {
              m_z = (0x9069 * (m_z & 0xFFFF) + (m_z >> 0x10)) & mask;
              m_w = (0x4650 * (m_w & 0xFFFF) + (m_w >> 0x10)) & mask;
              var result = ((m_z << 0x10) + m_w) & mask;
              result /= 0x100000000;
              result += 0.5;
              return result * (Math.random() > .5 ? 1 : -1);
          }
      });

      for (var i = 0, rcache; i < nBytes; i += 4) {
          var _r = r((rcache || Math.random()) * 0x100000000);

          rcache = _r() * 0x3ade67b7;
          words.push((_r() * 0x100000000) | 0);
      }

      return new WordArray.init(words, nBytes);
  }

Burada r(), MWC tabanlı özel üreteçtir; Math.random() ise üretecin durumunun başlatılmasına veya etkilenmesine katkıda bulunur. Bu sözde rastgele sayı üreteci (PRNG), sıradan entropi gibi görünen baytlar üretir; ancak uygulama kriptografik öngörülemezlik sağlamıyordu. Etkin aday uzayları, nominal 128 bitlik çıktı için yaklaşık 2 USD^{39}$,nominal256bitlik\stackrel{\backslash c}{c}\mathrm{ı}kt\mathrm{ı}i\stackrel{\backslash c}{c}inseyakla\stackrel{\backslash c}{s}\mathrm{ı}k2US{D}^{47},\; nominal\; 256\; bitlik\; çıktı\; içinse\; yaklaşık\; 2\; USD^\{47\}$ idi [3].

Bu daha küçük uzaylar, olası kurtarma ifadelerinin yeniden oluşturulmasını, bunlara karşılık gelen cüzdan adreslerinin türetilmesini ve adreslerin herkese açık blokzincir faaliyetleriyle eşleştirilmesini uygulanabilir kıldı. Böylece gizli değer, mağdurun cihazından hiçbir şey çıkarılmadan elde edilebilirdi. Anımsatıcı ifade standardına uymak, eski bağımlılıktan devralınan zayıf rastgeleliği düzeltemezdi.

2,2 Coldcard: Kodun Kullanmadığı Bir Donanım Rastgele Sayı Üreteci

Coldcard, uygulama farklı bir üreteci çağırıyorsa güvenli bir rastgelelik kaynağına sahip olmanın neden yeterli olmadığını gösteriyor. Cihazda bir donanım rastgele sayı üreteci bulunmasına rağmen, derleme aşamasındaki bir entegrasyon hatası, tohum oluşturma yolundaki rng_get() çağrısının bunun yerine MicroPython’ın yazılımsal sözde rastgele sayı üreteci (PRNG) Yasmarang’a yönelmesine neden oldu. Kriptografik amaçlara uygun olmayan bu PRNG, cihazın sabit benzersiz kimliği ve sınırlı zamanlama bilgileri kullanılarak tohumlanıyordu. Bu da başlangıç durumunu, oluşturulan cüzdan tohumlarının etkin entropisini ciddi ölçüde azaltacak kadar öngörülebilir kılıyordu [5].

Tohum oluşturma yordamı ayrıca ikinci bir Yasmarang üretecinin çıktısını da karıştırıyordu. Eski Mk2/Mk3 cihazlarında bu ikinci üreteç, herkese açık sabitlerden başlıyor ve ek entropi sağlamıyordu. Daha yeni modellerde ise güvenli öğelerden gelen rastgelelik kullanılmaya başlanmış olsa da yeniden tohumlama sırasında yalnızca 32 bit korunuyordu. Dolayısıyla 256 bitlik cüzdan tohumları üretilmesine rağmen etkin arama uzayı büyük ölçüde daralmıştı. Coinkite, belirttiği saldırı varsayımları altında Mk2/Mk3 için yaklaşık 2 USD^{40}$,Mk4\mathrm{/}Q\mathrm{/}Mk5i\stackrel{\backslash c}{c}inise2US{D}^{72},\; Mk4/Q/Mk5\; için\; ise\; 2\; USD^\{72\}$ aday olduğunu ön tahmin olarak açıkladı [6, 7].

Bu zayıflık, tohumun ele geçirilmesini çevrimdışı bir arama problemine dönüştürdü: Saldırgan, aday tohumlardan adresler türetip bunları herkese açık blok zinciri verileriyle karşılaştırabilirdi. Uygulamadaki maliyet modele ve saldırı varsayımlarına bağlıdır; 2 USD^{72}$ tahmini, 2 USD^{40}$ durumuyla aynı uygulanabilirlik düzeyini ifade etmez. Başarılı bir eşleşme, ilgili özel anahtarları açığa çıkarır.

2.3 XRPH Wallet: Anahtar Uzayını Daraltan Bir Girdi Biçimi Hatası

Oluşturma süreci, rastgele çıktının bir cüzdan API’sinin beklediği girdiye dönüştürülmesini de içerir. XRPH Wallet’ta bu dönüşüm, üretilen girdinin büyük bölümünü atıyordu. Android uygulaması, JavaScript Math.random() ile ondalık sayı blokları oluşturuyor, bunları bir metin dizisinde birleştiriyor ve bu diziyi Wallet.fromEntropy() işlevine iletiyordu. Girdiyi alan kod, karakterleri küçük tamsayı bayt değerleri olarak yorumluyor ve yalnızca ilk 16 konumu koruyordu. İki konumda sabit boşluk ayraçları bulunduğundan, ortaya çıkan cüzdanın entropisine yalnızca 14 değişken ondalık rakam katkıda bulunuyordu [8].

padlock = { A, B, C, D, E, F, G, H };     // each = 6 digits from the line above
r6 =  A.join('') + ' ' + B.join('') + ' ' + C.join('') + ' ' + D.join('')
    + ' ' + E.join('') + ' ' + F.join('') + ' ' + G.join('') + ' ' + H.join('');
r5 = Wallet.fromEntropy;
r3 = r5.bind(Wallet)(r6);                 // a 55-char STRING is passed; fromEntropy wants 16 bytes

// compute entropy be like
const input = "528875 921568 528239 ...";  // decimal blocks
const entropy = Uint8Array.from(input).slice(0, 16);
// Result: [5,2,8,8,7,5,0,9,2,1,5,6,8,0,5,2]

Bu dönüşüm sonucunda erişilebilir cüzdan girdilerinin sayısı yaklaşık 10 USD^{14}\approx 2^{46}$ düzeyinde kaldı; oysa eşit olasılıkla örneklenen 16 baytlık entropi için amaçlanan uzay yaklaşık 2 USD^{128}$ düzeyindeydi. Bu sayı, gözlemlenen dönüşüm altında erişilebilir adayları tanımlar; Math.random() işlevinin istatistiksel entropisine ilişkin kriptografik bir kanıt değildir.

İki hata birbirinin etkisini artırdı: uygun olmayan bir rastgelelik kaynağı ve API sınırındaki bir gösterim/kodlama hatası. Cüzdan yine de makul görünen adresler oluşturduğu ve geçerli işlemleri imzaladığı için her iki hata da işlevsel testlerden kaçabilir. Kamuya açık inceleme, anahtarların ele geçirilebileceği bir uzay bulunduğunu ortaya koyuyor; ancak saldırganın anahtarı elde etmek için hangi yolu kullandığını tek başına kanıtlamıyor.

2,4 Qubic Wallet: 55 Karakterlik Bir Tohumun Ardındaki Zayıf Rastgelelik

Çıktı dizisi ne kadar uzun görünürse görünsün, üretecin başlangıç durumu da olası tohumları sınırlayabilir. Qubic bu sorunu örnekliyor: Bildirilen cüzdan ihlalinde, JavaScript’in kriptografik amaçlara uygun olmayan Math.random() işleviyle oluşturulmuş tohumlar söz konusuydu. Etkilenen ortamlar arasında Apple tarayıcıları ve JavaScriptCore tabanlı bazı eski iOS uygulama sürümleri vardı [9, 10].

Güvenlik açığı içeren oluşturma mantığı ve düzeltmesi şöyle özetlenebilir [11]:

// Vulnerable seed generation (abridged)
seed += letters[Math.floor(Math.random() * 26)];

// Corrected approach (schematic excerpt of the fix)
crypto.getRandomValues(bytes);
if (byte < 234) seed += letters[byte % 26];

Math.random() işlevini 55 kez çağırmak, birbirinden bağımsız 55 entropi kaynağı sağlamaz. Yeniden tohumlama olayları arasında, her PRNG çağrısı iç durumunu deterministik olarak ilerletir. Sabit bir çağrı konumu için başlangıç tohumu $SS$ ise 55 karakterlik cüzdan tohumunun tamamı deterministik bir $W=F(S)W=F(S)$ işlevidir. $SS$ değerini ve bu çağrı konumunu bilmek, 55 karakterin tamamını yeniden üretmek için yeterlidir; PRNG’yi daha fazla çağırmak ek entropi oluşturmaz.

Olası başlangıç durumlarının aralığı, çalışma ortamının başlatma biçimine bağlıdır. 29.10.2026 tarihinde alınan JavaScriptCore kaynak kodu anlık görüntüsünde, PRNG 32 bitlik bir tohumla başlatılır; bu da sabit bir çağrı konumu için en fazla 2 USD^{32}$ dizi oluşturur. Burada incelenen V8 kaynak kodu, 64 bitlik bir tohum kullanır; bu da en fazla 2 USD^{64}$ böyle dizi oluşturur. Bu üst sınırlar, sabit bir çağrı konumunda incelenen başlatma yolları için geçerlidir. Anlık görüntüler, olayda kullanılan tarayıcı sürümlerini veya bunlardan yararlanmanın maliyetini kesin olarak ortaya koymaz. Düzeltme ise kriptografik açıdan güvenli rastgelelik elde etmek için crypto.getRandomValues() işlevini kullanır; baytları 26 harfe eşlerken yanlılığı önlemek için de ret örneklemesi (byte < 234) uygular [12, 13, 14].

3. Hatalı İmzalama: Herkese Açık İmzalardan Özel Anahtarın Ele Geçirilmesi

Bir anahtar güvenli biçimde oluşturulduktan sonra, imzalama için kullanıldığında da gizli kalmalıdır. Her imza, gözlemcilerin erişebileceği veriler üretir; uygulama hataları ise bu herkese açık verilerin özel anahtarı ele geçirmek için yeterli bilgiye dönüşmesine neden olabilir. ECDSA ve Schnorr, özel anahtarın herkese açık imzaya katkısını gizlemek için her imzaya özgü, nonce adı verilen gizli bir skaler kullanır.

Nonce gizli kalmalı, aynı anahtarla farklı mesajlar imzalanırken yeniden kullanılmamalı ve şemanın dağılım gerekliliklerini karşılamalıdır. Deterministik türetme bu gerekliliklerle uyumludur: Açık anahtarı ve imzalanan mesajı bilmek, nonce değerini tahmin etmek için yeterli olmamalıdır.

Örnek olarak basitleştirilmiş Schnorr bağıntısını ele alalım:

$s=k-rd(\mathrm{m}\mathrm{o}\mathrm{d}n),s=k-rd\backslash pmod\; n,$

Burada $dd$ özel anahtar, $kk$ nonce, $rr$ herkese açık bilgilerle (örneğin açık anahtar ve mesajla) hesaplanan herkese açık bir sınama değeri, $ss$ herkese açık imza skaleri ve $nn$ alt grubun mertebesidir. $rr$ terslenebilirse nonce değerinin bilinmesi, $d=(k-s)r^{-1}(\mathrm{m}\mathrm{o}\mathrm{d}n)d=(k-s)r^\{-1\}\backslash pmod\; n$ özel anahtarını doğrudan açığa çıkarır.

Ayrıca anahtarın sızması için nonce değerinin bütünüyle bilinmesi gerekmez. Birden fazla nonce üzerindeki kısıtlar veya yanlılık, kafes tabanlı yöntemlerle anahtarı ele geçirmek için yeterli bilgi sağlayabilir. Bunun uygulanabilirliği, açığa çıkan bilgilere ve mevcut imzalara bağlıdır.

Tablo, bu bölümde incelenen iki nonce hatasını birbirinden ayırıyor: Zilliqa’nın nonce değerleri kısmen kısıtlanmışken SecondFi’nin nonce değerleri kamuya açık verilerden hesaplanabilir hâle geldi. Bildirilen etkiler, birbirinden ayrı geçmiş raporlama dönemlerine aittir.

3,1 Zilliqa Ledger Wallet: Her Schnorr Nonce Değerinde Eksik 64 Bit

Zilliqa Ledger Wallet olayı, eski Zilliqa EC-Schnorr işlemleri için kullanılan uygulamadaki bir kusurla ilgiliydi [15]. Uygulama nonce için veri üretiyor, ancak bunun yanlış bölümünü son imzalama tamponuna kopyalıyordu. Sekiz baytlık sıfır dolgusunu korurken gerçek rastgele verinin sekiz baytını atıyordu. Sonuç olarak, etkilenen her nonce, yaklaşık 256 bitlik secp256k1 grup mertebesi boyunca uygun biçimde dağılmak yerine 0 USD \le k < 2^{192},$ koşulunu sağlıyordu.

İmza denklemleri, nonce değerini kısıtlamanın neden önemli olduğunu gösteriyor:

Burada $GG$ grup üretecidir. Denklem yeniden düzenlendiğinde

$k=s+rd(\mathrm{m}\mathrm{o}\mathrm{d}n)\mathrm{.}k=s+rd\backslash pmod\; n.$

elde edilir. Dolayısıyla her imza, bilinmeyen $dd$ için nonce değeri 2 USD^{192}$ ile sınırlı olan bir modüler ilişki sağlar. Birkaç bağımsız ilişkinin birleştirilmesi, kafes indirgeme yoluyla çözülebilecek bir Gizli Sayı Problemi (HNP) örneği oluşturur. Resmî olay sonrası rapora göre, etkilenen dört veya daha fazla imzadan özel anahtar kurtarılabilmiştir.

Güvenli öğenin özel anahtar baytlarını açığa çıkarması gerekmiyordu. Yanlı nonce değerleri, bu anahtarın zincirde zaten yayımlanmış imzalardan kurtarılabilmesine yol açtı.

3,2 SecondFi: Kamuya Açık Verilerden Hesaplanabilen Bir İmzalama Nonce Değeri

SecondFi’de hatalı Ed25519 nonce türetimi, kısmi bir kısıttan daha fazlasını açığa çıkardı: nonce değerini kamuya açık verilerden hesaplanabilir hâle getirdi. Bu, kamuya açık tek bir işlem imzasından özel imzalama anahtarlarının kurtarılmasına olanak tanıdı [16].

Ed25519 tarzı bir imza için öngörülen yapı, gizli anahtar verilerinden gizli bir skaler $aa$ ve özel bir nonce öneki türetir. Burada $A=aBA=aB$ açık anahtar, $BB$ Ed25519 taban noktası, $MM$ imzalanan mesaj, $LL$ alt grubun mertebesi ve $HH$ SHA-512 anlamına gelir. Şematik olarak:

Hatalı uygulama ise $r=H(M)Lr=H(M)\backslash bmod\; L$ olarak belirler. İmzalanan mesajı bilen herkes $rr$ değerini türetebilir. $RR$, $AA$ ve $SS$ kamuya açık olduğundan bir gözlemci, $hh$ değerinin $LL$ modülüne göre sıfır olmaması koşuluyla,

$a=(S-r)h^{-1}(\mathrm{m}\mathrm{o}\mathrm{d}L),a=(S-r)h^\{-1\}\backslash pmod\; L,$

ifadesini hesaplayabilir.

Zilliqa’daki kısmi nonce sızıntısının aksine, etkilenen tek bir imza imzalama skalerini kurtarmak için yeterliydi. Bu, özgün anımsatıcı ifadenin veya hiyerarşik bir cüzdandaki aynı hiyerarşi düzeyindeki tüm diğer anahtarların da kurtarılabildiğini kendiliğinden kanıtlamaz. Hata, anahtar türetimi ile imzalama arasındaki arayüzdeydi: gerekli gizli veri mevcuttu, ancak nonce türetme yordamına hiç aktarılmamıştı.

4. Güvenli Uygulama İlkeleri ve Doğrulama

Bu olaylar birlikte ele alındığında, rastgelelik kaynakları ile imzalama algoritmalarının, bunları birbirine bağlayan kodla birlikte neden incelenmesi gerektiğini gösteriyor. Öngörülemez bir kaynak öngörülemez anahtarlar üretmeli ve bu anahtarlar imzalama sırasında gizli kalmalıdır. Dönüştürme yordamlarındaki veya kütüphane arayüzlerindeki hatalar, bu gerekliliklerden herhangi birini ihlal edebilir.

4,1 ve 4,2 bölümleri, üretim ve imzalamaya ilişkin tasarım ve uygulama ilkelerini ortaya koyuyor. 4,3 bölümü ise bu ilkelerin dağıtıma alınmış sistemde karşılanıp karşılanmadığını değerlendirmek için incelemelerin ve testlerin hangi kanıtları sağlaması gerektiğini açıklıyor.

4,1 Anahtar Üretimi Sırasında Güvenliği Koruyun

Üretimle ilgili olaylar üç uygulama gerekliliğine işaret ediyor:

1. Kriptografik açıdan güvenli rastgelelik kullanın ve hata durumunda işlemi durdurun. Seed değerleri ve özel anahtarlar, kriptografik açıdan güvenli sözde rastgele sayı üreteci (CSPRNG) gibi uygun ve kriptografik açıdan güvenli bir kaynak gerektirir. Ill Bloom ve Qubic, genel amaçlı bir üretecin neden bu işlevi göremeyeceğini gösteriyor. Amaçlanan kaynak kullanılamıyorsa veya başarısız olursa, daha zayıf bir alternatife sessizce geçmek yerine üretim durdurulmalıdır.

2. Veri dönüştürme boyunca entropiyi koruyun. Güvenli bir kaynağın çıktısı; kodlanırken, örneklenirken veya arayüzler arasında aktarılırken gerekli belirsizliği korumalıdır. XRPH Wallet olayı, geçerli görünen bir çıktının neden yeterli olmadığını gösteriyor. Tür, uzunluk ve kodlama kısıtları, istenmeyen kesilmelerin veya yanlı eşlemelerin etkin anahtar uzayını daraltmasını önlemelidir.

3. Dağıtıma alınmış kodun amaçlanan kaynağı kullandığından emin olun. Coldcard, güvenli bir rastgelelik kaynağının mevcut olmasının, uygulamanın gerçekte hangi kaynağı çağırdığını göstermediğini ortaya koyuyor. Kaynak seçimi; hata ve yedek yollara da uygulanacak şekilde entegrasyon, derleme ve dağıtım boyunca doğru kalmalıdır. RNG hakkındaki bir tasarım varsayımı, hedef platformda çalışan yürütülebilir dosya için de geçerli olmalıdır.

4,2 İmzalama Sırasında Gizliliği Koruyun

Üretim gereklilikleri, anahtarın nasıl oluşturulduğunu güvence altına alır. Anahtarı kullanım sırasında gizli tutmak, nonce değerlerinin doğru işlenmesini de gerektirir. Gereklilikler kullanılan şemaya bağlıdır; liste, olaylarda incelenen Schnorr ve Ed25519 şemalarının yanı sıra ECDSA’yı da içerir.

1. ECDSA: Nonce değerinin gizliliğini ve öngörülemezliğini koruyun; farklı mesajlarda aynı anahtar altında yeniden kullanılmasını önleyin. RFC 6979 [17] uyarınca deterministik üretim, her imza için yeni harici rastgeleliğe bağımlılığı ortadan kaldırır; ancak uygulamaların yine de yan kanal sızıntılarına ve hata saldırılarına karşı korunması gerekir.

2. EdDSA: Nonce türetiminin gerektirdiği tüm gizli girdileri koruyun. SecondFi, özel önekin çıkarılıp yalnızca kamuya açık verilerin kullanılmasının sonuçlarını gösteriyor. Sarmalayıcılar ve anahtar adaptörleri, çalışan bir imzayı girdilerin doğru olduğuna kanıt saymak yerine RFC 8032 [18] tarafından gerekli kılınan gizli girdilerin tamamını aktarmalıdır.

3. Schnorr: Şemanın gerektirdiği nonce dağılımını ve gösterimini koruyun. Zilliqa’nın gösterdiği gibi, rastgeleliğin bir bölümü kayboluyorsa nonce değerlerinin tekrarından ve tamamen öngörülebilir olmasından kaçınmak yeterli değildir. Verilerin işlenmesi ve skaler dönüştürme, istismar edilebilir kısıtlar veya yanlılık oluşturmamalıdır.

Kapsamlı biçimde incelenmiş kütüphaneler uygulama riskini azaltır, ancak entegrasyon hatalarını ortadan kaldırmaz. Doğru bir imzalama temel bileşeni, onu çağıran kod eksik veya bozulmuş girdiler sağlıyorsa güvenli değildir.

4.3 Güvenlik Özelliklerini Test Edin

Bu gerekliliklerin karşılanıp karşılanmadığını değerlendirmek için incelemeler, girdileri gerçekten çalışan uygulama boyunca izlemelidir. Geçerli bir çıktı bir entegrasyon hatasını gizleyebilir; bu nedenle doğrulama, olağan işlevsel testlerin gözden kaçırdığı yolları da kapsamalıdır. Tablo, üretim ve imzalama gerekliliklerini belirli inceleme hedeflerine dönüştürüyor:

Bu hedeflerin değerlendirilmesi birkaç yöntemin birlikte kullanılmasını gerektirir. Kod incelemesi, gizli ve rastgele girdilerin dağıtıma alınmış üretim ve imzalama yordamlarına nasıl ulaştığını izler. Olumsuz yol testleri ve hata enjeksiyonu, olağan varsayımlar geçerli olmadığında sistemin davranışını inceler; bilinen cevap testleri ve bağımsız uygulamalarla karşılaştırmalar ise şemadan sapmaları ortaya çıkarabilir. İstatistiksel testler belirgin yanlılıkları saptayabilir, ancak başarılı adres üretimi, imza doğrulaması veya istatistiksel testler tek başına kriptografik güvenliği ortaya koyamaz. Birlikte elde edilen kanıtları kaynak, girdi işleme ve şema gerekliliklerine göre değerlendirin.

Üçüncü taraf güvenlik ekipleri veya uzmanlar, özellikle rastgelelik kaynakları, anahtar türetimi ve imzalama kütüphanelerinin kesiştiği noktalarda kod ve entegrasyon denetimleriyle kurum içi doğrulamayı tamamlayabilir. Kapsam, bağımlılık sürümlerini, derleme yapılandırmasını ve yürütülen kod yolunu içermelidir. Bulgular, etkilenen güvenlik özelliğini belirtmeli ve yeniden üretilebilir kanıtlar ile regresyon kontrolleri sağlamalıdır. Uygulamada veya bağımlılıklarında yapılan değişikliklerin de doğrulanması gerekir.

5. Sonuç

Altı olay, uygulama hatalarının korunan anahtarların güvenliğini iki şekilde zayıflatabileceğini gösteriyor: üretim sırasında olası anahtarların sayısını azaltarak veya mevcut bir anahtara ilişkin bilgileri imzalar aracılığıyla açığa çıkararak. Analiz, bu hatalardan ödeme altyapısında dağıtıma alınmış koda yönelik inceleme ve test hedefleriyle birlikte üretim ve imzalama gereklilikleri çıkarıyor.

Ödeme kuruluşları açısından güvenli saklama, saklanan gizli veriyi korur; öngörülebilir üretimi veya imzalama yoluyla sızan bilgileri düzeltemez. Gerekli özellikler bağımlılıklar, adaptörler ve dağıtım boyunca korunmalıdır. İncelemeler ve testler, geçerli adres ve imzalardan güvenlik sonucunu çıkarmak yerine bu uygulamanın tamamını ele almalıdır.

Bu uygulama gereklilikleri, Beyond Secure Storage’ın 1. bölümünde incelenen iş akışı kontrollerini tamamlar. 1. bölüm, iş akışı risklerini, önleyici kontrolleri ve bu kontroller yetkisiz işlemleri durduramadığında kayıpların sınırlandırılmasını inceler. 2. bölüm ise saldırgana bağımsız imzalama yeteneği kazandırabilecek uygulama kusurlarını ele alır. Kriptografik işlemlerin doğru yürütülmesi, işlemin iş süreçleri açısından yetkilendirildiğini kanıtlamaz; geçerli bir iş onayı da imzalama anahtarının öngörülemez olduğunu veya kurtarılamayacağını ortaya koymaz. Güvenli ödeme ve imzalama sistemleri, hem yetkilendirme iş akışının hem de temelindeki kriptografik uygulamanın tasarlanmasını ve doğrulanmasını gerektirir.

Kaynaklar

• [1] BIP-39, Deterministik Anahtarlar Üretmek için Anımsatıcı Kod.

• [2] BIP-32, Hiyerarşik Deterministik Cüzdanlar.

• [3] CryptoJS, Güvenlik Duyurusu GHSA-rg76-677x-56q9.

• [4] CryptoJS, core.js kaynak kodu, sürüm 3.1.9-1.

• [5] Coldcard, Ürün yazılımı duyurusu ve sürüm notları.

• [6] MicroPython, MicroPython Açısından Coldcard Olay Sonrası Değerlendirmesi.

• [7] Coinkite, Entropi Sorununun Ayrıntılı Teknik İncelemesi.

• [8] XRPL.to, XRPH Wallet Saldırısı: 4011 Cüzdan Boşaltıldı ve Her Anahtar Tahmin Edilebilirdi.

• [9] Qubic, Olay açıklaması ve etkilenen platformlara yönelik rehberlik.

• [10] Qubicmap, Qubic olayının zaman çizelgesi ve cüzdan özeti.

• [11] Qubic Wallet, Güvenli seed üretimi düzeltmesi 09dd288.

• [12] WebKit, JSGlobalObject.cpp, m_weakRandom başlatılması.

• [13] WebKit, WeakRandom.h, seed ve PRNG uygulaması.

• [14] V8, math-random.cc, PRNG durumunun başlatılması.

• [15] Zilliqa, Olay Sonrası Değerlendirme: Eski Schnorr Nonce Değerlerindeki Yanlılık.

• [16] KarpelesLab, SecondFi uygulamasının analizi ve hatanın yeniden üretilmesi.

• [17] RFC 6979, DSA ve ECDSA’nın Deterministik Kullanımı.

• [18] RFC 8032, Edwards Eğrisi Dijital İmza Algoritması (EdDSA).