Del 2: Genesis of Ledger Recover - Sikker distribution af aktierne | Hovedbog

Del 2: Genesis of Ledger Recover – Sikker fordeling af aktierne | Hovedbog

Tidsstempel: 25. juli 2023 kl. 7
Kildeknude: 2785813

Velkommen tilbage til anden del af vores blogserie om Ledger Recover's tilblivelse! Vores mål er at udforske de mange tekniske forhindringer, man støder på, når man bygger en frøgendannelsestjeneste, og hvordan Ledger Recover løser dem med et sikkert design og infrastruktur.

I forrige del, undersøgte vi, hvordan man sikkerhedskopierer en hemmelig gendannelsessætning ved at opdele den, og hvordan Ledger Recover gør det for dig ved hjælp af Pedersen Verificerbar hemmelighedsdeling.

Nu hvor du har tre aktier, er det næste spørgsmål: hvordan kan du sikkert distribuere dem til dine backup-udbydere? Faktisk, hvis en ondsindet part opsnapper alle aktierne, mens du overfører dem, besejrer det formålet med at splitte frøet i første omgang. I cybersikkerhed kaldes dette en Man-in-the-Middle angreb, hvor en angriber står mellem dig og din modtager og manipulerer med kommunikationen for at forsøge at afsløre hemmeligheder.

Når du bruger Ledger Recover, udføres transmissionen af ​​dit frø gennem en sikker distributionsmekanisme. Den er afhængig af flere kryptografiske værktøjer og matematiske begreber, som vi vil forklare grundigt.

Vi vil starte med at beskrive problemet mere detaljeret. Derefter vil vi introducere adskillige kryptografiske værktøjer og matematiske koncepter, som Ledger Recover udnytter til sikkert at distribuere dine seed shares til backup-udbydere.

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

Den mest oplagte måde at beskytte dig selv mod en ondsindet mellemmand er slet ikke at have nogen. Du kan selv gå til dine venners huse eller samle dem på det samme, lukkede sted for at levere aktierne. Men det bliver meget sværere, hvis du ikke er samlokaliseret og gerne vil sende aktierne til en bekendt på længere afstand.

Hvis vi antager, at det netværk, vi kommunikerer over (f.eks. postvæsenet) i sagens natur er utroværdigt, hvordan kan vi så garantere, at aflyttere aldrig får et glimt af vores hemmelige aktier?

Det er tid til at introducere Alice og Bob og den berygtede Eve, tre velkendte kryptografiske personer. Alice har en hemmelighed, hun gerne vil dele med Bob, og har intet andet valg end at sende den gennem Eve, deres utroværdige kurer. I kryptografiske ord, Alice og Bob ønsker at etablere en sikker kommunikationskanal med hinanden for at udveksle deres hemmelighed sikkert.

Her er hvad Alice og Bob kunne gøre:

  • Alice lægger sin hemmelighed i en æske, låser den med sin personlige hængelås, før hun sender den til Bob.
  • Da Bob modtager æsken, tilføjer han sin egen hængelås, og sender den tilbage.
  • Alice kan nu bruge sin nøgle til at fjerne sin hængelås fra kassen, inden hun sender den en sidste gang.
  • For at afslutte processen bruger Bob blot sin nøgle til at fjerne sin hængelås og hente – endelig – hemmeligheden fra Alice.

Under hele udvekslingen, hver gang Eve har haft æsken i hænderne, var den altid beskyttet, enten af ​​Alices lås eller Bobs eller begge dele.

