Del 3: Genesis of Ledger Recover – Undgå samordning og lækager | Hovedbog

Velkommen tilbage til tredje 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, leveret af Coincover løser dem med et sikkert design og infrastruktur.

I de foregående dele forklarede vi, hvordan entropien i en hemmelig gendannelsessætning kan være opdelt i flere aktier (eller fragmenter)og sendt til betroede backup-udbydere, mens du altid opretholder det højeste sikkerhedsniveau. Takket være moderne kryptografiværktøjer og sikker hardware er vi i stand til at udføre en fuld backup af et frø med garanti for, at ingen angribere kan få fat i nogen af ​​aktierne under transit.

Vi vil nu gå videre til det næste logiske trin, fysisk sikkerhedskopiering af aktierne. At sørge for sikker opbevaring er nøglen og rejser afgørende spørgsmål, som vi skal tage stilling til: Hvordan sikrer vi, at aktierne opbevares sikkert og ikke kan stjæles? Hvordan kan vi forhindre samarbejde mellem backup-udbydere for at rekonstruere dit frø?

Flere lag af sikkerhed

For at sikre sikkerheden ved share storage er en mulig tilgang at få hver udbyder til at gemme deres individuelle andel på et sikkert sted, såsom et pengeskab. Alternativt kan du vælge selv at opbevare den i en – anden – bankboks. Denne ordning giver udbydere mulighed for udelukkende at fokusere på at beskytte deres respektive nøgler, hvilket gør det nemmere at kontrollere adgangen og reducerer risikoen for lækager fra familie og venner.

At beskytte os selv mod potentielt hemmeligt samarbejde giver flere udfordringer. Du kan overveje at oprette flere delinger fordelt på forskellige kategorier af venner eller lagerudbydere. Du kan også binde dem med kontrakter. Selvom disse løsninger er levedygtige, kræver de stadig en vis grad af tillid.

En alternativ løsning er at kryptere delingen, før de sendes til dine venner. På den måde, selvom de samarbejder, vil de ikke være i stand til at bruge aktierne til at genopbygge dit frø. Men her er catch-22 i det fysiske rum: For at kryptere aktierne skal du bruge en ny personlig hemmelig nøgle. Du bakker i bund og grund op om en hemmelighed, dit frø, ved introducerer en anden hemmelighed som du skal beskytte og huske.

Vi kunne argumentere for, at denne nye hemmelighed er mindre kritisk end den originale, da den kun bruges til at beskytte dig mod hemmelige aftaler mellem dine venner. En angriber, der får adgang til denne nye nøgle, ville ikke være i stand til direkte at stjæle dine penge, men hvis du skulle miste dem, ville du også miste adgangen til dit seed.

Hvordan Ledger Recover gør det: Sikker hardware og flere niveauer af kryptering

I Ledger Recover, leveret af Coincover, bruger vi egenskaberne af den sikre hardware til vores rådighed til at besvare disse spørgsmål på den mest brugervenlige måde som muligt. Vi er afhængige af Secure Element (SE), der er indeholdt i din Ledger hardware wallet, såvel som Hardware Security Modules (HSM), der bruges af hver af backup-udbyderne.

Secure Elements: Sikkerhedens kraft i din håndflade

Et sikkert element er en specialiseret chip, der almindeligvis bruges i pas, kreditkort og betalingssystemer til sikker opbevaring og behandling af følsomme data. SE'er er specielt udviklet til at modstå en lang række angreb såsom fysisk manipulation, sidekanal, fejlinjektion, softwareudnyttelse eller malware. Disse chips er certificeret af tredjeparts sikkerhedslaboratorier gennem intensiv test af disse angreb.

Din Ledger Nano er afhængig af denne gennemprøvede og pålidelige teknologi til at opbevare og beskytte dine frø. Ledger OS, der kører på denne SE, vil altid bede om dit fysiske samtykke, før du bruger frøet.

HSM'er: Sikring af serverne

