Parte 2: Genesis of Ledger Recover – Distribuzione sicura delle azioni | Libro mastro

Bentornati alla seconda 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 il modo in cui Ledger Recover li risolve con un design e un'infrastruttura sicuri.

Nel parte precedente, abbiamo esaminato come eseguire il backup di una frase di recupero segreta suddividendola e in che modo Ledger Recover lo fa per te utilizzando Condivisione segreta verificabile Pedersen.

Ora che hai tre condivisioni, la domanda successiva è: come puoi distribuirli in modo sicuro ai tuoi fornitori di backup? Infatti, se una parte malintenzionata intercetta tutte le condivisioni mentre le stai trasmettendo, vanifica in primo luogo lo scopo di dividere il seme. Nella sicurezza informatica, questo si chiama a Attacco Man-in-the-Middle, in cui un utente malintenzionato si frappone tra te e il tuo destinatario e manomette la comunicazione per cercare di scoprire i segreti.

Quando si utilizza Ledger Recover, la trasmissione del seme viene eseguita attraverso un meccanismo di distribuzione sicuro. Si basa su diversi strumenti crittografici e concetti matematici che spiegheremo a fondo.

Inizieremo descrivendo il problema in questione in modo più dettagliato. Quindi introdurremo diversi strumenti crittografici e concetti matematici che Ledger Recover sfrutta per distribuire in modo sicuro le condivisioni seed ai fornitori di backup.

Courier-In-The-Middle: un esempio reale

Il modo più ovvio per proteggersi da un intermediario malintenzionato è non averne affatto. Potresti andare tu stesso a casa dei tuoi amici o radunarli nello stesso luogo chiuso per consegnare le azioni. Ma questo diventa molto più difficile se non sei collocato e vuoi inviare le azioni a un conoscente a distanza.

Supponendo che la rete su cui comunichiamo (ad esempio il servizio postale) sia intrinsecamente inaffidabile, come possiamo garantire che gli intercettatori non possano mai intravedere le nostre condivisioni segrete?

È giunto il momento di presentare Alice e Bob, e la famigerata Eve, tre noti personaggi della crittografia. Alice ha un segreto che vuole condividere con Bob e non ha altra scelta che inviarlo tramite Eve, il loro corriere inaffidabile. In parole crittografiche, Alice e Bob vogliono stabilire un canale di comunicazione sicuro tra loro per scambiarsi il loro segreto in sicurezza.

Ecco cosa potrebbero fare Alice e Bob:

• Alice mette il suo segreto in una scatola, la chiude a chiave con il suo lucchetto personale, prima di inviarla a Bob.
• Quando Bob riceve la scatola, aggiunge il proprio lucchetto e lo rimanda indietro.
• Alice ora può usare la sua chiave per rimuovere il suo lucchetto dalla scatola prima di inviarlo un'ultima volta.
• Per finire il processo, Bob usa semplicemente la sua chiave per rimuovere il suo lucchetto e recuperare - finalmente - il segreto di Alice.

Durante tutto lo scambio, ogni volta che Eve ha avuto la scatola tra le mani, è stata sempre protetta, o dal lucchetto di Alice, o da quello di Bob, o da entrambi.

Anche se questo è un ottimo inizio, ci sono diversi problemi da risolvere in questo scenario:

• Autenticazione reciproca: Alice e Bob hanno bisogno di modi infallibili per verificare che ogni lucchetto provenga davvero dall'altra parte. Altrimenti, Eve potrebbe scambiarlo con la sua scatola e lucchetto e ingannare Alice o Bob facendogli credere di essere l'altra parte.
• Segreto in avanti: Se Eve avesse rubato la scatola chiusa a chiave e in seguito avesse rubato la chiave di Alice o Bob, avrebbe potuto recuperare il segreto originale. Vogliamo invece assicurarci che future fughe di chiavi a lungo termine non possano compromettere i vecchi pacchetti rubati.
• Tutela della privacy: In questo scenario, gli indirizzi di Alice e Bob vengono comunicati al corriere. Nell'equivalente digitale di questo processo, vogliamo un protocollo che non riveli nulla sui destinatari.

Protezione dei messaggi digitali

Nella sicurezza digitale, a canale sicuro è un modo per trasferire dati tra due autenticato parti tali che i dati riservatezza ed interezza sono garantiti. Quando utilizzi un canale sicuro, gli aggressori non possono intercettare o manomettere la tua comunicazione.

Il protocollo di Ledger Recover sia per il backup che per il ripristino si basa su a Protocollo canale sicuro, o SCP. Utilizza molteplici strumenti della moderna cassetta degli attrezzi di crittografia, come crittografia simmetrica e asimmetrica, certificati e firme digitali.
Le prossime sezioni ti daranno una rapida introduzione a tutti questi concetti, che ti permetteranno di comprendere l'intero schema di sicurezza utilizzato in Ledger Recover.

