Apparaten voor hardwareondertekening zijn ontworpen om de gebruiker te beschermen tegen verschillende veelvoorkomende aanvalsvectoren, zoals:

• Ongeoorloofde toegang en extractie van het zaad
• Malware die uw bijbehorende softwareportemonnee infecteert
• Softwarekwetsbaarheden op het apparaat zelf

Zoals elk bedrijf is het in het belang van de fabrikant om apparaten zo te maken onbreekbaar zoals ze kunnen. Het slagen in deze missie is van het grootste belang, en beveiligingsbedrijven zoals Ledger vertrouwen op een reputatie die is gebaseerd op hun staat van dienst.

Sommige gebruikers kunnen zich echter nog steeds zorgen maken. Wat weerhoudt het bedrijf er zelf van om a achterdeur in de apparaten?

In zelfbewaring, wij vertrouw niet, wij verifiëren.
Maar kan de gebruiker werkelijk controleren of een apparaat geen achterdeur heeft?

Dat is de hamvraag waar dit artikel op ingaat. Meer precies behandelt dit artikel de volgende onderwerpen:

• wat is een achterdeur en waarom is het moeilijk, zo niet onmogelijk, om te bewijzen dat er geen is;
• waarom alleen gebruikers zichzelf tegen dit risico kunnen beschermen;
• hoe miniscript praktische oplossingen biedt voor deze uitdaging voor bitcoin-wallets.

Door de eerste hardware wallet te zijn die wordt ondersteund minischrift, hopen we ontwikkelaars te inspireren om veilige oplossingen te bouwen en onze hele branche te upgraden, en de kans te elimineren dat een dergelijk systeemrisico zich ooit voordoet.

Hoe de te bouwen niet achterhaalbaar ondertekenapparaat

Laten we het duidelijk zeggen: dat kan niet.

Om jezelf te verdedigen tegen een mogelijke achterdeur heb je een ander aanvalsmodel nodig dan het model dat we hierboven hebben geschetst: in dit scenario kan de tegenstander de verkoper zelf zijn, of een corrupte insider.

De vaak aangeprezen oplossing voor dit probleem is Open Source: als je de code kunt inspecteren, wat kan er dan mis gaan?

De waarheid is echter complexer. Aangezien de verkoper de hardware assembleert, kan er een achterdeur volledig in zitten. De hardware kan zijn ontworpen om de software op bepaalde punten te negeren en in plaats daarvan kwaadaardige code uit te voeren.

In tegenstelling tot software die wordt uitgevoerd op algemene computerapparatuur (zoals uw laptop of telefoon), is het met de huidige technologie praktisch onmogelijk om de hardware nauwkeurig te onderzoeken. Zelfs als de hardwarespecificaties volledig open source waren, compleet met de details van elke afzonderlijke poort in het circuit, zou je nog steeds dure apparatuur nodig hebben om te verifiëren dat een specifieke chip in overeenstemming hiermee is gebouwd.

Hoe een hardware wallet te backdooren

Hier zijn enkele van de eenvoudigste methoden die een kwaadwillende hardwareleverancier zou kunnen gebruiken om een ​​achterdeur te introduceren, samen met enkele manieren waarop ervaren gebruikers zichzelf tegenwoordig kunnen beschermen.

Zaad generatie

Veel apparaten bieden je de mogelijkheid om een ​​seed te genereren (ook wel de Geheime herstelzin) rechtstreeks op het apparaat, met behulp van een Echte willekeurige nummergenerator.

😈 Het kwaadaardige apparaat kan zaden genereren die willekeurig lijken, maar in werkelijkheid voorspelbaar zijn voor de aanvaller.

🛡️ Krachtige gebruikers kunnen dit probleem omzeilen door offline een geheugensteuntje te genereren. Bovendien is het opnemen van een robuust passphrase kan ook een volledig onafhankelijke seed genereren die de hardwareleverancier niet kan voorspellen. De wisselwerking is dat gebruikers ervoor moeten zorgen dat ze naast de geheugensteuntjes ook een goede back-up maken van de wachtwoordzin.

Afleiding van openbare sleutels