Hardware Security Module (HSM) er en sikkerhedsenklave, der typisk er tilgængelig som et plug-in-kort eller ekstern enhed direkte forbundet til en computer eller netværksserver. Det udnytter kryptografiske processorer, sikre minder og forskellige modforanstaltninger mod manipulation til sikkert at opbevare og behandle hemmeligheder. Disse moduler beskytter kritiske infrastrukturer og er ansat af meget sikkerhedsbevidste organisationer, herunder bankindustrien, til at sikre deres hemmelige nøgler og infrastruktur.

Ledger bruger flere HSM'er til forskellige brugssager, herunder verificering af ægtheden af ​​Ledger Nano- og Ledger Stax-enheder, og aktiverer sikre OS-opdateringer over en krypteret og autentificeret kanal.

Både SE'er og HSM'er spiller en afgørende rolle i at forbedre datasikkerheden i forskellige applikationer. De hjælper organisationer med at opfylde regulatoriske krav til databeskyttelse og sikkerhed og sikker manipulation af kritiske data.

Seed-kryptering af Secure Element

Det første lag af beskyttelse kommer fra selve Secure Element (SE). Inden entropien opdeles i tre shares, krypterer SE den ved hjælp af en AES 256 symmetrisk nøgle gemt i dets operativsystem (benævnt 'Entropy Encryption Key'). Efter kryptering opdeles entropien i tre shares, der derefter distribueres til backup-udbydere. Selvfølgelig har du kontrol over denne proces, og SE vil altid anmode om dit udtrykkelige samtykke, før det påbegyndes, ligesom for enhver anden applikation, der anmoder om adgang til frøet.

Selv i tilfælde af et samarbejde mellem sikkerhedskopieringsudbydere, der forsøger at rekonstruere frøet (et scenarie, der er næsten umuligt af andre robuste beskyttelser, vi vil diskutere senere), vil deres indsats kun resultere i at få det krypterede frø. Uden krypteringsnøglen, der er gemt i Secure Element (SE), ville de ikke være i stand til at bruge frøet.

Et nøglepunkt at forstå: denne entropikrypteringsnøgle er fælles for alle Ledger-enheder, så du kan gendanne din seed på enhver legitim Ledger-enhed. Det injiceres i operativsystemet under en OS-opdatering, i sig selv en meget sikker operation.

Ved at inkorporere entropikrypteringsnøglen direkte i enheden eliminerer vi behovet for, at brugere skal huske eller gemme en ekstra krypteringsnøgle for at beskytte mod samordningsrisici (fangsten 22 nævnt ovenfor). Denne tilgang sikrer øget sikkerhed uden at kræve yderligere tillid til Ledger, da den stemmer overens med det eksisterende sikkerhedsniveau, der leveres gennem OS-opdateringer.

Beskyttelse af entropikrypteringsnøglen

På grund af dets kritiske niveau bliver Entropy Encryption Key udelukkende brugt af enhedens operativsystem under autentiske Ledger Recover-gendannelses- og sikkerhedskopieringsprocesser. Denne proces involverer etablering af autentificerede sikre kanaler med flere HSM'er fra forskellige virksomheder (hver backup-udbyder). Derudover administreres forskellige andre infrastrukturkomponenter, såsom detektion af mistænkelig aktivitet (f.eks. gendannelse af flere frø på den samme enhed) og identitetsbekræftelse, af separate teams, hvilket drastisk øger antallet af personer, der kræves for at udføre et vellykket samordningsangreb. Vi vil grave dybere ned i den styring og overvågning, vi har indført i 5. del af denne serie!

På samme måde besidder ingen enkelt person hos Ledger autoriteten til at levere nye OS-opgraderinger til enheden. Processen håndhæves kryptografisk for altid at kræve den digitale signatur fra et kvorum af flere personer fra forskellige teams, hver med forskellige interesser i virksomheden.

