Donanım imzalama cihazları, kullanıcıyı aşağıdakiler gibi çeşitli yaygın saldırı vektörlerinden korumak için tasarlanmıştır:

• Tohuma yetkisiz erişim ve çıkarma
• İlişkili yazılım cüzdanınızı etkileyen kötü amaçlı yazılım
• Cihazın kendisindeki yazılım güvenlik açıkları

Her işte olduğu gibi, cihazları şu şekilde yapmak üreticinin çıkarınadır: kırılmaz yapabildikleri kadar. Bu görevde başarılı olmak çok önemlidir ve Ledger gibi güvenlik şirketleri geçmiş performanslarına dayanan bir itibara güvenirler.

Ancak, bazı kullanıcıların hala endişeleri olabilir. Şirketin kendisinin bir şeyi saklamasını engelleyen nedir? arka kapı cihazlarda?

Kendi kendine velayet içinde, biz güvenme, doğrularız.
Ancak kullanıcı Gerçekten mi bir cihazın arka kapısı olmadığını doğrulayın?

Bu makalenin ele aldığı anahtar soru bu. Daha doğrusu, bu makale aşağıdaki konuları ele alıyor:

• arka kapı nedir ve olmadığını kanıtlamak imkansız değilse de neden zordur;
• neden sadece kullanıcılar kendilerini bu riskten koruyabilir;
• miniscript, bitcoin cüzdanları için bu zorluğa nasıl pratik çözümler sağlar.

destekleyen ilk donanım cüzdanı olarak mini yazı, geliştiricilere güvenli çözümler oluşturmaları ve tüm endüstrimizi yükseltmeleri için ilham vermeyi ve böyle bir sistemik riskin gerçekleşme olasılığını ortadan kaldırmayı umuyoruz.

Nasıl inşa edilir geri alınamaz imzalama cihazı

Açıkça söyleyelim: Yapamazsınız.

Kendinizi potansiyel bir arka kapıya karşı savunmak için yukarıda özetlediğimizden farklı bir saldırı modeline ihtiyacınız var: Bu senaryoda, düşman satıcının kendisi veya yozlaşmış bir içeriden olabilir.

Bu sorunun sık sık dile getirilen çözümü Açık Kaynak'tır: Sonuçta, kodu inceleyebiliyorsanız, neyin yanlış gitmesi olasıdır?

Ancak, gerçek daha karmaşıktır. Satıcı donanımı bir araya getirdiğinden, bir arka kapı tamamen onun içinde olabilir. Donanım, belirli noktalarda yazılımı dikkate almamak ve bunun yerine kötü amaçlı kod yürütmek üzere tasarlanabilir.

Genel amaçlı bilgi işlem cihazlarında (dizüstü bilgisayarınız veya telefonunuz gibi) çalışan yazılımların aksine, günümüz teknolojisinde donanımı incelemek neredeyse imkansızdır. Donanım belirtimleri tamamen açık kaynak olsa ve devredeki her bir geçidin ayrıntılarıyla tamamlansa bile, belirli bir çipin bunlara uygun olarak üretildiğini doğrulamak için yine de yüksek maliyetli ekipmana ihtiyacınız olacaktır.

Bir donanım cüzdanı nasıl arka kapıdan kapatılır?

Burada, kötü niyetli bir donanım satıcısının bir arka kapı oluşturmak için kullanabileceği en basit yöntemlerden birkaçının yanı sıra ileri düzey kullanıcıların günümüzde kendilerini koruyabilecekleri bazı yöntemler yer almaktadır.

Tohum üretimi

Pek çok cihaz size bir tohum oluşturma yeteneği sunar (aynı zamanda Gizli Kurtarma İfadesi) doğrudan cihazda, bir Gerçek Rastgele Sayı Üreticisi.

😈 Kötü cihaz, rastgele görünen ancak aslında saldırgan tarafından tahmin edilebilir olan tohumlar üretebilir.

🛡️ Uzman kullanıcılar çevrimdışı bir anımsatıcı oluşturarak bu sorunu aşabilir. Ek olarak, sağlam bir parola ayrıca donanım satıcısının tahmin edemeyeceği tamamen bağımsız bir tohum oluşturabilir. Takas, kullanıcıların anımsatıcı sözcüklere ek olarak parolayı da düzgün bir şekilde yedeklemeleri gerektiğidir.

Genel anahtar türetme