Crittografia simmetrica: uno strumento potente ma limitato

Per garantire la riservatezza dei dati scambiati tra due parti, i dati vengono solitamente crittografati e decrittografati con la stessa chiave segreta.
Questo processo è indicato come crittografia simmetrica, che è lo studio di primitive che implicano un'unica chiave segreta per garantire una o più delle proprietà di un canale sicuro.

Pur essendo un potente strumento per proteggere le tue comunicazioni, la crittografia simmetrica ha alcune ovvie limitazioni: Supponiamo che Alice voglia scambiare diversi messaggi crittografati con Bob. Prima sceglie una chiave segreta, poi la condivide con Bob, prima di iniziare a inviare messaggi.
Ovviamente il problema ora diventa: come fa Alice a condividere la chiave segreta in modo sicuro con Bob? Se qualcuno entra in possesso della chiave, la comunicazione di Alice e Bob non sarà più confidenziale.
Alice potrebbe incontrare Bob di persona per dargli la chiave, ma in questo caso perché non discuterne allora, lontano da orecchie indiscrete?

Per le comunicazioni digitali, abbiamo bisogno di un metodo sicuro per condividere la chiave simmetrica e avviare lo scambio protetto di dati. È tempo di presentare il lavoro di due titani della crittografia moderna, Whitfield Diffie ed Martin Hellmann.

Crittografia asimmetrica: nascondere le parti intime

Accordo chiave Diffie-Hellman

Con la crittografia a chiave pubblica, Diffie e Hellman hanno escogitato un nuovo approccio per proteggere le comunicazioni. Hanno definito un protocollo con due chiavi distinte per la crittografia e la decrittografia. Le due chiavi sono comunemente chiamate chiavi pubbliche e private, formando una coppia che può essere utilizzata per crittografare/decrittografare e firmare/verificare i dati.

Chiavi pubbliche e private
La crittografia a chiave pubblica è la base della maggior parte della nostra sicurezza digitale. Viene utilizzato per proteggerti sul Web ed è anche il modo in cui dimostri la proprietà di monete e token su tutte le blockchain pubbliche.

Scopri di più su questo argomento su Ledger Academy!

Ciò che è davvero interessante per noi è il modo in cui Diffie e Hellman hanno suggerito di utilizzare la crittografia a chiave pubblica per distribuire chiavi simmetriche. Il loro metodo, noto come Scambio di chiavi Diffie-Hellman, consiste in scambi avanti e indietro tra due parti per concordare alla fine un segreto condiviso. Se eseguiti correttamente, gli intercettatori non sono in grado di calcolare lo stesso segreto condiviso dalle informazioni che sentono.

Il TL; DR è che nel diagramma sopra Eve non è matematicamente in grado di capire il segreto k anche se ha accesso a tutte le comunicazioni di Alice e Bob. Per capire perché questo segreto condiviso è al sicuro da qualsiasi intercettatore, dobbiamo scavare un po' nella teoria dei gruppi. 

La sicurezza dello scambio di chiavi Diffie-Hellman si basa sulla complessità del problema del logaritmo discreto su un gruppo ciclico. Un gruppo ciclico è un gruppo generato da un singolo elemento.
In poche parole, Alice e Bob eseguono i seguenti passaggi per concordare un segreto condiviso k:

1. Alice e Bob concordano su un gruppo ciclico G di ordine n generato da un elemento g
2. Alice estrae a caso un numero 0 < a < n e invia pa =ga ∈G a Bob
3. Bob estrae a caso un numero 0 < b < n e invia pb =gb ∈G ad Alice
4. Alice calcola il segreto condiviso k =(pagb )a ∈G
5. Bob calcola il segreto condiviso k =(paga )b ∈G

La sicurezza del protocollo dipende dalla difficoltà di ritrovamento k = gab dato g, ga, gb. Questo si chiama il Calcolo Ipotesi Diffie-Hellman (CDH). L'ipotesi che CDH sia difficile da risolvere suppone che il problema del logaritmo discreto è difficile da risolvere.

In questo schema, mentre il segreto condiviso è al sicuro da intercettazioni, non vi è alcuna garanzia sull'origine dei dati scambiati. Affinché l'interazione sia sicura, Alice e Bob devono in qualche modo dimostrare reciprocamente la loro identità.

Autenticazione reciproca e firma digitale

Una firma autografa viene solitamente utilizzata per riconoscere e accettare il contenuto di un documento. Solo il firmatario è in grado di produrre la firma, ma chiunque "sa" come appare la firma può verificare che il documento sia stato firmato dalla persona giusta.