Denne praksis, kendt som adskillelse af pligten, er en anden afgørende cybersikkerhedsforanstaltning, som vi vil dykke dybere ned i i afsnittet om operationel sikkerhed.

Del kryptering i hvile for sikkerhedskopieringsudbydere

Nu på siden af ​​backup-udbyderne har vi et noget tilsvarende setup.

Hver backupudbyder bruger et hardwaresikkerhedsmodul til at manipulere deres andel af frøet. Når deres HSM modtager delingen fra enheden sikkert (dobbeltkrypteret med Entropy Encryption Key og den midlertidige sikker kanalnøgle beskrevet i forrige blogindlæg), Secure Channel-kryptering ophæves, og delekonsistens verificeres direkte i HSM.

På grund af begrænset hukommelseskapacitet kan HSM'er ikke gemme et stort antal shares. Derfor, til opbevaringsformål, bliver hver share genkrypteret ved hjælp af en AES 256 symmetrisk krypteringsnøgle, kendt som 'Provider Storage Key'. Dette ekstra lag af kryptering gør det muligt at opbevare shares sikkert uden for grænserne af HSM i et RDMS. Med andre ord vises aktierne aldrig uden for en sikker enklave uden en dobbeltkrypteringsordning.
Leverandørlagernøglen genereres inde i HSM af hver udbyder og forlader den aldrig uindpakkede. Den er aldrig tilgængelig for nogen, inklusive ansatte hos backupudbyderne selv. Dette er standard cybersikkerhedspraksis fra virksomheder, der håndterer højhemmelige, meget følsomme data.

Aktierne efterlader heller aldrig grænserne for HSM frit, og de er altid krypteret enten under transit eller i hvile.

Endnu en gang håndhæves en robust adskillelse af opgaver for personer, der har evnen til at manipulere og få adgang til HSM'erne. Forskellige ansvarsområder, såsom opdatering af koden, fysisk adgang til HSM, adgang til databasen og installation af software på HSM's fysiske vært, er tildelt forskellige personer med begrænsede adgangsrettigheder. Desuden skal enhver software, der kører på HSM, gennemgå digital signering af et kvorum af flere personer fra forskellige teams og med forskellige interesser i virksomheden.

Alt dette gør det ekstremt svært – næsten umuligt – for en enkelt person i nogen af ​​de involverede virksomheder at få adgang til aktierne.

HSMs Strike Again: Databasediversificering

Okay, vi nærmer os en komplet løsning til sikker opbevaring af vores aktier!

Men hvad nu hvis flere insidere inden for backup-udbydere i fællesskab ønskede at hente en persons entropi, og orkestrerede en effektiv omfattende aftale mellem teams og kvorumsmedlemmer fra hver virksomhed?

Er det muligt at indføre tekniske foranstaltninger, der gør det ekstremt udfordrende, hvis ikke umuligt, at opnå? Kan vi implementere sikkerhedsforanstaltninger, der giver nok tid til, at enhver insider i nogen af ​​virksomhederne kan slå alarm til alle brugere, før der sker noget?

En løsning er at bruge det, der er kendt som "Databasediversificering". Endnu en gang udnytter vi vores HSM'ers muligheder for at implementere det.

Hvis du har fulgt dette blogindlæg fra begyndelsen, forstår du nu, at behandlingen af ​​shares udelukkende styres inden for de sikre rammer af HSM'er, men at den faktiske lagring af disse krypterede shares foregår i en separat backend-database uden for HSM.

Her er, hvad vi vil gøre: Lad HSM generere unikke database-id'er for hver share, der fungerer som deres specifikke identifikatorer i backend-databasen. Disse ID'er vil blive genereret på en 'diversificeret' måde, afledt af en hemmelighed skabt af HSM selv, sikkert gemt i sin egen sikre hukommelse og aldrig afsløret uindpakket. Backend'en fungerer derfor kun som et eksternt lager, ude af stand til at læse dets databaseindhold eller bestemme identifikatorerne for sine egne databaseposter.