Selvom dette er en fremragende start, er der flere problemer tilbage, der skal løses i dette scenarie:

  • Gensidig godkendelse: Alice og Bob har brug for idiotsikre måder at kontrollere, at hver hængelås virkelig kommer fra den anden part. Ellers kunne Eve bytte den med sin egen boks og hængelås og narre Alice eller Bob til at tro, at hun er den anden part.
  • Videresend hemmeligholdelse: Hvis Eve stjal den låste boks og senere stjal Alice eller Bobs nøgle, kunne hun finde den oprindelige hemmelighed. I stedet ønsker vi at sikre, at fremtidige lækager af langtidsnøgler ikke kan kompromittere ældre stjålne pakker.
  • Bevarelse af privatlivets fred: I dette scenarie bliver Alice og Bobs adresser afsløret til kureren. I den digitale ækvivalent til denne proces ønsker vi en protokol, der ikke oplyser noget om modtagerne.
Sikring af digitale beskeder

Inden for digital sikkerhed, en sikker kanal er en måde at overføre data mellem to autentificeret parter sådan data fortrolighed , integritet er garanteret. Når du bruger en sikker kanal, kan angribere ikke aflytte eller manipulere med din kommunikation.

Ledger Recovers protokol for både backup og gendannelse er baseret på en Secure Channel Protocoleller SCP. Den bruger flere værktøjer i den moderne kryptografiske værktøjskasse, såsom symmetrisk og asymmetrisk kryptering, certifikater og digitale signaturer.
De næste afsnit vil give dig en hurtig primer om alle disse koncepter, som giver dig mulighed for at forstå hele sikkerhedsskemaet, der bruges i Ledger Recover.

Symmetrisk kryptografi: Et kraftfuldt, men begrænset værktøj

For at garantere fortroligheden af ​​de data, der udveksles mellem to parter, krypteres og dekrypteres dataene normalt med den samme hemmelige nøgle.
Denne proces kaldes symmetrisk kryptografi, som er studiet af primitiver, der involverer en enkelt hemmelig nøgle for at garantere en eller flere af egenskaberne ved en sikker kanal.

Selvom det er et kraftfuldt værktøj til at beskytte din kommunikation, har symmetrisk kryptografi nogle åbenlyse begrænsninger: Antag, at Alice ønsker at udveksle flere krypterede beskeder med Bob. Hun vælger først en hemmelig nøgle og deler den derefter med Bob, før hun begynder at sende beskeder.
Selvfølgelig bliver problemet nu: Hvordan deler Alice den hemmelige nøgle sikkert med Bob? Hvis nogen får fat i nøglen, vil Alice og Bobs kommunikation ikke længere være fortrolig.
Alice kunne møde Bob personligt for at give ham nøglen, men i dette tilfælde hvorfor så ikke have deres diskussion, væk fra nysgerrige ører?

Til digital kommunikation har vi brug for en sikker metode til at dele den symmetriske nøgle og starte den beskyttede dataudveksling. Det er tid til at introducere arbejdet fra to titaner af moderne kryptografi, Whitfield Diffie , Martin Hellman.

Asymmetrisk kryptografi: Skjul dine private dele
Diffie-Hellman nøgleaftale

Med Public Key Cryptography kom Diffie og Hellman op med en ny tilgang til at sikre kommunikation. De definerede en protokol med to forskellige nøgler til kryptering og dekryptering. De to nøgler kaldes almindeligvis offentlige og private nøgler, der danner et par, som kan bruges til at kryptere/dekryptere og signere/verificere data.

Offentlige og private nøgler
Offentlig nøglekryptering er grundlaget for det meste af vores digitale sikkerhed. Det bruges til at beskytte dig på nettet, og det er også hvordan du beviser ejerskab af mønter og tokens på alle offentlige blockchains.

Lær mere om dette emne på Ledger Academy!

Det, der virkelig er overbevisende for os, er, hvordan Diffie og Hellman foreslog at bruge offentlig nøglekryptografi til at distribuere symmetriske nøgler. Deres metode, kendt som Diffie-Hellman nøgleudveksling, består af frem og tilbage udvekslinger mellem to parter for i sidste ende at blive enige om en fælles hemmelighed. Hvis det udføres korrekt, er aflyttere ikke i stand til at beregne den samme delte hemmelighed ud fra den information, de overhører.

