Deel 3: Ontstaan ​​van Ledger Recover – Collusie en lekken voorkomen | Grootboek

Welkom terug bij het derde deel van onze blogserie over Grootboek herstellen's ontstaan! Ons doel is om de vele technische hindernissen te onderzoeken die je tegenkomt bij het bouwen van een service voor zaadherstel, en hoe Ledger Recover, geleverd door Coincover, deze oplost met een veilig ontwerp en een veilige infrastructuur.

In de vorige delen hebben we uitgelegd hoe de entropie van een geheime herstelzin kan zijn opgesplitst in meerdere aandelen (of fragmenten) en verzonden naar vertrouwde back-upproviders, terwijl altijd het hoogste beveiligingsniveau wordt gehandhaafd. Dankzij moderne cryptografietools en veilige hardware zijn we in staat een volledige back-up van een zaadje uit te voeren, met de garantie dat geen enkele aanvaller tijdens de overdracht de aandelen in handen kan krijgen.

We gaan nu verder met de volgende logische stap, het fysiek maken van een back-up van de shares. Het bieden van veilige opslag is essentieel en roept cruciale vragen op die we moeten beantwoorden: hoe zorgen we ervoor dat de aandelen veilig worden opgeslagen en niet kunnen worden gestolen? Hoe kunnen we samenzwering tussen back-upproviders voorkomen om uw zaad te reconstrueren?

Meerdere beveiligingslagen

Om de veiligheid van de gedeelde opslag te garanderen, is een mogelijke aanpak om elke aanbieder zijn individuele aandeel op een veilige locatie, zoals een kluis, te laten opslaan. U kunt er ook voor kiezen om het zelf in een – andere – bankkluis te bewaren. Dankzij deze regeling kunnen providers zich uitsluitend concentreren op het beschermen van hun respectieve sleutels, waardoor het gemakkelijker wordt om de toegang te controleren en het risico op lekken van familie en vrienden te verminderen.

Onszelf beschermen tegen mogelijke collusie brengt meer uitdagingen met zich mee. U kunt overwegen om meerdere shares te maken, verdeeld over verschillende categorieën vrienden of opslagproviders. U kunt ze ook binden met contracten. Hoewel deze oplossingen levensvatbaar zijn, vereisen ze nog steeds een bepaald niveau van vertrouwen.

Een alternatieve oplossing is om encrypt de aandelen voordat ze naar je vrienden worden verzonden. Op die manier kunnen ze, zelfs als ze samenspannen, de aandelen niet gebruiken om je zaad opnieuw op te bouwen. Maar hier is de catch-22 van de fysieke ruimte: om de shares te versleutelen, heb je een nieuwe persoonlijke geheime sleutel nodig. Je steunt in wezen een geheim, jouw zaad, door nog een geheim introduceren die je moet beschermen en onthouden.

We zouden kunnen stellen dat dit nieuwe geheim minder kritisch is dan het oorspronkelijke, omdat het alleen wordt gebruikt om je te beschermen tegen samenzwering tussen je vrienden. Een aanvaller die toegang krijgt tot deze nieuwe sleutel, kan uw geld niet rechtstreeks stelen, maar als u deze verliest, verliest u ook de toegang tot uw zaad.

Hoe Ledger Recover het doet: veilige hardware en meerdere coderingsniveaus

In Ledger Recover, geleverd door Coincover, gebruiken we de eigenschappen van de beveiligde hardware die we tot onze beschikking hebben om die vragen zo gebruiksvriendelijk mogelijk te beantwoorden. We vertrouwen op het Secure Element (SE) in uw Ledger-hardwareportemonnee, evenals op Hardware Security Modules (HSM) die door elk van de back-upproviders worden gebruikt.

Veilige elementen: de kracht van veiligheid in de palm van uw hand

Een Secure Element is een gespecialiseerde chip die vaak wordt gebruikt in paspoorten, creditcards en betalingssystemen om gevoelige gegevens veilig op te slaan en te verwerken. SE's zijn specifiek ontworpen om een ​​breed scala aan aanvallen te weerstaan, zoals fysiek geknoei, side-channel, foutinjectie, software-exploitatie of malware. Deze chips zijn gecertificeerd door beveiligingslaboratoria van derden door middel van intensieve tests met betrekking tot deze aanvallen.