Donanım cüzdanları, ortak anahtarlar (olarak da adlandırılır xpub'lariçin kısa genişletilmiş ortak anahtar tanımlandığı gibi BİP-32. xpub'lar madeni para almak için olası adresleri oluşturmak için kullanılır.

😈 Kötü cihaz, tohumdan türetilen doğru anahtarlar yerine saldırgan tarafından kontrol edilen genel anahtarları döndürebilir.

🛡️ Kullanıcılar türetilenleri doğrulayabilir xpub başka bir çevrimdışı cihazda. Ancak başka cihazlarda tohuma girmek kendi risklerini taşır. Güvenlik bilincine sahip kullanıcılar, tohuma erişen herhangi bir cihazı potansiyel olarak onları yok etme noktasına kadar tehlikeli olarak görebilir. Tipik bir kullanıcı, ek riskleri yönetirken bu prosedürü doğru bir şekilde gerçekleştirmekte zorlanabilir.

Sızan bilgi

An hava boşluğu kötü amaçlı veya güvenliği ihlal edilmiş bir cihazın özel anahtarları dışarı sızdırmasını önlemek için sıklıkla bir çözüm olarak önerilir. Sonuçta bir cihaz dış dünya ile iletişim kuramıyorsa zararlı bir şey yapamaz değil mi?

Tam olarak değil!

Cihaz kullanımdayken her zaman iletişim kurabilir: imzalar üretir. Bu imzalar, blok zincirinde sonsuza kadar yayınlanan ve saklanan işlemlerin içinde sona erer.

İmza, en az 64 baytlık rastgele görünen bir bayt dizisidir. Bununla birlikte, birden fazla geçerli imza aynı mesaja karşılık gelebileceğinden, kötü amaçlı bir cihaz, birden fazla imza oluşturarak ve hangisini yayınlayacağını seçerek seçerek, bir imzanın her üretildiğinde birkaç bitlik bilgi iletebilir.

😈 Sahte bir cihaz, rastgele olmayan imzalar üreterek, birçok işlemde saldırganın çekirdeğini ortaya çıkarabilir!

Böyle bir arka kapı kurmayı başaran bir saldırganın, yalnızca tüm çekirdeği yeniden oluşturmak için yeterli bilgiye sahip olana kadar kötü niyetli imzaların blok zincirinde görünmesini beklemesi gerekir.

🛡️ ECDSA imzaları için, nonce'yi deterministik olarak türetmek için standartlaştırılmış bir yöntem kullanarak (örneğin RFC6979) üretilen imzanın beklenen imzayla eşleştiği doğrulanırsa bu saldırıyı engeller. Bununla birlikte, durumun böyle olmasını sağlamak, önceki bölümde belirtilen aynı pratik sorunlara yol açan aynı tohumla ikinci bir cihazın yüklenmesini gerektirir.

🛡️ İlginç bir yaklaşım, anabolik etkileri de mevcuttur cihaz aslında rastgele bir nonce seçecek. olarak bilinen bu amaca yönelik bir protokol sınır dışı edilme karşıtı or klepto karşıtı, şu anda Blockstream Jade ve ShiftCrypto BitBox02 donanım cüzdanlarında uygulanmaktadır. Daha fazlasını okuyun ShiftCrypto'nun blogu, ayrıca böyle bir saldırının nasıl yürütülebileceğine dair teknik bir açıklama da içerir.

Tamam o zaman hiç umut yok mu?

Yukarıda listelenen savunmaların🛡️ çoğu, çoğunlukla kullanıcının kendilerini korumak için açık, müdahaleci eylemler gerçekleştirmesini gerektirir: ya çekirdeği kendi başlarına oluşturarak (aslında donanım cüzdanındaki işlevselliği değiştirmek için beyinlerini kullanarak) ya da hesaplamaların doğru yürütüldüğünü doğrulamak için ek bir cihaz kullanarak.

Bununla birlikte, anti-exfil protokolü öne çıkıyor: Donanımı imzalayan ile dış dünya arasında her zaman aracılık yapan bir makine olduğu düşünülürse, bu makine yardımcı olabilir. Donanım imzalayıcısı ile etkileşimli bir protokol aracılığıyla, uygulamak gerçekten rastgele bir nonce kullanımı, böylece nihai imzayı önemli ölçüde manipüle etme şansını azaltır veya ortadan kaldırır.

Bu blog yazısında, öncelikle bu tür önlemlerle ilgileniyoruz: UX'i önemli ölçüde kötüleştiren stratejiler uzman kullanıcılar için çekici olsa da, muhtemelen bir şeyler yapacaklardır. kötü pratikte teknik olarak daha az yetenekli kullanıcılar için - ki bu büyük çoğunluktur.

güvenlik modeli

Donanım imzalayanlar için standart model

Donanım imzalayıcı üreticileri, kullanıcıları çeşitli olası tehditlerden korumayı amaçlar (daha fazla ayrıntı için bkz. Tehdit Modeli). Bu yazıda, aşağıdaki gibi özetlenebilecek çok önemli bir özelliğe odaklanıyoruz:

Kullanıcılar, onaylanmadan önce ekrandaki bilgileri anlamaları ve doğrulamaları koşuluyla, fon kaybıyla sonuçlanan bir işlem için kandırılamazlar.

Her türlü hassas işlem için, özellikle imzalar için onay gereklidir. Kötü amaçlı yazılım, tüm fonları tüketen bir işlem gibi rastgele mesajlar için imzalar üretebilirse, tohumu korumak boşuna olacaktır!

Yazılım cüzdanı tamamen ele geçirilmiş olsa bile yukarıdaki özelliğin geçerli olması gerektiğini vurgulamak çok önemlidir. Dizüstü bilgisayarınızın/telefon ekranınızda görüntülenenlere güvenilemez: kötü amaçlı yazılım adreslerin yerini alabilir, hangi adreslerin size ait olduğu konusunda sizi yanıltabilir, bir işlem sunabilir ancak daha sonra imza için farklı bir adresi cihaza iletebilir vb.

Bu nedenle, bir donanım imzalama cihazında çalışan aygıt yazılımı ve uygulamalar, yazılım cüzdanını doğası gereği dikkate alır. güvenilmeyen ve güvenilmez.

Yazılım cüzdanları için arka kapıya karşı güvenlik modeli

Bu bölümde rolleri tamamen çeviriyoruz. Şimdi bir tasarım yapmak istiyoruz yazılım cüzdanı donanım üreticisinin çalmasını veya fon kaybına neden olmasını engelleyen, cihaz tamamen kötü niyetli olsa bile.

Bu nedenle, bu bir mülk olamaz cihaz: bunun yerine, yazılım cüzdanı kurmak. Bunu şöyle özetleyebiliriz:

Yazılım cüzdanının tehlikeye atılmaması koşuluyla, donanım üreticisi kullanıcının para kaybetmesine neden olamaz.

Bu, yukarıda ayrıntıları verilen standart güvenlik modeliyle doğrudan çeliştiği için mantığa aykırı görünebilir. Ancak, "arka kapıya sahip olmamak", "yapmaları gerekeni tam olarak yapmak" anlamına gelir. Yazılım cüzdanı olduğu için taban imzalama cihazı ile dış dünya arasındaki arayüz, ister bir hata ister cihazın açık bir şekilde tehlikeye girmesi nedeniyle olsun, hatalı davranışlara karşı korumanın uygulanabileceği tek yerdir.

Bu modelin, istismar edilebilir bir hata gibi bir cihaz arızasının önemli ölçüde ötesine geçtiğini unutmayın. Bu durumda, cihazın aktif olarak fon kaybına neden olmaya çalıştığı bir senaryo dahilinde hareket ediyoruz.

Tabii ki, üretici başarılı bir şekilde güvenliği aşmışsa olası bir koruma yoktur. her ikisi de cihaz ve ayrıca yazılım cüzdanını çalıştıran makineniz. Bu nedenle, özellikle donanımı üreten aynı satıcı tarafından oluşturulmuşsa, yazılım cüzdanınızın Açık Kaynak ve denetlenebilir olduğundan emin olmanız kesinlikle hayati önem taşır.

Miniscript'in rolü

Miniscript, cüzdan geliştiricilerine bitcoin Script'in gelişmiş özelliklerini tam olarak kullanma yeteneği sağlar. Miniscript'in kilidini açtığı inanılmaz olasılıklara genel bir bakış için bkz. bir önceki blog yazımız. Ayrıca dinlemek isteyebilirsiniz Stephan Livera Podcast'in 452. Bölümü miniscript'in bitcoin ortamına neler getirdiğine dair bir tartışma için.

Ledger Bitcoin uygulaması, Şubat 2.1.0'te dağıtılan 2023 sürümünden bu yana miniscript'i desteklemektedir. Miami'deki Bitcoin 2023 konferansında Wizardsardine, 1.0 sürümünü duyurdu. Liana cüzdanı, miniscript tabanlı ilk dağıtılan cüzdan.

Bu yazının temel fikri, bir bitcoin cüzdan hesabının yalnızca biriyle değil, çoklu anahtarlar. Bu, bir anahtarın tamamen arızalanması veya tehlikeye atılmasının bile felaket olmadığı durumlarda esnek güvenlik çerçevelerine izin verir.

çoklu imza düşünceleri

Multisig, kendi kendine gözetim çözümünün gücünde önemli bir yükseltmedir. Bitcoin Komut Dosyasının programlanabilirliğinden yararlanarak, yalnızca bir anahtar yerine birden çok anahtar gerektiren cüzdanların oluşturulmasını sağlar. A k-Of-n multisig cüzdanı bir kombinasyon gerektirir k geçerli imzalar, toplam n olası olanlar

Ancak multisig, kullanıcıya bir UX yükü de yükler ve hatalar için yeni fırsatlar sunar. Ayrı konumlarda güvenli bir şekilde yedeklenen üç farklı anahtarı içeren 3'ten 3'e çoklu imza kurulumu, güçlü güvenlik sunar... tek anahtar kaybolur, madeni paralar kalıcı olarak erişilemez hale gelir!

Bu nedenle, daha fazla fazlalık sunan kurulumlar (2'te 3 veya 3'te 5 gibi) daha popüler olma eğilimindedir: tek bir anahtar kaybolsa bile, diğer anahtarlar yine de kurtarmayı kolaylaştırabilir. Ancak bu bir değiş tokuşa yol açar: Sizin haberiniz olmadan bir anahtarın güvenliği ihlal edilirse, genel güvenlik önemli ölçüde azalır!

Şirketler gibi Ev ve Unchained Sermaye müşterileri için anahtarların küçük bir kısmını ellerinde bulundurdukları durumlarda kendi kendine velayet çözümlerinde uzmanlaşırlar. Ayrıca, teknik olmayan çoğu kullanıcı için göz korkutucu olabilecek gözetim sistemlerinin kullanımını basitleştirerek ve katılım sürecinde onlara rehberlik ederek kullanıcılarına yardımcı olurlar.

Miniscript ve zaman kilitli kurtarma yolları

Liana, birden çok harcama yöntemi olan cüzdanlar oluşturmak için miniscript kullanıyor:

• hemen kullanılabilen bir birincil harcama koşulu;
• belirli bir süre sonra geçerli olan bir veya daha fazla ek harcama koşulu (sözde zaman kilidi).

Bu, birçok ilginç kullanım durumunu mümkün kılar:

• Tedavi Süreci: Birincil harcama yolu olarak tek imzalı veya çoklu imzalı standart bir cüzdan; ancak ayrı bir kurtarma mekanizması (farklı bir tohuma sahip bir anahtar, bir multisig, teknolojiden anlayan bir arkadaş, bir sorumlu) 6 ay sonra kullanılabilir hale gelir.
• Yönetim: İki yöneticili bir şirket, şirketin hazinesi için 2'ye 2 oluşturabilir; anlaşmazlık durumunda, güvenilir bir avukat 6 ay sonra fonlara erişebilir.
• Çürüyen çoklu imza: Bir cüzdan 3'te 3 olarak başlar, 2 ay sonra 3'de 6'e geçer ve 1 ay sonra 3'de 9 olur.
• Otomatik devralma: 6 aydan sonraki iyileşme yolu, üç çocuğunuzdan 2/3'ünü içerir; belki 1 yıl sonra ikinci bir kurtarma yolu, mirasçıların uzlaşmaya varamaması durumunda noterden geçer.

Açıklama: yukarıdaki tüm örneklerde bir göreceli zaman kilidi, madeni paraların yaşını ifade eder (yani: fonların en son taşındığı zaman). Takas, zaman kilidinin sona ermek üzere olması durumunda kullanıcının madeni paraları (kendilerine göndererek) harcamayı hatırlaması gerektiğidir.

Bunlar sadece birkaç örnek, ancak okuyucuyu miniscript'in Bitcoin'in potansiyelini gerçekleştirme yolunda önemli bir adım olduğuna ikna etmek için yeterli olmalılar. programlanabilir para.

Cüzdan politikası kaydı

Birden fazla anahtar kullanan Bitcoin cüzdan hesapları için (multisig veya daha gelişmiş miniscript tabanlı çözümler), cihazı o hesaba ait adresleri tanımlayacak şekilde eğitmek çok önemlidir. Cihazın, kullanıcının doğru adreslerden alım veya harcama yapmasını sağlamasına yardımcı olabilmesinin tek yolu budur...

Politikanın doğrulanması ve xpub'lar alıcının güvenilir bir yedeğe karşı korunması önemlidir, ancak nispeten zaman alıcıdır.
İyi haber şu ki, yalnızca bir kez yapılması gerekiyor:

Bir poliçe bir adla kaydedildiğinde (“Decaying 3of3” örneğinde olduğu gibi), böyle bir poliçe kullanıldığında cihazınız poliçeyi tanıyabilecektir.

Teknik detaylarla ilgilenenler, daha fazla bilgiyi aşağıdaki adreste bulabilirler. BİP teklifi.

İlke yedekleme

Unutulmaması gereken kritik bir husus, çok anahtarlı politikaların bir alt kümeye izin vermesidir. özel anahtarlar işlemlere izin vermek için, bilgisi herşey ortak anahtarlar (ve kesin politikası) gereklidir.

Ancak, çekirdeğin aksine, ilkeyi ve ortak anahtarları yedeklemek çok daha az risklidir: Biri onu keşfederse, o ilkeyle bağlantılı tüm işlemleri izleyebilir. Bu ideal olmasa da - mahremiyet önemlidir! − madeni paralarınızı kaybetmek kadar feci değil ve potansiyel saldırganlar için daha az çekici. Sonuç olarak, politikanın birden fazla kopyasını sıcak cüzdanlarda saklamak, yazdırıp çeşitli yerlerde saklamak, şifrelemek ve bulut depolamada saklamak vb. uygulanabilir stratejilerdir.

Geri alınamaz tek imzalı cüzdan

Geri adım atalım. Çoklu imzalı cüzdanlardan bahsetmiştik, ancak şimdi tek imzalı bir cüzdan oluşturmak için temel bilgilere geri dönüyoruz. Daha doğrusu, bir cüzdan istiyoruz ki hissediyor ve görünüyor ilk kurulum aşamasından sonra tek imzalı bir cüzdan gibi. Yine de üreticinin kötü niyetli olsalar bile paranızı çalamayacağı bir cüzdan yaratmayı hedefliyoruz 😈 ve donanım imzalama cihazı öngörülemeyen şekillerde davranıyor.

Yaklaşım, çoklu imza cüzdanları için kolayca genelleştirilebilir.

Aşağıdaki örnekler adlı bir dilde yazılacaktır. politika, miniscript yerine. Politika, insanların okuması ve üzerinde düşünmesi daha kolaydır ve otomatikleştirilmiş araçlarla küçük yazı biçiminde derlenebilir. Miniscript ve politika hakkında daha fazlasını okuyun.

Donanım cüzdanı sizi standart güvenlik modelinde koruyabilir. Miniscript sizi arka kapıya karşı güvenlik modelinde (ve çok daha fazlasında!) koruyabilir.

Adım sıfır: statüko

Bu, günümüzde çoğu kullanıcının kullandığı politikadır: donanım cüzdanında üretilen bir tohumdan türetilen tek bir anahtar.

pk(key_ledger)

Elbette arka kapının olmadığını kanıtlamanın bir yolu yok.

Birinci adım: bu tuşları ikiye katlayın

İlk adım basittir:

and(pk(key_ledger), pk(key_client))

Burada, key_client kullanıcının makinesinde oluşturulur, dolayısıyla bir Hot Key. Temel olarak, 2'den 2'ye çoklu imza kurulumu. Anahtar özellik, kullanıcının çok fazla etkileşime girmemesidir. key_client: yazılım cüzdanı bu anahtarı oluşturur, cüzdanın yedeğine dahil eder ve gerektiğinde imzalar (örneğin, kullanıcı donanım imzalayıcısı ile imzalamakla meşgulken).

Bu zaten oldukça ilginç görünüyor: fonlar onsuz harcanamaz. key_clientdonanım satıcısı tarafından kullanılamayan; Kötü satıcı, cihazdaki anahtar hakkında tam bilgiye sahip olsa bile, kullanıcıyı açıkça hedeflemeden, örneğin yazılım cüzdanını çalıştıran makineyi tehlikeye atarak, fonları yine de taşıyamaz.

Bununla birlikte, bir sorun var: Cüzdana katılım sırasında, donanım imzalayan kişi, genel anahtarı (xpub) oluşturabilen tek varlıktır. key_ledger cüzdanda kullanılır. Bu nedenle, cihaz kasıtlı olarak bir yanlış xpub saldırgan tarafından kontrol edilir ve daha sonra imzalamayı reddeder (veya imzalayamaz). Muhtemelen, bu oldukça aşırı bir saldırı senaryosudur: arka kapı yaratıcısı fonları çalamaz ve yapabileceği en fazla şey kullanıcıyı bireysel olarak hedef alıp fidye talep etmektir ("Yarısını bana ödersen paranı geri almana yardım edebilirim").

Daha gerçekçi olarak, bu, hata yapma olasılığını artırır: artık iki çekirdeğiniz / özel anahtarınız var ve ihtiyacınız var her ikisi de harcayabilmek için. İkisini de kaybederseniz paralar sonsuza kadar kilitlenir.

İkinci adım: zaman kilitli kurtarma

Yalnızca belirli bir zaman kilidinden sonra erişilebilen ayrı bir kurtarma anahtarı sunuyoruz: and(older(25920), pk(key_recovery))25920, 6 aydaki yaklaşık blok sayısıdır. Tam politika şu hale gelir:

or(
  and(pk(key_ledger), pk(key_client)), and(after(25920), pk(key_recovery))
)

Bu, önceki senaryoya benzer, ancak bir farkla: eğer key_ledger or key_client herhangi bir nedenle kullanılamıyorsa (çoğunlukla çekirdek yedeğinin kaybedilmesi!), kurtarma yolu 6 ay sonra erişilebilir hale gelir.

için birkaç seçenek var key_recovery, her birinin kendi ödünleşimleri var:

a. Başka bir tane kullan Hot Key. Kullanıcı zaman kilidini sıfırlamayı hatırladığı sürece bu pratik bir çözümdür. Ancak, kısayol tuşlarının güvenliği ihlal edilirse (genelde oldukça muhtemel kabul edilmesi gereken bir senaryo!), saldırgan zaman kilidi sona erer erişmez fonlara erişmeye çalışabilir ve yasal sahiple bir yarış başlatabilir.

b. Ayrı bir donanım imzalama cihazı kullanın. Bu sağlam bir çözümdür ve istenirse farklı bir satıcıyla birlikte kullanılabilir; ancak, kullanıcı deneyimi açısından kurulum karmaşıklığını ve kullanıcı için maliyeti artırır.

c. Güvenilir bir harici hizmet kullanın. Yazılım cüzdanı, harici bir hizmetten bir xpub'ı şu şekilde kullanarak içe aktarabilir: key_recovery. Bu üçüncü taraf, yalnızca zaman kilidinin süresi dolduğunda güvenilir; bu, bazı kullanıcılar için çekici bir değiş tokuş olabilir.

Bahsedildiği gibi, zaman kilitli herhangi bir politikada olduğu gibi, kullanıcının zaman kilidinin sona ermesinden önce madeni paraları yenilemeyi hatırlaması önemlidir.

Üçüncü adım: güvenilmeyen üçüncü taraf

Her iki fikri (a) ve (c) harmanlayalım: kurtarma yolu için yerel bir kısayol anahtarına ihtiyacımız var key_recovery_localVe key_recovery_remote yarı güvenilir bir hizmetle barındırılan; zaman kilidini de koruyoruz.

or(
and(pk(key_ledger), pk(key_client)),
  and(older(25920),
    and(pk(key_recovery_local), pk(key_recovery_remote))
)
)

Bu, kurtarma hizmeti için gereken güven düzeyini azaltır. Ancak dikkatli olmalıyız: hizmetin kendisi blok zinciri izliyor ve UTXO'larımızı tespit ediyor olabilir - sonuçta bize şu bilgileri sağladılar: key_recovery_remote xpub, böylece türetilen pubkey'leri içeren UTXO'ları tarayabilirler. key_recovery_remote. Zaman kilidinin süresi dolmadan ve biz onların hizmetlerinden hiç yararlanmamış olsak bile mali geçmişimizi öğrenebilecekler.

Açıklama: Taproot ağaçları, belirli politikalar için bu gizlilik sorununu ortadan kaldırabilir, ancak bu her zaman böyle değildir ve belirli politikaya dayalı olarak dikkatli bir değerlendirme gerektirir.

Dördüncü adım: üçüncü tarafı kör edin 🙈

Kurtarma hizmetinin finansal geçmişimizi öğrenmesini önlemek için bize ilettikleri pubkey yerine bir kör xpub teknik mflaxman tarafından burada ayrıntılı olarak açıklanmıştır. Kısacası kullanmak yerine key_recovery_remote politikamızda dört adet 31 bitlik rasgele sayı seçiyoruz a, b, c, d ( kör edici faktörler) ve aşağıdakileri kullanırız BİP-32 türetilmiş pubkey:

key_recovery_remote_blind = key_recovery_remote_blind/a/b/c/d

Ayrıca eklememiz çok önemli key_recovery_remoteve kör edici faktörler a, b, c ve d ileride başvurmak üzere yedeklememize.

Kurtarma hizmetini kullanmamız gerekirse, açıklayacağız a, b, c, d onlara. O zamana kadar, kendi anahtarlarından türetilen anahtarları keşfetmelerinin hiçbir yolu yoktur. key_recovery_remote blok zincirinde yayınlanıyor: 4 kör etme faktörü için olası kombinasyonların sayısı 2^(31*4) = 2^124, bu da hepsini kaba kuvvetle zorlamayı imkansız kılar.

Beşinci adım: çok fazla kısayol tuşu canınızı yakabilir 🔥

Yazılım cüzdanımızı geri alınamaz hale getirmeyi başardık. Ancak, farklı bir sorunla karşılaştık: Her iki harcama koşulu da yerel olarak üretilen, Sıcak donanım cüzdanı tarafından doğrulanmayan anahtar. Bu nedenle, ana makinenin güvenliği ihlal edilmişse, pubkey'leri kullanarak politikayı kaydetmeniz için sizi kandırabilir. key_client ve key_recovery_local, ancak yedeklememize rastgele, ilgisiz özel anahtarlar koyun (unutmayın, Sıcak anahtarlar yedeklememizin bir parçasıdır!).

Bu temelde cüzdana gönderilen herhangi bir parayı yapar harcanamaz, imzalamak için gerekli özel anahtarları kimse kontrol etmediğinden.

Bu sorunu çözmek için birkaç çözüm var:

• Onboarding sırasında, yedeğimizi kağıda yazdırdıktan sonra, yedeklemedeki özel ve genel kısayol tuşlarının gerçekten eşleştiğini doğrulamak için ayrı bir cihaz kullanabiliriz. Yeniden yapılandırma ve imzalama için gerekli tüm anahtarlara sahip olduğumuzdan emin olacağımız için bu yaklaşım sorunu ortadan kaldıracaktır.
• Yalnızca daha uzun bir zaman kilidi (9 ay, 38880 blok) ile başka bir harcama koşulu ekleyebiliriz. key_ledger_failsafe donanım aygıtından. Bu şekilde, diğer her şeyin başarısız olduğu mutlak en kötü durum senaryosunda, tek bir imzalama cihazının güvenliğine geri dönüyoruz. Normal işlemlerde, birinci zaman kilidinin sona ermesine asla izin vermeyiz, dolayısıyla ikinci zaman kilidinin de süresi dolmaz!

İkinci yaklaşımla, nihai politika şöyle görünecektir

or(
  and(pk(key_ledger), pk(key_client)),
  or(
    and(older(25920),
        and(pk(key_recovery_local), pk(key_recovery_remote_blind))
    ),
    and(older(38880), pk(key_ledger_failsafe))
  ),
)

Bu yazılım cüzdanı yapılandırması, başta iddia ettiğimiz tüm güvenlik özelliklerini karşılar. Ayrıca, ana harcama anahtarları durumunda bir kurtarma yolu sunar. key_ledger kayıp. Sahip olmak için güzel bir özellik!

Geri alınamaz yazılım cüzdanına katılım

Bu kadar karmaşık bir politika kullanan bir cüzdan için kullanıcı deneyimi nasıl olur? İşte kısa bir genel bakış:

• Kullanıcı, yazılım cüzdanını açar ve yeni bir hesap oluşturmaya başlar.
• Yazılım cüzdanı, kullanıcıdan imzalama cihazını bağlamasını ister ve xpub'ları alır. key_ledger ve key_ledger_failsafe.
• Yazılım cüzdanı, key_client kısayol anahtarını otonom olarak oluşturur.
• Yazılım cüzdanı elde eder key_recovery_remote bir ortak imzalama hizmetinden veya kullanıcının bir anahtarı başka bir şekilde belirtmesine izin verir. İsteğe bağlı olarak, key_recovery_remote_blind daha önce bahsedilen körleme tekniğini kullanarak.
• Yazılım cüzdanı, kesin miniscript politikasını, tüm xpub'ları ve genişletilmiş özel anahtarı içeren bir politika yedeği oluşturur. key_client kısayol tuşu. Bu yedekleme güvenli bir şekilde saklanır (örneğin, kağıda yazdırılır veya ayrı bir cihaza kaydedilir).
• Son olarak, yazılım cüzdanı, kullanıcıya politikayı cihaza kaydetmesi talimatını verir. Kullanıcı, yedeği çapraz kontrol eder (kağıt üzerinde veya yazılım cüzdanı tarafından kontrol edilen ekran dışında herhangi bir ortamda).

Yazılım cüzdanı, yukarıdaki adımların çoğunu yöneterek kullanıcının katılımını, çoklu imzalı bir cüzdan kurmak için bugün gereken beklenen çabadan daha külfetli hale getirmez.

İyi bir kullanıcı deneyimi oluşturulduktan sonra işe alım yalnızca birkaç dakika sürmelidir. Yazılım cüzdanı tamamlandığında, tipik bir tek imza cüzdanına çok benzer bir kullanıcı deneyimi sağlayabilir. Miniscript her şeyi böyle değiştirecek: kullanıcının gözünden kaybolarak!

Taproot iyileştirmeleri

Ledger, Mart ayında yayınlanan Bitcoin uygulamasının 2.1.0 sürümünden bu yana miniscript'i desteklemektedir. Taproot adreslerine alma ve bu adreslerden harcama desteği etkinleştirildiğinden beri kökten softfork Kasım 2021'de yol haritasının bir sonraki adımı olan taproot için miniscript desteği için son rötuşları yapıyoruz.

Taproot, bu makalede sunulan yaklaşımların kullanılabilirliği üzerinde büyük bir etkiye sahip olacaktır. Birincil harcama yolu tek anahtarlı bir harcama koşuluysa, geri kazanım harcama yollarının varlığı, kullanılmadıkları sürece blok zincirinde tespit edilemez. Bu, standart harcama yolu için parmak izlerini tamamen ortadan kaldırarak gizliliği büyük ölçüde artıracaktır. Ayrıca, standart harcama yolu mümkün olduğu kadar uygun maliyetli hale geldiğinden ölçeklenebilirliği artırır. Bu, kullanılmadıkları sürece kurtarma yollarının varlığı nedeniyle hiçbir ek maliyetin oluşmayacağı anlamına gelir. Bu, herhangi bir harcama sırasında tüm harcama koşulları da dahil olmak üzere tüm komut dosyasının yayınlanmasını gerektiren SegWit işlemlerinden önemli bir yükseltmedir.

Son olarak, daha gelişmiş protokoller gibi MuSig2 (yakın zamanda standardize edilmiş) ve DON taproot anahtar yolunu güçlendirecektir. Schnorr imzaları üzerine inşa edilen bu protokoller, tek bir toplam pubkey temsil etmek için kullanılabilecek bir n-Of-n çoklu imza veya k-Of-n eşik şeması. Bu, günümüzde daha yaygın olarak belirli multisig betikleriyle temsil edilen durumlarda bile taproot anahtar yolunun kullanılmasına izin verir.

Sonuç

Bu makale, miniscript'in yazılım cüzdanları için serbest bıraktığı geniş tasarım alanının küçük (ama önemli) bir nişini araştırıyor.

Miniscript'in "geri alınamaz" bir yazılım cüzdanı oluşturmak için nasıl kullanılabileceğini gösterdik ve aynı zamanda feci anahtar kayıplarını önlemeye izin veren ek bir kurtarma yolu ekledik. Donanım imzalama cihazları arka kapı karşıtı güvenlik modelini uygulayamazken, miniscript'i destekleyerek tam olarak bunu yapan yazılım cüzdanlarını etkinleştirirler!

Çoklu imza şemaları, zaman kilitleri, kör xpub'lar ve kısayol tuşlarının bir kombinasyonunu akıllıca kullanarak güvenlik, gizlilik ve sağlamlığı dengeleyen güvenli bir cüzdan yapılandırması gösterdik.

Ayrıca, kurulumun karmaşıklığı büyük bir ek UX yüküne dönüşmediğinden, bunun kullanıcı deneyimini olumsuz etkilemeden mümkün olduğunu savunduk.

Miniscript'in yeni nesil bitcoin kendi kendine velayeti için kilidini açacağı olasılıklar için heyecanlıyız.

• SEO Destekli İçerik ve Halkla İlişkiler Dağıtımı. Bugün Gücünüzü Artırın.
• PlatoData.Network Dikey Üretken Yapay Zeka. Kendine güç ver. Buradan Erişin.
• PlatoAiStream. Web3 Zekası. Bilgi Genişletildi. Buradan Erişin.
• PlatoESG. Otomotiv / EV'ler, karbon, temiz teknoloji, Enerji, Çevre, Güneş, Atık Yönetimi. Buradan Erişin.
• Blok Ofsetleri. Çevre Dengeleme Sahipliğini Modernleştirme. Buradan Erişin.
• Kaynak: https://www.ledger.com/blog/towards-a-trustless-bitcoin-wallet-with-miniscript