Generering af en fælles hemmelighed k

TL;DR er, at i ovenstående diagram er Eva matematisk ude af stand til at finde ud af hemmeligheden k selvom hun har adgang til al Alice og Bobs kommunikation. For at forstå, hvorfor denne fælles hemmelighed er sikker for enhver aflytning, er vi nødt til at grave i lidt gruppeteori. 

Sikkerheden ved Diffie-Hellman nøgleudveksling afhænger af kompleksiteten af ​​det diskrete logaritmeproblem over en cyklisk gruppe. En cyklisk gruppe er en gruppe genereret af et enkelt element.
I en nøddeskal udfører Alice og Bob følgende trin for at blive enige om en fælles hemmelighed k:

  1. Alice og Bob er enige om en cyklisk gruppe G af orden n genereret af et element g
  2. Alice tegner tilfældigt et tal 0 < a < n og sender pa = ga ∈ G til Bob
  3. Bob trækker tilfældigt et tal 0 < b < n og sender pb = gb ∈ G til Alice
  4. Alice udregner den fælles hemmelighed k =(sb )a ∈ G
  5. Bob beregner den delte hemmelighed k =(sa )b ∈ G

Protokollens sikkerhed afhænger af, hvor hårdt det er at finde k =gab given g, ga, gb. Dette kaldes Beregning Diffie-Hellman antagelse (CDH). Hypotesen om, at CDH er svær at løse, antager, at diskret logaritmeproblem er svær at løse.

I denne ordning, mens den delte hemmelighed er sikker mod aflytning, er der ingen garanti for oprindelsen af ​​de data, der udveksles. For at interaktionen skal være sikker, skal Alice og Bob på en eller anden måde bevise deres identitet over for hinanden.

Gensidig autentificering og digital signatur

En håndskrevet signatur bruges normalt til at anerkende og acceptere indholdet af et dokument. Kun underskriveren er i stand til at fremstille signaturen, men enhver, der "ved", hvordan signaturen ser ud, kan bekræfte, at dokumentet er underskrevet af den rette person.

Mens den har lignende egenskaber, giver en digital signatur yderligere stærke garantier ved at udnytte asymmetrisk kryptografi:

  • Autenticitet: alle kan bekræfte, at beskeden blev signeret med den private nøgle, der svarer til den angivne offentlige nøgle.
  • Uafviselighed: underskriveren kan ikke nægte at have underskrevet og sendt beskeden.
  • Integritet: beskeden blev ikke ændret under transmissionen.

Nu, så længe vi kender og stoler på den offentlige nøgle fra vores korrespondent, kan vi kontrollere ægtheden af ​​alle meddelelser ved at verificere deres digitale signatur.
I de fleste tilfælde i den virkelige verden kender vi dog enten ikke vores korrespondent tæt, eller også skal de regelmæssigt ændre deres private/offentlige nøglepar af sikkerhedsmæssige årsager. Dette kræver et ekstra lag af verifikation og tillid i form af Certifikater, som indeholder beskrivelsen af ​​en enhed og deres offentlige nøgle.

Hvert certifikat er underskrevet af en overordnet offentlig nøgle. Ved at have en Root Certificate Authority (eller Root CA), som vi altid har tillid til, kan vi skabe en tillidskæde ved hjælp af successive digitale signaturer.

Elliptiske kurver: Næste niveau offentlig nøgle kryptografi

Elliptic curve cryptography (ECC) er et underområde af Public Key Cryptography, som består i at bruge elliptiske kurver til kryptografiske applikationer, fx til kryptering eller signaturskemaer. 
Baseret på aktuelt forstået matematik giver ECC et væsentligt mere sikkert grundlag end tidligere offentlige nøglekrypteringssystemer som f.eks. RSA.