Pur avendo proprietà simili, una firma digitale fornisce ulteriori solide garanzie sfruttando la crittografia asimmetrica:

• Autenticità: chiunque può verificare che il messaggio sia stato firmato con la chiave privata corrispondente alla chiave pubblica specificata.
• Non ripudio: il firmatario non può negare di aver firmato e inviato il messaggio.
• Integrità: il messaggio non è stato alterato durante la trasmissione.

Ora, finché conosciamo e ci fidiamo della chiave pubblica del nostro corrispondente, possiamo controllare l'autenticità di tutti i messaggi verificando la loro firma digitale.
Nella maggior parte dei casi del mondo reale, tuttavia, o non conosciamo intimamente il nostro corrispondente o potrebbe essere necessario modificare regolarmente la coppia di chiavi privata/pubblica per motivi di sicurezza. Ciò richiede un ulteriore livello di verifica e fiducia sotto forma di Certificati, che contengono la descrizione di un'entità e la relativa chiave pubblica.

Ogni certificato è firmato da una chiave pubblica padre. Avendo un'autorità di certificazione radice (o CA radice) di cui ci fidiamo sempre, possiamo creare una catena di fiducia utilizzando firme digitali successive.

Curve ellittiche: crittografia a chiave pubblica di livello superiore

La crittografia a curva ellittica (ECC) è una sottoarea della crittografia a chiave pubblica che consiste nell'utilizzare curve ellittiche per applicazioni crittografiche, ad esempio per schemi di cifratura o firma. 
Basato sulla matematica attualmente compresa, ECC fornisce una base significativamente più sicura rispetto ai precedenti sistemi di crittografia a chiave pubblica come RSA.

A parità di livello di sicurezza, ECC comporta lunghezze di chiave inferiori rispetto ad altri sistemi crittografici asimmetrici, il che lo rende una buona scelta per i sistemi embedded con risorse limitate.
Se vuoi saperne di più, Questo articolo può aiutare a comprendere meglio le curve ellittiche.

Ordine di una curva ellittica
L'ordine di un elemento g di un gruppo è un parametro importante dello scambio di chiavi Diffie-Hellman. Quando il gruppo è una curva ellittica, quell'elemento è un punto e il suo ordine è il numero di volte in cui può essere aggiunto a se stesso prima di tornare al suo valore iniziale.
Nota che questa addizione non ha nulla a che fare con la tua solita somma su numeri reali, ma ha proprietà di additività simili.

Prendiamo la curva ellittica E: si2 =x3 +2x +3 sopra il campo 𝔽97 come esempio. Come funzione discreta, è rappresentata dai punti nella figura sottostante. Ci concentreremo sul punto P =(3, 6) e tutti i suoi multipli.

Lo vediamo dopo le 5.P, siamo tornati all'inizio e abbiamo raggiunto gli stessi punti di prima. Non importa quale sia il valore dello scalare P è moltiplicato per, otterremo sempre uno dei nostri 5 punti iniziali.
Così l'ordine di P è 5 e il sottogruppo che genera contiene esattamente 5 punti. Per le applicazioni crittografiche, tuttavia, l'ordine è molto più grande di 5, aumentando la casualità.

Mescola tutto: ECDH con autenticazione

Ora abbiamo tutti gli strumenti di cui abbiamo bisogno per creare un ottimo protocollo di scambio di chiavi:  Curva ellittica Diffie-Hellman (ECDH).

ECDH è uno schema crittografico standardizzato che implementa lo scambio di chiavi Diffie-Hellman sopra descritto, utilizzando la crittografia a curva ellittica per generare le coppie di chiavi e il segreto condiviso.

Inizia selezionando una curva ellittica e il suo punto di generazione. Le due parti si scambiano quindi certificati attendibili, che consentono loro di verificare l'autenticità delle rispettive chiavi pubbliche. Una volta autenticati, possono generare un segreto condiviso k che viene calcolato come:

k = dA . DB . sol
dA: chiave privata di Alice
dB: chiave privata di Bob
G: punto CE

Per raggiungere il segreto in avanti proprietà, la coppia di chiavi sia di Alice che di Bob dovrebbe essere effimera, ovvero essere generata sul momento e utilizzata per una singola esecuzione del protocollo. Parliamo di un Elliptic Curve Diffie-Hellman Ephemeral (ECDHE). In questo scenario, le chiavi temporanee firmate sia dalle chiavi statiche sul dispositivo che dagli HSM, consentono una forte autenticazione delle chiavi. Anche se in futuro si verificasse un accesso non autorizzato alle chiavi statiche, non garantirebbe capacità di decrittazione per gli scambi protetti dalle chiavi temporanee.