Hvad betyder det? Share-id'erne vil være forskellige på tværs af forskellige backup-udbydere, herunder Ledger, Coincover og EscrowTech. Da brugerdata desuden forbliver krypteret og diversificeret, ville det, selv hvis der skulle forekomme hemmeligt samarbejde mellem to udbydere, ikke give nogen fingerpeg om, hvilken databasepost der svarer til hvilken bruger eller til hvilken indgang i den anden udbyders database.

Den eneste mulige tilgang ville være at brute force alle mulige kombinationer af delinger på tværs af alle databaser fra alle involverede backup-udbydere. Denne proces er meget tidskrævende og kræver et fuldt gendannelsesflow, der involverer udnyttelse af den fulde infrastruktur af HSM'er og en legitim Ledger-enhed til at dekryptere hver kombination med manuel godkendelse med PIN-kode. Som tilsigtet kræver denne tilgang betydelig tid og kræfter.

Den ikke-diversificerede brugeridentifikation er naturligvis til stede i den komponent, der er ansvarlig for at orkestrere gendannelsesflowet (kun til stede på Ledger-siden). Det er netop derfor, som tidligere nævnt, en streng adskillelse af opgaver håndhæves mellem de teams og personer, der administrerer Orchestration-komponenten, og dem, der fører tilsyn med Backup Provider HSM'er og databaser.

Trygt og hyggeligt, nu for at bevise, at jeg er mig

Efter at have opdelt og sikkert delt hemmelige gendannelsessætninger, har vi nu udtænkt en løsning, der sikrer sikker opbevaring af de forskellige shares. Den er afhængig af hardwareenheder, kryptografiske konstruktioner og operationelle adskillelser, der alle er afgørende for at bygge et sikkert produkt. Vi er nu beskyttet mod risici ved kilde- og destinationsendepunkterne, men også under transit og opbevaring. Vi har også reduceret risikoen for samarbejde fra enkeltpersoner inden for hver virksomhed eller inden for virksomhederne selv, så tæt på nul som muligt.

På dette tidspunkt undrer du dig måske over den sidste manglende del: Frigivelse af delinger, der er krypteret af hver backup-udbyder. Denne proces skal være stærkt beskyttet, så hvordan sikrer vi os, at den faktiske ejer af frøet er den, der starter anmodningen om aktiefrigivelse?

Det er nu tid til at introducere Identity Verification (eller IDV) processen, som er den sidste brik i puslespillet. Når en backup-udbyder bliver bedt om at frigive sin andel af et frø, forventer den at modtage en autorisation fra en IDV-udbyder, som er bevis på, at anmodningen er iværksat af den reelle ejer af frøet.

Ved at have en anden IDV-udbyder for hver Backup-udbyder tilføjer vi et ekstra lag af beskyttelse mod hemmeligt samarbejde.

Implementering af IDV'er for flere backup-udbydere kan være ret komplekst, og derfor vil vi dedikere vores næste blogindlæg til at forklare det i detaljer. Tag med hvis du vil vide mere!

Pierre AOUN / Yacine BADISS

Software arkitekter

• SEO Powered Content & PR Distribution. Bliv forstærket i dag.
• PlatoData.Network Vertical Generative Ai. Styrk dig selv. Adgang her.
• PlatoAiStream. Web3 intelligens. Viden forstærket. Adgang her.
• PlatoESG. Automotive/elbiler, Kulstof, CleanTech, Energi, Miljø, Solenergi, Affaldshåndtering. Adgang her.
• PlatoHealth. Bioteknologiske og kliniske forsøgs intelligens. Adgang her.
• ChartPrime. Løft dit handelsspil med ChartPrime. Adgang her.
• BlockOffsets. Modernisering af miljømæssig offset-ejerskab. Adgang her.
• Kilde: https://www.ledger.com/blog/part-3-genesis-of-ledger-recover-avoiding-collusion-and-leaks