Med samme sikkerhedsniveau involverer ECC mindre nøglelængder sammenlignet med andre asymmetriske kryptosystemer, hvilket gør det til et godt valg for indlejrede systemer med begrænsede ressourcer.
Hvis du gerne vil vide mere, denne artikel kan hjælpe med at forstå elliptiske kurver bedre.

Rækkefølgen af ​​en elliptisk kurve
Rækkefølgen af ​​et element g of a group is an important parameter of the Diffie-Hellman key exchange. When the group is an Elliptic Curve, that element is a point, and its order is the number of times it can be added to itself before looping around on its initial value.
Note that this addition has nothing to do with your usual sum over real numbers, but has similar properties of additivity.

Lad os tage den elliptiske kurve E: y2 =x3 +2x +3 over feltet 𝔽97 som et eksempel. Som en diskret funktion er den repræsenteret ved punkterne i figuren nedenfor. Vi vil fokusere på pointen P =(3, 6) og alle dens multipla.

Det ser vi efter 5.P, vi er tilbage ved begyndelsen, og vi rammer de samme punkter som før. Uanset værdien af ​​skalaren P is multiplied by, we will always hit one of our 5 initial points.
Thus the order of P er 5, og undergruppen den genererer indeholder præcis 5 point. For kryptografiske applikationer er rækkefølgen dog langt større end 5, hvilket øger tilfældigheden.

Mash det hele sammen: ECDH med autentificering

Vi har nu alle de værktøjer, vi har brug for til at skabe en fantastisk nøgleudvekslingsprotokol:  Elliptic Curve Diffie-Hellman (ECDH).

ECDH er et standardiseret kryptografisk skema, der implementerer Diffie-Hellman nøgleudveksling, vi beskrev ovenfor, ved at bruge elliptisk kurve-kryptering til at generere nøgleparrene og den delte hemmelighed.

Autentificeret ECDH nøgleudveksling

Den starter med at vælge en elliptisk kurve og dens genereringspunkt. De to parter udveksler derefter betroede certifikater, som giver dem mulighed for at verificere ægtheden af ​​deres respektive offentlige nøgler. Når de er godkendt, kan de generere en delt hemmelighed k, der beregnes som:

k = dA . dB . G
dA: Alices private nøgle
dB: Bobs private nøgle
G: EF-punkt

For at opnå fremad hemmeligholdelse ejendom, bør nøgleparret for både Alice og Bob være flygtige, dvs. de genereres på stedet og bruges til en enkelt eksekvering af protokollen. Vi taler om en Elliptic Curve Diffie-Hellman Ephemeral (ECDHE). I dette scenarie er de flygtige nøgler signeret af både de statiske nøgler på enheden og HSM'erne, hvilket muliggør en stærk godkendelse af nøglerne. Selv hvis uautoriseret adgang til de statiske nøgler skulle forekomme i fremtiden, ville det ikke give dekrypteringsmuligheder for de udvekslinger, der er beskyttet af de flygtige nøgler.

Desuden har vi implementeret en bemærkelsesværdig forbedring af protokollen ved at skjule de statiske nøgler på enhederne i den sikre kanal. Denne sikkerhedsforanstaltning forhindrer angribere i at opnå synlighed på enhedernes statiske certifikat, hvilket igen kan føre til lækage af unikke identifikatorer, der bruges under sikkerhedskopiering/gendannelse.

Tilbage til Ledger Recover: Et frøs rejse

Okay, tid til at holde pause i et minut.

Vi har dækket en masse emner, der vedrører både sikkerhed og matematik, og resultatet er en protokol til sikker kommunikation over ethvert usikkert netværk. Lad os opsummere, hvad vi har set indtil videre:

To enheder kan have sikker kommunikation over en usikker kanal ved at blive enige om en unik hemmelighed takket være ECDHE, som er en implementering af Diffie-Hellman nøgleaftaleprotokollen, der bruger flygtige nøgler for at beskytte fremadrettet hemmeligholdelse. Hver enhed er i stand til verificere ægtheden af deres korrespondent takket være en initial Certifikatbekræftelse.