Hardware wallets ontlenen en exporteren de openbare sleutels (ook wel genoemd xpubs, kort voor uitgebreide openbare sleutel zoals gedefinieerd in BIP-32. De xpubs worden gebruikt om de mogelijke adressen voor het ontvangen van munten te genereren.

😈 Het kwaadaardige apparaat kan openbare sleutels retourneren die door de aanvaller worden beheerd in plaats van de juiste die zijn afgeleid van het zaad.

🛡️ Gebruikers kunnen de afgeleide valideren xpub op een ander, offline apparaat. Het invoeren van het zaad op andere apparaten brengt echter zijn eigen risico's met zich mee. Beveiligingsbewuste gebruikers kunnen elk apparaat dat toegang heeft tot de seed als gevaarlijk beschouwen, mogelijk zelfs tot het punt dat ze worden vernietigd. De typische gebruiker kan moeite hebben om deze procedure correct uit te voeren terwijl hij de extra risico's beheert.

Lekkende informatie

An luchtgat wordt vaak voorgesteld als een oplossing om te voorkomen dat een kwaadaardig of gecompromitteerd apparaat privésleutels exfiltreert. Immers, als een apparaat niet kan communiceren met de buitenwereld, kan het ook niets schadelijks doen, toch?

Niet helemaal!

Het apparaat kan altijd communiceren wanneer het in gebruik is: het produceert handtekeningen. Deze handtekeningen komen terecht in transacties die worden uitgezonden en voor altijd worden opgeslagen op de blockchain.

Een handtekening is een willekeurig ogende bytestring van minimaal 64 bytes. Aangezien er echter meer dan één geldige handtekening kan corresponderen met hetzelfde bericht, kan een kwaadaardig apparaat elke keer dat een handtekening wordt aangemaakt een paar stukjes informatie doorgeven door meerdere handtekeningen te genereren en selectief te kiezen welke het wil publiceren.

😈 Een malafide apparaat kan niet-willekeurige handtekeningen produceren die, na veel transacties, het zaad aan de aanvaller onthullen!

Een aanvaller die erin slaagt zo'n achterdeur te installeren, hoeft alleen maar te wachten tot kwaadaardige handtekeningen op de blockchain verschijnen totdat hij genoeg informatie heeft om het hele zaad te reconstrueren.

🛡️ Gebruik voor ECDSA-handtekeningen een gestandaardiseerde methode om de nonce deterministisch af te leiden (zoals RFC6979) verijdelt deze aanval, op voorwaarde dat men valideert dat de geproduceerde handtekening overeenkomt met de verwachte. Om ervoor te zorgen dat dit het geval is, moet echter een tweede apparaat met hetzelfde zaad worden geladen, wat leidt tot dezelfde praktische problemen als vermeld in de vorige sectie.

🛡️ Een interessante benadering is om op een slimme manier te gebruiken dwingen het apparaat om daadwerkelijk een willekeurige nonce te kiezen. Hiervoor is een protocol, de zgn anti-exfil or anti-klepto, is momenteel geïmplementeerd in Blockstream Jade en ShiftCrypto BitBox02 hardware wallets. Lees meer op ShiftCrypto's blog, die ook een technische beschrijving bevat van hoe een dergelijke aanval kan worden uitgevoerd.

Oké dan, is er geen hoop?

De meeste van de hierboven genoemde verdedigingen🛡️ vereisen meestal dat de gebruiker expliciete, opdringerige acties uitvoert om zichzelf te beschermen: ofwel door het zaad zelf te genereren (in wezen door hun hersens te gebruiken om de functionaliteit van de hardware-portemonnee te vervangen), of door een extra apparaat te gebruiken om te verifiëren dat berekeningen correct worden uitgevoerd.

Het anti-exfil-protocol valt echter op: aangezien er altijd een machine is die bemiddelt tussen de hardware-ondertekenaar en de buitenwereld, kan deze machine helpen. Via een interactief protocol met de hardware-ondertekenaar kan dat afdwingen het gebruik van een echt willekeurige nonce, waardoor de kans op significante manipulatie van de definitieve handtekening wordt verkleind of geëlimineerd.

In deze blogpost zijn we vooral geïnteresseerd in dit soort maatregelen: terwijl strategieën die de UX aanzienlijk verslechteren, aantrekkelijk kunnen zijn voor ervaren gebruikers, zullen ze waarschijnlijk dingen maken erger in de praktijk voor de minder technisch onderlegde gebruikers − wat de overgrote meerderheid is.

Het beveiligingsmodel

Standaardmodel voor hardware-ondertekenaars

Fabrikanten van hardware-ondertekenaars proberen gebruikers te beschermen tegen verschillende potentiële bedreigingen (zie voor meer informatie Bedreigingsmodel). In dit artikel richten we ons op één zeer belangrijke eigenschap, die als volgt kan worden samengevat:

Gebruikers kunnen niet worden misleid tot een actie die leidt tot verlies van geld, op voorwaarde dat ze de informatie op het scherm begrijpen en verifiëren voordat ze worden goedgekeurd.

Goedkeuring is vereist voor elke gevoelige actie, met name handtekeningen. Het beschermen van het zaad zou zinloos zijn als malware handtekeningen zou kunnen produceren voor willekeurige berichten, zoals een transactie die al het geld opslokt!

Het is van cruciaal belang om te benadrukken dat de bovenstaande eigenschap moet gelden, zelfs als de softwareportemonnee volledig is gecompromitteerd. Wat op het scherm van uw laptop/telefoon wordt weergegeven, kan niet worden vertrouwd: malware kan adressen vervangen, u misleiden over welke adressen van u zijn, een transactie presenteren maar vervolgens een andere naar het apparaat doorsturen voor ondertekening, enz.

Daarom houden de firmware en applicaties die op een hardware-ondertekeningsapparaat worden uitgevoerd, inherent rekening met de softwareportemonnee niet vertrouwd en onbetrouwbaar.

Anti-backdoor-beveiligingsmodel voor softwareportefeuilles

In deze sectie draaien we de rollen volledig om. We willen nu een ontwerp maken software portemonnee die voorkomt dat de hardwarefabrikant steelt of fondsverlies veroorzaakt, zelfs als het apparaat volledig kwaadaardig is.

Daarom kan dit geen eigenschap zijn van de apparaat: het is eerder een eigenschap van de software portemonnee opgericht. We zouden het als volgt kunnen samenvatten:

Op voorwaarde dat de softwareportemonnee niet is gecompromitteerd, kan de hardwarefabrikant er niet voor zorgen dat de gebruiker geld verliest.

Dit lijkt misschien contra-intuïtief, omdat het rechtstreeks in tegenspraak is met het hierboven beschreven standaard beveiligingsmodel. "Geen achterdeur hebben" betekent echter "precies doen wat ze moeten doen". Omdat de softwareportemonnee de zon interface tussen het ondertekeningsapparaat en de buitenwereld, het is de enige plaats waar bescherming tegen wangedrag kan worden afgedwongen, of het nu gaat om een ​​bug of expliciete inbreuk op het apparaat.

Merk op dat dit model veel verder gaat dan een apparaatfout, zoals een exploiteerbare bug. In dit geval werken we binnen een scenario waarin het apparaat actief probeert geldverlies te veroorzaken.

Natuurlijk is er geen mogelijke bescherming als de fabrikant met succes een compromis heeft gesloten zowel het apparaat en ook uw machine waarop de softwareportemonnee draait. Daarom is het absoluut essentieel om ervoor te zorgen dat uw softwareportemonnee Open Source is en controleerbaar is, vooral als deze is gebouwd door dezelfde leverancier die de hardware produceert.

De rol van miniscript

Miniscript voorziet portemonnee-ontwikkelaars van de mogelijkheid om de geavanceerde functies van bitcoin Script volledig te benutten. Raadpleeg voor een overzicht van de ongelooflijke mogelijkheden die miniscript ontgrendelt onze vorige blogpost. Misschien wil je er ook naar luisteren Aflevering 452 van de Stephan Livera Podcast voor een discussie over wat miniscript toevoegt aan het bitcoin-landschap.

De Ledger Bitcoin-app ondersteunt miniscript sinds de 2.1.0-release, die in februari 2023 werd geïmplementeerd. Op de Bitcoin 2023-conferentie in Miami kondigde Wizardsardine de 1.0-release aan van hun Liana portemonnee, de eerste geïmplementeerde portemonnee op basis van miniscript.

Het basisidee van dit bericht is dat een bitcoin-portemonnee-account niet alleen met één, maar met kan worden beschermd meervoudig sleutels. Dit maakt flexibele beveiligingskaders mogelijk waarbij zelfs een totale storing of compromis van een sleutel niet catastrofaal is.

Multisig-mijmeringen

Multisig is een aanzienlijke verbetering van de kracht van een self-custody-oplossing. Door gebruik te maken van de programmeerbaarheid van Bitcoin Script, kunnen portemonnees worden gemaakt waarvoor meerdere sleutels nodig zijn in plaats van slechts één. A k-van-n multisig wallet vereist een combinatie van k geldige handtekeningen, op een totaal van n mogelijke.

Multisig legt echter ook een UX-last op de gebruiker en introduceert nieuwe mogelijkheden voor fouten. Een 3-van-3 multisig-configuratie, waarbij drie verschillende sleutels veilig op afzonderlijke locaties worden geback-upt, biedt een sterke beveiliging... maar het betekent ook dat als zelfs een single sleutel verloren is, zijn de munten permanent ontoegankelijk!

Daarom zijn configuraties die meer redundantie bieden (zoals 2-van-3 of 3-van-5) populairder: als een enkele sleutel verloren gaat, kunnen de andere sleutels nog steeds het herstel vergemakkelijken. Maar dit brengt een afweging met zich mee: als een sleutel wordt gecompromitteerd zonder dat u het weet, wordt de algehele beveiliging aanzienlijk verminderd!

Bedrijven houden van huis en Ontketend kapitaal gespecialiseerd in self-custody-oplossingen waarbij ze een minderheid van de sleutels voor hun klanten in handen hebben. Ze helpen hun gebruikers ook door hen door het onboardingproces te leiden en het gebruik van bewaringssystemen te vereenvoudigen, wat anders voor de meeste niet-technische gebruikers ontmoedigend kan zijn.

Miniscript en tijdvergrendelde herstelpaden

Liana gebruikt miniscript om portefeuilles te maken die op meerdere manieren kunnen worden uitgegeven:

• een primaire bestedingsvoorwaarde, die direct beschikbaar is;
• een of meer aanvullende bestedingsvoorwaarden die na een bepaalde periode beschikbaar komen (de zgn tijdslot).

Dit maakt veel interessante use-cases mogelijk:

• Herstel: Een standaardportemonnee met een enkele handtekening of multisig als primair bestedingspad; maar een apart herstelmechanisme (een sleutel met een andere seed, een multisig, een technisch onderlegde vriend, een bewaarder) komt na 6 maanden beschikbaar.
• Bestuur: Een bedrijf met twee bestuurders zou een 2-uit-2 kunnen vaststellen voor de schatkist van het bedrijf; in geval van onenigheid kan een vertrouwde advocaat na 6 maanden toegang krijgen tot het geld.
• Vervallen multisig: Een portemonnee begint als een 3-van-3, gaat na 2 maanden over in een 3-van-6 en wordt na 1 maanden een 3-van-9.
• Automatische erfenis: Het hersteltraject na 6 maanden omvat een 2-op-3 van uw drie kinderen; eventueel een tweede hersteltraject na 1 jaar via een notaris, voor het geval de erfgenamen het niet eens kunnen worden.

Opmerking: alle bovenstaande voorbeelden gebruiken a relatief tijdslot, wat verwijst naar de ouderdom van de munten (dat wil zeggen: de laatste keer dat het geld is verplaatst). De wisselwerking is dat de gebruiker moet onthouden om de munten uit te geven (door ze naar zichzelf te sturen) als het tijdslot bijna afloopt.

Dit zijn slechts enkele voorbeelden, maar ze zouden genoeg moeten zijn om de lezer ervan te overtuigen dat miniscript een belangrijke stap voorwaarts is in de richting van het realiseren van het potentieel van Bitcoin als programmeerbaar geld.

Portefeuillebeleid registratie

Voor Bitcoin-portemonneeaccounts die meerdere sleutels gebruiken (of het nu gaat om multisig of meer geavanceerde op miniscript gebaseerde oplossingen), is het cruciaal om het apparaat te trainen om de adressen te identificeren die bij dat account horen. Dit is de enige manier waarop het apparaat de gebruiker kan helpen ervoor te zorgen dat ze van de juiste adressen ontvangen of uitgeven...

Het valideren van het beleid en de xpubs van de medeondertekenaar tegen een vertrouwde back-up is essentieel, maar relatief tijdrovend.
Het goede nieuws is dat het maar één keer hoeft te gebeuren:

Zodra een polis is geregistreerd met een naam (in het voorbeeld "Decaying 3of3"), kan uw apparaat deze herkennen wanneer een dergelijke polis wordt toegepast.

Geïnteresseerden in technische details kunnen meer informatie vinden in de BIP voorstel.

Beleidsback-up

Een cruciaal aspect om op te merken is dat hoewel beleid met meerdere sleutels een subset van de persoonlijke sleutels om transacties te autoriseren, de kennis van allen de openbare sleutels (en de exact beleid) zijn vereist.

In tegenstelling tot het zaad, is het maken van een back-up van het beleid en de openbare sleutels echter veel minder riskant: als iemand het zou ontdekken, zou hij alle transacties kunnen traceren die aan dat beleid zijn gekoppeld. Hoewel dit niet ideaal is, is privacy belangrijk! − het is niet zo rampzalig als het verliezen van je munten en minder aantrekkelijk voor potentiële aanvallers. Bijgevolg zijn het allemaal haalbare strategieën om meerdere exemplaren van het beleid op te slaan in hot wallets, het af te drukken en op verschillende plaatsen op te slaan, het te versleutelen en op te slaan in cloudopslag, enzovoort.

De unbackdoorable single-signature portemonnee

Laten we een stap terug doen. We hebben portemonnees met meerdere handtekeningen besproken, maar nu gaan we terug naar de basis om een ​​portemonnee met één handtekening te maken. Meer precies, we willen een portemonnee die voelt zich en er gezonder uitzien zoals een portemonnee met één handtekening, na een initiële installatiefase. Toch streven we ernaar een portemonnee te creëren waarvan de fabrikant uw geld niet kan stelen, zelfs niet als ze kwaadaardig zijn 😈, en het hardware-ondertekeningsapparaat gedraagt ​​zich op onvoorspelbare manieren.

De aanpak kan eenvoudig worden gegeneraliseerd voor portefeuilles met meerdere handtekeningen.

De onderstaande voorbeelden zijn geschreven in een taal genaamd beleidsmaatregelen, in plaats van miniscript. Beleid is voor mensen gemakkelijker te lezen en te overdenken, en kan met geautomatiseerde tools worden gecompileerd tot miniscript. Lees meer over miniscript en beleid.

De hardware wallet kan je beschermen in het standaard beveiligingsmodel. Miniscript kan u beschermen in het anti-backdoor-beveiligingsmodel (en nog veel meer!).

Stap nul: de status quo

Dit is het beleid dat de meeste gebruikers tegenwoordig gebruiken: een enkele sleutel die is afgeleid van een seed die is geproduceerd in de hardware wallet.

pk(key_ledger)

Er is natuurlijk geen manier om de afwezigheid van een achterdeur te bewijzen.

Stap één: verdubbel die sleutels

De eerste stap is eenvoudig:

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

Hier key_client wordt gegenereerd op de computer van de gebruiker, dus a Sneltoets. In wezen is het een 2-van-2 multisig-opstelling. Het belangrijkste aspect is dat de gebruiker er niet veel mee communiceert key_client: de softwareportemonnee genereert deze sleutel, neemt deze op in de back-up van de portemonnee en ondertekent wanneer nodig (bijvoorbeeld terwijl de gebruiker bezig is met ondertekenen met zijn hardware-ondertekenaar).

Dit lijkt al best interessant: de fondsen zijn niet uit te geven zonder key_client, die niet beschikbaar is voor de hardwareleverancier; zelfs als de kwaadwillende verkoper volledige kennis had van de sleutel in het apparaat, zou hij nog steeds niet in staat zijn om het geld te verplaatsen zonder zich expliciet op de gebruiker te richten, bijvoorbeeld door de machine te compromitteren waarop hun softwareportemonnee draait.

Er is echter een probleem: tijdens het onboarden van de portemonnee is de hardware-ondertekenaar de enige entiteit die de openbare sleutel kan genereren (xpub) key_ledger gebruikt in de portemonnee. Daarom kan het apparaat opzettelijk een verkeerd xpub gecontroleerd door de aanvaller, en later weigeren (of niet in staat zijn) om te ondertekenen. Dit is waarschijnlijk een vrij extreem aanvalsscenario: de maker van de achterdeur kan het geld niet stelen, en het meeste wat ze kunnen doen is de gebruiker individueel aanvallen en losgeld eisen ("Ik kan u helpen uw geld terug te krijgen als u de helft aan mij betaalt").

Realistischer gezien vergroot dit de kans op vergissingen: je hebt nu twee seed/private keys, en die heb je nodig zowel om te kunnen besteden. Verlies een van beide en munten zijn voor altijd vergrendeld.

Stap twee: tijdgebonden herstel

We introduceren een aparte herstelsleutel, die alleen toegankelijk is na een specifiek tijdslot: and(older(25920), pk(key_recovery)), waarbij 25920 het geschatte aantal blokken in 6 maanden is. Het volledige beleid wordt:

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

Dit is vergelijkbaar met het vorige scenario, maar met een twist: als key_ledger or key_client om welke reden dan ook niet meer beschikbaar is (meestal verlies van de seed-back-up!), a herstel pad wordt toegankelijk na 6 maanden.

Er zijn verschillende opties voor key_recovery, elk met zijn eigen afwegingen:

a. Gebruik een andere Sneltoets. Dit is een praktische oplossing zolang de gebruiker eraan denkt het tijdslot te resetten. Als de sneltoetsen echter worden gecompromitteerd (een scenario dat over het algemeen als zeer waarschijnlijk moet worden beschouwd!), kan de aanvaller proberen toegang te krijgen tot het geld zodra het tijdslot afloopt, waardoor een race met de legitieme eigenaar wordt gestart.

b. Gebruik een apart hardware-ondertekeningsapparaat. Dit is een robuuste oplossing en kan desgewenst in combinatie met een andere leverancier worden gebruikt; het verhoogt echter de installatiecomplexiteit en de kosten voor de gebruiker in termen van gebruikerservaring.

c. Gebruik een vertrouwde externe service. De softwareportemonnee kan een xpub van een externe service importeren en gebruiken als key_recovery. Deze derde partij wordt alleen vertrouwd als het tijdslot verloopt, wat voor sommige gebruikers een aantrekkelijke afweging kan zijn.

Zoals vermeld, is het, zoals voor elk beleid met tijdsloten, belangrijk dat de gebruiker eraan denkt de munten te vernieuwen voordat het tijdslot verloopt.

Stap drie: de niet-vertrouwde derde partij

Laten we beide ideeën (a) en (c) combineren: voor het herstelpad hebben we een lokale sneltoets nodig key_recovery_localEn een key_recovery_remote die wordt gehost met een semi-vertrouwde service; ook behouden we het tijdslot.

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

Dit verlaagt het vereiste vertrouwensniveau van de herstelservice. We moeten echter voorzichtig zijn: de service zelf zou de blockchain kunnen monitoren en onze UTXO's kunnen detecteren - ze hebben ons tenslotte de key_recovery_remote xpub, zodat ze kunnen scannen op UTXO's die pubkeys bevatten die zijn afgeleid van key_recovery_remote. Ze zullen onze financiële geschiedenis kunnen leren kennen, zelfs voordat het tijdslot afloopt, en zelfs als we nooit gebruik hebben gemaakt van hun service.

Opmerking: Taproot-bomen kunnen dit privacyprobleem voor bepaalde beleidsregels oplossen, maar dit is niet altijd het geval en vereist zorgvuldige evaluatie op basis van het specifieke beleid.

Stap vier: verblind de derde partij 🙈

Om te voorkomen dat de hersteldienst achter onze financiële geschiedenis komt, kunnen we in plaats van de pubkey te gebruiken die ze ons meedelen, een blinde xpub techniek uitgelegd door mflaxman in detail hier. Kortom, in plaats van gebruiken key_recovery_remote in ons beleid kiezen we vier 31-bits willekeurige getallen a, b, c, d (De verblindende factoren), en we gebruiken het volgende BIP-32 afgeleide pubkey:

key_recovery_remote_blind = key_recovery_remote_blind/a/b/c/d

Het is cruciaal dat we ook toevoegen key_recovery_remoteen de verblindende factoren a, b, c en d naar onze back-up, voor toekomstig gebruik.

Als we ooit de herstelservice moeten gebruiken, zullen we dit onthullen a, b, c, d naar hen. Tot die tijd kunnen ze op geen enkele manier ontdekken dat de sleutels van hun zijn afgeleid key_recovery_remote worden gepubliceerd op de blockchain: het aantal mogelijke combinaties voor de 4 verblindende factoren is 2^(31*4) = 2^124, waardoor het onmogelijk is om ze allemaal met brute kracht te forceren.

Stap vijf: te veel sneltoetsen kunnen je verbranden 🔥

We zijn erin geslaagd om onze software wallet unbackdoorable te maken. We hebben echter een ander probleem geïntroduceerd: beide bestedingsvoorwaarden gebruiken een lokaal gegenereerde, warm sleutel die niet is geverifieerd door de hardware wallet. Daarom, als de hostmachine is gecompromitteerd, kan het u misleiden om het beleid te registreren met behulp van de pubkeys key_client en key_recovery_local, maar plaats willekeurige, niet-gerelateerde privésleutels in onze back-up (denk eraan, de warm sleutels maken deel uit van onze back-up!).

Dat zou in feite al het geld naar de portemonnee sturen onuitgeefbaar, aangezien niemand de privésleutels beheert die nodig zijn om te ondertekenen.

Er zijn een paar oplossingen om dit probleem op te lossen:

• Tijdens de onboarding kunnen we, nadat we onze back-up op papier hebben afgedrukt, een apart apparaat gebruiken om te controleren of de privé- en openbare sneltoetsen op de back-up inderdaad overeenkomen. Deze aanpak zou het probleem oplossen, omdat we er zeker van zouden zijn dat we alle vereiste sleutels hebben die nodig zijn voor reconstructie en ondertekening.
• We kunnen nog een bestedingsvoorwaarde toevoegen met een nog langer tijdslot (9 maanden, 38880 blokken) waarvoor slechts een key_ledger_failsafe van het hardwareapparaat. Op deze manier vallen we in het absolute worstcasescenario, waarin al het andere faalt, terug op de veiligheid van één enkel ondertekeningsapparaat. Bij normaal gebruik zouden we het eerste tijdslot nooit laten verlopen, dus het tweede tijdslot zal ook niet verlopen!

Met de tweede benadering zou het uiteindelijke beleid er als volgt uitzien

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))
  ),
)