Inoltre, abbiamo implementato un notevole miglioramento del protocollo nascondendo le chiavi statiche dei dispositivi all'interno del canale sicuro. Questa misura precauzionale impedisce agli aggressori di ottenere visibilità sul certificato statico dei dispositivi, il che, a sua volta, potrebbe portare alla perdita di identificatori univoci utilizzati durante le operazioni di backup/ripristino.

Torna a Ledger Recover: il viaggio di un seme

Va bene, è ora di fare una pausa per un minuto.

Abbiamo trattato molti argomenti, relativi sia alla sicurezza che alla matematica, e il risultato è un protocollo per comunicare in modo sicuro su qualsiasi rete non sicura. Riassumiamo quanto visto finora:

Due entità possono avere una comunicazione sicura su un canale non sicuro concordando a segreto unico grazie al ECDHE, che è un'implementazione del protocollo di accordo chiave Diffie-Hellman che utilizza chiavi effimere per proteggere il segreto in avanti. Ogni entità è in grado di verificarne l'autenticità del loro corrispondente grazie ad una iniziale Verifica del certificato.

Nel caso di Ledger Recover, abbiamo stabilito quattro canali sicuri utilizzando il protocollo Secure Channel. Questi canali collegano il dispositivo a ciascuno dei fornitori di backup e all'orchestrator, tutti dotati di moduli di sicurezza hardware (HSM).

Ogni attore detiene il proprio certificato personale, firmato da un certificato di registro che funge da radice della catena di fiducia. Quando il dispositivo dell'utente trasmette per la prima volta l'intenzione di eseguire un backup all'orchestrator, avvia un ECDHE autenticato. Sotto questi mTLS sessioni, l'orchestrator trasmette le informazioni che collegheranno i futuri canali sicuri alla particolare richiesta di backup dell'utente, insieme all'identità dell'utente che verrà richiesta per la convalida durante l'esecuzione di un ripristino successivo del seme.

Tutto è pronto per eseguire finalmente la parte più critica dell'intera operazione: trasmettendo le tre condivisioni del seme dell'utente.

Ancora una volta, creiamo nuovi canali sicuri, ma questa volta tra il dispositivo Ledger dell'utente e gli HSM dei provider di backup direttamente. Le condivisioni seed vengono trasmesse in un canale crittografato end-to-end al loro luogo di archiviazione finale, garantendo al tempo stesso che raggiungano la destinazione corretta (è qui che la verificabilità di Pedersen Secret Sharing introdotta in parte 1 è utile).
Il dispositivo dell'utente autentica gli HSM dei fornitori di backup uno per uno e i fornitori di backup sanno che stanno scambiando con l'unico dispositivo Ledger ufficiale che ha avviato questa specifica richiesta di backup.
Nessuno oltre al dispositivo dell'utente e agli HSM dei provider di backup vede mai le condivisioni seed crittografate dalle chiavi simmetriche di questi canali sicuri reciprocamente autenticati, nemmeno l'orchestrator.

Ricevuto in modo sicuro... e archiviato?

In questa parte abbiamo introdotto diversi nuovi concetti, alcuni dei quali sono piuttosto tecnici. Ciascuno di questi concetti è necessario per stabilire una trasmissione sicura che garantisca la riservatezza e l'integrità dello scambio. Indipendentemente dalla sicurezza della rete, ora possiamo inviare le nostre condivisioni segrete senza temere che possano essere manomesse o intercettate. Questo è piuttosto l'aggiornamento!

L'intero processo è supportato da crittografia solida e hardware sicuro, sotto forma di dispositivo hardware Ledger e HSM di proprietà di ciascun provider di backup.

È giunto il momento di passare al recupero delle quote seed! Tutto quello che dobbiamo fare è chiedere ai fornitori di backup di restituirci le condivisioni che stanno archiviando sulla loro infrastruttura...

Ma aspetta: come stanno esattamente memorizzando questi dati molto sensibili? Non ci servirebbe a niente se avessimo i canali di comunicazione più sicuri, ma i nostri fornitori di backup si limitavano a mantenere le condivisioni in chiaro, implorando che venissero rubate.

Quindi, prima di parlare di recupero, ci arriveremo, lo prometto! –, dobbiamo fare una breve deviazione nella parte 3 per discutere la sicurezza delle nostre quote di semi a riposo. Rimani sintonizzato!

• 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.
• BlockOffset. Modernizzare la proprietà della compensazione ambientale. Accedi qui.
• Fonte: https://www.ledger.com/blog/part-2-genesis-of-ledger-recover-securely-distributing-the-shares