Del 2: Genesis of Ledger Recover – Sikker distribusjon av aksjene | Ledger

Velkommen tilbake til andre del av bloggserien vår om Reskontrogjenopprettingsin tilblivelse! Målet vårt er å utforske de mange tekniske hindringene man møter når man bygger en frøgjenvinningstjeneste, og hvordan Ledger Recover løser dem med en sikker design og infrastruktur.

på forrige del, undersøkte vi hvordan du sikkerhetskopierer en hemmelig gjenopprettingsfrase ved å dele den, og hvordan Ledger Recover gjør det for deg ved å bruke Pedersen Verifiserbar hemmelig deling.

Nå som du har tre aksjer, er neste spørsmål: hvordan kan du sikkert distribuere dem til backupleverandørene dine? Faktisk, hvis en ondsinnet part avskjærer alle aksjene mens du overfører dem, beseirer det hensikten med å splitte frøet i utgangspunktet. I cybersikkerhet kalles dette en Man-in-the-Middle angrep, der en angriper står mellom deg og mottakeren din, og tukler med kommunikasjonen for å prøve å avdekke hemmeligheter.

Når du bruker Ledger Recover, utføres overføringen av frøet ditt gjennom en sikker distribusjonsmekanisme. Den er avhengig av flere kryptografiske verktøy og matematiske konsepter som vi vil forklare grundig.

Vi vil starte med å beskrive problemet mer detaljert. Deretter vil vi introdusere flere kryptografiske verktøy og matematiske konsepter som Ledger Recover utnytter for å sikkert distribuere frøaksjene dine til backupleverandører.

Courier-In-The-Middle: Et eksempel fra den virkelige verden

Den mest åpenbare måten å beskytte deg mot en mellommann med dårlig intensjoner er å ikke ha noen i det hele tatt. Du kan gå hjem til vennene dine selv eller samle dem på samme, lukkede sted for å levere aksjene. Men dette blir mye vanskeligere hvis du ikke er samlokalisert og ønsker å sende aksjene til en bekjent på avstand.

Forutsatt at nettverket vi kommuniserer over (f.eks. postvesenet) er iboende upålitelig, hvordan kan vi garantere at avlyttere aldri får et glimt av våre hemmelige aksjer?

Det er på tide å introdusere Alice og Bob, og den beryktede Eve, tre velkjente kryptografiske personas. Alice har en hemmelighet hun vil dele med Bob, og har ikke noe annet valg enn å sende den gjennom Eve, deres upålitelige kurer. Med kryptografiske ord, Alice og Bob ønsker å etablere en sikker kommunikasjonskanal med hverandre for å utveksle hemmeligheten deres trygt.

Her er hva Alice og Bob kunne gjøre:

• Alice legger hemmeligheten sin i en boks, låser den med sin personlige hengelås før hun sender den til Bob.
• Når Bob mottar esken, legger han til sin egen hengelås, og sender den tilbake.
• Alice kan nå bruke nøkkelen sin til å fjerne hengelåsen fra esken før hun sender den en siste gang.
• For å fullføre prosessen, bruker Bob ganske enkelt nøkkelen sin til å fjerne hengelåsen og hente – endelig – hemmeligheten fra Alice.

Gjennom hele utvekslingen, hver gang Eve har hatt boksen i hendene, var den alltid beskyttet, enten av Alices lås, eller Bobs, eller begge deler.

Selv om dette er en utmerket start, er det flere problemer som gjenstår å løse i dette scenariet:

• Gjensidig autentisering: Alice og Bob trenger idiotsikre måter å sjekke at hver hengelås virkelig kommer fra den andre parten. Ellers kan Eve bytte den med sin egen boks og hengelås og lure Alice eller Bob til å tro at hun er den andre parten.
• Videresend hemmelighold: Hvis Eve stjal den låste boksen, og senere stjal Alice eller Bobs nøkkel, kunne hun finne den opprinnelige hemmeligheten. I stedet ønsker vi å sikre at fremtidige lekkasjer av langtidsnøkler ikke kan kompromittere eldre stjålne pakker.
• Beskytte personvernet: I dette scenariet blir Alice og Bobs adresser avslørt til kureren. I den digitale ekvivalenten til denne prosessen ønsker vi en protokoll som ikke avslører noe om mottakerne.

Sikring av digitale meldinger

I digital sikkerhet, a sikker kanal er en måte å overføre data mellom to autentisert parter slik at data konfidensialitet og integritet er garantert. Når du bruker en sikker kanal, kan ikke angripere avlytte eller tukle med kommunikasjonen din.