Deze configuratie van de softwareportemonnee voldoet aan alle beveiligingseigenschappen die we in het begin beweerden. Bovendien biedt het een herstelpad voor het geval de belangrijkste bestedingssleutels key_ledger zijn verloren. Een leuke eigenschap om te hebben!

Onboarding naar de unbackdoorable software wallet

Hoe zou de gebruikerservaring voor een portemonnee met zo'n complex beleid eruit zien? Hier is een kort overzicht:

• De gebruiker opent de software wallet en begint een nieuw account aan te maken.
• De softwareportemonnee vraagt ​​de gebruiker om zijn ondertekeningsapparaat aan te sluiten en haalt de xpubs voor key_ledger en key_ledger_failsafe.
• De software wallet genereert autonoom de sneltoets key_client.
• De software wallet verkrijgt key_recovery_remote van een medeondertekeningsservice of stelt de gebruiker in staat om op een andere manier een sleutel op te geven. Optioneel berekent het de key_recovery_remote_blind met behulp van de eerder genoemde verblindingstechniek.
• De softwareportefeuille genereert een beleidsback-up met het precieze miniscriptbeleid, alle xpubs en de uitgebreide privésleutel voor de key_client sneltoets. Deze back-up wordt veilig opgeslagen (bijvoorbeeld geprint op papier of op een apart device).
• Ten slotte instrueert de softwareportemonnee de gebruiker om het beleid op het apparaat te registreren. De gebruiker controleert de back-up (op papier of op een ander medium dan het scherm dat wordt beheerd door de softwareportemonnee).

