Parte 3: Genesis of Ledger Recover – Evitare collusioni e fughe di notizie | Libro mastro

Bentornati alla terza parte della nostra serie di blog su Recupero del libro mastrola genesi! Il nostro obiettivo è esplorare i numerosi ostacoli tecnici incontrati durante la creazione di un servizio di recupero seed e in che modo Ledger Recover, fornito da Coincover, li risolve con un design e un'infrastruttura sicuri.

Nelle parti precedenti abbiamo spiegato come può essere l'entropia di una Secret Recovery Phrase suddivisa in più condivisioni (o frammenti)e inviato a fornitori di backup affidabili, mantenendo sempre il massimo livello di sicurezza. Grazie a moderni strumenti di crittografia e hardware sicuro, siamo in grado di eseguire un backup completo di un seed, con la garanzia che nessun utente malintenzionato possa impossessarsi di nessuna delle condivisioni durante il transito.

Passeremo ora al passaggio logico successivo, il backup fisico delle condivisioni. Fornire uno spazio di archiviazione sicuro è fondamentale e solleva questioni cruciali che dobbiamo affrontare: come possiamo garantire che le condivisioni siano archiviate in modo sicuro e non possano essere rubate? Come possiamo prevenire la collusione tra i fornitori di backup per ricostruire il tuo seed?

Più livelli di sicurezza

Per garantire la sicurezza dell'archiviazione delle condivisioni, un possibile approccio consiste nel fare in modo che ciascun provider memorizzi la propria condivisione individuale in un luogo sicuro, ad esempio una cassaforte. In alternativa, potresti scegliere di conservarlo in una cassaforte bancaria diversa. Questa disposizione consente ai fornitori di concentrarsi esclusivamente sulla salvaguardia delle rispettive chiavi, semplificando il controllo degli accessi e riducendo il rischio di fughe di notizie da parte di familiari e amici.

Proteggerci da potenziali collusioni pone più sfide. Potresti prendere in considerazione la creazione di più condivisioni distribuite tra diverse categorie di amici o fornitori di archiviazione. Puoi anche vincolarli con contratti. Sebbene queste soluzioni siano fattibili, richiedono comunque un certo livello di fiducia.

Una soluzione alternativa è cifrare le condivisioni prima che vengano inviate ai tuoi amici. In questo modo, anche se colludono, non saranno in grado di utilizzare le condivisioni per ricostruire il seme. Ma ecco il problema 22 dello spazio fisico: per crittografare le condivisioni, è necessaria una nuova chiave segreta personale. Stai essenzialmente sostenendo un segreto, il tuo seme, con introducendo un altro segreto che devi proteggere e ricordare.

Potremmo sostenere che questo nuovo segreto è meno critico di quello originale poiché viene utilizzato solo per proteggerti dalla collusione tra i tuoi amici. Un utente malintenzionato che ottiene l'accesso a questa nuova chiave non sarebbe in grado di rubare direttamente i tuoi fondi, ma se dovessi perderlo perderesti anche l'accesso al tuo seme.

Come funziona Ledger Recover: hardware sicuro e più livelli di crittografia

In Ledger Recover, fornito da Coincover, utilizziamo le proprietà dell'hardware sicuro a nostra disposizione per rispondere a queste domande nel modo più intuitivo possibile. Facciamo affidamento sul Secure Element (SE) contenuto nel tuo portafoglio hardware Ledger, nonché sui moduli di sicurezza hardware (HSM) utilizzati da ciascuno dei fornitori di backup.

Elementi sicuri: il potere della sicurezza nel palmo della tua mano

Un Secure Element è un chip specializzato comunemente utilizzato in passaporti, carte di credito e sistemi di pagamento per archiviare ed elaborare in modo sicuro dati sensibili. Gli SE sono specificamente progettati per resistere a un'ampia gamma di attacchi come manomissione fisica, side-channel, fault-injection, sfruttamento del software o malware. Questi chip sono certificati da laboratori di sicurezza di terze parti attraverso test intensivi relativi a tali attacchi.