Ledger Recovers protokoll for både sikkerhetskopiering og gjenoppretting er basert på en Secure Channel Protocoleller SCP. Den bruker flere verktøy i den moderne kryptografiverktøykassen, for eksempel symmetrisk og asymmetrisk kryptering, sertifikater og digitale signaturer.
De neste avsnittene vil gi deg en rask innføring i alle disse konseptene, som lar deg forstå hele sikkerhetsordningen som brukes i Ledger Recover.

Symmetrisk kryptografi: Et kraftig, men begrenset verktøy

For å garantere konfidensialiteten til dataene som utveksles mellom to parter, blir dataene vanligvis kryptert og dekryptert med samme hemmelige nøkkel.
Denne prosessen omtales som symmetrisk kryptografi, som er studiet av primitiver som involverer en enkelt hemmelig nøkkel for å garantere en eller flere av egenskapene til en sikker kanal.

Selv om det er et kraftig verktøy for å beskytte kommunikasjonen din, har symmetrisk kryptografi noen åpenbare begrensninger: Anta at Alice ønsker å utveksle flere krypterte meldinger med Bob. Hun velger først en hemmelig nøkkel, og deler den deretter med Bob, før hun begynner å sende meldinger.
Selvfølgelig blir problemet nå: Hvordan deler Alice den hemmelige nøkkelen sikkert med Bob? Hvis noen får tak i nøkkelen, vil Alice og Bobs kommunikasjon ikke lenger være konfidensiell.
Alice kunne møte Bob personlig for å gi ham nøkkelen, men i dette tilfellet hvorfor ikke ha diskusjonen deres da, vekk fra nysgjerrige ører?

For digital kommunikasjon trenger vi en sikker metode for å dele den symmetriske nøkkelen og starte den beskyttede datautvekslingen. Det er på tide å introdusere arbeidet til to titaner innen moderne kryptografi, Whitfield Diffie og Martin Hellman.

Asymmetrisk kryptografi: Skjuler dine private deler

Diffie-Hellman nøkkelavtale

Med Public Key Cryptography kom Diffie og Hellman opp med en ny tilnærming til å sikre kommunikasjon. De definerte en protokoll med to forskjellige nøkler for kryptering og dekryptering. De to nøklene kalles vanligvis offentlige og private nøkler, som danner et par som kan brukes til å kryptere/dekryptere og signere/verifisere data.

Offentlige og private nøkler
Offentlig nøkkelkryptering er grunnlaget for det meste av vår digitale sikkerhet. Det brukes til å beskytte deg på nettet, og er også hvordan du beviser eierskap til mynter og tokens på alle offentlige blokkjeder.

Lær mer om dette emnet på Ledger Academy!

Det som virkelig er overbevisende for oss er hvordan Diffie og Hellman foreslo å bruke offentlig nøkkelkryptografi for å distribuere symmetriske nøkler. Metoden deres, kjent som Diffie-Hellman nøkkelutveksling, består av frem og tilbake utvekslinger mellom to parter for til slutt å bli enige om en felles hemmelighet. Hvis de utføres riktig, kan ikke avlyttere beregne den samme delte hemmeligheten fra informasjonen de overhører.

TL;DR er at i diagrammet ovenfor er Eve matematisk ute av stand til å finne ut av hemmeligheten k selv om hun har tilgang til all kommunikasjon til Alice og Bob. For å forstå hvorfor denne delte hemmeligheten er trygg for enhver avlytting, må vi grave i litt gruppeteori. 

Sikkerheten til Diffie-Hellman nøkkelutveksling er avhengig av kompleksiteten til det diskrete logaritmeproblemet over en syklisk gruppe. En syklisk gruppe er en gruppe generert av et enkelt element.
I et nøtteskall utfører Alice og Bob følgende trinn for å bli enige om en felles hemmelighet k:

1. Alice og Bob er enige om en syklisk gruppe G av orden n generert av et element g
2. Alice trekker tilfeldig et tall 0 < a < n og sender pa = ga ∈ G til Bob
3. Bob trekker tilfeldig et tall 0 < b < n og sender pb = gb ∈ G til Alice
4. Alice beregner den delte hemmeligheten k =(sb )a ∈ G
5. Bob beregner den delte hemmeligheten k =(sa )b ∈ G

Sikkerheten til protokollen avhenger av hvor vanskelig det er å finne k =gab gitt g, ga, gb. Dette kalles Beregning Diffie-Hellman-antakelse (CDH). Hypotesen om at CDH er vanskelig å løse antar at diskret logaritmeproblem er vanskelig å løse.

I denne ordningen, mens den delte hemmeligheten er trygg mot avlytting, er det ingen garanti for opprinnelsen til dataene som utveksles. For at samhandlingen skal være sikker, må Alice og Bob på en eller annen måte bevise identiteten sin for hverandre.