Uw Ledger Nano vertrouwt op deze bewezen en vertrouwde technologie om uw zaad op te slaan en te beschermen. Het Ledger-besturingssysteem dat op deze SE draait, zal altijd om uw fysieke toestemming vragen voordat het zaad wordt gebruikt.

HSM's: de servers beveiligen

Hardware Security Module (HSM) is een beveiligingsenclave die doorgaans verkrijgbaar is als insteekkaart of als extern apparaat dat rechtstreeks op een computer of netwerkserver is aangesloten. Het maakt gebruik van cryptografische processors, beveiligde herinneringen en verschillende tegenmaatregelen tegen manipulatie om geheimen veilig op te slaan en te verwerken. Deze modules beveiligen kritieke infrastructuren en worden gebruikt door zeer veiligheidsbewuste organisaties, waaronder de banksector, om hun geheime sleutels en infrastructuur te beveiligen.

Ledger gebruikt meerdere HSM's voor verschillende gebruiksscenario's, waaronder het verifiëren van de authenticiteit van Ledger Nano- en Ledger Stax-apparatenen het mogelijk maken van veilige OS-updates via een gecodeerd en geverifieerd kanaal.

Zowel SE's als HSM's spelen een cruciale rol bij het verbeteren van de gegevensbeveiliging in diverse toepassingen. Ze helpen organisaties te voldoen aan de wettelijke vereisten voor gegevensprivacy en -beveiliging en veilige manipulatie van kritieke gegevens.

Seed-encryptie door het Secure Element

De eerste beschermingslaag komt van het Secure Element (SE) zelf. Voordat de entropie in drie delen wordt gesplitst, codeert de SE deze met behulp van een AES 256 symmetrische sleutel die is opgeslagen in het besturingssysteem (ook wel de 'Entropy Encryption Key' genoemd). Na versleuteling wordt de entropie verdeeld in drie aandelen die vervolgens worden gedistribueerd naar back-upproviders. Uiteraard heeft u controle over dit proces en zal de SE altijd om uw uitdrukkelijke toestemming vragen voordat deze wordt gestart, net als bij elke andere applicatie die om toegang tot het zaad vraagt.

Zelfs in het geval van samenspanning tussen back-upproviders die proberen het zaad te reconstrueren (een scenario dat bijna onmogelijk wordt gemaakt door andere robuuste beveiligingen die we later zullen bespreken), zouden hun inspanningen alleen maar resulteren in het verkrijgen van het gecodeerde zaad. Zonder de encryptiesleutel die in het Secure Element (SE) is opgeslagen, zouden ze het zaad niet kunnen gebruiken.

Een belangrijk punt om te begrijpen: deze Entropy-coderingssleutel is gemeenschappelijk voor alle Ledger-apparaten, zodat u uw zaad op elk legitiem Ledger-apparaat kunt herstellen. Het wordt tijdens een OS-update in het besturingssysteem geïnjecteerd, wat op zichzelf een zeer veilige bewerking is.

Door de Entropy-encryptiesleutel rechtstreeks in het apparaat te integreren, elimineren we de noodzaak voor gebruikers om een ​​extra encryptiesleutel te onthouden of op te slaan ter bescherming tegen collusierisico's (de hierboven genoemde catch 22). Deze aanpak zorgt voor verbeterde beveiliging zonder extra vertrouwen in Ledger te vereisen, omdat deze aansluit bij het bestaande beveiligingsniveau dat wordt geboden via OS-updates.

Bescherming van de entropie-coderingssleutel

Gezien het kritieke niveau wordt de Entropy Encryption Key uitsluitend gebruikt door het besturingssysteem van het apparaat tijdens authentieke Ledger Recover-herstel- en back-upprocessen. Dit proces omvat het opzetten van geverifieerde beveiligde kanalen met meerdere HSM's van verschillende bedrijven (elke back-upprovider). Bovendien worden verschillende andere infrastructuurcomponenten, zoals de detectie van verdachte activiteiten (bijvoorbeeld het herstellen van meerdere zaden op hetzelfde apparaat) en identiteitsverificatie, beheerd door afzonderlijke teams, waardoor het aantal mensen dat nodig is om een ​​succesvolle collusieaanval uit te voeren drastisch toeneemt. In het vijfde deel van deze serie gaan we dieper in op het bestuur en de monitoring die we hebben ingevoerd!

