Ting å vite: |
- Miniscript gjør det mulig å bygge Bitcoin programvare lommebøker som gjør en bakdør umulig å utnytte. Vi er glade for å si at Ledger er den første kommersielle maskinvarelommebokprodusenten som støtter miniscript.
- Tilleggsfunksjonene kan implementeres uten at det går på bekostning av brukeropplevelsen. |
Maskinvaresigneringsenheter er konstruert for å beskytte brukeren mot forskjellige vanlige angrepsvektorer, for eksempel:
- Uautorisert tilgang og utvinning av frøet
- Skadelig programvare infiserer den tilknyttede programvarelommeboken
- Programvaresårbarheter på selve enheten
Som enhver bedrift er det i produsentens beste interesse å lage enheter som uknuselig som de kan. Å lykkes med dette oppdraget er avgjørende, og sikkerhetsselskaper som Ledger er avhengige av et rykte bygget på deres merittliste.
Noen brukere kan imidlertid fortsatt ha bekymringer. Hva hindrer selskapet selv i å skjule en backdoor i enhetene?
I selvforvaring, vi ikke stol på, vi bekrefter.
Men kan brukeren virkelig bekrefte at en enhet ikke har en bakdør?
Det er nøkkelspørsmålet denne artikkelen går inn på. Mer presist tar denne artikkelen opp følgende emner:
- hva er en bakdør, og hvorfor det er vanskelig, om ikke umulig, å bevise at det ikke finnes en;
- hvorfor bare brukere kan beskytte seg mot denne risikoen;
- hvordan miniscript muliggjør praktiske løsninger på denne utfordringen for bitcoin-lommebøker.
Ved å være den første maskinvarelommeboken som støtter miniskript, håper vi å inspirere utviklere til å bygge sikre løsninger og oppgradere hele bransjen vår, og eliminere sjansen for at en slik systemrisiko noen gang vil materialisere seg.
Hvordan bygge ubrukelig signeringsenhet
La oss si det klart: du kan ikke.
For å forsvare deg mot en potensiell bakdør trenger du en annen angrepsmodell enn den vi skisserte ovenfor: i dette scenariet kan motstanderen være leverandøren selv, eller en ødelagt innsidemann.
Den ofte omtalte løsningen på dette problemet er åpen kildekode: tross alt, hvis du kan inspisere koden, hva kan muligens gå galt?
Sannheten er imidlertid mer kompleks. Siden leverandøren setter sammen maskinvaren, kan en bakdør være helt inne i den. Maskinvaren kan være utformet for å se bort fra programvaren på visse punkter og kjøre ondsinnet kode i stedet.
I motsetning til programvare som kjører på generelle dataenheter (som din bærbare datamaskin eller telefon), er det praktisk talt umulig å granske maskinvaren med dagens teknologi. Selv om maskinvarespesifikasjonene var helt åpen kildekode, komplett med detaljene for hver enkelt port i kretsen, ville du fortsatt trenge høykostutstyr for å bekrefte at en spesifikk brikke er bygget i samsvar med dem.
Slik bakdører du en maskinvarelommebok
Her er noen av de enkleste metodene en ondsinnet maskinvareleverandør kan bruke for å introdusere en bakdør, sammen med noen måter strømbrukere kan beskytte seg selv i dag.
Frøgenerering
Mange enheter gir deg muligheten til å generere et frø (også kalt Hemmelig gjenopprettingsfrase) direkte på enheten ved å bruke en Ekte tilfeldig tallgenerator.
😈 Den onde enheten kan generere frø som virker tilfeldige, men som faktisk er forutsigbare for angriperen.
🛡️ Avanserte brukere kan omgå dette problemet ved å generere en mnemonikk offline. I tillegg inkluderer en robust passphrase kan også generere et helt uavhengig frø som maskinvareleverandøren ikke kan forutsi. Avveiningen er at brukerne må sørge for at de sikkerhetskopierer passordfrasen på riktig måte i tillegg til mnemoniske ord.
Avledning av offentlig nøkkel
Maskinvare lommebøker utlede og eksportere offentlige nøkler (også kalt xpubs, kort for utvidet offentlig nøkkel som definert i BIP-32. De xpubs brukes til å generere mulige adresser for mottak av mynter.
😈 Den onde enheten kan returnere offentlige nøkler kontrollert av angriperen i stedet for de riktige som er hentet fra frøet.
🛡️ Brukere kan validere det utledede xpub på en annen, frakoblet enhet. Å gå inn i frøet på andre enheter har imidlertid sin egen risiko. Sikkerhetsbevisste brukere kan anse enhver enhet som har fått tilgang til frøet som farlig, potensielt til det punktet å ødelegge dem. Den typiske brukeren kan slite med å utføre denne prosedyren riktig mens han håndterer tilleggsrisikoen.
Lekk informasjon
An luft mellomrom er ofte foreslått som en løsning for å forhindre at en ondsinnet eller kompromittert enhet eksfiltrerer private nøkler. Tross alt, hvis en enhet ikke kan kommunisere med omverdenen, kan den ikke gjøre noe skadelig, ikke sant?
Ikke helt!
Enheten kan alltid kommunisere når den er i bruk: den produserer signaturer. Disse signaturene ender opp i transaksjoner som kringkastes og lagres for alltid på blokkjeden.
En signatur er en tilfeldig utseende byte-streng på minst 64 byte. Men siden mer enn én gyldig signatur kan tilsvare den samme meldingen, kan en skadelig enhet kommunisere noen få biter med informasjon hver gang en signatur produseres, ved å generere flere signaturer og selektivt velge hvilken som skal publiseres.
😈 En useriøs enhet kan produsere ikke-tilfeldige signaturer som over mange transaksjoner avslører frøet til angriperen!
En angriper som lykkes med å installere en slik bakdør vil bare måtte vente på at ondsinnede signaturer vises på blokkjeden til de har nok informasjon til å rekonstruere hele frøet.
🛡️ For ECDSA-signaturer, bruk en standardisert metode for å utlede nonsen deterministisk (som RFC6979) hindrer dette angrepet, forutsatt at man validerer at den produserte signaturen samsvarer med den forventede. For å sikre at dette er tilfelle, kreves det imidlertid lasting av en annen enhet med samme frø, noe som fører til de samme praktiske problemene som nevnt i forrige avsnitt.
🛡️ En interessant tilnærming er å bruke en smart måte å styrke enheten for å faktisk velge en tilfeldig nonce. En protokoll for dette formålet, kjent som anti-exfil or anti-klepto, er for tiden implementert i Blockstream Jade og ShiftCrypto BitBox02 maskinvare lommebøker. Les mer på ShiftCryptos blogg, som også inkluderer en teknisk beskrivelse av hvordan et slikt angrep kan utføres.
Ok da, er det ikke noe håp?
De fleste av forsvarene🛡️ oppført ovenfor krever for det meste at brukeren utfører eksplisitte, påtrengende handlinger for å beskytte seg selv: enten ved å generere frøet på egen hånd (i hovedsak bruke hjernen til å erstatte funksjonaliteten fra maskinvarelommeboken), eller ved å bruke en ekstra enhet for å bekrefte at beregningene er korrekt utført.
Imidlertid skiller anti-exfil-protokollen seg ut: gitt at det alltid er en maskin som formidler mellom maskinvareunderskriveren og omverdenen, kan denne maskinen hjelpe. Gjennom en interaktiv protokoll med maskinvaresigneren kan den håndheve bruken av en genuint tilfeldig nonce, og dermed redusere eller eliminere sjansen for betydelig manipulering av den endelige signaturen.
I dette blogginnlegget er vi først og fremst interessert i denne typen tiltak: mens strategier som betydelig forverrer brukeropplevelsen kan være tiltalende for superbrukere, vil de sannsynligvis gjøre ting verre i praksis for de mindre teknisk dyktige brukerne – som er de aller fleste.
Sikkerhetsmodellen
Standardmodell for maskinvaresignere
Maskinvaresigneringsprodusenter tar sikte på å beskytte brukere mot en rekke potensielle trusler (for mer informasjon, se Trusselmodell). I denne artikkelen fokuserer vi på en, veldig viktig egenskap, som kan oppsummeres som følger:
Brukere kan ikke bli lurt til en handling som resulterer i tap av midler, forutsatt at de forstår og bekrefter informasjonen på skjermen før godkjenning.
Godkjenning er nødvendig for enhver sensitiv handling, spesielt signaturer. Beskyttelse av frøet ville være nytteløst hvis skadelig programvare kunne produsere signaturer for vilkårlige meldinger, for eksempel en transaksjon som tapper alle midlene!
Det er avgjørende å understreke at egenskapen ovenfor må gjelde selv om programvarelommeboken er fullstendig kompromittert. Det som vises på skjermen på den bærbare datamaskinen/telefonen kan ikke stoles på: skadelig programvare kan erstatte adresser, lure deg om hvilke adresser som er dine, presentere en transaksjon, men deretter videresende en annen til enheten for signering osv.
Derfor vurderer fastvaren og applikasjonene som kjører på en maskinvaresigneringsenhet programvarelommeboken i seg selv utro og upålitelig.
Anti-bakdør sikkerhetsmodell for programvarelommebøker
I denne delen snur vi rollene helt. Vi ønsker nå å designe en programvare lommebok som forhindrer maskinvareprodusenten i å stjele eller forårsake tap av midler, selv om enheten er fullstendig skadelig.
Derfor kan ikke dette være en eiendom til enhet: snarere, det er en egenskap til programvare lommebok oppsett. Vi kan oppsummere det slik:
Forutsatt at programvarelommeboken ikke er kompromittert, kan ikke maskinvareprodusenten føre til at brukeren taper penger.
Dette kan virke motintuitivt, da det direkte motsier standard sikkerhetsmodellen beskrevet ovenfor. Men "ikke ha en bakdør" betyr "å gjøre akkurat det de skal gjøre". Siden programvarelommeboken er såle grensesnittet mellom signeringsenheten og den ytre verden, er det det eneste stedet der beskyttelse mot feil oppførsel kan håndheves – enten det er på grunn av en feil eller eksplisitt kompromittering av enheten.
Merk at denne modellen strekker seg betydelig utover en enhetsfeil, for eksempel en utnyttbar feil. I dette tilfellet opererer vi innenfor et scenario der enheten aktivt søker å forårsake tap av midler.
Selvfølgelig er det ingen mulig beskyttelse hvis produsenten har kompromittert både enheten og også maskinen din som kjører programvarelommeboken. Derfor er det helt avgjørende å sikre at programvarelommeboken din er åpen kildekode og kan kontrolleres, spesielt hvis den er bygget av samme leverandør som produserer maskinvaren.
Rollen som miniskript
Miniscript utstyrer lommebokutviklere med muligheten til å fullt ut utnytte de avanserte funksjonene til bitcoin Script. For en oversikt over de utrolige mulighetene miniscript låser opp, se vårt forrige blogginnlegg. Du vil kanskje også høre på Episode 452 av Stephan Livera Podcast for en diskusjon om hva miniskript bringer til bitcoin-landskapet.
Ledger Bitcoin-appen støtter miniskript siden 2.1.0-utgivelsen, som ble distribuert i februar 2023. På Bitcoin 2023-konferansen i Miami kunngjorde Wizardsardine 1.0-utgivelsen av deres Liana lommebok, den første utplasserte lommeboken basert på miniskript.
Den grunnleggende ideen med dette innlegget er at en bitcoin-lommebokkonto kan beskyttes ikke bare med en, men med flere nøkler. Dette tillater fleksible sikkerhetsrammer der selv en total feil eller kompromittering av en nøkkel ikke er katastrofal.
Multisig-grublerier
Multisig er en betydelig oppgradering av styrken til en selvdepotløsning. Ved å utnytte programmerbarheten til Bitcoin Script, muliggjør det opprettelsen av lommebøker som krever flere nøkler i stedet for bare én. EN k-av-n multisig lommebok krever en kombinasjon av k gyldige signaturer, av totalt n mulige.
Imidlertid legger multisig også en UX-belastning på brukeren, og introduserer nye muligheter for feil. Et 3-av-3 multisig-oppsett, som involverer tre forskjellige nøkler som er sikkert sikkerhetskopiert på separate steder, tilbyr sterk sikkerhet ... men det betyr også at selv om en enkelt nøkkelen er tapt, myntene blir permanent utilgjengelige!
Derfor har oppsett som tilbyr mer redundans (som 2-av-3 eller 3-av-5) en tendens til å være mer populære: Skulle en enkelt nøkkel gå tapt, kan de andre nøklene fortsatt lette gjenoppretting. Men dette introduserer en avveining: Hvis én nøkkel blir kompromittert uten at du vet det, reduseres den generelle sikkerheten betydelig!
Bedrifter som Hus og Ubehandlet kapital spesialiserer seg på selvdepotløsninger hvor de innehar et mindretall av nøklene for sine kunder. De hjelper også brukerne sine ved å veilede dem gjennom onboarding-prosessen og forenkle bruken av depotsystemer, noe som ellers kan være skremmende for de fleste ikke-tekniske brukere.
Miniscript og tidslåste gjenopprettingsbaner
Liana bruker miniskript for å lage lommebøker som har flere måter å bruke penger på:
- en primær forbruksbetingelse, som er umiddelbart tilgjengelig;
- en eller flere tilleggsbetingelser som blir tilgjengelige etter en viss periode (den såkalte tidlås).
Dette muliggjør mange interessante brukstilfeller:
- Gjenoppretting: En standard lommebok med enten enkeltsignatur eller multisig som primær utgiftsbane; men en egen gjenopprettingsmekanisme (en nøkkel med et annet frø, en multisig, en teknisk kunnskapsrik venn, en forvalter) blir tilgjengelig etter 6 måneder.
- Governance: Et selskap med to styremedlemmer kan etablere en 2-av-2 for selskapets treasury; i tilfelle uenighet, kan en betrodd advokat få tilgang til midlene etter 6 måneder.
- Rånende multisig: En lommebok starter som en 3-av-3, går over til en 2-av-3 etter 6 måneder, og blir en 1-av-3 etter 9 måneder.
- Automatisk arv: Restitusjonsveien etter 6 måneder inkluderer en 2-av-3 av dine tre barn; kanskje en ny utvinningsvei etter 1 år involverer en notarius, i tilfelle arvingene ikke kan nå en konsensus.
Merknad: alle eksemplene ovenfor bruker en relativ tidslås, som refererer til alderen på myntene (det vil si: forrige gang midlene ble flyttet). Avveiningen er at brukeren må huske å bruke myntene (ved å sende dem til seg selv) hvis tidslåsen nærmer seg utløp.
Dette er bare noen få eksempler, men de burde være nok til å overbevise leseren om at miniskript er et betydelig skritt fremover mot å realisere Bitcoins potensial som programmerbare penger.
Registrering av lommebokpolicy
For Bitcoin-lommebokkontoer som bruker flere nøkler (det være seg multisig, eller mer sofistikerte miniscript-baserte løsninger), er det avgjørende å trene enheten til å identifisere adressene som tilhører den kontoen. Dette er den eneste måten enheten kan hjelpe brukeren med å sikre at de mottar eller bruker fra de riktige adressene ...
Validering av policyen og xpubs av cosigner mot en pålitelig sikkerhetskopi er viktig, men relativt tidkrevende.
Den gode nyheten er at det bare trenger å gjøres én gang:
Når en policy er registrert med et navn (i eksempelet «Decaying 3of3»), vil enheten din kunne gjenkjenne den når en slik policy brukes.
De som er interessert i tekniske detaljer kan finne mer informasjon i BIP forslag.
Sikkerhetskopiering av policy
Et kritisk aspekt å merke seg er at mens flernøkkelpolicyer tillater en undergruppe av private nøkler å autorisere transaksjoner, kunnskap om alle de offentlige nøklene (og eksakte policy) er påkrevd.
Imidlertid, i motsetning til frøet, er sikkerhetskopiering av policyen og de offentlige nøklene langt mindre risikabelt: Hvis noen skulle oppdage det, kunne de spore alle transaksjonene knyttet til den policyen. Selv om dette ikke er ideelt – personvern er viktig! − det er ikke så katastrofalt som å miste myntene dine og mindre fristende for potensielle angripere. Følgelig er å lagre flere kopier av policyen i hot wallets, skrive den ut og lagre den på forskjellige steder, kryptere den og lagre den i skylagring, og så videre, alle levedyktige strategier.
Lommeboken med én signatur uten bakdør
La oss ta et skritt tilbake. Vi har diskutert lommebøker med flere signaturer, men nå går vi tilbake til det grunnleggende for å lage en lommebok med én signatur. Mer presist vil vi ha en lommebok som føles og utseende som en lommebok med én signatur, etter en innledende oppsettfase. Likevel har vi som mål å lage en lommebok som produsenten ikke kan stjele pengene dine fra selv om de er ondsinnede 😈, og maskinvaresigneringsenheten oppfører seg på uforutsigbare måter.
Tilnærmingen kan lett generaliseres for lommebøker med flere signaturer.
Eksemplene nedenfor vil være skrevet på et språk som heter politikk, i stedet for miniskript. Politikk er lettere for mennesker å lese og tenke på, og kan kompileres til miniskript med automatiserte verktøy. Les mer om miniskript og policy.
Maskinvarelommeboken kan beskytte deg i standard sikkerhetsmodell. Miniscript kan beskytte deg i sikkerhetsmodellen mot bakdør (og mye mer!).
Trinn null: status quo
Dette er policyen de fleste brukere bruker i dag: en enkelt nøkkel som er avledet fra et frø produsert i maskinvarelommeboken.
pk(key_ledger)
Selvfølgelig er det ingen måte å bevise fraværet av en bakdør.
Trinn én: doble disse tastene
Det første trinnet er enkelt:
and(pk(key_ledger), pk(key_client))
Her key_client
genereres på brukerens maskin, derav en hurtigtast. I hovedsak er det et 2-av-2 multisig-oppsett. Nøkkelaspektet er at brukeren ikke samhandler mye med key_client
: programvarelommeboken genererer denne nøkkelen, inkluderer den i lommebokens sikkerhetskopi og signerer når det er nødvendig (for eksempel mens brukeren er opptatt med å signere med maskinvaren sin).
Dette virker allerede ganske interessant: midlene er ubrukelige uten key_client
, som ikke er tilgjengelig for maskinvareleverandøren; selv om den onde leverandøren hadde full kunnskap om nøkkelen i enheten, ville de fortsatt ikke være i stand til å flytte midlene uten å eksplisitt målrette brukeren, for eksempel ved å kompromittere maskinen som kjører programvarelommeboken deres.
Det er imidlertid et problem: under onboarding av lommeboken er maskinvaresigneren den eneste enheten som er i stand til å generere den offentlige nøkkelen (xpub) key_ledger
brukt i lommeboken. Derfor kan enheten med vilje generere en Feil xpub kontrollert av angriperen, og senere avslå (eller være ute av stand til) å signere. Utvilsomt er dette et ganske ekstremt angrepsscenario: bakdørsskaperen kan ikke stjele midlene, og det meste de kan gjøre er å målrette brukeren individuelt og kreve løsepenger ("Jeg kan hjelpe deg med å hente pengene dine hvis du betaler halvparten til meg").
Mer realistisk øker dette sjansen for feil av feil: du har nå to frø / private nøkler, og du trenger både for å kunne bruke. Tap enten, og mynter er låst for alltid.
Trinn to: tidslåst gjenoppretting
Vi introduserer en egen gjenopprettingsnøkkel, kun tilgjengelig etter en bestemt tidslås: and(older(25920)
, pk(key_recovery))
, hvor 25920 er det omtrentlige antallet blokker på 6 måneder. Hele policyen blir:
or(
and(pk(key_ledger), pk(key_client)), and(after(25920), pk(key_recovery))
)
Dette ligner på forrige scenario, men med en vri: if key_ledger
or key_client
blir utilgjengelig av en eller annen grunn (oftest, å miste frø-backupen!), a gjenopprettingsvei blir tilgjengelig etter 6 måneder.
Det er flere alternativer for key_recovery
, hver med sine egne avveininger:
a. Bruk en annen hurtigtast. Dette er en praktisk løsning så lenge brukeren husker å tilbakestille tidslåsen. Imidlertid, hvis hurtigtastene er kompromittert (et scenario som generelt bør anses som ganske sannsynlig!), kan angriperen forsøke å få tilgang til midlene så snart tidslåsen utløper, og starte et kappløp med den legitime eieren.
b. Bruk en separat maskinvaresigneringsenhet. Dette er en robust løsning og kan brukes i kombinasjon med en annen leverandør om ønskelig; det øker imidlertid kompleksiteten og kostnadene for oppsettet for brukeren når det gjelder brukeropplevelse.
c. Bruk en pålitelig ekstern tjeneste. Programvarelommeboken kan importere en xpub fra en ekstern tjeneste ved å bruke den som key_recovery
. Denne tredjeparten er bare klarert hvis tidslåsen utløper, noe som kan være en tiltalende avveining for noen brukere.
Som nevnt, som for enhver policy med tidslås, er det viktig at brukeren husker å oppdatere myntene før tidslåsens utløp.
Trinn tre: den upålitelige tredjeparten
La oss blande begge ideene (a) og (c): for gjenopprettingsbanen krever vi en lokal hurtigtast key_recovery_local
Og key_recovery_remote
som er vert for en semi-klarert tjeneste; vi beholder også tidslåsen.
or(
and(pk(key_ledger), pk(key_client)),
and(older(25920),
and(pk(key_recovery_local), pk(key_recovery_remote))
)
)
Dette reduserer nivået av tillit som trengs fra gjenopprettingstjenesten. Vi må imidlertid utvise forsiktighet: tjenesten i seg selv kan overvåke blokkjeden og oppdage UTXO-ene våre – tross alt ga de oss key_recovery_remote
xpub, slik at de kan skanne etter UTXO-er som inneholder pubnøkler avledet fra key_recovery_remote
. De vil kunne lære om vår økonomiske historie, selv før tidslåsen utløper, og selv om vi aldri har brukt tjenesten deres.
Merknad: Pælerottrær kan eliminere dette personvernproblemet for visse retningslinjer, men dette er ikke alltid tilfelle og krever nøye evaluering basert på den spesifikke policyen.
Trinn fire: blind tredjeparten 🙈
For å forhindre at gjenopprettingstjenesten lærer om vår økonomiske historie, i stedet for å bruke pubnøkkelen de kommuniserer til oss, kan vi bruke en blind xpub teknikk forklart av mflaxman i detalj her. Kort sagt, i stedet for å bruke key_recovery_remote
i retningslinjene våre velger vi fire 31-biters tilfeldige tall a
, b
, c
, d
(Den blendende faktorer), og vi bruker følgende BIP-32 avledet pubkey:
key_recovery_remote_blind = key_recovery_remote_blind/a/b/c/d
Det er avgjørende at vi også legger til key_recovery_remote
, og de blendende faktorene a
, b
, c
og d
til vår sikkerhetskopi, for fremtidig referanse.
Hvis vi noen gang trenger å bruke gjenopprettingstjenesten, vil vi avsløre a
, b
, c
, d
til dem. Inntil da har de ingen måte å oppdage at nøkler stammer fra deres key_recovery_remote
blir publisert på blokkjeden: antall mulige kombinasjoner for de 4 blindingsfaktorene er 2^(31*4) = 2^124
, som gjør det umulig å bruteforce dem alle.
Trinn fem: for mange hurtigtaster kan brenne deg 🔥
Vi lyktes i å gjøre programvarelommeboken vår ubrukelig. Vi introduserte imidlertid et annet problem: begge forbruksbetingelsene bruker en lokalt generert, varmt nøkkel som ikke er verifisert av maskinvarelommeboken. Derfor, hvis vertsmaskinen er kompromittert, kan det lure deg til å registrere policyen ved hjelp av pubnøklene key_client
og key_recovery_local
, men legg tilfeldige, ikke-relaterte private nøkler i sikkerhetskopien vår (husk at varmt nøkler er en del av sikkerhetskopien vår!).
Det vil i utgangspunktet gjøre at alle midler sendes til lommeboken ubrukelig, siden ingen kontrollerer de private nøklene som er nødvendige for å signere.
Det er noen løsninger for å løse dette problemet:
- Under onboarding, etter å ha skrevet ut sikkerhetskopien på papir, kan vi bruke en separat enhet for å bekrefte at de private og offentlige hurtigtastene på sikkerhetskopien faktisk stemmer overens. Denne tilnærmingen ville eliminere problemet, siden vi ville være sikre på at vi har alle nødvendige nøkler som trengs for rekonstruksjon og signering.
- Vi kan legge til en annen forbruksbetingelse med en enda lengre tidslås (9 måneder, 38880 blokker) som bare krever en
key_ledger_failsafe
fra maskinvareenheten. På denne måten faller vi tilbake til sikkerheten til en enkelt signeringsenhet i det absolutte verste tilfellet der alt annet feiler. I normale operasjoner ville vi aldri la den første tidslåsen utløpe, og dermed vil den andre tidslåsen heller ikke utløpe!
Med den andre tilnærmingen vil den endelige politikken se slik ut
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))
),
)
Denne programvarelommebokkonfigurasjonen tilfredsstiller alle sikkerhetsegenskapene som vi hevdet i begynnelsen. Dessuten tilbyr det en gjenopprettingsvei i tilfelle de viktigste utgiftsnøklene key_ledger
er tapt. En fin funksjon å ha!
Ombord på programvarelommeboken som ikke kan åpnes
Hvordan vil brukeropplevelsen for en lommebok som bruker en så kompleks policy se ut? Her er en kort oversikt:
- Brukeren åpner programvarelommeboken og begynner å opprette en ny konto.
- Programvarelommeboken ber brukeren om å koble til signeringsenheten sin og henter xpubene for
key_ledger
ogkey_ledger_failsafe
. - Programvarelommeboken genererer automatisk hurtigtasten key_client.
- Programvaren lommebok får
key_recovery_remote
fra en samsigneringstjeneste eller lar brukeren spesifisere en nøkkel på en annen måte. Eventuelt beregner denkey_recovery_remote_blind
ved å bruke blendingsteknikken nevnt tidligere. - Programvarelommeboken genererer en policy-sikkerhetskopi som inneholder den nøyaktige miniscript-policyen, alle xpubene og den utvidede private nøkkelen for
key_client
hurtigtast. Denne sikkerhetskopien er trygt lagret (for eksempel skrevet ut på papir eller lagret på en separat enhet). - Til slutt instruerer programvarelommeboken brukeren om å registrere policyen på enheten. Brukeren krysssjekker sikkerhetskopien (på papir eller et annet medium enn skjermen som kontrolleres av programvarelommeboken).
Programvarelommeboken håndterer de fleste av trinnene ovenfor, noe som gjør brukerens involvering ikke mer tyngende enn den forventede innsatsen som trengs i dag for å sette opp en multisignaturlommebok.
Onboardingen skal bare ta noen minutter når en god UX er bygget for den. Når den er fullført, kan programvarelommeboken gi en brukeropplevelse som er veldig lik den til en vanlig lommebok med én signatur. Slik vil miniskript endre alt: ved å forsvinne fra brukerens syn!
Taproot forbedringer
Ledger støtter miniskript siden versjon 2.1.0 av Bitcoin-appen, utgitt i mars. Mens støtte for mottak til og utgifter fra taproot-adresser var aktivert siden pælerot softgaffel i november 2021 legger vi nå siste hånd på neste trinn i veikartet: miniskriptstøtte for taproot.
Taproot vil ha en stor innvirkning på brukervennligheten til tilnærmingene som presenteres i denne artikkelen. Hvis den primære utgiftsbanen er en enkelt-nøkkel utgiftsbetingelse, vil eksistensen av gjenvinningsutgiftsbaner være uoppdagelige på blokkjeden med mindre de blir brukt. Dette vil i stor grad forbedre personvernet ved å fullstendig eliminere eventuelle fingeravtrykk for standard forbruksbanen. Videre forbedrer det skalerbarheten, ettersom standardutgiftsbanen blir så kostnadseffektiv å bruke som mulig. Dette betyr at ingen ekstra kostnader vil påløpe på grunn av tilstedeværelsen av gjenopprettingsbaner, med mindre de brukes. Dette er en betydelig oppgradering fra SegWit-transaksjoner, som krever publisering av hele skriptet, inkludert alle forbruksbetingelser, under ethvert forbruk.
Til slutt, mer avanserte protokoller som MuSig2 (nylig standardisert) og FROST vil overlade taproot-tastebanen. Disse protokollene er bygget på Schnorr-signaturer og lar deg lage en singel samlet pubnøkkel som kan brukes til å representere en n-av-n multisignatur eller en k-av-n terskelordning. Dette vil tillate bruk av taproot-tastebanen selv i tilfeller som i dag er mer vanlig representert med spesifikke multisig-skript.
Konklusjoner
Denne artikkelen utforsker en liten (men viktig) nisje av den enorme designplassen som miniskriptet frigjør for programvarelommebøker.
Vi viste hvordan miniscript kan brukes til å lage en programvarelommebok som ikke kan åpnes, samtidig som vi legger til en ekstra gjenopprettingsbane som gjør det mulig å forhindre katastrofale nøkkeltap. Mens maskinvaresigneringsenheter ikke kan håndheve anti-bakdørssikkerhetsmodellen, ved å støtte miniscript aktiverer de programvarelommebøker som gjør akkurat det!
Ved smart å bruke en kombinasjon av multisignaturskjemaer, tidslåser, blinde xpubs og hurtigtaster, har vi demonstrert en sikker lommebokkonfigurasjon som balanserer sikkerhet, personvern og robusthet.
Dessuten hevdet vi at dette er mulig uten å påvirke brukeropplevelsen negativt, siden kompleksiteten til oppsettet ikke oversetter til en stor ekstra UX-byrde.
Vi er spente på mulighetene som miniscript vil låse opp for neste generasjon av bitcoin-selvforvaring.
- SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
- PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
- PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
- PlatoESG. Bil / elbiler, Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
- BlockOffsets. Modernisering av eierskap for miljøkompensasjon. Tilgang her.
- kilde: https://www.ledger.com/blog/towards-a-trustless-bitcoin-wallet-with-miniscript
- : har
- :er
- :ikke
- :hvor
- $OPP
- 1
- 2021
- 2023
- 30
- 7
- 9
- a
- evne
- I stand
- Om oss
- ovenfor
- Absolute
- absolutt
- adgang
- aksesseres
- tilgjengelig
- samsvar
- Logg inn
- kontoer
- Handling
- handlinger
- aktivt
- faktisk
- legge til
- legge
- tillegg
- Ytterligere
- I tillegg
- adresser
- avansert
- Etter
- mot
- alder
- Aid
- sikte
- Alle
- tillate
- tillater
- langs
- allerede
- også
- Selv
- alltid
- an
- og
- annonsert
- En annen
- noen
- hva som helst
- app
- tiltrekkende
- vises
- søknader
- tilnærming
- tilnærminger
- godkjenning
- tilnærmet
- ER
- antageligvis
- argumentert
- Artikkel
- AS
- aspektet
- bistå
- assosiert
- At
- angripe
- kontrollerbar
- autorisere
- Automatisert
- autonomt
- tilgjengelig
- tilbake
- backdoor
- Backed
- backing
- Backup
- balanserer
- basert
- grunnleggende
- I utgangspunktet
- Grunnleggende
- BE
- fordi
- bli
- blir
- før du
- Begynnelsen
- være
- under
- BEST
- mellom
- Beyond
- Bitcoin
- Bitcoin lommebok
- bitcoin lommebøker
- Blend
- blockchain
- Blocks
- Blockstream
- Blogg
- både
- Brain
- Bringer
- kringkaste
- Bug
- bygge
- bygget
- byrde
- brenne
- virksomhet
- opptatt
- men
- by
- som heter
- CAN
- kan ikke
- stand
- forsiktig
- saken
- saker
- katastrofal
- Årsak
- forårsaker
- forsiktighet
- viss
- utfordre
- sjanse
- endring
- Barn
- chip
- Velg
- velge
- hevdet
- klart
- Cloud
- sky lagring
- kode
- Mynter
- kombinasjon
- kombinasjoner
- kommersiell
- Felles
- vanligvis
- kommunisere
- Selskaper
- Selskapet
- Selskapets
- fullføre
- helt
- komplekse
- kompleksitet
- kompromittert
- kompromittere
- beregninger
- databehandling
- bekymringer
- tilstand
- forhold
- Konferanse
- Konfigurasjon
- Koble
- Konsensus
- Følgelig
- Vurder
- ansett
- inneholdt
- kontrolleres
- kontroller
- overbevise
- korrigere
- ødelagt
- Kostnad
- kunne
- Kurs
- skape
- Opprette
- skaperverket
- skaperen
- kritisk
- kritisk aspekt
- avgjørende
- I dag
- vaktmester
- varetekt
- Kunder
- Dangerous
- Avslå
- avtar
- anser
- definert
- Etterspørsel
- demonstrert
- utplassert
- Avledet
- beskrivelse
- utforming
- designet
- ønsket
- detalj
- detaljert
- detaljer
- oppdage
- utviklere
- enhet
- Enheter
- forskjellig
- vanskelig
- avtagende
- direkte
- Styremedlemmer
- forsvinner
- katastrofal
- oppdage
- oppdage
- diskutert
- diskusjon
- vises
- do
- gjør
- ikke
- gjort
- dobbelt
- to
- under
- hver enkelt
- enklere
- lett
- innsats
- enten
- eliminere
- eliminere
- ellers
- understreke
- ansatt
- muliggjøre
- aktivert
- muliggjør
- slutt
- håndheve
- nok
- sikre
- sikrer
- går inn
- fristende
- Hele
- fullstendig
- enhet
- utstyr
- feil
- spesielt
- avgjørende
- hovedsak
- etablere
- etc
- evaluering
- Selv
- NOEN GANG
- Hver
- alt
- nøyaktig
- eksempel
- eksempler
- opphisset
- henrette
- henrettet
- Øvelse
- eksistens
- forventet
- erfaring
- utløp
- Exploit
- utforsker
- eksportere
- strekker
- utvendig
- ekstrem
- legge til rette
- faktorer
- mislykkes
- Failure
- ganske
- Fall
- langt
- Trekk
- Egenskaper
- Februar
- Noen få
- slutt~~POS=TRUNC
- finansiell
- økonomihistorie
- Finn
- Først
- fleksibel
- Flip
- Fokus
- etter
- følger
- Til
- for alltid
- Forward
- fire
- rammer
- ofte
- venn
- fra
- fullt
- fullt
- funksjonalitet
- fond
- midler
- Dess
- nytteløs
- framtid
- generell
- generelt
- generere
- generert
- genererer
- genererer
- generasjonen
- gitt
- Go
- skal
- god
- flott
- sterkt
- HAD
- Halvparten
- maskinvare
- maskinvareenhet
- Maskinvare lommebok
- Produsent av maskinvarelommebok
- Maskinvare lommebøker
- skadelig
- Ha
- å ha
- hjelpe
- derav
- historie
- hold
- håp
- vert
- vert
- HOT
- Hvordan
- Men
- http
- HTTPS
- stort
- Mennesker
- Tanken
- ideell
- Ideer
- identifisere
- if
- umiddelbart
- Påvirkning
- slag
- implementert
- importere
- viktig
- umulig
- forbedre
- in
- inkluderer
- Inkludert
- innlemme
- øker
- utrolig
- faktisk
- uavhengig
- individuelt
- industri
- informasjon
- iboende
- innledende
- innsiden
- insider
- inspirere
- installere
- f.eks
- i stedet
- med hensikt
- samhandle
- interaktiv
- interesse
- interessert
- interessant
- Interface
- inn
- introdusere
- introdusert
- Introduserer
- intrusively
- engasjement
- involverer
- utstedelse
- IT
- DET ER
- selv
- bare
- bare én
- nøkkel
- nøkler
- Vet
- kunnskap
- kjent
- landskap
- Språk
- laptop
- Siste
- seinere
- advokat
- Fører
- LÆRE
- læring
- minst
- Ledger
- venstre
- legitim
- mindre
- la
- Nivå
- utnytte
- i likhet med
- Sannsynlig
- knyttet
- oppført
- lasting
- lokal
- steder
- låst
- Lang
- lenger
- Se
- ser ut som
- taper
- å miste
- tap
- tap
- tapte
- maskin
- Hoved
- Flertall
- gjøre
- GJØR AT
- Making
- malware
- forvalter
- administrerende
- manipulere
- måte
- Produsent
- Produsenter
- mange
- Mars
- Match
- Kan..
- midler
- målinger
- mekanisme
- medium
- nevnt
- bare
- melding
- meldinger
- metode
- metoder
- Miami
- kunne
- miniskript
- minoritet
- minutter
- Oppdrag
- feil
- modell
- penger
- overvåking
- måneder
- mer
- Videre
- mest
- for det meste
- flytte
- flyttet
- mye
- flere
- multitegn
- må
- navn
- nærmer seg
- nødvendig
- Trenger
- nødvendig
- behov
- negativt
- nettverk
- aldri
- Ny
- nyheter
- neste
- fint
- Nei.
- ikke-teknisk
- normal
- November
- november 2021
- nå
- Antall
- tall
- innhenter
- of
- tilby
- tilby
- Tilbud
- offline
- on
- onboarding
- gang
- ONE
- seg
- bare
- åpen
- åpen kildekode
- åpner
- drift
- Drift
- Muligheter
- alternativer
- or
- rekkefølge
- Annen
- ellers
- vår
- ut
- skissert
- utenfor
- enn
- samlet
- oversikt
- egen
- eieren
- Papir
- Paramount
- del
- spesielt
- parti
- banen
- Betale
- Utfør
- kanskje
- perioden
- permanent
- fase
- telefon
- Sted
- steder
- plato
- Platon Data Intelligence
- PlatonData
- Point
- poeng
- Politikk
- politikk
- Populær
- muligheter
- mulig
- muligens
- Post
- potensiell
- potensielt
- makt
- Praktisk
- praktisk talt
- praksis
- presis
- nettopp
- forutsi
- Forutsigbar
- tilstedeværelse
- presentere
- presentert
- forebygge
- forhindrer
- forrige
- tidligere
- primært
- primære
- utskrift
- Før
- privatliv
- privat
- private Key
- Private nøkler
- Problem
- problemer
- prosedyren
- prosess
- produsere
- produsert
- produserer
- riktig
- egenskaper
- eiendom
- foreslått
- beskytte
- beskyttet
- beskytte
- beskyttelse
- protokollen
- protokoller
- Bevis
- gi
- forutsatt
- offentlig
- offentlig Key
- offentlige nøkler
- publisere
- publisert
- Publisering
- formål
- sette
- Sette
- spørsmål
- Race
- tilfeldig
- Ransom
- heller
- å nå
- Lese
- Reader
- realisere
- grunnen til
- mottak
- nylig
- gjenkjenne
- rekord
- utvinning
- refererer
- registrere
- registrert
- registrering
- relativt
- slipp
- utgitt
- avhengige
- husker
- erstatte
- representere
- representert
- omdømme
- krever
- påkrevd
- Krever
- resulterende
- beholde
- retur
- avsløre
- ikke sant
- Risiko
- risikoer
- Risikabelt
- veikart
- robust
- robusthet
- Rolle
- roller
- rennende
- går
- samme
- sier
- skalerbarhet
- skanne
- scenario
- ordningen
- ordninger
- schnorr
- Skjerm
- skript
- Sekund
- Seksjon
- sikre
- sikkert
- sikkerhet
- se
- seed
- frø
- søker
- synes
- synes
- SegWit
- Selvforvaring
- sending
- sensitive
- sendt
- separat
- tjeneste
- sett
- oppsett
- flere
- Kort
- bør
- viste
- undertegne
- signaturer
- signifikant
- betydelig
- signering
- Skilt
- lignende
- Enkelt
- forenkle
- siden
- enkelt
- liten
- Smart
- So
- Software
- løsning
- Solutions
- LØSE
- noen
- Noen
- snart
- sofistikert
- kilde
- Rom
- spesialister
- spesifikk
- spesifikasjoner
- bruke
- utgifter
- Standard
- står
- starter
- status
- Trinn
- Steps
- Still
- lagring
- lagret
- lagring
- strategier
- styrke
- String
- sterk
- Struggle
- vellykket
- vellykket
- slik
- oppsummere
- Superladning
- støtte
- Støtte
- Støtter
- ment
- systemisk
- systemisk risiko
- Systemer
- takler
- Ta
- taprot
- Target
- rettet mot
- Teknisk
- teknisk sett
- Teknologi
- vilkår
- enn
- Det
- De
- Myntene
- deres
- Dem
- seg
- deretter
- Der.
- derved
- derfor
- Disse
- de
- ting
- tror
- Tredje
- denne
- De
- trusler
- tre
- terskel
- Gjennom
- Dermed
- tid
- tidkrevende
- til
- i dag
- dagens
- også
- verktøy
- temaer
- Totalt
- mot
- Trace
- spor
- banerekord
- Tog
- Transaksjonen
- Transaksjoner
- overganger
- oversette
- treasury
- Trær
- sant
- Stol
- klarert
- trustless
- Sannhet
- vri
- to
- typer
- typisk
- ute av stand
- forstå
- slipper løs
- I motsetning til
- låse opp
- låser opp
- uforutsigbare
- til
- oppgradering
- us
- brukervennlighet
- bruke
- brukt
- Bruker
- Brukererfaring
- Brukere
- bruker
- ved hjelp av
- bruke
- benyttes
- utnytte
- ux
- VALIDERE
- variasjon
- ulike
- enorme
- leverandør
- verifisert
- verifisere
- versjon
- veldig
- levedyktig
- vital
- Sikkerhetsproblemer
- vente
- lommebok
- Lommebøker
- ønsker
- var
- Vei..
- måter
- we
- var
- Hva
- når
- når som helst
- om
- hvilken
- mens
- hele
- hvorfor
- Wikipedia
- vil
- med
- innenfor
- uten
- ord
- verden
- ville
- skrevet
- Feil
- år
- ennå
- Du
- Din
- deg selv
- zephyrnet
- null