Gjensidig autentisering og digital signatur

En håndskrevet signatur brukes vanligvis til å erkjenne og akseptere innholdet i et dokument. Bare underskriveren kan produsere signaturen, men alle som "vet" hvordan signaturen ser ut kan bekrefte at dokumentet er signert av rett person.

Selv om den har lignende egenskaper, gir en digital signatur ytterligere sterke garantier ved å utnytte asymmetrisk kryptografi:

• Autentisitet: hvem som helst kan bekrefte at meldingen ble signert med den private nøkkelen som tilsvarer den angitte offentlige nøkkelen.
• Ikke-benektelse: underskriveren kan ikke nekte for å ha signert og sendt meldingen.
• Integritet: meldingen ble ikke endret under overføring.

Nå, så lenge vi kjenner og stoler på den offentlige nøkkelen til vår korrespondent, kan vi sjekke ektheten til alle meldinger ved å bekrefte deres digitale signatur.
I de fleste tilfeller av den virkelige verden kjenner vi imidlertid ikke korrespondenten vår på nært hold, eller så kan det hende at de regelmessig må endre sitt private/offentlige nøkkelpar av sikkerhetsgrunner. Dette krever et ekstra lag med verifisering og tillit i form av sertifikater, som inneholder beskrivelsen av en enhet og deres offentlige nøkkel.

Hvert sertifikat er signert av en overordnet offentlig nøkkel. Ved å ha en Root Certificate Authority (eller Root CA) som vi alltid stoler på, kan vi opprette en kjede av tillit ved å bruke påfølgende digitale signaturer.

Elliptiske kurver: Neste nivå offentlig nøkkelkryptering

Elliptic curve cryptography (ECC) er et underområde av Public Key Cryptography som består i å bruke elliptiske kurver for kryptografiske applikasjoner, for eksempel for kryptering eller signaturskjemaer. 
Basert på matematikk som for øyeblikket er forstått, gir ECC et betydelig sikrere grunnlag enn tidligere offentlige nøkkelkryptografisystemer som RSA.

Med samme sikkerhetsnivå innebærer ECC mindre nøkkellengder sammenlignet med andre asymmetriske kryptosystemer, noe som gjør det til et godt valg for innebygde systemer med begrensede ressurser.
Hvis du vil vite mer, denne artikkelen kan bidra til å bedre forstå elliptiske kurver.

Rekkefølgen av en elliptisk kurve
Rekkefølgen til et element g av en gruppe er en viktig parameter for Diffie-Hellman nøkkelutveksling. Når gruppen er en elliptisk kurve, er det elementet et punkt, og rekkefølgen er antall ganger det kan legges til seg selv før det går rundt på startverdien.
Merk at denne addisjonen ikke har noe å gjøre med din vanlige sum over reelle tall, men har lignende egenskaper for additivitet.

La oss ta den elliptiske kurven E: y2 =x3 +2x +3 over feltet 𝔽97 som et eksempel. Som en diskret funksjon er den representert ved punktene i figuren nedenfor. Vi vil fokusere på poenget P =(3, 6) og alle dens multipler.

Vi ser det etter 5.P, vi er tilbake i begynnelsen og vi treffer de samme poengene som før. Uansett verdien av skalaren P multipliseres med, vil vi alltid treffe ett av våre 5 startpoeng.
Dermed rekkefølgen av P er 5, og undergruppen den genererer inneholder nøyaktig 5 poeng. For kryptografiske applikasjoner er imidlertid rekkefølgen mye større enn 5, noe som øker tilfeldigheten.

Bland alt sammen: ECDH med autentisering

Vi har nå alle verktøyene vi trenger for å lage en flott nøkkelutvekslingsprotokoll:  Elliptic Curve Diffie-Hellman (ECDH).

ECDH er et standardisert kryptografisk opplegg som implementerer Diffie-Hellman-nøkkelutvekslingen vi beskrev ovenfor, ved å bruke elliptisk kurve-kryptografi for å generere nøkkelparene og den delte hemmeligheten.

Den starter med å velge en elliptisk kurve og dens genereringspunkt. De to partene utveksler deretter pålitelige sertifikater, som lar dem verifisere ektheten til deres respektive offentlige nøkler. Når de er autentisert, kan de generere en delt hemmelig k som beregnes som:

k = dA . dB . G
dA: Alices private nøkkel
dB: Bobs private nøkkel
G: EC-punkt

