Çok Zincirli Saklama Sorunu — Tek Kurtarma İfadesi, Birçok Defter

Tek bir kâğıt parçasını — on iki ya da yirmi dört kelimeyi — yedekleyip kriptonuzun güvende olduğundan emin olursunuz. Ancak bu kâğıt tek bir hesabı korumaz. Cüzdanınızın desteklediği tüm blokzincirlerdeki bütün hesaplarınızı korur. Zelcore’da bu, aynı anda 80’den fazla zincir demektir. Bunun neden böyle olduğunu ve saklama tercihlerinizi nasıl etkilediğini tam olarak anlamak, öz saklama güvenliğiyle ilgili diğer her şeyin temelidir.

Kurtarma ifadesi nasıl bir anahtarlar evrenini kodlar?

Bir kurtarma ifadesi rastgele kelimelerden oluşuyor gibi görünür, ancak aslında ham entropinin hassas bir kodlamasıdır. Biçimi standartlaştıran Bitcoin İyileştirme Önerisi BIP-39, tam 2.048 İngilizce kelimelik bir liste tanımlar. Her kelime 11 bit bilgi kodlar; yani hiçbir kelime süs değildir: ifadedeki her kelime belirli bir veri taşır. 12 kelimelik bir ifade 128 bit entropi, 24 kelimelik bir ifade ise 256 bit entropi kodlar.

Kurtarma ifadesinin kendisi kriptografik seed değildir. Herhangi bir anahtar türetilmeden önce cüzdan, ifadeyi 2.048 yinelemeli PBKDF2-HMAC-SHA512 adlı, hesaplama açısından maliyetli bir anahtar uzatma işlevinden geçirir. Çıktı, gerçek seed olan 512 bitlik ikili bir değerdir. Bu uzatma, saldırgan bazı kelimeleri tahmin etse bile kaba kuvvet saldırılarını uygulanamaz hâle getirir.

Önemli bir sonuç: İsteğe bağlı bir parola (bazen 25. kelime olarak adlandırılır) eklerseniz PBKDF2 işlevi bu parolayı da hesaba katar ve tamamen farklı bir 512 bitlik seed üretir. Aynı on iki kelime, farklı bir parolayla bambaşka bir cüzdanın kilidini açar. Aralarında hiçbir ilişki yoktur. Parolayı unutursanız bu fonlardaki varlıklarınıza kalıcı olarak erişemezsiniz.

Türetme ağacı: Tek seed, sonsuz hesap

512 bitlik seed, BIP-32’de tanımlanan hiyerarşik deterministik (HD) cüzdan ağacının köküdür. Cüzdan, seed baytlarını HMAC-SHA512’ye (anahtar olarak "Bitcoin seed" metin dizisini kullanarak) verir ve 512 bitlik çıktıyı iki eşit parçaya böler: 256 bitlik ana özel anahtar ve 256 bitlik ana zincir kodu. Cüzdandaki her alt anahtar, alt-alt anahtar ve adres, bu iki değerden tekrarlanan HMAC-SHA512 işlemleriyle türetilir.

BIP-44, ağacın nasıl izleneceğini standartlaştırır ve m/purpose'/coin_type'/account'/change/index biçiminde bir türetme yolu tanımlar. Her bölümün belirli bir işlevi vardır:

• purpose BIP-44 cüzdanlarında her zaman 44' değeridir.
• coin_type, SLIP-0044 adlı bir kayıt defterinde her blokzincire atanmış zincir ayırt edicisidir. Bitcoin için 0, Ethereum için 60, Solana için 501, Litecoin için 2, Dogecoin için 3, Cardano için 1815 kullanılır.
• account, aynı zincirdeki bağımsız hesapları birbirinden ayırır.
• change ve index, tekil adresler üretir.

Kesme işaretleri sertleştirilmiş türetmeyi belirtir: ele geçirilmiş bir alt anahtarın kardeş anahtarları veya üst anahtarı türetmesini matematiksel olarak önleyen tek yönlü bir işlem. Ethereum hesap anahtarlarınızın, ikisi de aynı ana anahtardan türetilmiş olsa bile Bitcoin hesap anahtarlarınızı açığa çıkaramamasının nedeni budur.

Zelcore’da tek bir kurtarma ifadesi BTC, ETH, SOL, ADA ve onlarca başka varlığı aynı anda yönetir. Her biri kendi coin_type alt ağacında yer alır ve aynı 512 bitlik kökten deterministik olarak türetilir.

