Saker att veta: |
- Miniscript gör det möjligt att bygga Bitcoin mjukvaruplånböcker som gör en bakdörr omöjlig att utnyttja. Vi är glada att kunna säga att Ledger är den första kommersiella hårdvaruplånbokstillverkaren som stöder miniscript.
- De ytterligare funktionerna kan implementeras utan att kompromissa med användarupplevelsen. |
Maskinvarusigneringsenheter är konstruerade för att skydda användaren från olika vanliga attackvektorer, såsom:
- Otillåten åtkomst och utvinning av fröet
- Skadlig programvara som infekterar din tillhörande programvaruplånbok
- Sårbarheter i programvaran på själva enheten
Som alla företag ligger det i tillverkarens bästa intresse att göra enheter som okrossbar som de kan. Att lyckas med det här uppdraget är av största vikt, och säkerhetsföretag som Ledger förlitar sig på ett rykte som bygger på deras meritlista.
Vissa användare kan dock fortfarande vara oroliga. Vad hindrar företaget från att dölja en bakdörr i enheterna?
I självvårdnad har vi lita inte på, vi verifierar.
Men kan användaren verkligen verifiera att en enhet inte har en bakdörr?
Det är den nyckelfråga som denna artikel går in på. Mer exakt tar den här artikeln upp följande ämnen:
- vad är en bakdörr och varför det är svårt, för att inte säga omöjligt, att bevisa att det inte finns någon;
- varför bara användare kan skydda sig från denna risk;
- hur miniscript möjliggör praktiska lösningar på denna utmaning för bitcoin-plånböcker.
Genom att vara den första hårdvaruplånboken att stödja miniskript, hoppas vi kunna inspirera utvecklare att bygga säkra lösningar och uppgradera hela vår bransch, och eliminera risken för att en sådan systemrisk någonsin kommer att förverkligas.
Hur man bygger otillgänglig signeringsenhet
Låt oss uttrycka det tydligt: du kan inte.
För att försvara dig mot en potentiell bakdörr behöver du en annan attackmodell än den vi beskrev ovan: i det här scenariot kan motståndaren vara säljaren själv eller en skadad insider.
Den ofta presenterade lösningen på det här problemet är öppen källkod: trots allt, om du kan inspektera koden, vad kan eventuellt gå fel?
Sanningen är dock mer komplex. Eftersom leverantören monterar hårdvaran kan en bakdörr vara helt innesluten i den. Hårdvaran kan utformas för att bortse från programvaran vid vissa punkter och köra skadlig kod istället.
Till skillnad från programvara som körs på generella datorenheter (som din bärbara dator eller telefon), är det praktiskt taget omöjligt att granska hårdvaran med dagens teknik. Även om hårdvaruspecifikationerna var helt och hållet öppen källkod, komplett med detaljerna för varje enskild gate i kretsen, skulle du fortfarande behöva högkostnadsutrustning för att verifiera att ett specifikt chip är byggt i enlighet med dem.
Hur man bakdörrar en hårdvaruplånbok
Här är några av de enklaste metoderna som en illvillig hårdvaruleverantör kan använda för att introducera en bakdörr, tillsammans med några sätt som avancerade användare kan skydda sig själva idag.
Frögenerering
Många enheter erbjuder dig möjligheten att generera ett frö (även kallat Hemlig återställningsfras) direkt på enheten med hjälp av en True Random Number Generator.
😈 Den onda enheten kan generera frön som verkar slumpmässiga men som faktiskt är förutsägbara för angriparen.
🛡️ Power-användare kan kringgå detta problem genom att generera en minnesminne offline. Dessutom innehåller en robust lösenfras kan också generera ett helt oberoende frö som hårdvaruleverantören inte kan förutse. Avvägningen är att användare måste se till att de säkerhetskopierar lösenfrasen på rätt sätt utöver minnesorden.
Offentlig nyckel härledning
Hårdvaruplånböcker härleda och exportera offentliga nycklar (även kallad xpubs, Förkortning av utökad offentlig nyckel enligt definitionen i BIP-32. De xpubs används för att generera möjliga adresser för att ta emot mynt.
😈 Den onda enheten kan returnera offentliga nycklar som kontrolleras av angriparen istället för de korrekta som kommer från fröet.
🛡️ Användare kan validera det härledda xpub på en annan, offline-enhet. Att komma in i fröet på andra enheter medför dock sina egna risker. Säkerhetsmedvetna användare kan anse alla enheter som har fått åtkomst till fröet som farliga, potentiellt till den grad att de förstörs. Den typiska användaren kan kämpa för att korrekt utföra denna procedur medan han hanterar de ytterligare riskerna.
Läckande information
An lufthål föreslås ofta som en lösning för att förhindra att en skadlig eller komprometterad enhet exfiltrerar privata nycklar. När allt kommer omkring, om en enhet inte kan kommunicera med omvärlden kan den inte göra något skadligt, eller hur?
Inte riktigt!
Enheten kan alltid kommunicera när den används: den producerar signaturer. Dessa signaturer hamnar i transaktioner som sänds och lagras för alltid på blockkedjan.
En signatur är en bytesträng med slumpmässigt utseende på minst 64 byte. Men eftersom mer än en giltig signatur kan motsvara samma meddelande, kan en skadlig enhet kommunicera några bitar av information varje gång en signatur produceras, genom att generera flera signaturer och selektivt välja vilken som ska publiceras.
😈 En oseriös enhet kan producera icke-slumpmässiga signaturer som över många transaktioner avslöjar fröet för angriparen!
En angripare som lyckas med att installera en sådan bakdörr skulle bara behöva vänta på att skadliga signaturer dyker upp på blockkedjan tills de har tillräckligt med information för att rekonstruera hela fröet.
🛡️ För ECDSA-signaturer, med en standardiserad metod för att härleda nonce deterministiskt (som RFC6979) motverkar denna attack, förutsatt att man validerar att den producerade signaturen matchar den förväntade. För att säkerställa att så är fallet krävs dock att en andra enhet laddas med samma frö, vilket leder till samma praktiska problem som nämndes i föregående avsnitt.
🛡️ Ett intressant tillvägagångssätt är att använda ett smart sätt att styrka enheten för att faktiskt välja en slumpmässig nonce. Ett protokoll för detta ändamål, känt som anti-exfil or anti-klepto, är för närvarande implementerad i Blockstream Jade och ShiftCrypto BitBox02 hårdvaruplånböcker. Läs mer på ShiftCryptos blogg, som också innehåller en teknisk beskrivning av hur en sådan attack kan utföras.
Okej då, finns det inget hopp?
De flesta av försvaren🛡️ listade ovan kräver oftast att användaren utför explicita, påträngande åtgärder för att skydda sig själva: antingen genom att generera fröet på egen hand (i huvudsak genom att använda sin hjärna för att ersätta funktionaliteten från hårdvaruplånboken), eller genom att använda en ytterligare enhet för att verifiera att beräkningar är korrekt utförda.
Anti-exfil-protokollet sticker dock ut: med tanke på att det alltid finns en maskin som förmedlar mellan maskinvarusigneraren och omvärlden kan den här maskinen hjälpa. Genom ett interaktivt protokoll med maskinvarusigneraren kan den förstärka användningen av en genuint slumpmässig nonce, vilket minskar eller eliminerar chansen att väsentligt manipulera den slutliga signaturen.
I det här blogginlägget är vi främst intresserade av dessa typer av åtgärder: medan strategier som avsevärt försämrar UX kan vara tilltalande för avancerade användare, kommer de sannolikt att göra saker sämre i praktiken för de mindre tekniskt skickliga användarna – vilket är de allra flesta.
Säkerhetsmodellen
Standardmodell för maskinvarusignerare
Tillverkare av maskinvarusignerare strävar efter att skydda användare från en mängd olika potentiella hot (för mer information, se Hotmodell). I den här artikeln fokuserar vi på en, mycket viktig egenskap, som kan sammanfattas enligt följande:
Användare kan inte luras till en åtgärd som leder till fondförlust, förutsatt att de förstår och verifierar informationen på skärmen innan de godkänns.
Godkännande krävs för alla känsliga åtgärder, särskilt underskrifter. Att skydda fröet skulle vara meningslöst om skadlig programvara kunde producera signaturer för godtyckliga meddelanden, såsom en transaktion som dränerar alla pengar!
Det är viktigt att betona att ovanstående egenskap måste gälla även om mjukvaruplånboken är fullständigt komprometterad. Det som visas på din bärbara dator/telefon kan inte litas på: skadlig programvara kan ersätta adresser, lura dig om vilka adresser som är dina, presentera en transaktion men sedan vidarebefordra en annan till enheten för signering, etc.
Därför tar den fasta programvaran och applikationerna som körs på en maskinvarusigneringsenhet hänsyn till mjukvaruplånboken opålitliga och opålitlig.
Anti-bakdörr säkerhetsmodell för mjukvaruplånböcker
I det här avsnittet vänder vi rollerna helt. Vi vill nu designa en programvaruplånbok som förhindrar hårdvarutillverkaren från att stjäla eller orsaka fondförlust, även om enheten är helt skadlig.
Därför kan detta inte vara en egenskap hos anordning: snarare är det en egenskap hos programvaruplånbok uppstart. Vi skulle kunna sammanfatta det så här:
Förutsatt att mjukvaruplånboken inte äventyras kan maskinvarutillverkaren inte orsaka att användaren förlorar pengar.
Detta kan verka kontraintuitivt, eftersom det direkt motsäger standardsäkerhetsmodellen som beskrivs ovan. Men att "inte ha en bakdörr" betyder "att göra exakt vad de ska göra". Eftersom mjukvaruplånboken är enda gränssnittet mellan signeringsenheten och omvärlden, är det den enda platsen där skydd mot felaktigt uppträdande kan upprätthållas – oavsett om det beror på en bugg eller explicit intrång i enheten.
Observera att denna modell sträcker sig betydligt längre än ett enhetsfel, till exempel en exploateringsbar bugg. I det här fallet arbetar vi inom ett scenario där enheten aktivt försöker orsaka fondförlust.
Naturligtvis finns det inget möjligt skydd om tillverkaren har lyckats kompromissa båda enheten och även din maskin som kör programvaruplånboken. Därför är det absolut nödvändigt att se till att din mjukvaruplånbok är öppen källkod och kan granskas, särskilt om den är byggd av samma leverantör som tillverkar hårdvaran.
Rollen som miniskript
Miniscript utrustar plånboksutvecklare med möjligheten att fullt ut utnyttja de avancerade funktionerna i bitcoin Script. För en översikt över de otroliga möjligheter miniscript låser upp, se vårt tidigare blogginlägg. Du kanske också vill lyssna på Avsnitt 452 av Stephan Livera Podcast för en diskussion om vad miniscript tillför bitcoin-landskapet.
Ledger Bitcoin-appen stöder miniskript sedan dess 2.1.0-släpp, som lanserades i februari 2023. Vid Bitcoin 2023-konferensen i Miami tillkännagav Wizardsardine 1.0-släppet av deras Liana plånbok, den första utplacerade plånboken baserad på miniskript.
Grundidén med det här inlägget är att ett bitcoin-plånbokskonto kan skyddas inte bara med ett, utan med multipel nycklar. Detta tillåter flexibla säkerhetsramverk där inte ens ett totalt fel eller kompromittering av en nyckel inte är katastrofalt.
Multisig funderingar
Multisig är en betydande uppgradering av styrkan hos en självvårdande lösning. Genom att utnyttja programmerbarheten hos Bitcoin Script möjliggör det skapandet av plånböcker som kräver flera nycklar istället för bara en. A k-av-n multisig plånbok kräver en kombination av k giltiga signaturer, av totalt n möjliga.
Men multisig lägger också en UX-belastning på användaren och introducerar nya möjligheter för fel. En 3-av-3 multisig-installation, som involverar tre olika nycklar som är säkert säkerhetskopierade på separata platser, erbjuder stark säkerhet... men det betyder också att om även en enda nyckeln är förlorad, mynten blir permanent otillgängliga!
Därför tenderar inställningar som erbjuder mer redundans (som 2-av-3 eller 3-av-5) att vara mer populära: om en enskild nyckel skulle gå förlorad kan de andra nycklarna fortfarande underlätta återställningen. Men detta introducerar en kompromiss: om en nyckel äventyras utan att du vet, minskar den totala säkerheten avsevärt!
Företag som Hem och Obehandlat kapital specialiserar sig på självvårdslösningar där de innehar en minoritet av nycklarna för sina kunder. De hjälper också sina användare genom att vägleda dem genom introduktionsprocessen och förenkla användningen av vårdnadssystem, vilket annars kan vara skrämmande för de flesta icke-tekniska användare.
Miniscript och tidslåsta återställningsvägar
Liana använder miniskript för att skapa plånböcker som har flera sätt att spendera:
- ett primärt utgiftsvillkor, som är omedelbart tillgängligt;
- ett eller flera ytterligare utgiftsvillkor som blir tillgängliga efter en viss period (det sk tidlås).
Detta möjliggör många intressanta användningsfall:
- Återvinning: En standardplånbok med antingen singelsignatur eller multisig som primär utgiftsväg; men en separat återställningsmekanism (en nyckel med ett annat frö, en multisig, en tekniskt kunnig vän, en vårdnadshavare) blir tillgänglig efter 6 månader.
- Bolagsstyrning: Ett företag med två styrelseledamöter skulle kunna upprätta en 2-av-2 för bolagets kassa; i händelse av oenighet kan en betrodd advokat få tillgång till pengarna efter 6 månader.
- Förfallande multisig: En plånbok börjar som en 3-av-3, övergår till en 2-av-3 efter 6 månader och blir en 1-av-3 efter 9 månader.
- Automatiskt arv: Återhämtningsvägen efter 6 månader inkluderar en 2-av-3 av dina tre barn; kanske en andra återhämtningsväg efter 1 år involverar en notarie, om arvingarna inte kan nå enighet.
Anmärkning: alla exemplen ovan använder en relativ tidslåsning, som hänvisar till myntens ålder (det vill säga: senaste gången medlen flyttades). Avvägningen är att användaren måste komma ihåg att spendera mynten (genom att skicka dem till sig själva) om tidslåset närmar sig utgången.
Detta är bara några exempel, men de borde räcka för att övertyga läsaren om att miniskript är ett betydande steg framåt mot att förverkliga Bitcoins potential som programmerbara pengar.
Registrering av plånbokspolicy
För Bitcoin-plånbokskonton som använder flera nycklar (oavsett om det är multisig eller mer sofistikerade miniskriptbaserade lösningar), är det avgörande att träna enheten för att identifiera adresserna som tillhör det kontot. Detta är det enda sättet som enheten kan hjälpa användaren att säkerställa att de tar emot eller spenderar från rätt adresser...
Validera policyn och xpubs av cosigner mot en pålitlig backup är viktigt, men relativt tidskrävande.
Den goda nyheten är att det bara behöver göras en gång:
När en policy har registrerats med ett namn (i exemplet "Decaying 3of3") kommer din enhet att kunna känna igen den när en sådan policy används.
De som är intresserade av tekniska detaljer kan hitta mer information i BIP förslag.
Säkerhetskopiering av policy
En viktig aspekt att notera är att medan flernyckelpolicyer tillåter en delmängd av privata nycklar att auktorisera transaktioner, kunskap om alla de publika nycklarna (och exakt policy) krävs.
Men till skillnad från fröet är det mycket mindre riskabelt att säkerhetskopiera policyn och de offentliga nycklarna: om någon skulle upptäcka det skulle de kunna spåra alla transaktioner kopplade till den policyn. Även om detta inte är idealiskt – integritet är viktigt! − det är inte lika katastrofalt som att förlora sina mynt och mindre lockande för potentiella angripare. Att lagra flera kopior av policyn i heta plånböcker, skriva ut den och lagra den på olika ställen, kryptera den och lagra den i molnlagring, och så vidare, är följaktligen alla genomförbara strategier.
En plånbok med en signatur utan dörrar
Låt oss ta ett steg tillbaka. Vi har diskuterat plånböcker med flera signaturer, men nu går vi tillbaka till grunderna för att skapa en plånbok med en signatur. Mer exakt vill vi ha en plånbok som känns och utseende som en plånbok med en signatur, efter en första installationsfas. Ändå strävar vi efter att skapa en plånbok från vilken tillverkaren inte kan stjäla dina pengar även om de är skadliga 😈, och hårdvarusigneringsenheten beter sig på oförutsägbara sätt.
Tillvägagångssättet kan lätt generaliseras för plånböcker med flera signaturer.
Exemplen nedan kommer att skrivas på ett språk som kallas policy, snarare än miniskript. Policy är lättare för människor att läsa och tänka på och kan sammanställas till miniskript med automatiserade verktyg. Läs mer om miniskript och policy.
Hårdvaruplånboken kan skydda dig i standardsäkerhetsmodellen. Miniscript kan skydda dig i säkerhetsmodellen mot bakdörr (och mycket mer!).
Steg noll: status quo
Detta är den policy som de flesta användare använder idag: en enda nyckel som härrör från ett frö som produceras i hårdvaruplånboken.
pk(key_ledger)
Naturligtvis finns det inget sätt att bevisa frånvaron av en bakdörr.
Steg ett: dubbla dessa nycklar
Det första steget är enkelt:
and(pk(key_ledger), pk(key_client))
Här, key_client
genereras på användarens maskin, därav en kortkommando. I huvudsak är det en 2-av-2 multisig-inställning. Nyckelaspekten är att användaren inte interagerar mycket med key_client
: mjukvaruplånboken genererar denna nyckel, inkluderar den i plånbokens säkerhetskopia och signerar när det behövs (till exempel när användaren är upptagen med att signera med sin maskinvarusignerare).
Detta verkar redan ganska intressant: medlen är oanvändbara utan key_client
, som inte är tillgänglig för hårdvaruleverantören; även om den onda säljaren hade full kunskap om nyckeln i enheten, skulle de fortfarande inte kunna flytta pengarna utan att uttryckligen rikta in sig på användaren, till exempel genom att kompromissa med maskinen som kör deras mjukvaruplånbok.
Det finns dock ett problem: under introduktionen av plånboken är maskinvarusigneraren den enda enheten som kan generera den publika nyckeln (xpub) key_ledger
används i plånboken. Därför kan enheten avsiktligt generera en oförrätter xpub kontrolleras av angriparen, och senare avböja (eller vara oförmögen) att signera. Förmodligen är detta ett ganska extremt attackscenario: bakdörrsskaparen kan inte stjäla pengarna, och det mesta de kan göra är att rikta in sig på användaren individuellt och kräva en lösensumma ("Jag kan hjälpa dig att hämta dina pengar om du betalar hälften till mig ”).
Mer realistiskt, detta ökar risken för misstag av misstag: du har nu två frön / privata nycklar, och du behöver båda för att kunna spendera. Förlora antingen, och mynt är låsta för alltid.
Steg två: tidslåst återhämtning
Vi introducerar en separat återställningsnyckel, tillgänglig endast efter ett specifikt tidslås: and(older(25920)
, pk(key_recovery))
, där 25920 är det ungefärliga antalet block på 6 månader. Hela policyn blir:
or(
and(pk(key_ledger), pk(key_client)), and(after(25920), pk(key_recovery))
)
Detta liknar det tidigare scenariot, men med en twist: if key_ledger
or key_client
blir otillgänglig av någon anledning (oftast, att förlora fröbackupen!), a återhämtningsväg blir tillgänglig efter 6 månader.
Det finns flera alternativ för key_recovery
, var och en med sina egna avvägningar:
a. Använd en annan kortkommando. Detta är en praktisk lösning så länge användaren kommer ihåg att återställa tidslåset. Men om snabbtangenterna äventyras (ett scenario som i allmänhet bör anses vara ganska troligt!), kan angriparen försöka komma åt pengarna så snart tidslåset löper ut, vilket initierar ett lopp med den legitima ägaren.
b. Använd en separat maskinvarusigneringsenhet. Detta är en robust lösning och kan användas i kombination med en annan leverantör om så önskas; det ökar dock komplexiteten och kostnaden för användaren när det gäller användarupplevelsen.
c. Använd en pålitlig extern tjänst. Programvaruplånboken kan importera en xpub från en extern tjänst, använda den som key_recovery
. Denna tredje part är bara betrodd om tidslåset löper ut, vilket kan vara en tilltalande kompromiss för vissa användare.
Som nämnts, precis som för alla policyer med tidslås, är det viktigt att användaren kommer ihåg att uppdatera mynten innan tidslåsets utgång.
Steg tre: den opålitliga tredje parten
Låt oss blanda båda idéerna (a) och (c): för återställningsvägen kräver vi en lokal snabbtangent key_recovery_local
Och en key_recovery_remote
som är värd för en semi-betrodd tjänst; vi behåller även tidslåset.
or(
and(pk(key_ledger), pk(key_client)),
and(older(25920),
and(pk(key_recovery_local), pk(key_recovery_remote))
)
)
Detta minskar nivån av förtroende som behövs från återställningstjänsten. Vi måste dock vara försiktiga: tjänsten i sig kan övervaka blockkedjan och upptäcka våra UTXO - trots allt försåg de oss med key_recovery_remote
xpub, så att de kan söka efter UTXO som innehåller pubnycklar som härrör från key_recovery_remote
. De kommer att kunna lära sig om vår ekonomiska historia, även innan tidslåset löper ut, och även om vi aldrig använt deras tjänst.
Anmärkning: Pålrotsträd kan eliminera detta integritetsproblem för vissa policyer, men detta är inte alltid fallet och kräver noggrann utvärdering baserat på den specifika policyn.
Steg fyra: blind den tredje parten 🙈
För att förhindra återställningstjänsten från att lära sig om vår ekonomiska historia, istället för att använda pubnyckeln de kommunicerar till oss, kan vi använda en blind xpub Tekniken förklaras av mflaxman i detalj här. Kort sagt, istället för att använda key_recovery_remote
i vår policy väljer vi fyra 31-bitars slumptal a
, b
, c
, d
(Den förblindande faktorer), och vi använder följande BIP-32 härledd pubnyckel:
key_recovery_remote_blind = key_recovery_remote_blind/a/b/c/d
Det är avgörande att vi också lägger till key_recovery_remote
och de förblindande faktorerna a
, b
, c
och d
till vår backup, för framtida referens.
Om vi någonsin behöver använda återställningstjänsten kommer vi att avslöja a
, b
, c
, d
till dem. Tills dess har de inget sätt att upptäcka att nycklar härrör från deras key_recovery_remote
publiceras på blockchain: antalet möjliga kombinationer för de 4 bländande faktorerna är 2^(31*4) = 2^124
, vilket gör det omöjligt att bruteforce dem alla.
Steg fem: för många kortkommandon kan bränna dig 🔥
Vi lyckades göra vår mjukvaruplånbok otillgänglig. Men vi introducerade ett annat problem: båda utgiftsvillkoren använder en lokalt genererad, het nyckel som inte verifieras av hårdvaruplånboken. Därför, om värddatorn äventyras, kan det lura dig att registrera policyn med hjälp av pubnycklarna key_client
och key_recovery_local
, men lägg slumpmässiga, orelaterade privata nycklar i vår säkerhetskopia (kom ihåg att het nycklar är en del av vår backup!).
Det skulle i princip göra att alla pengar skickas till plånboken outnyttjad, eftersom ingen kontrollerar de privata nycklar som krävs för att signera.
Det finns några lösningar för att lösa detta problem:
- Under onboarding, efter att ha skrivit ut vår säkerhetskopia på papper, kan vi använda en separat enhet för att verifiera att de privata och offentliga snabbtangenterna på säkerhetskopian verkligen matchar. Detta tillvägagångssätt skulle eliminera problemet, eftersom vi skulle vara säkra på att vi har alla nödvändiga nycklar som behövs för rekonstruktion och signering.
- Vi kan lägga till ytterligare ett utgiftsvillkor med ett ännu längre tidslås (9 månader, 38880 block) som bara kräver en
key_ledger_failsafe
från hårdvaruenheten. På så sätt, i det absolut värsta scenariot där allt annat misslyckas, faller vi tillbaka till säkerheten för en enda signeringsenhet. I normala operationer skulle vi aldrig låta det första tidslåset löpa ut, därför kommer det andra tidslåset inte heller att löpa ut!
Med det andra tillvägagångssättet skulle den slutliga politiken se ut så här
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))
),
)
Denna mjukvaruplånbokskonfiguration uppfyller alla säkerhetsegenskaper som vi gjorde anspråk på i början. Dessutom erbjuder det en återhämtningsväg i fall de viktigaste utgiftsnycklarna key_ledger
är försvunna. En trevlig funktion att ha!
Introduktion till den otillgängliga mjukvaruplånboken
Hur skulle användarupplevelsen för en plånbok med en så komplex policy se ut? Här är en kort översikt:
- Användaren öppnar mjukvaruplånboken och börjar skapa ett nytt konto.
- Programvaruplånboken uppmanar användaren att ansluta sin signeringsenhet och hämtar xpubarna för
key_ledger
ochkey_ledger_failsafe
. - Programvaruplånboken genererar automatiskt snabbtangenten key_client.
- Programvaruplånboken får
key_recovery_remote
från en samsigneringstjänst eller låter användaren specificera en nyckel på annat sätt. Alternativt beräknar denkey_recovery_remote_blind
använda den förblindande tekniken som nämnts tidigare. - Programvaruplånboken genererar en policybackup som innehåller den exakta miniskriptpolicyn, alla xpubs och den utökade privata nyckeln för
key_client
snabbtangent. Denna säkerhetskopia lagras säkert (till exempel utskriven på papper eller sparad på en separat enhet). - Slutligen instruerar programvaruplånboken användaren att registrera policyn på enheten. Användaren dubbelkontrollerar säkerhetskopian (på papper eller något annat medium än skärmen som kontrolleras av mjukvaruplånboken).
Mjukvaruplånboken hanterar de flesta av ovanstående steg, vilket gör att användarens engagemang inte blir mer betungande än den förväntade ansträngningen som krävs idag för att skapa en multisignaturplånbok.
Introduktionen bör bara ta några minuter när en bra UX är byggd för den. När den är färdig kan mjukvaruplånboken ge en användarupplevelse som är mycket lik den för en typisk ensignaturplånbok. Så här kommer miniskriptet att förändra allt: genom att försvinna ur användarens syn!
Taproot förbättringar
Ledger stöder miniskript sedan version 2.1.0 av Bitcoin-appen, som släpptes i mars. Medan stöd för att ta emot till och spendera från taproot-adresser var aktiverat sedan pålrot mjukgaffel i november 2021 lägger vi nu sista handen på nästa steg i färdplanen: miniskriptstöd för taproot.
Taproot kommer att ha en enorm inverkan på användbarheten av de metoder som presenteras i den här artikeln. Om den primära utgiftsvägen är ett enskilt utgiftsvillkor, kommer förekomsten av utgiftsvägar för återhämtning att vara omöjliga att upptäcka i blockkedjan om de inte används. Detta kommer att förbättra integriteten avsevärt genom att helt eliminera alla fingeravtryck för standardutgiftsvägen. Dessutom förbättrar det skalbarheten, eftersom standardutgiftsvägen blir så kostnadseffektiv att spendera som möjligt. Detta innebär att inga extra kostnader kommer att uppstå på grund av förekomsten av återställningsvägar, såvida de inte används. Detta är en betydande uppgradering från SegWit-transaktioner, som kräver publicering av hela skriptet, inklusive alla utgiftsvillkor, under alla utgifter.
Slutligen, mer avancerade protokoll som MuSig2 (nyligen standardiserad) och FROST kommer att överbelasta taproot-tangentbanan. Byggt på Schnorr-signaturer, tillåter dessa protokoll att skapa en singel samlad pubnyckel som kan användas för att representera en n-av-n multisignatur eller en k-av-n tröskelsystem. Detta skulle tillåta användningen av taproot-nyckelvägen även i fall som idag är vanligare representerade med specifika multisig-skript.
Slutsatser
Den här artikeln utforskar en liten (men viktig) nisch av det stora designutrymme som miniskript släpper lös för programvaruplånböcker.
Vi visade hur miniscript kan användas för att skapa en "otillgänglig" mjukvaruplånbok, samtidigt som vi lägger till en ytterligare återställningsväg som gör det möjligt att förhindra katastrofala nyckelförluster. Medan hårdvarusigneringsenheter inte kan genomdriva anti-bakdörrssäkerhetsmodellen, genom att stödja miniscript möjliggör de mjukvaruplånböcker som gör just det!
Genom att på ett skickligt sätt använda en kombination av multisignaturscheman, tidslås, blinda xpub och snabbtangenter, har vi demonstrerat en säker plånbokskonfiguration som balanserar säkerhet, integritet och robusthet.
Dessutom hävdade vi att detta är möjligt utan att negativt påverka användarupplevelsen, eftersom komplexiteten i installationen inte leder till en stor extra UX-börda.
Vi är glada över möjligheterna som miniscript kommer att låsa upp för nästa generation av bitcoin-självvård.
- SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
- PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
- PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
- Platoesg. Fordon / elbilar, Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
- BlockOffsets. Modernisera miljökompensation ägande. Tillgång här.
- Källa: https://www.ledger.com/blog/towards-a-trustless-bitcoin-wallet-with-miniscript
- : har
- :är
- :inte
- :var
- $UPP
- 1
- 2021
- 2023
- 30
- 7
- 9
- a
- förmåga
- Able
- Om Oss
- ovan
- Absolut
- absolut
- tillgång
- Accessed
- tillgänglig
- överensstämmelse
- Konto
- konton
- Handling
- åtgärder
- aktivt
- faktiskt
- lägga till
- tillsats
- Dessutom
- Annat
- Dessutom
- adresser
- avancerat
- Efter
- mot
- ålder
- Stöd
- Syftet
- Alla
- tillåter
- tillåter
- längs
- redan
- också
- Även
- alltid
- an
- och
- meddelade
- Annan
- vilken som helst
- något
- app
- lockande
- visas
- tillämpningar
- tillvägagångssätt
- tillvägagångssätt
- godkännande
- ungefärlig
- ÄR
- det kan argumenteras att
- argued
- Artikeln
- AS
- aspekt
- bistå
- associerad
- At
- attackera
- granskbar
- godkänna
- Automatiserad
- autonomt
- tillgänglig
- tillbaka
- bakdörr
- dragen tillbaka
- stöd
- säkerhetskopiering
- saldon
- baserat
- grundläggande
- I grund och botten
- Grunderna
- BE
- därför att
- blir
- blir
- innan
- Börjar
- Där vi får lov att vara utan att konstant prestera,
- nedan
- BÄST
- mellan
- Bortom
- Bitcoin
- Bitcoin plånbok
- bitcoin plånböcker
- Blandning
- blockchain
- Block
- Blockstream
- Blogg
- båda
- Hjärna
- Bringar
- sända
- Bug
- SLUTRESULTAT
- byggt
- belastning
- bränna
- företag
- upptagen
- men
- by
- kallas
- KAN
- kan inte
- kapabel
- noggrann
- Vid
- fall
- katastrofal
- Orsak
- orsakar
- försiktighet
- vissa
- utmanar
- chans
- byta
- Barn
- chip
- Välja
- välja
- hävdade
- klart
- cloud
- Cloud Storage
- koda
- Mynt
- kombination
- kombinationer
- kommersiella
- Gemensam
- vanligen
- kommunicera
- Företag
- företag
- Företagets
- fullborda
- fullständigt
- komplex
- Komplexiteten
- Äventyras
- komprometterande
- beräkningar
- databehandling
- oro
- tillstånd
- villkor
- Konferens
- konfiguration
- Kontakta
- Konsensus
- Följaktligen
- Tänk
- anses
- innehöll
- kontrolleras
- kontroller
- övertyga
- korrekt
- skadad
- Pris
- kunde
- Kurs
- skapa
- Skapa
- skapande
- skaparen
- kritisk
- kritisk aspekt
- avgörande
- För närvarande
- väktare
- Vårdnad
- Kunder
- Dangerous
- Nedgång
- minskar
- anse
- definierade
- Efterfrågan
- demonstreras
- utplacerade
- Härledd
- beskrivning
- Designa
- utformade
- önskas
- detalj
- detaljerad
- detaljer
- upptäcka
- utvecklare
- anordning
- enheter
- olika
- svårt
- minskande
- direkt
- Direktörer
- försvinna
- katastrofal
- Upptäck
- upptäcka
- diskuteras
- diskussion
- visas
- do
- gör
- inte
- gjort
- dubbla
- grund
- under
- varje
- lättare
- lätt
- ansträngning
- antingen
- eliminera
- eliminera
- annars
- betona
- anställd
- möjliggöra
- aktiverad
- möjliggör
- änden
- förstärka
- tillräckligt
- säkerställa
- säkerställa
- in
- lockande
- Hela
- helt
- enhet
- Utrustning
- fel
- speciellt
- väsentlig
- väsentligen
- etablera
- etc
- utvärdering
- Även
- NÅGONSIN
- Varje
- allt
- exakt
- exempel
- exempel
- exciterade
- exekvera
- exekveras
- Motionera
- Förekomsten
- förväntat
- erfarenhet
- utgångs
- Exploit
- utforskar
- export
- sträcker
- extern
- extrem
- främja
- faktorer
- misslyckas
- Misslyckande
- ganska
- Höst
- långt
- Leverans
- Funktioner
- Februari
- få
- slutlig
- finansiella
- ekonomisk historia
- hitta
- Förnamn
- flexibel
- Flip
- Fokus
- efter
- följer
- För
- alltid
- Framåt
- fyra
- ramar
- ofta
- vän
- från
- full
- fullständigt
- funktionalitet
- fond
- fonder
- Vidare
- fruktlöst
- framtida
- generell mening
- allmänhet
- generera
- genereras
- genererar
- generera
- generering
- ges
- Go
- kommer
- god
- stor
- kraftigt
- hade
- Hälften
- hårdvara
- hårdvara
- Hårdvaruplånbok
- Tillverkare av plånbok för hårdvara
- Hårdvara plånböcker
- skadliga
- Har
- har
- hjälpa
- därav
- historia
- hålla
- hoppas
- värd
- värd
- HET
- Hur ser din drömresa ut
- Men
- http
- HTTPS
- stor
- Människa
- Tanken
- idealisk
- idéer
- identifiera
- if
- blir omedelbart
- Inverkan
- slag
- genomföras
- importera
- med Esport
- omöjligt
- förbättra
- in
- innefattar
- Inklusive
- införlivande
- Ökar
- otroligt
- ja
- oberoende
- Individuellt
- industrin
- informationen
- inneboende
- inledande
- inuti
- Insider
- inspirerar
- installera
- exempel
- istället
- avsiktligt
- interagera
- interaktiva
- intresse
- intresserad
- intressant
- Gränssnitt
- in
- införa
- introducerade
- Introducerar
- påträngande
- inblandning
- involverar
- fråga
- IT
- DESS
- sig
- bara
- bara en
- Nyckel
- nycklar
- Vet
- kunskap
- känd
- liggande
- språk
- laptop
- Efternamn
- senare
- advokat
- Leads
- LÄRA SIG
- inlärning
- t minst
- Ledger
- vänster
- legitim
- mindre
- Låt
- Nivå
- hävstångs
- tycka om
- sannolikt
- kopplade
- Noterade
- läser in
- lokal
- platser
- låst
- Lång
- längre
- se
- ser ut som
- förlorar
- förlora
- förlust
- förluster
- förlorat
- Maskinen
- Huvudsida
- Majoritet
- göra
- GÖR
- Framställning
- malware
- förvaltar
- hantera
- manipulerings
- sätt
- Tillverkare
- Tillverkare
- många
- Mars
- Match
- Maj..
- betyder
- åtgärder
- mekanism
- Medium
- nämnts
- endast
- meddelande
- meddelanden
- metod
- metoder
- Miami
- kanske
- miniskript
- minoritet
- minuter
- Mission
- misstag
- modell
- pengar
- övervakning
- månader
- mer
- Dessutom
- mest
- för det mesta
- flytta
- rörd
- mycket
- multipel
- multisig
- måste
- namn
- närmar sig
- nödvändigt för
- Behöver
- behövs
- behov
- negativt
- nätverk
- aldrig
- Nya
- nyheter
- Nästa
- trevligt
- Nej
- inte teknisk
- normala
- November
- november 2021
- nu
- antal
- nummer
- erhåller
- of
- erbjudanden
- erbjuda
- Erbjudanden
- offline
- on
- Onboarding
- gång
- ONE
- ettor
- endast
- öppet
- öppen källkod
- öppnas
- drift
- Verksamhet
- möjligheter
- Tillbehör
- or
- beställa
- Övriga
- annat
- vår
- ut
- skisse
- utanför
- över
- övergripande
- Översikt
- egen
- ägaren
- Papper
- Yttersta
- del
- särskilt
- parti
- bana
- Betala
- Utföra
- kanske
- perioden
- permanent
- fas
- telefon
- Plats
- platser
- plato
- Platon Data Intelligence
- PlatonData
- Punkt
- poäng
- Strategier
- policy
- Populära
- Möjligheterna
- möjlig
- eventuellt
- Inlägg
- potentiell
- potentiellt
- kraft
- Praktisk
- praktiskt taget
- praktiken
- exakt
- exakt
- förutse
- Förutsägbar
- Närvaron
- presentera
- presenteras
- förhindra
- förhindrar
- föregående
- tidigare
- primärt
- primär
- tryckning
- Innan
- privatpolicy
- privat
- privat nyckel
- Privata nycklar
- Problem
- problem
- förfaranden
- process
- producera
- producerad
- producerar
- ordentligt
- egenskaper
- egenskapen
- föreslagen
- skydda
- skyddad
- skydda
- skydd
- protokoll
- protokoll
- Bevisa
- ge
- förutsatt
- allmän
- Public Key
- offentliga nycklar
- publicera
- publicerade
- publicering
- Syftet
- sätta
- sätta
- fråga
- Lopp
- slumpmässig
- Ransom
- snarare
- nå
- Läsa
- Läsare
- inse
- Anledningen
- mottagande
- nyligen
- känner igen
- post
- återvinning
- hänvisar
- registrera
- registrerat
- registrera
- relativt
- frigöra
- frigörs
- förlita
- ihåg
- ersätta
- representerar
- representerade
- rykte
- kräver
- Obligatorisk
- Kräver
- resulterande
- behålla
- avkastning
- avslöjar
- höger
- Risk
- risker
- Riskabel
- färdplan
- robusta
- robusthet
- Roll
- roller
- rinnande
- kör
- Samma
- säga
- skalbarhet
- scanna
- scenario
- ordningen
- system
- skura
- screen
- skript
- Andra
- §
- säkra
- säkert
- säkerhet
- se
- frö
- frön
- söker
- verka
- verkar
- SegWit
- Själv vårdnad
- skicka
- känslig
- skickas
- separat
- service
- in
- inställning
- flera
- Kort
- skall
- visade
- signera
- signaturer
- signifikant
- signifikant
- signering
- Tecken
- liknande
- Enkelt
- förenkla
- eftersom
- enda
- Small
- smarta
- So
- Mjukvara
- lösning
- Lösningar
- LÖSA
- några
- någon
- snart
- sofistikerade
- Källa
- Utrymme
- specialisera
- specifik
- specifikationer
- spendera
- Spendera
- standard
- står
- startar
- status
- Steg
- Steg
- Fortfarande
- förvaring
- lagras
- misslyckande
- strategier
- hållfasthet
- Sträng
- stark
- Kamp
- framgångsrik
- Framgångsrikt
- sådana
- sammanfatta
- Superladdning
- stödja
- Stödjande
- Stöder
- förment
- systemisk
- systemrisk
- System
- Tackles
- Ta
- pålrot
- Målet
- targeting
- Teknisk
- tekniskt
- Teknologi
- villkor
- än
- den där
- Smakämnen
- Mynt
- deras
- Dem
- sig själva
- sedan
- Där.
- vari
- därför
- Dessa
- de
- saker
- tror
- Tredje
- detta
- de
- hot
- tre
- tröskelvärde
- Genom
- Således
- tid
- tidskrävande
- till
- i dag
- dagens
- alltför
- verktyg
- ämnen
- Totalt
- mot
- Trace
- spår
- track record
- Tåg
- transaktion
- Transaktioner
- övergångar
- Översätt
- kassan
- Träd
- sann
- Litar
- betrodd
- trustless
- sanningen
- vridning
- två
- typer
- typisk
- oförmögen
- förstå
- släpper loss
- till skillnad från
- låsa
- låser upp
- oförutsägbar
- tills
- uppgradera
- us
- användbarhet
- användning
- Begagnade
- Användare
- Användarupplevelse
- användare
- användningar
- med hjälp av
- utnyttja
- utnyttjas
- Använda
- ux
- BEKRÄFTA
- mängd
- olika
- Omfattande
- leverantör
- verifierade
- verifiera
- version
- mycket
- genomförbar, livskraftig
- avgörande
- sårbarheter
- vänta
- plånbok
- Plånböcker
- vill
- var
- Sätt..
- sätt
- we
- były
- Vad
- när
- närhelst
- om
- som
- medan
- Hela
- varför
- wikipedia
- kommer
- med
- inom
- utan
- ord
- världen
- skulle
- skriven
- Fel
- år
- ännu
- Om er
- Din
- själv
- zephyrnet
- noll-