Il tuo Ledger Nano si affida a questa tecnologia collaudata e affidabile per conservare e proteggere i tuoi semi. Il sistema operativo Ledger in esecuzione su questo SE richiederà sempre il tuo consenso fisico prima di utilizzare il seme.

HSM: proteggere i server

Hardware Security Module (HSM) è un'enclave di sicurezza generalmente disponibile come scheda plug-in o dispositivo esterno direttamente collegato a un computer o server di rete. Sfrutta processori crittografici, memorie sicure e varie contromisure anti-manomissione per archiviare ed elaborare in modo sicuro i segreti. Questi moduli salvaguardano le infrastrutture critiche e sono utilizzati da organizzazioni altamente attente alla sicurezza, incluso il settore bancario, per proteggere le proprie chiavi segrete e l'infrastruttura.

Ledger utilizza più HSM per vari casi d'uso, tra cui verificare l'autenticità dei dispositivi Ledger Nano e Ledger Staxe abilitando aggiornamenti sicuri del sistema operativo su un canale crittografato e autenticato.

Sia gli SE che gli HSM svolgono un ruolo fondamentale nel migliorare la sicurezza dei dati in diverse applicazioni. Aiutano le organizzazioni a soddisfare i requisiti normativi per la privacy e la sicurezza dei dati e la manipolazione sicura dei dati critici.

Crittografia dei semi tramite Secure Element

Il primo livello di protezione viene dallo stesso Secure Element (SE). Prima di suddividere l'entropia in tre condivisioni, SE la crittografa utilizzando una chiave simmetrica AES 256 memorizzata nel suo sistema operativo (denominata "Entropy Encryption Key"). Dopo la crittografia, l'entropia viene suddivisa in tre condivisioni che vengono poi distribuite ai fornitori di backup. Naturalmente, hai il controllo su questo processo e SE richiederà sempre il tuo consenso esplicito prima di avviarlo, proprio come per qualsiasi altra applicazione che richieda l'accesso al seed.

Anche in caso di collusione tra i fornitori di backup che tentano di ricostruire il seme (uno scenario reso quasi impossibile da altre robuste protezioni di cui parleremo più avanti), i loro sforzi porterebbero solo all'ottenimento del seme crittografato. Senza la chiave di crittografia memorizzata nel Secure Element (SE), non sarebbero in grado di utilizzare il seme.

Un punto chiave da capire: questa chiave di crittografia Entropy è comune a tutti i dispositivi Ledger, in modo da poter ripristinare il seme su qualsiasi dispositivo Ledger legittimo. Viene iniettato nel sistema operativo durante un aggiornamento del sistema operativo, di per sé un'operazione molto sicura.

Incorporando la chiave di crittografia Entropy direttamente nel dispositivo, eliminiamo la necessità per gli utenti di ricordare o archiviare una chiave di crittografia aggiuntiva per proteggersi dai rischi di collusione (il trucco 22 menzionato sopra). Questo approccio garantisce una maggiore sicurezza senza richiedere ulteriore fiducia in Ledger, in quanto si allinea con il livello di sicurezza esistente fornito tramite gli aggiornamenti del sistema operativo.

Protezione della chiave di crittografia Entropy

Dato il suo livello di criticità, la chiave di crittografia Entropy viene utilizzata esclusivamente dal sistema operativo del dispositivo durante i processi di ripristino e backup autentici di Ledger Recover. Questo processo prevede la creazione di canali sicuri autenticati con più HSM di aziende diverse (ciascun provider di backup). Inoltre, vari altri componenti dell'infrastruttura, come il rilevamento di attività sospette (ad esempio, il ripristino di più seed sullo stesso dispositivo) e la verifica dell'identità, sono gestiti da team separati, il che aumenta drasticamente il numero di persone necessarie per eseguire con successo un attacco di collusione. Approfondiremo la governance e il monitoraggio che abbiamo messo in atto nella quinta parte di questa serie!

Allo stesso modo, in Ledger, nessuna singola persona possiede l'autorità per fornire nuovi aggiornamenti del sistema operativo per il dispositivo. Il processo viene applicato crittograficamente per richiedere sempre la firma digitale a un quorum di diverse persone appartenenti a team diversi, ciascuno con interessi diversi all'interno dell'azienda.