Bu saldırı nasıl işler: Tüm zincirlerde tek bir arıza noktası

Türetme deterministik ve standartlaştırılmış olduğundan, kurtarma ifadenizi elinde bulunduran herkes desteklenen tüm zincirlerdeki her özel anahtarı yeniden oluşturabilir. Bu, tasarımdaki bir kusur değildir; tasarımın kendisidir. Güvenlik modeli, kurtarma ifadesini başka hiç kimsenin görmeyeceğini varsayar.

Pratik sonucu çok ciddi. Sızdırılan bir kurtarma ifadesi yalnızca Bitcoin’inizi açığa çıkarmaz. Saldırgan Ethereum adresinizi, Solana adresinizi, Cardano adresinizi ve diğer tüm varlıklarınızı aynı anda türetebilir. Birisi Bitcoin kurtarma ifadenizin fotoğrafını çektiği anda Solana varlıklarınız da tehlikeye girer. SOL tuttuğunuzu bilmesine bile gerek yoktur.

Kurtarma ifadesini kaybetmek bunun ters yöndeki sorununu yaratır: zincir başına ayrı bir yedek yöntem, hesap kurtarma seçeneği veya müşteri desteğine başvurma yolu yoktur. Seed’i oluşturan entropi matematiksel olarak geri döndürülemez. Kâğıdı kaybetmek, tüm zincirlere aynı anda erişimi kaybetmektir.

Bu nedenle donanım cüzdanları kurtarma ifadesini güvenli bir bileşenin içinde üretir ve bağlı bilgisayara asla aktarmaz. Seed çevrimdışı üretilir ve orada kalır.

Seed’in korumadığı zincire özgü üst veriler

Kurtarma ifadesinden geri yükleme, özel anahtarları ve standart türetme yollarını yeniden oluşturur; ancak her şeyi korumaz. Bazı veri türleri seed’in yeniden oluşturabileceklerinin dışındadır:

• Zincir dışı üst veriler: İşlem etiketleri, adres defteri kayıtları ve özel notlar zincirde değil, cüzdan uygulamasında saklanır.
• Standart dışı türetme yolları: Bazı eski cüzdanlar ve bazı zincirler (Solana ve Cardano geçmişte katı BIP-44’ten farklı yol kuralları kullanmıştır) nedeniyle farklı bir cüzdan uygulamasına geri yükleme yaptığınızda, fonlar zincirde mevcut olsa bile bakiye sıfır görünebilir. Anahtarlar yerindedir; yazılım yalnızca yanlış adrese bakıyordur.
• Token bakiyeleri: Ethereum’daki ERC-20 token’ları ve Solana’daki SPL token’ları zincir üzerinde akıllı sözleşmelerde saklanır; ancak basit bir kurtarma aracı yalnızca yerel coin bakiyesini gösterebilir. Token’lar güvendedir; cüzdanın ilgili sözleşmeleri sorgulaması yeterlidir.
• DeFi pozisyonları ve NFT’ler: Bunlar yalnızca cüzdan hangi protokol sözleşmelerini sorgulayacağını ve hangi RPC uç noktasını kullanacağını biliyorsa görüntülenir.

Pratik öneri: Yalnızca kurtarma ifadenizi değil, kullandığınız cüzdan yazılımını ve türetme yollarını da kaydedin. Kurtarma ifadesi tek başına, aylar ya da yıllar sonra yapılacak bir kurtarma işlemi için gereken bağlamı her zaman sağlamaz.

Adresin yeniden kullanımı ve zincirler arası kimlik

BIP-44’ün coin_type segmentasyonu, aynı seed’den türetilen Bitcoin ve Ethereum adreslerinin matematiksel olarak ilişkisiz olduğu anlamına gelir: ortak kökleri vardır, ancak açık anahtarları farklıdır. Buna karşılık Ethereum, BNB Chain, Polygon, Avalanche C-Chain, Base ve diğerleri gibi EVM uyumlu zincirlerin tümü coin_type = 60 paylaşır. Bu nedenle aynı 0x... adresi her EVM zincirinde görünür.

Bu kasıtlıdır, ancak zincirler arasında bir kimlik bağı oluşturur. Ethereum adresinizi bilen herkes, aynı adresi kullanarak her EVM zincirindeki hareketlerinizi inceleyebilir. Gizliliğe önem veren kullanıcıların varlıklarını birleştirmeden önce bunu anlaması faydalı olur.