For å oppnå videre hemmelighold eiendom, bør nøkkelparet til både Alice og Bob være flyktige, dvs. de genereres på stedet og brukes til en enkelt utførelse av protokollen. Vi snakker om en Elliptic Curve Diffie-Hellman Ephemeral (ECDHE). I dette scenariet er de flyktige nøklene signert av både de statiske nøklene på enheten og HSM-ene, noe som muliggjør en sterk autentisering av nøklene. Selv om uautorisert tilgang til de statiske nøklene skulle skje i fremtiden, ville det ikke gi dekrypteringsmuligheter for sentralene som er beskyttet av de flyktige nøklene.

Videre har vi implementert en bemerkelsesverdig forbedring av protokollen ved å skjule de statiske nøklene til enhetene i den sikre kanalen. Dette forhåndstiltaket forhindrer angripere i å få synlighet på det statiske sertifikatet til enhetene, noe som igjen kan føre til lekkasje av unike identifikatorer som brukes under sikkerhetskopiering/gjenopprettingsoperasjoner.

Tilbake til Ledger Recover: En frøs reise

Ok, på tide å ta en pause et minutt.

Vi har dekket mange emner, knyttet til både sikkerhet og matematikk, og resultatet er en protokoll for å trygt kommunisere over ethvert usikkert nettverk. La oss oppsummere det vi har sett så langt:

To enheter kan ha sikker kommunikasjon over en usikker kanal ved å avtale en unik hemmelighet takk til ECDHE, som er en implementering av Diffie-Hellman nøkkelavtaleprotokoll som bruker flyktige nøkler for å beskytte fremadrettet hemmelighold. Hver enhet er i stand til verifisere ektheten av deres korrespondent takket være en initial Sertifikatbekreftelse.

Når det gjelder Ledger Recover, har vi etablert fire sikre kanaler som bruker Secure Channel Protocol. Disse kanalene kobler enheten til hver av backupleverandørene og orkestratoren, som alle er utstyrt med Hardware Security Modules (HSM).

Hver aktør holder på sitt personlige sertifikat, signert av et Ledger-sertifikat som fungerer som roten til tillitskjeden. Når brukerens enhet først sender sin intensjon om å utføre en sikkerhetskopi til Orchestrator, starter den en autentisert ECDHE. Under disse mTLS økter, overfører Orchestrator informasjon som vil knytte fremtidige sikre kanaler til brukerens spesielle sikkerhetskopieringsforespørsel, sammen med brukerens identitet som vil bli bedt om validering når du utfører en senere gjenoppretting av frøet.

Alt er klart for endelig å utføre den mest kritiske delen av hele operasjonen: overføring av de tre andelene av brukerens frø.

Nok en gang lager vi nye sikre kanaler, men denne gangen mellom brukerens Ledger-enhet og sikkerhetskopieringsleverandørenes HSM-er direkte. Frøaksjene overføres i en ende-til-ende kryptert kanal til deres endelige lagringssted, samtidig som de garanterer at de når riktig destinasjon (det er her verifiserbarheten til Pedersen Secret Sharing ble introdusert i del 1 er nyttig).
Brukerens enhet autentiserer sikkerhetskopieringsleverandørenes HSM-er én etter én, og sikkerhetskopieringsleverandørene vet at de utveksler med den unike offisielle Ledger-enheten som startet denne spesifikke sikkerhetskopieringsforespørselen.
Ingen bortsett fra brukerens enhet og sikkerhetskopieringsleverandørenes HSM-er ser noen gang frødelingene kryptert av disse gjensidig autentiserte sikre kanalenes symmetriske nøkler, ikke engang Orchestrator.

Sikkert mottatt... og lagret?

I denne delen har vi introdusert flere nye konsepter, hvorav noen er ganske tekniske. Hvert av disse konseptene kreves for å etablere en sikker overføring som garanterer konfidensialiteten og integriteten til utvekslingen. Uavhengig av nettverkets sikkerhet, vi kan nå sende våre hemmelige aksjer uten frykt for at de kan bli tuklet med eller avlyttet. Det er litt av oppgraderingen!

Hele prosessen støttes av lydkryptografi og sikker maskinvare, i form av din Ledger-maskinvareenhet og HSM-er som eies av hver backupleverandør.

Det er nå på tide å gå videre til å gjenopprette frøandelene! Alt vi trenger å gjøre er å be sikkerhetskopieringsleverandørene om å sende oss tilbake delingene som de lagrer på infrastrukturen deres...

Men vent: Hvordan lagrer de disse svært sensitive dataene? Det ville ikke hjelpe oss om vi hadde de sikreste kommunikasjonskanalene, men backupleverandørene våre holdt bare aksjene i klartekst og ba om å bli stjålet.

Så før vi snakker om bedring – vi kommer dit, jeg lover! –, vi må ta en rask omvei i del 3 for å diskutere sikkerheten til våre frøaksjer i ro. Følg med!

• 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/part-2-genesis-of-ledger-recover-securely-distributing-the-shares