Questa pratica, nota come separazione dei compiti, è un'altra misura cruciale per la sicurezza informatica che approfondiremo nella sezione sulla sicurezza operativa.

Condividi la crittografia dei dati inattivi per i provider di backup

Ora dalla parte dei fornitori di backup, abbiamo una configurazione in qualche modo equivalente.

Ogni provider di backup utilizza un modulo di sicurezza hardware per manipolare la propria quota di seed. Quando il loro HSM riceve la condivisione dal dispositivo in modo sicuro (doppiamente crittografato dalla chiave di crittografia Entropy e dalla chiave temporanea del canale sicuro descritta in il post precedente del blog), la crittografia Secure Channel viene revocata e la coerenza della condivisione viene verificata direttamente all'interno dell'HSM.

A causa della capacità di memoria limitata, gli HSM non possono archiviare un numero elevato di condivisioni. Pertanto, ai fini dell'archiviazione, ogni condivisione viene nuovamente crittografata utilizzando una chiave di crittografia simmetrica AES 256, nota come "Chiave di archiviazione del provider". Questo ulteriore livello di crittografia consente di archiviare in modo sicuro le condivisioni al di fuori dei limiti dell'HSM in un RDMS. In altre parole, le condivisioni non appaiono mai al di fuori di un'enclave sicura senza un doppio schema di crittografia.
La chiave di archiviazione del provider viene generata all'interno dell'HSM da ciascun provider e non la lascia mai scartare. Non è mai accessibile a nessuno, compresi i dipendenti degli stessi fornitori di backup. Questa è una pratica di sicurezza informatica standard delle aziende che gestiscono dati altamente segreti e altamente sensibili.

Inoltre, le condivisioni non lasciano mai in chiaro i confini dell'HSM e sono sempre crittografate sia in transito che a riposo.

Ancora una volta, viene applicata una solida separazione dei compiti per le persone che hanno la capacità di manipolare e accedere agli HSM. Diverse responsabilità, come l'aggiornamento del codice, l'accesso fisico all'HSM, l'accesso al database e l'installazione del software sull'host fisico dell'HSM, sono assegnate a persone distinte con diritti di accesso limitati. Inoltre, qualsiasi software in esecuzione sull'HSM deve essere sottoposto a firma digitale da parte di un quorum di più persone appartenenti a team diversi e con interessi diversi all'interno dell'azienda.

Tutto ciò rende estremamente difficile – quasi impossibile – per una singola persona in una qualsiasi delle società coinvolte avere accesso alle azioni.

Gli HSM colpiscono ancora: diversificazione del database

Ok, ci stiamo avvicinando a una soluzione completa per archiviare in modo sicuro le nostre condivisioni!

Ma cosa succederebbe se diversi addetti ai lavori all'interno dei fornitori di backup desiderassero collettivamente recuperare l'entropia di un individuo, orchestrando un'efficace grande collusione tra i team ei membri del quorum di ciascuna azienda?

È possibile introdurre accorgimenti tecnici che ne rendano estremamente impegnativo, se non irrealizzabile, il raggiungimento? Possiamo implementare misure di sicurezza che forniscano tempo sufficiente a qualsiasi insider all'interno di qualsiasi azienda per lanciare l'allarme a tutti gli utenti prima che accada qualcosa?

Una soluzione consiste nell'utilizzare la cosiddetta "diversificazione del database". Ancora una volta, sfruttiamo le capacità dei nostri HSM per implementarlo.

Se hai seguito questo post del blog dall'inizio, ora comprendi che l'elaborazione delle condivisioni è gestita esclusivamente all'interno dei confini sicuri degli HSM, ma che l'effettiva archiviazione di tali condivisioni crittografate avviene in un database back-end separato all'esterno dell'HSM.