Op dezelfde manier heeft bij Ledger geen enkele persoon de bevoegdheid om nieuwe OS-upgrades voor het apparaat te leveren. Het proces wordt cryptografisch afgedwongen om altijd de digitale handtekening te vereisen van een quorum van verschillende individuen uit verschillende teams, elk met verschillende belangen binnen het bedrijf.

Deze praktijk, bekend als scheiding van plichten, is een andere cruciale cyberbeveiligingsmaatregel waar we dieper op zullen ingaan in het onderdeel operationele veiligheid.

Deel encryptie in rust voor back-upproviders

Aan de kant van de back-upproviders hebben we een enigszins gelijkwaardige opzet.

Elke back-upprovider gebruikt een hardwarebeveiligingsmodule om zijn deel van het zaad te manipuleren. Wanneer hun HSM het aandeel van het apparaat veilig ontvangt (dubbel gecodeerd door de Entropy Encryption Key en de tijdelijke sleutel voor het beveiligde kanaal, beschreven in de vorige blogpost), wordt de Secure Channel-codering opgeheven en wordt de consistentie van het delen rechtstreeks binnen de HSM geverifieerd.

Vanwege de beperkte geheugencapaciteit kunnen HSM's geen groot aantal shares opslaan. Daarom wordt elk aandeel voor opslagdoeleinden opnieuw gecodeerd met behulp van een AES 256 symmetrische coderingssleutel, bekend als de 'Provider Storage Key'. Dankzij deze extra coderingslaag kunnen de shares veilig worden opgeslagen buiten de grenzen van de HSM in een RDMS. Met andere woorden: de aandelen verschijnen nooit buiten een beveiligde enclave zonder een dubbel versleutelingsschema.
De Provider Storage Key wordt door elke provider binnen de HSM gegenereerd en verlaat deze nooit onverpakt. Het is voor niemand toegankelijk, ook niet voor medewerkers van de back-upproviders zelf. Dit is de standaard cyberbeveiligingspraktijk van bedrijven die zeer geheime, zeer gevoelige gegevens verwerken.

De aandelen verlaten ook nooit de grenzen van de HSM en worden altijd gecodeerd, zowel tijdens het transport als in rust.

Opnieuw wordt een robuuste scheiding van taken afgedwongen voor personen die de mogelijkheid hebben om de HSM’s te manipuleren en er toegang toe te krijgen. Verschillende verantwoordelijkheden, zoals het bijwerken van de code, fysieke toegang tot de HSM, toegang tot de database en het installeren van software op de fysieke host van de HSM, worden toegewezen aan afzonderlijke personen met beperkte toegangsrechten. Bovendien moet alle software die op de HSM draait, digitaal worden ondertekend door een quorum van meerdere personen uit verschillende teams en met uiteenlopende belangen binnen het bedrijf.

Dit alles maakt het extreem moeilijk – bijna onmogelijk – voor één persoon in een van de betrokken bedrijven om toegang te krijgen tot de aandelen.

HSM's slaan opnieuw toe: databasediversificatie

Oké, we komen dichter bij een complete oplossing om onze aandelen veilig op te slaan!

Maar wat als verschillende insiders binnen de back-upproviders gezamenlijk de entropie van een individu wilden achterhalen, waardoor een effectieve grote samenzwering tussen teams en quorumleden van elk bedrijf zou worden georkestreerd?

Is het mogelijk om technische maatregelen te introduceren die het uiterst lastig, zo niet onhaalbaar, maken om dit te verwezenlijken? Kunnen we veiligheidsmaatregelen implementeren die elke insider binnen een van de bedrijven genoeg tijd geven om alarm te slaan bij alle gebruikers voordat er iets gebeurt?

Eén oplossing is het gebruik van wat bekend staat als “Databasediversificatie”. Opnieuw maken we gebruik van de mogelijkheden van onze HSM’s om dit te implementeren.

Als je deze blogpost vanaf het begin hebt gevolgd, begrijp je nu dat de verwerking van shares uitsluitend binnen de veilige grenzen van HSM’s wordt beheerd, maar dat de daadwerkelijke opslag van die gecodeerde shares plaatsvindt in een aparte backend-database buiten de HSM.