De softwareportefeuille beheert de meeste van de bovenstaande stappen, waardoor de betrokkenheid van de gebruiker niet zwaarder is dan de verwachte inspanning die vandaag nodig is om een ​​portefeuille met meerdere handtekeningen op te zetten.

De onboarding duurt slechts een paar minuten nadat er een goede UX voor is gebouwd. Eenmaal voltooid, kan de softwareportemonnee een gebruikerservaring bieden die sterk lijkt op die van een typische portemonnee met één handtekening. Dit is hoe miniscript alles zal veranderen: door uit het zicht van de gebruiker te verdwijnen!

Taproot-verbeteringen

Ledger ondersteunt miniscript sinds versie 2.1.0 van de Bitcoin-app, uitgebracht in maart. Terwijl ondersteuning voor het ontvangen van en besteden van taproot-adressen is ingeschakeld sinds de penwortel softfork in november 2021 leggen we nu de laatste hand aan de volgende stap van de roadmap: miniscript-ondersteuning voor taproot.

Taproot zal een enorme impact hebben op de bruikbaarheid van de benaderingen die in dit artikel worden gepresenteerd. Als het primaire uitgavenpad een single-key uitgavenvoorwaarde is, is het bestaan ​​van hersteluitgavenpaden niet detecteerbaar op de blockchain, tenzij ze worden gebruikt. Dit zal de privacy aanzienlijk verbeteren door alle vingerafdrukken voor het standaard bestedingspad volledig te elimineren. Bovendien verbetert het de schaalbaarheid, omdat het standaard bestedingspad zo kostenefficiënt mogelijk wordt om uit te geven. Dit betekent dat er geen extra kosten worden gemaakt vanwege de aanwezigheid van herstelpaden, tenzij deze worden gebruikt. Dit is een aanzienlijke upgrade ten opzichte van SegWit-transacties, waarvoor het volledige script moet worden gepubliceerd, inclusief alle uitgavenvoorwaarden, tijdens elke uitgave.