I tilfælde af Ledger Recover har vi etableret fire sikre kanaler ved hjælp af Secure Channel Protocol. Disse kanaler forbinder enheden med hver af backupudbyderne og orkestratoren, som alle er udstyret med hardwaresikkerhedsmoduler (HSM'er).

Hver aktør beholder sit personlige certifikat, underskrevet af et Ledger-certifikat, der fungerer som roden til tillidskæden. Når brugerens enhed først sender sin hensigt om at udføre en backup til Orchestrator, starter den en godkendt ECDHE. Under disse mTLS sessioner, transmitterer Orchestrator information, der vil binde fremtidige sikre kanaler til brugerens særlige backup-anmodning, sammen med brugerens identitet, der vil blive anmodet om validering, når der udføres en senere gendannelse af frøet.

Beskyttelse af hemmeligheder med HSM'er
Så meget som vi forsøger at undgå det, er det til tider nødvendigt at gemme og behandle hemmeligheder på servere. Dette kan være risikabelt, da beskyttelse af servere og deres adgang er en ikke-triviel opgave. For at mindske denne risiko bruger virksomheder og industrier, der værdsætter sikkerhed Hardware sikkerhedsmoduler. De er specialiseret hardware, der beskytter kryptografiske nøgler og giver kryptografisk behandling. Vi vil tale mere om HSM'er i senere dele af denne blogserie.

Alt er klar til endelig at udføre den mest kritiske del af hele operationen: transmission af de tre dele af brugerens frø.

Endnu en gang opretter vi nye sikre kanaler, men denne gang mellem brugerens Ledger-enhed og Backup-udbydernes HSM'er direkte. Seed-aktierne transmitteres i en ende-til-ende-krypteret kanal til deres endelige opbevaringssted, samtidig med at det garanteres, at de når den korrekte destination (det er her verificerbarheden af ​​Pedersen Secret Sharing introduceret i del 1 er nyttig).
Brugerens enhed autentificerer sikkerhedskopieringsudbydernes HSM'er én efter én, og sikkerhedskopieringsudbyderne ved, at de udveksler med den unikke officielle Ledger-enhed, der startede denne specifikke backupanmodning.
Ingen udover brugerens enhed og sikkerhedskopieringsudbydernes HSM'er ser nogensinde seed-shares krypteret af disse gensidigt autentificerede sikre kanalers symmetriske nøgler, ikke engang Orchestrator.

Sikkert modtaget... og opbevaret?

I denne del har vi introduceret flere nye koncepter, hvoraf nogle er ret tekniske. Hvert af disse koncepter er påkrævet for at etablere en sikker transmission, der garanterer udvekslingens fortrolighed og integritet. Uanset netværkets sikkerhed, vi kan nu sende vores hemmelige aktier uden frygt for, at de kan blive pillet ved eller opsnappet. Det er noget af opgraderingen!

Hele processen er understøttet af lydkryptering og sikker hardware i form af din Ledger-hardwareenhed og HSM'er, der ejes af hver backup-udbyder.

Det er nu tid til at gå videre til at genvinde frøandele! Alt, hvad vi skal gøre, er at bede backup-udbyderne om at sende os de aktier tilbage, som de gemmer på deres infrastruktur...

Men vent: Hvordan præcist opbevarer de disse meget følsomme data? Det ville ikke gavne os, hvis vi havde de mest sikre kommunikationskanaler, men vores backup-udbydere holdt bare aktierne i klartekst og tiggede om at blive stjålet.

Så før vi taler om bedring – vi når dertil, det lover jeg! –, vi er nødt til at tage en hurtig omvej i del 3 for at diskutere sikkerheden for vores seed-aktier i hvile. Bliv hængende!

Tidsstempel:

Mere fra Ledger