Bitcoin’in UTXO modeli geleneksel olarak her işlem için yeni bir adres oluşturmayı teşvik eder; HD cüzdanlar bunu otomatik yapar. Ethereum’un hesap modeli ise adres değiştirmeyi yaygın kılmaz; çoğu kullanıcı her hesap için tek bir adresi süresiz kullanır. Bir Bitcoin adresini birçok işlemde yeniden kullanmak, girdileri ortak bir sahip ile ilişkilendirmeyi kolaylaştırarak gizliliği zayıflatır.

Yüksek değerli varlıkları saklarken varlıkları seed’lere göre ayırmayı değerlendirin: yüksek riskli alım satım işlemleri için ayrı, uzun vadeli varlıklar için ayrı bir kurtarma ifadesi kullanabilir veya büyük pozisyonlarınızı internete bağlı bir cihaza hiç bağlanmamış, ağ bağlantısı kesilmiş bir cihazda tutabilirsiniz.

Kendinizi nasıl korursunuz: Tek arıza noktasına karşı önlem alın

Kurtarma ifadesi, aynı anda hem en güçlü kurtarma aracınız hem de en tehlikeli tek arıza noktanızdır. Onu korumak için atabileceğiniz somut adımlar:

1. Kâğıda değil, metale yazın. Paslanmaz çelik veya titanyum yedekleme plakaları yangına ve su baskınına dayanır. Kâğıt dayanmaz.
2. Asla dijital ortama aktarmayın. Ekran görüntüsü almayın, bulut notlarına kaydetmeyin, parola yöneticisi kullanmayın, dijital kopyasını yazmayın. Kurtarma ifadesi ağa bağlı bir cihaza girdiği anda saldırı yüzeyi önemli ölçüde genişler.
3. Önemli miktarda varlık yatırmadan önce kurtarmayı doğrulayın. Yalnızca kurtarma ifadesini kullanarak yeni bir cihaza geri yükleme yapın; ifadenin çalıştığını ve beklediğiniz adresleri oluşturduğunu doğrulayın.
4. Shamir’in Gizli Paylaşımı’nı (SLIP-39) değerlendirin. SLIP-39, bir seed’i N paya bölen ve yeniden oluşturmak için yalnızca M pay gerektiren bir standarttır. Böylece payları farklı yerlerde saklayabilirsiniz: biri evdeki kasada, biri güvendiğiniz bir kişide, biri banka kasasında. Böylece hiçbir konumda sırrın tamamı bulunmaz.
5. Parola ifadesinin ödünleşimini anlayın. Güçlü bir parola ifadesi (25. kelime) makul inkâr olanağı sağlar: parola ifadesi olmadan açılan cüzdanda küçük bir şaşırtmaca tutarı bulundurabilir, asıl varlıklara ise yalnızca parola ifadesiyle erişebilirsiniz. Risk iki yönlüdür: parola ifadesini unutmak, seed’in kendisini kaybetmek kadar kalıcı sonuçlar doğurur.

Zelcore’da birçok zincirde varlık tutan kripto cüzdanı kullanıcıları için son nokta özellikle önemlidir: kurtarma testi yalnızca en belirgin zinciri değil, aktif olarak kullandığınız tüm zincirleri kapsamalıdır.

Önemli noktalar

• 12 kelimelik bir seed 128 bit entropi, 24 kelimelik bir seed ise 256 bit entropi kodlar. Kaybolursa ikisi de kurtarılamaz.
• BIP-32 ve BIP-44, her blokzincir için ayrı bir anahtar alt ağacı türetir (coin_type); ancak tüm alt ağaçlar aynı ana anahtardan türediği için seed’in ele geçirilmesi tüm zincirleri birden tehlikeye atar.
• Zelcore’ın 80’den fazla zinciri desteklemesi, tek bir yedekleme ifadesinin büyük ve çeşitli bir portföyü kontrol ettiği anlamına gelir. Bu yedeğin fiziksel güvenliği, uzunluğu kadar önemlidir.
• EVM zincirleri (Ethereum, BNB Chain, Polygon ve diğerleri) coin_type = 60 değerini paylaşır ve bu nedenle aynı adres alanını kullanır. Aynı 0x adresi hepsinde görünür.
• Yalnızca seed’den geri yükleme yapmak, token bakiyelerini veya DeFi pozisyonlarını göstermeyebilir. Kullanılan cüzdan yazılımını ve yolları kaydedin.
• Metal yedekler, SLIP-39 ile payları farklı yerlere dağıtma ve parola ifadesi katmanı, tek arıza noktası riskini belirgin ölçüde azaltan üç somut iyileştirmedir.