Eindelijk, meer geavanceerde protocollen zoals MuSig2 (onlangs gestandaardiseerd) en VORST zal het penwortel-sleutelpad een boost geven. Deze protocollen zijn gebouwd op Schnorr-handtekeningen en maken het mogelijk om er een te maken geaggregeerde pubsleutel die kan worden gebruikt om een n-van-n multisignatuur of een k-van-n drempel regeling. Dit zou het gebruik van het taproot-sleutelpad mogelijk maken, zelfs in gevallen die tegenwoordig vaker worden weergegeven met specifieke multisig-scripts.

Conclusies

Dit artikel verkent een kleine (maar belangrijke) niche van de enorme ontwerpruimte die miniscript ontketent voor softwareportefeuilles.

We hebben laten zien hoe miniscript kan worden gebruikt om een ​​"niet-achterdeurbare" softwareportemonnee te maken, terwijl we ook een extra herstelpad hebben toegevoegd waarmee rampzalige sleutelverliezen kunnen worden voorkomen. Hoewel apparaten voor hardwareondertekening het anti-backdoor-beveiligingsmodel niet kunnen afdwingen, maken ze door miniscript te ondersteunen softwareportefeuilles mogelijk die precies dat doen!

Door slim gebruik te maken van een combinatie van schema's met meerdere handtekeningen, tijdsloten, blinde xpubs en sneltoetsen, hebben we een veilige portefeuilleconfiguratie gedemonstreerd die veiligheid, privacy en robuustheid in balans houdt.

Bovendien voerden we aan dat dit mogelijk is zonder de gebruikerservaring negatief te beïnvloeden, aangezien de complexiteit van de installatie zich niet vertaalt in een grote extra UX-last.

We zijn enthousiast over de mogelijkheden die miniscript zal ontgrendelen voor de volgende generatie van zelfbewaring van bitcoin.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoData.Network Verticale generatieve AI. Versterk jezelf. Toegang hier.
• PlatoAiStream. Web3-intelligentie. Kennis versterkt. Toegang hier.
• PlatoESG. Automotive / EV's, carbon, CleanTech, Energie, Milieu, Zonne, Afvalbeheer. Toegang hier.
• BlockOffsets. Eigendom voor milieucompensatie moderniseren. Toegang hier.
• Bron: https://www.ledger.com/blog/towards-a-trustless-bitcoin-wallet-with-miniscript