Dit is wat we gaan doen: de HSM unieke database-ID's laten genereren voor elke share, die dienen als hun specifieke ID's binnen de backend-database. Deze ID's worden op een 'gediversifieerde' manier gegenereerd, afgeleid van een geheim dat door de HSM zelf is gecreëerd, veilig opgeslagen in zijn eigen beveiligde geheugen en nooit onverpakt openbaar gemaakt. De backend dient daarom alleen als externe opslag en kan de database-inhoud niet lezen of beslissen over de identificatiegegevens van zijn eigen database-items.

Wat betekent dit? De deel-ID's zullen verschillend zijn voor verschillende back-upproviders, waaronder Ledger, Coincover en EscrowTech. Bovendien, aangezien gebruikersgegevens ook gecodeerd en gediversifieerd blijven, zou zelfs als er sprake zou zijn van collusie tussen twee aanbieders, dit geen enkele aanwijzing opleveren over welke database-invoer overeenkomt met welke gebruiker of met welke invoer in de database van de andere aanbieder.

De enige mogelijke aanpak zou zijn om alle mogelijke combinaties van shares in alle databases van alle betrokken back-upproviders bruut te forceren. Dit proces is zeer tijdrovend en vereist een volledige herstelstroom waarbij gebruik wordt gemaakt van de volledige infrastructuur van HSM's en een legitiem Ledger-apparaat voor het ontsleutelen van elke combinatie met handmatige goedkeuring via een pincode. Zoals bedoeld vergt deze aanpak veel tijd en moeite.

De niet-gediversifieerde gebruikers-ID is uiteraard aanwezig in de component die verantwoordelijk is voor het orkestreren van de herstelstroom (alleen aanwezig aan de Ledger-zijde). Dit is precies de reden waarom, zoals eerder vermeld, een strikte scheiding van taken wordt afgedwongen tussen de teams en individuen die de Orchestration-component beheren en degenen die toezicht houden op de HSM's en databases van de Backup Provider.

Veilig en gezellig, nu even bewijzen dat ik mezelf ben

Na het splitsen en veilig delen van Secret Recovery Phrases hebben we nu een oplossing bedacht die zorgt voor de veilige opslag van de verschillende shares. Het is afhankelijk van hardwareapparaten, cryptografische constructies en operationele scheidingen die allemaal essentieel zijn om een ​​veilig product te bouwen. We zijn nu beschermd tegen risico's op de bron- en bestemmingseindpunten, maar ook tijdens transport en opslag. We hebben ook het collusierisico van individuen binnen elk bedrijf, of binnen bedrijven zelf, tot zo dicht mogelijk teruggebracht.

Op dit punt vraagt ​​u zich misschien af ​​wat het laatste ontbrekende onderdeel is: het vrijgeven van de door elke back-upprovider versleutelde shares. Dit proces moet zwaar worden beschermd, dus hoe zorgen we ervoor dat de daadwerkelijke eigenaar van het zaad degene is die het verzoek om vrijgave van aandelen initieert?

Het is nu tijd om het identiteitsverificatieproces (of IDV-proces) te introduceren, wat het laatste stukje van de puzzel is. Wanneer een back-upprovider wordt gevraagd zijn deel van een Seed vrij te geven, verwacht hij een autorisatie te ontvangen van een IDV-provider, wat het bewijs is dat het verzoek is geïnitieerd door de echte eigenaar van het Seed.

Door voor elke back-upprovider een andere IDV-provider te hebben, voegen we een extra beschermingslaag tegen collusie toe.

Het implementeren van IDV's voor meerdere back-upproviders kan behoorlijk complex zijn. Daarom zullen we onze volgende blogpost wijden aan een gedetailleerde uitleg ervan. Tag mee als je meer wilt weten!

Pierre AOUN / Yacine BADISS

Software Architecten

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoData.Network Verticale generatieve AI. Versterk jezelf. Toegang hier.
• PlatoAiStream. Web3-intelligentie. Kennis versterkt. Toegang hier.
• PlatoESG. Automotive / EV's, carbon, CleanTech, Energie, Milieu, Zonne, Afvalbeheer. Toegang hier.
• Plato Gezondheid. Intelligentie op het gebied van biotech en klinische proeven. Toegang hier.
• ChartPrime. Verhoog uw handelsspel met ChartPrime. Toegang hier.
• BlockOffsets. Eigendom voor milieucompensatie moderniseren. Toegang hier.
• Bron: https://www.ledger.com/blog/part-3-genesis-of-ledger-recover-avoiding-collusion-and-leaks