Ecco cosa faremo: consentire all'HSM di generare ID di database univoci per ciascuna condivisione, che fungono da identificatori specifici all'interno del database di back-end. Questi ID verranno generati in modo "diversificato", derivato da un segreto creato dall'HSM stesso, archiviato in modo sicuro all'interno della propria memoria sicura e mai esposto non protetto. Il back-end funge quindi solo da memoria esterna, incapace di leggere il contenuto del database o decidere gli identificatori delle proprie voci di database.

Cosa significa questo? Gli identificatori di condivisione saranno distinti tra diversi fornitori di backup, tra cui Ledger, Coincover ed EscrowTech. Inoltre, poiché anche i dati degli utenti rimangono crittografati e diversificati, anche se si verificasse una collusione tra due fornitori, non fornirebbe alcun indizio su quale voce del database corrisponda a quale utente oa quale voce nel database dell'altro fornitore.

L'unico approccio possibile sarebbe quello di forzare tutte le possibili combinazioni di condivisioni su tutti i database da tutti i fornitori di backup coinvolti. Questo processo richiede molto tempo e richiede un flusso di ripristino completo che prevede l'utilizzo dell'infrastruttura completa degli HSM e di un dispositivo Ledger legittimo per decrittografare ogni combinazione con l'approvazione manuale tramite codice PIN. Come previsto, questo approccio richiede tempo e impegno notevoli.

L'identificatore utente non diversificato è ovviamente presente all'interno del componente preposto all'orchestrazione del flusso di recovery (presente solo lato Ledger). Questo è esattamente il motivo per cui, come accennato in precedenza, viene applicata una rigida separazione dei compiti tra i team e le persone che gestiscono la componente Orchestration e coloro che sovrintendono agli HSM e ai database del provider di backup.

Sicuro e accogliente, ora per dimostrare che sono io

Dopo aver suddiviso e condiviso in modo sicuro le frasi di recupero segreto, abbiamo ora ideato una soluzione che garantisce l'archiviazione sicura delle diverse condivisioni. Si basa su dispositivi hardware, costrutti crittografici e separazioni operative che sono tutti essenziali per costruire un prodotto sicuro. Ora siamo protetti dai rischi agli endpoint di origine e di destinazione, ma anche durante il transito e lo stoccaggio. Abbiamo anche ridotto i rischi di collusione da parte di individui all'interno di ciascuna azienda, o all'interno delle aziende stesse, il più vicino possibile allo zero.

A questo punto, ti starai chiedendo l'ultima parte mancante: il rilascio delle condivisioni crittografate da ciascun provider di backup. Questo processo deve essere fortemente protetto, quindi come possiamo assicurarci che l'effettivo proprietario del seme sia quello che avvia la richiesta di rilascio della condivisione?

È giunto il momento di introdurre il processo di verifica dell'identità (o IDV), che è l'ultimo pezzo del puzzle. Quando a un provider di backup viene chiesto di rilasciare la sua quota di seed, si aspetta di ricevere un'autorizzazione da un provider IDV che sia la prova che la richiesta è stata avviata dal vero proprietario del seed.

Avendo un provider IDV diverso per ogni provider di backup, aggiungiamo un ulteriore livello di protezione contro la collusione.

L'implementazione di IDV per più fornitori di backup può essere piuttosto complessa, motivo per cui dedicheremo il nostro prossimo post sul blog a spiegarlo in dettaglio. Taggate se volete saperne di più!

Pierre AOUN / Yacine BADISS

Architetti del software

• Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
• PlatoData.Network Generativo verticale Ai. Potenzia te stesso. Accedi qui.
• PlatoAiStream. Intelligenza Web3. Conoscenza amplificata. Accedi qui.
• PlatoneESG. Automobilistico/VE, Carbonio, Tecnologia pulita, Energia, Ambiente, Solare, Gestione dei rifiuti. Accedi qui.
• Platone Salute. Intelligence sulle biotecnologie e sulle sperimentazioni cliniche. Accedi qui.
• Grafico Prime. Migliora il tuo gioco di trading con ChartPrime. Accedi qui.
• BlockOffset. Modernizzare la proprietà della compensazione ambientale. Accedi qui.
• Fonte: https://www.ledger.com/blog/part-3-genesis-of-ledger-recover-avoiding-collusion-and-leaks