Protocolli di generazione distribuita delle chiavi

La Generazione distribuita delle chiavi (DKG) risolve il problema del dealer fidato nella crittografia a soglia. Senza DKG, un'entità centrale deve generare la coppia di chiavi e distribuire le quote, conoscendo temporaneamente la chiave privata completa. Il DKG consente a n partecipanti di generare congiuntamente una coppia di chiavi pubblica e privata tramite un protocollo in cui nessun singolo partecipante apprende la chiave privata, nemmeno il coordinatore del protocollo.

Il DKG di Pedersen è stato il primo protocollo DKG pratico, pubblicato nel 1991. Ognuno degli n partecipanti genera un segreto casuale s_i ed esegue un protocollo di condivisione verificabile del segreto (VSS) per condividerlo. Ogni partecipante trasmette pubblicamente gli impegni relativi ai coefficienti del proprio polinomio. Dopo che tutti i partecipanti hanno condiviso i propri contributi, il segreto combinato è la somma di tutti i valori s_i e ogni partecipante possiede una quota di questa somma.

Il VSS di Feldman (condivisione verificabile del segreto di Feldman, 1987) è l'elemento costitutivo principale della maggior parte dei protocolli DKG. Il dealer si impegna sui coefficienti del polinomio come elementi del gruppo (C_j = g^{a_j} mod p). Ogni partecipante che riceve una quota f(i) può verificarla rispetto a questi impegni controllando che g^{f(i)} sia uguale al prodotto di C_j^{i^j}. Questo consente ai partecipanti di rilevare se il dealer ha inviato quote errate.

Il DKG Joint-Feldman esegue il VSS di Feldman in parallelo per tutti gli n partecipanti, con ogni partecipante che agisce da dealer per il proprio segreto. I partecipanti presentano quindi una contestazione se ricevono quote non valide. La chiave finale è la somma dei segreti dei dealer contro i quali non sono state presentate contestazioni. Tuttavia, il DKG Joint-Feldman non è sicuro contro avversari adattivi che compromettono i partecipanti in base ai messaggi del protocollo: si tratta di una debolezza identificata da Gennaro, Jarecki, Krawczyk e Rabin.

Il protocollo DKG di GJKR (Gennaro, Jarecki, Krawczyk, Rabin, 1999 e 2007) ha risolto le debolezze del DKG Joint-Feldman. GJKR usa il VSS di Pedersen, con impegni a occultamento teorico-informativo, invece del VSS di Feldman, e aggiunge round di contestazione in cui i partecipanti possono contestare le quote non valide. Il DKG risultante è sicuro contro gli avversari adattivi ed è diventato il riferimento teorico standard per i DKG sicuri.

Il DKG di GJKR richiede tre round: il round degli impegni, in cui ogni partecipante trasmette pubblicamente gli impegni VSS; il round delle quote, in cui i partecipanti si inviano le quote peer-to-peer; e il round delle contestazioni, in cui i partecipanti trasmettono pubblicamente le contestazioni relative alle quote non valide. I partecipanti che non riescono a risolvere le contestazioni vengono esclusi. Un quarto round combina i contributi dei partecipanti validi nella chiave pubblica finale e nelle quote distribuite della chiave privata.

La gestione delle chiavi dei validatori di Ethereum usa il DKG per la tecnologia dei validatori distribuiti (DVT). EIP-4844 e l'ecosistema DVT (Obol Network, SSV Network) usano firme BLS a soglia su BLS12-381 per consentire ai comitati di validatori di firmare i blocchi senza che alcun singolo operatore conosca la chiave completa del validatore. Questo migliora la tolleranza ai guasti dei validatori e riduce il rischio di slashing dovuto alla compromissione della chiave.

DRAND è un beacon di casualità distribuita usato dalla catena beacon di Ethereum per generare numeri casuali imprevedibili. DRAND esegue un DKG tra un insieme di nodi della League of Entropy (Cloudflare, EPFL, Protocol Labs e altri) per generare una chiave BLS a soglia. A ogni round, t nodi su n contribuiscono con firme parziali che vengono combinate in un valore casuale imprevedibile. Nessun singolo nodo può influenzare o prevedere l'output.

Il DKG è molto più semplice per gli schemi a soglia Schnorr/EdDSA che per ECDSA. Negli schemi Schnorr a soglia, la chiave privata distribuita è semplicemente la somma dei segreti dei partecipanti (x = x1 + x2 + ... + xn), mentre la chiave pubblica è la somma delle quote di chiave pubblica (X = X1 + X2 + ... + Xn). Per ECDSA, la non linearità implica che il DKG debba produrre quote moltiplicative, richiedendo protocolli più complessi.

Le quote di una chiave a soglia mantenute per lungo tempo possono essere compromesse gradualmente se un avversario compromette lentamente i partecipanti nel corso del tempo. La condivisione proattiva del segreto, tramite protocolli di aggiornamento, randomizza nuovamente periodicamente le quote senza modificare la chiave sottostante. Dopo un aggiornamento, le quote precedenti all'aggiornamento non sono più utili, limitando la finestra di vulnerabilità. GJKR e i suoi derivati includono protocolli di aggiornamento che seguono la stessa struttura del DKG iniziale.

Il DKG è implementato in diversi sistemi di produzione. Il client DVT di Ethereum Obol Charon usa una cerimonia DKG basata sul VSS di Pedersen su BLS12-381. Silent Shard di Silence Laboratories usa il DKG per i wallet MPC mobili. La libreria dkg-go implementa GJKR per le applicazioni Go. Threshold Network (in precedenza Keep Network) usa il DKG per il proprio servizio ECDSA a soglia che protegge tBTC su Bitcoin.

Il DKG elimina il dealer fidato facendo generare congiuntamente a tutti gli n partecipanti una coppia di chiavi a soglia, senza che alcun partecipante conosca la chiave privata. Nel DKG di Pedersen, ogni partecipante esegue il VSS sul proprio contributo. GJKR aggiunge la sicurezza contro gli avversari adattivi tramite round di contestazione. Il DKG è alla base del DVT di Ethereum (Obol, SSV), del beacon di casualità DRAND e delle configurazioni di wallet MPC in produzione. I protocolli di aggiornamento estendono la sicurezza randomizzando nuovamente periodicamente le quote.